Firewall "härten"

[Reiter der OPNsense]

Ich strähle gerade meine Firewall-Regeln durch und gleichzeitig bin ich das eine oder andere Gelesene betreffend "Härtung" umzusetzen. Dabei merke ich, dass ich Verständnisschwierigkeiten bezüglich den Floating Rules habe. Vor allem dann, wenn "Direction out" im Spiel ist. Dabei geht es mir ungefähr wie in diesem Thread hier: https://forum.netgate.com/topic/123029/solved-curious-floating-rules-behavior
Die Verunsicherung bleibt auch nach dem Lesen von: https://docs.netgate.com/pfsense/en/latest/book/firewall/floating-rules.html,
weil ich bei eigenen Tests das Verhalten nicht so recht nachvollziehen konnte. Irgendwie scheine ich es nicht so ganz kapiert zu haben.
Wie auch immer, könntet ihr bitte mal meine Konfiguration gemäss Anhang prüfen betreffend:

1. Verhindern, dass RFC 1918 Verkehr das WAN-Interface verlässt, Umsetzung gemäss:
https://docs.netgate.com/pfsense/en/latest/firewall/preventing-rfc1918-traffic-from-exiting-a-wan-interface.html

2. ICMP-Regeln, Umsetzung gemäss:
https://de.wikipedia.org/wiki/Firewall-Regelwerk#ICMP-Regeln

Und dann noch in die Runde gefragt: Habt ihr noch weitere solcher "Härtungs-Tipps" zum Teilen?

[Reiter der OPNsense]

Da der Anhang kaum angesehen wurde, hier noch eine Nachfrage in Textform.

Um das hier umzusetzen:
"ICMP dient im Netzwerk zum Austausch von Fehler- und Informationsmeldungen, kann aber auch für Angriffe im Netzwerk missbraucht werden. Da die rigorose Methode, ICMP entweder ganz zu blockieren oder stets zu erlauben, zu viele Probleme verursachen würde, empfehlen Fachleute, die folgenden Typen freizuschalten:

ICMP Unreachable
ICMP Unreachable, Fragmentation Needed (wird verwendet von Path MTU Discovery)
ICMP Time Exceeded in Transit (TTL expired in transit bei traceroute unter UNIX und tracert unter Windows)
ICMP Echo Request (ausgehend, wird benutzt von Ping)"

Sind folgende Floating-Regeln hierfür stimmig?
Oder muss die Direction in statt any sein?
ICMP Type "ICMP Unreachable, Fragmentation Needed" gibt es in OPNsense nicht, ist in "Destination Unreachable" enthalten, heisst anders, oder…?
Haben diese Regeln überhaupt irgendwelche Auswirkungen? Wie kann man das testen? Ein tracert z. B. funktioniert unabhängig davon, ob ich diese Regeln aktiviert habe oder nicht.

Regel 1
Action: Pass
Quick: check
Interface: all excl. WAN
Direction: any
Protocol: ICMP
ICMP type: Destination Unreachable
Source: any
Destination: RFC 1918
Description: Allow IPv4 ICMP Destination Unreachable on all interfaces excl. WAN

Regel 2
Action: Pass
Quick: check
Interface: all excl. WAN
Direction: any
Protocol: ICMP
ICMP type: Time Exceeded
Source: any
Destination: RFC 1918
Description: Allow IPv4 ICMP Time Exceeded on all interfaces excl. WAN

[JeGr]

Ich finde es immer wieder extrem störend, mit vielen Floating Regeln zu hantieren. Im Fall vom angesprochenen RFC1918 Outbound blocking abgesehen sehe ich keinen Grund, irgendwelche Regeln die sich bspw. auf ICMP beziehen als Floating zu bauen. In der Vergangenheit hat sich das zumindest bei uns oft als fehleranfälliger erwiesen als die auf den entsprechenden Interfaces zu setzen, da es immer wieder zu Überraschungen kommt, was nun gilt, wo das konfiguriert ist und warum was wovor Vorrang hat oder vielleicht doch geht.

Ich sehe einfach keinen Grund Floating zu nutzen. Ja kann man, weil man ggf. faul die gleiche Regel für 3-4 Interfaces machen will. Geht aber genauso die Regel anzulegen, kopieren, Interface ändern, speichern - ist annähernd genauso schnell erledigt ABER gibt keine Fragen auf dem Interface, WAS alles bspw. auf LAN1, 2, 3 etc. konfiguriert ist.

Was ICMP blocking per se angeht, gibt es u.a. für IPv6 ganz klare Spielregeln was auf keinen Fall gedroppt werden darf. Auch für IP4 gibt es einige, die ich auf alle Fälle durchlassen würde (wenn nicht gar komplett, je nach Interface). Ich sehe aber das essentielle Problem nicht, bspw. auf dem WAN bspw. Echo Request, Reply, FragReq, TimeEx etc. (also solche die man aktiv benötigt) zuzulassen und ansonsten von der Innenseite (egress) generell ICMP zuzulassen. Ist ja im Normalfall nicht so, als würde ich meinen Netzen mißtrauen und müsste mich gegen die verteidigen? Daher wäre ICMP Blocking eh nur auf den WANs effektiv sinnvoll (information leakage protection oder potentieller Angriff) und da gibts Spielregeln, die man einhalten sollte:

http://shouldiblockicmp.com/
https://tools.ietf.org/html/rfc4890#section-4.3

Gerade letzterer sollte genau gelesen werden, was absolut nicht geblockt werden DARF, nicht sollte und was man weghauen kann.

Grüße

[chemlud]

Bei meinen Mininetzen geht seit Jahren kein ICMP,  nicht rein nicht raus. Bisher ist die Welt nicht untergegangen...

Würde ich im privaten Bereich grundsätzlich so machen, es sei denn, der Samsung-TV muss dringend irgendwohin leaken, damit er funktioniert.

[Reiter der OPNsense]

Danke, @JeGr

Ich finde Floating Regeln sehr praktisch, vor allem wenn sehr viele Interfaces im Spiel sind. Und vor allem was jene Regeln betrifft, die auf allen Interfaces greifen sollen und identisch sind. Gerade beim masseweisen Klonen von Regeln sind mir auch schon Flüchtigkeitsfehler passiert. Und ja du hast mich ertappt, ich gehöre wohl eher zur faulen Sorte was das betrifft.

Bis jetzt hatte ich ICMP immer auf allen Interfaces ausser auf WAN komplett freigeschaltet. Warum ich das nun ändern will ist nicht aus Sicherheitsbedenken. In meinen kleinen Netzen kann ich auch kein konkretes Angriffsszenario erkennen. Ich denke das Thema ist vor allem in grossen Netzen mit vielen Benutzern interessant. Mir geht es hier primär darum zu lernen was alles so hinter ICMP steckt und ums Begreifen wie man das auf der OPNsense umsetzt.

Die Empfehlungen deiner und meiner Quellen decken sich glaub so in etwa, aber ich habe das noch nicht im Detail verglichen.

Begriffen habe ich das Ganze eh noch nicht. Im Moment habe ich nur noch die Regeln mit Echo Request auf Interfaceebene aktiv. Ping und tracert funktionieren trotzdem, auch wenn ich nirgends "Echo Reply" und "Time Exceeded" aktiviert habe. Verstehe ich hier irgendetwas komplett falsch?

Immerhin konnte ich inzwischen nachvollziehen was passiert, wenn man bezüglich IPv6 "Router Advertisement" und "Router Solicitation" blockt. Das verhindert z. B. die DHCPv6 Static Mappings.
Was mir hier noch nicht klar ist:
Auf der Seite http://shouldiblockicmp.com/ ist die Rede von:
Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)
OPNsense scheint nur die ersten beiden Typen zu unterstützen oder ist der Rest in diesen beiden zusammengefasst?

[JeGr]

> Bei meinen Mininetzen geht seit Jahren kein ICMP,  nicht rein nicht raus. Bisher ist die Welt nicht untergegangen...

Nein, das sind aber die, die am lautesten schreien, wenn irgendwo die Performance auf Interfaces mies ist und nach Stunden des Debuggens rauskommt, dass die MTU schuld ist - PATH MTU Discovery läuft BTW auch über ICMP... Nicht das erste Mal gesehen. Dito mit congestion warnings etc. aber Hauptsache die Firewall ist "stealthy" und total protected... *facepalm*

> primär darum zu lernen was alles so hinter ICMP steckt und ums Begreifen wie man das auf der OPNsense umsetzt.

Durchaus gut und verständlich, gerade dann aber trotzdem der Punkt: wenn du kein Angriffsszenario siehst, in dem ICMP intern bei dir eine Rolle spielt, sehe ich keinen Grund ICMP intern überhaupt zu blocken. Und die Status Meldungen rauszusenden wenn sie benötigt werden (congestion, PathMTU etc.) ist m.E. auch nichts dramatisches. Dass man auf dem WAN eingehend filtert, klar warum nicht. Was man hier durchlassen kann und was nicht, steht ja unter anderem bei den Links mit bei.

> auch wenn ich nirgends "Echo Reply" und "Time Exceeded" aktiviert habe. Verstehe ich hier irgendetwas komplett falsch?

Offenbar ja Echo Reply musst du aktiv eigentlich nicht öffnen, wenn du inbound "echo request" reinlässt. Der "PF" kennt bei icmp "stateful", auch wenn es das Protokoll eigentlich nicht kann und lässt somit automatisch "replys" raus wenn ein "request" eingehend erlaubt wurde. Ansonsten müsstest du wie bei pf klassisch bei jedem Interface konfigurieren was rein und raus darf, also bspw. request eingehend auf WAN, reply ausgehend auf WAN. Das wäre aber noch komplexer, deshalb kann PF und die Sense Oberflächen das etwas einfacher. Time Exceeded tritt bei nem normalen Ping ja eigentlich eher selten auf.

> Immerhin konnte ich inzwischen nachvollziehen was passiert, wenn man bezüglich IPv6 "Router Advertisement" und "Router Solicitation" blockt. Das verhindert z. B. die DHCPv6 Static Mappings.

Nicht nur static mappings, sondern auch so ziemlich jedes weitere Routing und Routing-Zuweisung in diesem Netz. Also keine Prefix Delegation etc. mehr, aber korrekt, es macht IPv6 kaputt

> OPNsense scheint nur die ersten beiden Typen zu unterstützen oder ist der Rest in diesen beiden zusammengefasst?

Nein, das sind alles einzelne Flags (siehe Type Codes), aber du hast recht, war mir nicht aufgefallen, OPNsense unterscheidet hier leider in der Auswahl bei IPv4 und IPv6 überhaupt nicht nach Typen. Im Unterschied dazu ist der ICMP Subtypes Dialog der pfSense bspw. abhängig davon ob man IPv4 oder IPv6 (oder beides) auswählt und nur die Flags sichtbar, die sich auf das Protokoll beziehen. RS, RA, NS, NA sind ja v6 only Typen, Redirect gibt es bei v4 und v6.

Das wäre ggf. ein Fall für ein Feature Request bzw. Bugreport, dass hier die Oberfläche überhaupt nicht unterscheidet zwischen 4 und 6, sondern immer alle ihr bekannten Typen (und dazu etwas wenige) anbietet. Ich habe das gerade bei 19.1 und 19.7dev nachgesehen, beide zeigen egal ob IPv4 oder IPv6 bei ICMP stets die gleichen Typen.

Grüße

[chemlud]

Afaik kann ich die MTU auch von Hand testen. Schon gemacht. Alles in Ordnung. Für zwei interne (!) Interfaces, beide an der selben sense sollte doch bitte schön die MTU kein Problem sein. Oder?

 

[JeGr]

Es geht doch nicht darum, dass DU intern das prüfst, sondern dass draußen ein System dir sowas schickt, weil sie einen Engpass haben, es wegen seltsamem Routing dazwischen ein MTU Problem gibt, dass sich von außen jemand per VPN über ne doofe Verbindung einwählt etc. drekct. Wenn du nur dein eigenes kleines Universum siehst, wird sich da natürlich nicht viel tun. Aber dann schaut man eben auch immer nur bis zum Tellerrand.

[chemlud]

Genau, denn dort hören meine Probleme mit IT auch auf und ich muss Geld verdienen. Mit IT nur als Werchzeug, nicht mehr, nicht weniger.

[Reiter der OPNsense]

wenn du kein Angriffsszenario siehst, in dem ICMP intern bei dir eine Rolle spielt, sehe ich keinen Grund ICMP intern überhaupt zu blocken.

Wie gesagt, ich mach das primär aus Lerngründen. Aber spricht aus Deiner Sicht etwas gegen einen generellen Kompromiss zwischen "nur was gebraucht wird" und "alles offen"? Das ist ja auch das Credo in den von uns verlinkten Artikeln.

Dass man auf dem WAN eingehend filtert, klar warum nicht. Was man hier durchlassen kann und was nicht, steht ja unter anderem bei den Links mit bei.

Ja, da scheint mir dein zweiter Link sehr hilfreich, zumindest was IPv6 betrifft. Vielen Dank hierfür.
"Recommendations for ICMPv6 Transit Traffic" ist erst dann ein Thema, wenn Services von aussen her erreichbar sind (z. B. Mailserver) oder generell auch für den Verkehr von Clients ins Internet? Umsetzen kann man das momentan auf der Sense sowieso nicht, da fehlen zu viele ICMP Typen in der Auswahl. Ich frage mich, ob vielleicht gewisse Dinge standardmässig durchgelassen werden. Auf die Schnelle habe ich nichts in die Richtung gefunden.
Und wie verhält es sich bei IPv4 auf dem WAN-Interface? Ist da die Freigabe von gewissen ICMP-Typen wichtig? Das ist mir nach dem Lesen all dieser Artikel noch nicht klar.

Der "PF" kennt bei icmp "stateful", auch wenn es das Protokoll eigentlich nicht kann und lässt somit automatisch "replys" raus wenn ein "request" eingehend erlaubt wurde.

Pure Magie! Danke fürs Bretter entfernen.

Time Exceeded tritt bei nem normalen Ping ja eigentlich eher selten auf.

Ist es nicht so, dass wenn ich ICMP Time Exceeded blocke, ein Traceroute nicht funktionieren dürfte?

OPNsense unterscheidet hier leider in der Auswahl bei IPv4 und IPv6 überhaupt nicht nach Typen.

Oh, huch, man kann sogar unsinnige Kombinationen speichern.

Das wäre ggf. ein Fall für ein Feature Request bzw. Bugreport, dass hier die Oberfläche überhaupt nicht unterscheidet zwischen 4 und 6, sondern immer alle ihr bekannten Typen (und dazu etwas wenige) anbietet.

Unbedingt. Vielleicht wäre es zudem sinnvoll, zusätzlich zu den Bezeichnungen, auch noch (Type x, Code y) anzuzeigen. Und wie wäre es, wenn man mehrere Typen in einer Regel selektieren/zusammenfassen könnte?

[JeGr]

> Genau, denn dort hören meine Probleme mit IT auch auf und ich muss Geld verdienen. Mit IT nur als Werchzeug, nicht mehr, nicht weniger.

Darum ist es auch schwer, auf dem WAN "reply, timex, squench, unreach" als ICMP types freizugeben? Tja nun. Einmauern hat historisch auch immer gut geklappt

> Aber spricht aus Deiner Sicht etwas gegen einen generellen Kompromiss zwischen "nur was gebraucht wird" und "alles offen"?

Warum Kompromiss? Von außen mit v4 echoreq, timex, squench, unreach aufmachen IST ja "was gebraucht wird". Mehr brauchts nicht. Intern dann ggf. alles (oder viel) aufzumachen sehe ich als kein Problem an, interne Netze überwache ich. Wo wäre da jetzt der Kompromiss? Gegenüber gar nicht aufmachen? Wer ICMP ignoriert hat ganz andere Probleme.

> Ich frage mich, ob vielleicht gewisse Dinge standardmässig durchgelassen werden. Auf die Schnelle habe ich nichts in die Richtung gefunden.

Da musst du auch genau lesen, welche Richtung da gemeint ist, ob das als intiale Pakete oder als Antworten gemeint sind. Bei http://shouldiblockicmp.com/ bspw. ebenso. Der NDP & SLAAC Absatz dort ist z.B. überhaupt nicht über Routing Grenzen gemeint, sondern innerhalb des Netzsegments. Macht ja Sinn, denn sonst sägt man sich NDP, SLAAC, DHCP6 etc. ab. Redirects vom WAN bspw. will man IMHO auch eher weniger haben Genauso Echo Replys, die sind ja in den Sensen schon default erlaubt, weil man mit pf "stateful" ICMP konfiguriert.

>> Time Exceeded tritt bei nem normalen Ping ja eigentlich eher selten auf.
> Ist es nicht so, dass wenn ich ICMP Time Exceeded blocke, ein Traceroute nicht funktionieren dürfte?

Mein Fehler, natürlich beim Traceroute bei der TTL. Genau, deshalb "timex" von außen erlaubt.

> Oh, huch, man kann sogar unsinnige Kombinationen speichern.

leider ja.

> Unbedingt. Vielleicht wäre es zudem sinnvoll, zusätzlich zu den Bezeichnungen, auch noch (Type x, Code y) anzuzeigen. Und wie wäre es, wenn man mehrere Typen in einer Regel selektieren/zusammenfassen könnte?

Würde es nicht zu kompliziert fassen, aber vielleicht sollte man sich da mal am Cousin pfSense orientieren. Dort wird nach IP4/6 unterschieden und man kann unterschiedliche Typen nach Protokoll auswählen (und mehr als bei OPNsense).
Und man kann mehrere auswählen, die dann in der Regel auch angezeigt werden. Leider sieht man bei den OPNsense Rules nicht, dass und welcher ICMP Type überhaupt konfiguriert ist (erst bei Mouseover über "ICMP").


Wichtig ist wie gesagt eher, dass man genau liest, ob das Antworten sind (was man im Normalfall nicht explizit freigeben muss), oder ob es wirklich Requests sind die beantwortet werden und daher freigeschaltet werden sollten

[chemlud]

Darum ist es auch schwer, auf dem WAN "reply, timex, squench, unreach" als ICMP types freizugeben? Tja nun. Einmauern hat historisch auch immer gut geklappt

Ohwei, wer bezahlt dich, dass du dir solche Albernheiten ausdenkst? Ich bin raus.

[JeGr]

> Ohwei, wer bezahlt dich, dass du dir solche Albernheiten ausdenkst? Ich bin raus.

Genau, wenns mit den eigenen verschrobenen Ansichten nicht mehr passt, packt man Whataboutism aus oder der andere ist mal wieder von irgendeiner Firma bezahlt oder sonstwie ein Bot. Klarer Fall. Zu viel bei der Politik gerade "abgeschaut"?

Anyway, that bullshit aside

> Wie gesagt, ich mach das primär aus Lerngründen. Aber spricht aus Deiner Sicht etwas gegen einen generellen Kompromiss zwischen "nur was gebraucht wird" und "alles offen"?

Um nochmal auf die Frage zurückzukommen: was gebraucht wird bzw. sinnvoll ist aus Netzwerk(er)sicht, sollte auch offen sein. Ansonsten braucht man nicht jammern, wenns klemmt oder man macht unnötig anderen das Leben schwer. Egoistisch arbeiten mag zwar für einen selbst cool sein, das erste Mal wenn man auf der anderen Seite sitzt, wird man aber merken wie bescheuert das ist. Wir hatten solch ein Phänomen schon, bei dem es letztendlich das Problem an einen Dienstleister des Kunden zurückgegeben wurde der sich beschwehrte, dass Verbindungen (nur von ihnen kommend) Mist waren. Mit Packet Capturing hat man dann einen Salat aus Fragmentierung, MTU Drama und sonstigem gemessen, aber nach korrekter Einstellung der Sense (diese hat entsprechende Meldungen empfangen bzw. selbst gesendet) wurde die beim Empfänger einfach wohl stillschweigend gedroppt. Die Clients dahinter haben sich zumindest nie auf andere geforderte Rahmengrößen verständigt. Aber weil große Firma und "wir machen alles richtig und droppen alles" Attitüde wurde das nicht gefixt und der Kunde ständig dafür angegangen. Mit dem Capture haben wir es belegen und dokumentieren können.

Kommt also nicht nur theoretisch vor, sondern durchaus auch mal in der Praxis.

[Reiter der OPNsense]

> Warum Kompromiss? Von außen mit v4 echoreq, timex, squench, unreach aufmachen IST ja "was gebraucht wird". Mehr brauchts nicht. Intern dann ggf. alles (oder viel) aufzumachen sehe ich als kein Problem an [ ]

Ich glaube ich hab’s jetzt begriffen (bitte nicht hauen und nicht lachen, ich sehe mich immer noch als Netzwerkanfänger): Bei den Empfehlungen in all den verlinkten Artikeln geht es immer nur um die Schnittstelle zwischen internem und externem Netz. Beim BSI ist das schön verständlich beschrieben, finde ich:
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m05/m05120.html

In diesem Artikel wird für öffentliche Server in der DMZ ebenfalls Source Quench (Typ 4) ankommend zulassen empfohlen. Gemäss Wikipedia (und OPNsens-WebGUI) ist das veraltet.
"Since research suggested that "ICMP Source Quench [was] an ineffective (and unfair) antidote for congestion",[9] routers' creation of source quench messages was deprecated in 1995 by RFC 1812. Furthermore, forwarding of and any kind of reaction to (flow control actions) source quench messages was deprecated from 2012 by RFC 6633."
Quelle: https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Source_quench

>>> Time Exceeded tritt bei nem normalen Ping ja eigentlich eher selten auf.
>> Ist es nicht so, dass wenn ich ICMP Time Exceeded blocke, ein Traceroute nicht funktionieren dürfte?
>Mein Fehler, natürlich beim Traceroute bei der TTL. Genau, deshalb "timex" von außen erlaubt.

Ich war/bin verwirrt, weil ein Traceroute intern funktioniert (Host von einem VLAN auf Host in einem anderen VLAN), auch wenn ich ICMP Time Exceeded zu Testzwecken explizit blocke. Darum auch ich die Frage, ob die Sense standardmässig gewisse Dinge durchlässt. Allerdings sollte sie das ja spätestens bei einem expliziten Block nicht mehr tun, vermute ich jetzt mal.

[JeGr]

> Ich glaube ich hab’s jetzt begriffen (bitte nicht hauen und nicht lachen, ich sehe mich immer noch als Netzwerkanfänger)

da haut dich auch keiner für Und wenn dir die BSI Liste hilft es besser zu greifen umso besser.

> ist das veraltet.

Durchaus richtig, deshalb auch "kann" man machen. Ist aber nicht zwingend.

> auch wenn ich ICMP Time Exceeded zu Testzwecken explizit blocke. Darum auch ich die Frage, ob die Sense standardmässig gewisse Dinge durchlässt

Nein standardmäßig nicht, aber ich kenne auch deine sonstigen Regeln nicht. Da intern ICMP filtern wenig sinnvoll ist (zumindest wenn dir alles gehört), habe ich das von LAN auf LAN nicht betrachtet
Allerdings gibt es ggf. auch bei Traceroutes oder MTRs noch Möglichkeiten via UDP, evtl. kommt das daher.

Daher restriktiv vom WAN: echoreq, timex, unreach erlauben bei v4. echoreq, timex, unreach, toobig bei v6 erlauben sollte an der Stelle völlig entspannt möglich sein und damit auch Kollegen drin wie draußen das Leben erleichtern.

Grüße