OPNsense Forum

International Forums => German - Deutsch => Topic started by: Reiter der OPNsense on March 14, 2019, 01:58:20 pm

Title: Firewall "härten"
Post by: Reiter der OPNsense on March 14, 2019, 01:58:20 pm
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?
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on March 19, 2019, 07:21:57 pm
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
Title: Re: Firewall "härten"
Post by: JeGr on March 20, 2019, 05:10:59 pm
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
Title: Re: Firewall "härten"
Post by: chemlud on March 20, 2019, 06:54:17 pm
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.
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on March 20, 2019, 09:43:23 pm
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?
Title: Re: Firewall "härten"
Post by: JeGr on March 21, 2019, 10:47:38 am
> 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
Title: Re: Firewall "härten"
Post by: chemlud on March 21, 2019, 02:08:14 pm
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?

 
Title: Re: Firewall "härten"
Post by: JeGr on March 21, 2019, 04:09:46 pm
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. :)
Title: Re: Firewall "härten"
Post by: chemlud on March 21, 2019, 04:45:03 pm
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.
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on March 21, 2019, 05:05:24 pm
Quote
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.

Quote
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.

Quote
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. :)

Quote
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?

Quote
OPNsense unterscheidet hier leider in der Auswahl bei IPv4 und IPv6 überhaupt nicht nach Typen.
Oh, huch, man kann sogar unsinnige Kombinationen speichern.

Quote
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?
Title: Re: Firewall "härten"
Post by: JeGr on March 22, 2019, 11:57:08 am
> 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 :)
Title: Re: Firewall "härten"
Post by: chemlud on March 22, 2019, 03:03:47 pm
Quote from: JeGr on March 22, 2019, 11:57:08 am

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.
Title: Re: Firewall "härten"
Post by: JeGr on March 25, 2019, 01:32:53 pm
> 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"? :D

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. :)
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on March 26, 2019, 11:53:17 am
> 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.
Title: Re: Firewall "härten"
Post by: JeGr on March 26, 2019, 02:41:49 pm
> 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

Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on March 26, 2019, 06:42:30 pm
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.
Title: Re: Firewall "härten"
Post by: JeGr on March 27, 2019, 02:12:39 pm
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.
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on March 27, 2019, 03:05:04 pm
> 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?
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on March 27, 2019, 03:20:54 pm
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. :(
Title: Re: Firewall "härten"
Post by: chemlud on March 29, 2019, 04:25:31 pm
Quote from: Reiter der OPNsense on March 27, 2019, 03:20:54 pm
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
Title: Re: Firewall "härten"
Post by: JeGr on March 29, 2019, 04:27:21 pm
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! :D Na? Für wen arbeite ich heute? Reptiloiden? ;D

> 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.
Title: Re: Firewall "härten"
Post by: JeGr on March 29, 2019, 04:35:57 pm
> 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."

Title: Re: Firewall "härten"
Post by: rolfd on March 30, 2019, 04:33:39 am
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!
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on April 01, 2019, 04:46:26 pm
Ich versuche mich mal mit folgender Zusammenfassung:
Habt ihr Einwände oder Ergänzungen?
Title: Re: Firewall "härten"
Post by: JeGr on April 03, 2019, 10:08:29 am
> 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.
Title: Re: Firewall "härten"
Post by: Reiter der OPNsense on April 07, 2019, 11:51:09 am
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)"
Title: Re: Firewall "härten"
Post by: JeGr on April 23, 2019, 05:00:40 pm
> 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 :)