Firewall "härten"

[Reiter der OPNsense]

Vielen Dank, soweit begriffen. Sind folgende Regeln für die Umsetzung korrekt? Nur mal IPv4.

Pass,	WAN,	IPv4,	ICMP,	Destination Unreachable,	Source: any,	Destination: any*
Pass,	WAN,	IPv4,	ICMP,	Time Exceeded,	Source: any,	Destination: any*

*Oder Destination irgendwie einschränken?

Pass,	LAN,	IPv4,	ICMP,	Echo request,	Source: LAN net,	Destination: LAN address
Block,	LAN,	IPv4,	ICMP,	Echo request,	Source: LAN net,	Destination: RFC 1918*
Pass,	LAN,	IPv4,	ICMP,	any,	Source: LAN net,	Destination: RFC 1918
Pass,	LAN,	IPv4,	ICMP,	Echo request,	Source: LAN net,	Destination: ! RFC 1918
Pass,	LAN,	IPv4,	ICMP,	Destination Unreachable,	Source: LAN net,	Destination: ! RFC 1918
Pass,	LAN,	IPv4,	ICMP,	Time Exceeded,	Source: LAN net,	Destination: ! RFC 1918

*Sofern ich nicht will, dass lokal alles überallhin pingen kann.

[JeGr]

Auf dem WAN würde ich Echo Request noch erlauben. Destination any würde nur etwas bringen, wenn du public IPs bspw. in einer DMZ oder so noch hättest, ansonsten würde ich das auf WAN Address oder This Firewall einschränken.

Auf dem LAN: wenn du vorher explizit RFC1918 wegfilters durch Blocks und Passes, kannst du dahinter eigentlich "any" nutzen, das !RFC1918 kann auch manchmal recht seltsame Blüten treiben.

[Reiter der OPNsense]

> Auf dem WAN würde ich Echo Request noch erlauben.

Für welchen Verwendungszweck? Die einzige Idee, die mir in den Sinn kommt, ist dass ich auf dem WAN-Interface nach Innen Pingen könnte und das will/brauch ich eigentlich nicht?

> Destination any würde nur etwas bringen, wenn du public IPs bspw. in einer DMZ oder so noch hättest, ansonsten würde ich das auf WAN Address oder This Firewall einschränken.

"Normale Rechner" im Netz profitieren davon nicht? Ich bin unsicher wie das BSI das genau meint. Eigentlich habe ich das so interpretiert, dass man Typ 3 und 11 komplett auf alle Rechner durchlassen darf/soll.

> Auf dem LAN: wenn du vorher explizit RFC1918 wegfilters durch Blocks und Passes, kannst du dahinter eigentlich "any" nutzen

Sorry, aber ich verstehe nicht was du meinst. Gibt es eine elegantere/bessere Lösung?

[Reiter der OPNsense]

Oh, ich bin jetzt gerade noch über diesen Thread hier gestolpert:
https://forum.opnsense.org/index.php?topic=8736.msg38955#msg38955

Wenn ich das richtig verstanden habe und die Analyse von @indyspeed stimmt, dann sind zumindest meine abgehenden Regeln eh für die Katz.

[chemlud]

Oh, ich bin jetzt gerade noch über diesen Thread hier gestolpert:
https://forum.opnsense.org/index.php?topic=8736.msg38955#msg38955

Wenn ich das richtig verstanden habe und die Analyse von @indyspeed stimmt, dann sind zumindest meine abgehenden Regeln eh für die Katz.

Seeehr cool! Hatte ich noch gar nicht gesehen. Passt genau in meine Ansichten zu diesem ICMP Quatsch. Jaja, ich mache das Internet kaputt, weiß schon.... :-D

[JeGr]

Das ist nur eine Mutmaßung. Ich habe noch nichts gelesen, was dazu Details liefert Kein einziger Entwickler hat dazu Feedback gegeben.
@Chemlud: Genau du bist raus - ach nee da passt was in dein Weltbild und schwupp ist er wieder da! Na? Für wen arbeite ich heute? Reptiloiden?

> Für welchen Verwendungszweck? Die einzige Idee, die mir in den Sinn kommt, ist dass ich auf dem WAN-Interface nach Innen Pingen könnte und das will/brauch ich eigentlich nicht?

Das hat doch nichts mit WAN darf Reply beantworten zu tun. Es macht nur überhaupt keinen Sinn - auch für Debugging - Ping Requests zu blocken. Früher hat man solchen BS als "Security" verkauft, Stealth oder Unsichtbar weil die FW keine Pings beantwortet. Totaler Quark, man kann es trotzdem sehen, dass da ein Gerät ist das blockt. Daher gibt es keinen sinnvollen Grund es zu blocken, es hilft aber ggf. bei z.B. VPN Debugging zu sehen "aha meine Sense antwortet und ist da".

> "Normale Rechner" im Netz profitieren davon nicht? Ich bin unsicher wie das BSI das genau meint. Eigentlich habe ich das so interpretiert, dass man Typ 3 und 11 komplett auf alle Rechner durchlassen darf/soll.

Wie sollen die denn davon profitieren? Wir reden von Ping vom Internet aus. Du _kannst_ aus dem Internet deine PCs doch überhaupt nicht adressieren, da du nur eine einzelne IP4 hast, auf die geNATtet wird. Wie sollst du also von außen auf deine PCs pingen? Das funktioniert ggf. bei IP6 aber bei IP4 und NAT nicht.

> Sorry, aber ich verstehe nicht was du meinst. Gibt es eine elegantere/bessere Lösung?

Logik: wenn vorher mittels Block/Reject explizit mit Destination RFC1918 alles weggeblockt wird, macht es bei der darauf folgenden Regel keinen Sinn mehr !RFC1918 zu nutzen. Dann kannst du auch ANY nehmen - was zu weniger Mißverständnissen führt - da RFC1918 schon weggefiltert ist und somit eh nur noch der komplette public-IP4-space über bleibt. Simple Subtraktion. Und es gab schon einige Problemchen, bei denen NOT (!) Regeln nicht wie erwartet funktioniert hatten, deshalb vermeide ich persönlich das gern damit es klar verständlich bleibt.

[JeGr]

> Oh, ich bin jetzt gerade noch über diesen Thread hier gestolpert:
https://forum.opnsense.org/index.php?topic=8736.msg38955#msg38955

BTW: In dem Post lese ich Outbound Filtering. Nicht spezifisch LAN->WAN, sondern outbound und darauf bezieht sich die PF Manpage: Dass bei einer erlaubten bspw. TCP HTTPS Verbindung mit "Keep State" ein zurückkommendes(!) (weil Verbindung doof) ICMP Source Quench Paket auf die Verbindung gematcht und an den PC/Host weitergeleitet wird, damit er Bescheid bekommt, DASS es bei dieser Verbindung ein Problem gibt. Da geht es nicht um ICMP Pakete die VOM LAN weggehend geschickt werden, sondern um Verbindungsinfos, die reinkommen und zu einer vorhandenen TCP Verbindung bspw. gehören. Genau über sowas wird ja im BSI Paper gesprochen, dass Status und Zutandsmeldungen via ICMP zu einer Verbindung bitte nicht geblockt werden sollen, zum Teil übernimmt das in PF eben schon das "keep state" bei einigen Verbindungen. Zumindest liest sich

https://www.openbsd.org/faq/pf/filter.html:
"Another advantage of keeping state is that corresponding ICMP traffic will be passed through the firewall. For example, if a TCP connection passing through the firewall is being tracked statefully and an ICMP source-quench message referring to this TCP connection arrives, it will be matched to the appropriate state entry and passed through the firewall."

[rolfd]

Meiner Meinung nach ist es Job des IP Stacks... respektive des Betriebssystems ... mit ICMP korrekt umzugehen und nicht einer Firewall. Es mag funktionieren, kurzfristig einen FW-Filter zu setzen wenn an einem aktuellen Angriffsscenario per ICMP beteiligt wäre und mit einem ICMP Filter die Situation entschärft werden kann. Pingofdeath scheint damals sowas gewesen zu sein. Aber daraus abzuleiten, es würde immer helfen wenn man ICMP an der FW WAN oder LAN seitig im vorraus verrammelt ... ist humbug! Man schafft sich nur deutlich mehr Probleme als sein muss - wie auch der Thread zeigt.
Wäre dein System so relevant wie DNS Rootserver oder zentraler Multiport Router für ein Netzwerk mit 10000 Clients, würde ich mal anfangen über ICMP nachzudenken aber 99,9% der User hier sind einfache mini-netze mit ipv4 NAT oder ein paar dynamischen SLAAC ipv6 Clients.
Das einzige was für euch im normalfall relevant ist, ist zu verhindern das sich in eurem Netz ein Botnet über Viren/Trojaner breit macht oder ein open Proxy entsteht. Und das hat mit icmp mal rein garnichts zu tun!
Und guckt nicht so viele IT-Katastrophen- und Hackerfilme auf NTV oder WELT... 90% davon ist auch Schwachsinn!

[Reiter der OPNsense]

Ich versuche mich mal mit folgender Zusammenfassung:

• Man muss sich bei der Sense nicht um ICMP-Firewallregeln kümmern, weil sich das "state keeping" um alles Nötige kümmert. (Erlaubte, aufbauende Verbindungen erhalten allfällige ICMP-Antworten in jedem Fall.)
• Einzige Ausnahmen sind "Echo request" zulassen, wenn ein Interface oder etwas in einem Netz pingbar sein soll und "ICMPv6 Router Advertisement" + "ICMPv6 Router Solicitation" zulassen, wenn IPv6 im Einsatz ist.
• Die generelle Empfehlung (u. A. vom BSI) "ICMP redirect" ausgehend zu blocken, wird von der Sense per "tunables" umgesetzt. (Allerdings erst ab 19.1.3: https://forum.opnsense.org/index.php?topic=11941.msg54462#msg54462
  Ich musste unter System: Settings: Tunables noch auf Default klicken, damit dieses tunable angezeigt wurde.)
  
• ICMP kann per Firewallregeln nicht geblockt werden.

Habt ihr Einwände oder Ergänzungen?

[JeGr]

> Man muss sich bei der Sense nicht um ICMP-Firewallregeln kümmern, weil sich das "state keeping" um alles Nötige kümmert. (Erlaubte, aufbauende Verbindungen erhalten allfällige ICMP-Antworten in jedem Fall.)

Das ist aber schon wieder zu generell ausgedrückt. Man muss sich nicht um ICMP AUSgehend auf Interfaces kümmern (also es aus der Firewall rauszulassen). Um das REINlassen schon! Ohne dass du irgendwo eine "ICMP allow irgendwas" Regel hast, geht da nichts, da Default des PF Filters in jeder Sense "block quick log any" ist.

> Einzige Ausnahmen sind "Echo request" zulassen, wenn ein Interface oder etwas in einem Netz pingbar sein soll und "ICMPv6 Router Advertisement" + "ICMPv6 Router Solicitation" zulassen, wenn IPv6 im Einsatz ist.

ICMP generell muss wie gesagt erlaubt werden, sonst geht es nicht. ICMP6 RA/RS sollte bei aktivem Interface auf LANs eh erlaubt sein, auf dem WAN kommt es darauf an, ob ggf. vorgeschaltet noch ein weiterer Router steht.

> Die generelle Empfehlung (u. A. vom BSI) "ICMP redirect" ausgehend zu blocken

Wie gesagt, per default blockt die Sense eh alles, somit muss sie auch initial erstmal nichts tun. Ob und was man erlaubt steuert man ja selbst. Dass es eine spezifische Sonderbehandlung von Redirect gibt, liegt an einem Security Fix den es diesbezüglich gab (m.W.)

> ICMP kann per Firewallregeln nicht geblockt werden.

DOCH. Warum sollte das nicht gehen? *seufz*

Nochmal: Was von ICMP erlaubt wird, steuerst DU. Der von dir zitierte Bericht bezog sich - und so lese ich auch die Manpage von OpenBSDs PF - nur auf ICMP Antworten(!) auf vorhandene TCP/UDP Verbindungen. Das hat nichts mit "normalen" ICMP Anfragen zu tun, die von irgendwo initiiert werden wie bspw. ein Ping Request oder ein Traceroute.

[Reiter der OPNsense]

Jetzt wo ich meine Zusammenfassung nochmals lese: ja, ist ziemlich verworren das Ganze. Sorry, dass ich dich zum Seufzen bringe, JeGr. Und ein herzliches Dankeschön für deine Zeit und Geduld.

Schwamm drüber und aus die Maus mit "härten". Rein nach dem Motto:
"Historically, ICMP has a bad reputation but it is generally beneficial and does not deserve the reputation on modern networks. Allowing an ICMP type of any is typically acceptable when allowing ICMP."
https://docs.netgate.com/pfsense/en/latest/book/firewall/configuring-firewall-rules.html

Und falls noch andere ICMP-Noobs wie ich hier mitlesen und eine Vorlage wünschen, hier bitte sehr:
Ich mach das jetzt so wie seit eh und je plus neu lasse ich auf dem WAN-Interface gewisse ICMP-Typen rein:

ICMP+ICMPv6-LAN-Regeln

Pass,	LAN,	IPv4,	ICMP,	Echo Request,	Source: LAN net,	Destination: LAN address *1
Block,	LAN,	IPv4,	ICMP,	Echo Request,	Source: LAN net,	Destination: RFC 1918 *1
Block,	LAN,	IPv6,	ICMP,	Echo Request,	Source: LAN net,	Destination: RFC 1918 *1
Pass,	LAN,	IPv4+6,	ICMP,	any,	Source: LAN net,	Destination: any

ICMP-WAN-Regeln

Pass,	WAN,	IPv4,	ICMP,	Echo Request,	Source: any,	Destination: WAN address
Pass,	WAN,	IPv4,	ICMP,	Destination Unreachable,	Source: any,	Destination: WAN address *2
Pass,	WAN,	IPv4,	ICMP,	Time Exceeded,	Source: any,	Destination: WAN address *2

ICMPv6-WAN-Regeln gem. https://tools.ietf.org/html/rfc4890#section-4.3

Pass,	WAN,	IPv6,	ICMP,	Destination Unreachable,	Source: any,	Destination: WAN address *2
Pass,	WAN,	IPv6,	ICMP,	Packet Too Big,	Source: any,	Destination: WAN address *3
Pass,	WAN,	IPv6,	ICMP,	Time Exceeded,	Source: any,	Destination: WAN address *2
Pass,	WAN,	IPv6,	ICMP,	Parameter Problem,	Source: any,	Destination: WAN address *2
Pass,	WAN,	IPv6,	ICMP,	Echo Request,	Source: any,	Destination: WAN address
Pass,	WAN,	IPv6,	ICMP,	Echo Reply,	Source: any,	Destination: WAN address *2

*1) Sofern man nicht will, dass lokal alles überallhin pingen kann, z. B. im Gästenetz und in der DMZ.

*2) Ob diese Regeln nötig sind oder durch das "state keeping" abgedeckt sind, kann ich immer noch nicht abschätzen. Zumindest die ICMPv6-Echo-Reply-Regel dürfte nicht viel bringen.
Beispielsweise ein IPv6-Test mit http://ipv6-test.com/ ergibt auch nur mit zugelassenem Echo Request die volle Punktzahl.

*3) Bei den ICMPv6-WAN-Regeln würde noch Packet Too Big (Type 2) dazu gehören, aber das steht bei OPNsense momentan nicht zur Verfügung. Das dürfte aber nicht tragisch sein, denn Type 2 (wie auch Type 1 Destination Unreachable) ist standardmässig frei gegeben, sofern ich die erste der folgenden Regeln richtig interpretiere:

Code: [Select]

root@OPNsense:~ # cat /tmp/rules.debug | grep ipv6-icmp
pass in log quick inet6 proto ipv6-icmp from {any} to {any} icmp6-type {1,2,135,136} keep state label "IPv6 requirements (ICMP)"
pass out log quick inet6 proto ipv6-icmp from {(self)} to {fe80::/10,ff02::/16} icmp6-type {129,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {fe80::/10} to {fe80::/10,ff02::/16} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"
pass in log quick inet6 proto ipv6-icmp from {ff02::/16} to {fe80::/10} icmp6-type {128,133,134,135,136} keep state label "IPv6 requirements (ICMP)"

[JeGr]

> Jetzt wo ich meine Zusammenfassung nochmals lese: ja, ist ziemlich verworren das Ganze. Sorry, dass ich dich zum Seufzen bringe, JeGr. Und ein herzliches Dankeschön für deine Zeit und Geduld.

Gehört dazu

Und das Thema per se ist ja auch nicht aus der Luft gegriffen. Ich filtere bei unserem DC auch ICMP aber eben nur das "nötige" bzw. was wirklich unnötig ist einfach weil wir schon Fälle hatten, bei denen durch hartes "hauen wir alles weg" Probleme entstanden. Daher: alles gut