egress Filter Evaluation

[ole]

Hello OPNsense Freunde,

wie werden die Regeln für egress Filtering bzgl. Reihenfolge angewandt? Die Doku (https://docs.netgate.com/pfsense/en/latest/book/firewall/ingress-and-egress-filtering.html#egress-filtering) ist nicht sehr aussagekräftig, oder ich habe nicht aufmerksam genug gelesen.

Ich habe mich diesem mal angenommen (siehe auch [Egress Filtering FAQ - SANS Institute](https://www.sans.org/reading-room/whitepapers/firewalls/egress-filtering-faq-1059)) und was heraus gekommen ist ist im Anhang zu sehen - ein Misch aus ingress und egress Filtering bzgl. Reihenfolge. Oder ist das bzgl. in/out egal?

Ich überlege mir, gerade den MS Kram mit in die Silent Block Category aufzunehmen - da schwirrt ja eine Menge rum. Was sagen die Praktiker dazu?

[JeGr]

Warum blockst du überhaupt ausgehend TFTP, SNMP und Syslog? Warum sollte das rausgehen? Wovon? Warum sollte es dann da schon reingelassen werden?

Wie das Regelwerk abgewarbeitet wird, steht eigentlich klar in den Docs drin. Regeln mit Quick (Blitz) sind first match - also top down die erste gewinnt. Ohne quick ist es "last one matches" außer es gibt vorher eine Regel die quick ist. Daher mixt man die nur höchst ungern.

Ich sehe tatsächlich recht wenig Sinn in WAN Egress Filtering bis auf einige wenige Ausnahmen. RFC1918 outbound bspw. - das hat upstream nix zu suchen und wird spätestens dort eh verworfen, muss aber gern nicht erst dahinkommen. Alles andere: Warum soll ich es "out" blocken wenn ich es "in" gar nicht reinlasse? Macht für mich wenig Sinn

[ole]

Warum blockst du überhaupt ausgehend TFTP, SNMP und Syslog? Warum sollte das rausgehen? Wovon? Warum sollte es dann da schon reingelassen werden?

Aus der SANS FAQ:

Trivial File Transfer Protocol - TFTP (UDP/69) When an attacker exploits a system, the first thing he does is go looking for some way to move his toolkit onto the system. TFTP is the tool of choice since it permits the attacker to transfer the file without any interactive prompting.  Not only should you block outbound access to TFTP, but you should also alert on this traffic pattern since it is usually an indication that an internal system has already been compromised.  As a bonus feature, blocking TFTP will prevent the transfer of the toolkit, thus making system recovery that much easier.

Prinzipiell trifft das lt. der FAQ auch auf IRC zu (darüber ließt man dann in den News konkret) etc. Wer aus einem hijacked System raus will, findet auch einen Weg (ggf. HTTPS/SSH), aber man sollte es ihm/ihr nicht so einfach machen. Ich hatte mal einen RaspPI am Netz hängen und konnte durch Zufall auf dem Screen mit ansehen, wie das Teil auseinander genommen wurde - getauschte SSL Certs, per cpio ein neues home unter /var/lib etc).

Wie das Regelwerk abgewarbeitet wird, steht eigentlich klar in den Docs drin. Regeln mit Quick (Blitz) sind first match - also top down die erste gewinnt. Ohne quick ist es "last one matches" außer es gibt vorher eine Regel die quick ist. Daher mixt man die nur höchst ungern.

wie wird den konkret in und out in dieser gegeben Reihenfolge abgearbeitet? Solange alles dir=in war, war alles klar

Ich sehe tatsächlich recht wenig Sinn in WAN Egress Filtering bis auf einige wenige Ausnahmen. RFC1918 outbound bspw. - das hat upstream nix zu suchen und wird spätestens dort eh verworfen, muss aber gern nicht erst dahinkommen. Alles andere: Warum soll ich es "out" blocken wenn ich es "in" gar nicht reinlasse? Macht für mich wenig Sinn

wie gesagt, Malware und anderes Ungeziefer, das evtl. die Kiddies ahnungslos reinlassen und dann raus wollen um dann richtig nachzuladen.

[JeGr]

> Aus der SANS FAQ:

Das ist ja schön und gut, dass das da steht. Und jetzt? von welchem "exploiteten" System reden wir? Im LAN? DMZ? Also HINTER der OPNsense. Warum lasse ich es dann von diesem Subnetz überhaupt in die Firewall REIN? Was ich nicht reinlasse muss ich auch hinten nicht wieder rauslassen. Ganz einfach. Und ob das heute nocht stimmt, dass die irgendwelchen Kram mit TFTP machen, wenn man so viele Schichten NAT hat, wage ich zu bezweifeln. Da ist ein HTTP Port um irgendwas rauszuballern an einen Server im Netz garantiert einfacher und HTTP/S ist wesentlich schwerer zu tracken und "geht unter" als TFTP was raus sticht wie eine Neonreklame.

Das Dokument ist 14 Jahre als - Zeiten und Gefahren ändern sich. Damals war auch SSH noch "erst im kommen", geschweige denn dass jemand viel mit HTTPS gemacht hat.

> aber man sollte es ihm/ihr nicht so einfach machen.

Gefahrenanalyse. WER kommt WIE überhaupt in meine Systeme rein. WAS ist in diesem Fall "hijacked". Irgendwelche theoretischen Probleme kann man immer aufzeigen und finden. Die Frage ist doch eher, welche Fälle sind praktisch überhaupt möglich. Was wird denn bei dir ggf. hijacked und wie. Da muss man sich heutige Malware und Exploits ansehen. Nutzt da jemand noch IRC? TFTP? ICQ?

Der Punkt mag damals korrekt sein, aber heute hättest du überhaupt erstmal ein Problem auf den Systemen sowas wie IRC oder TFTP zu finden. Und wenn ich das eh erst nachinstallieren muss dann kann ich mir auch beliebige Lieblingsmalware/Übertragungstool 2.0 von meinem Host laden und damit arbeiten.

> aber man sollte es ihm/ihr nicht so einfach machen.

Wenn man nach dem Grundsatz "nur Dinge zulassen die man absolut braucht" seine Regeln erstellt, kommt man genau da raus. Wenn ich aus meinem LAN o.ä. nur HTTP/S und SSH zulasse brauche ich auch nichts mehr wegzufiltern. Wird dann aber schwer mit bspw. der Family die spielen möchte.

Was ist mein IST-Zutand? Ich habe bspw. einen Stall Win10 Rechner und davor die Firewall? Dann sind bspw. TFTP und IRC witzlos - gibts dort nicht. Du hast eine DMZ mit Zugriff von außen und dort Linux Server mit alter Software oder altem OS? Holla, ja dann hast du ggf. ganz andere Probleme

Ich sage nicht per se, dass die Regeln "doof" sind, sondern ich sage irgendwelche Empfehlungen von vor Anno 2004 gelten heute nicht mehr. Wir haben ein anderes Internet. Wir haben ganz andere Dienste und Notwendigkeiten. Und die verpackt man ggf. in Regeln und kann dann ggf. das ganze noch mit Features wie IDS obendrauf absichern wenn man seinen Netzen/Geräten nicht traut.

Ich habe mit der FAQ bspw. schon mit dem zweiten bzw. dritten Absatz Probleme. Nach viel etc. etc. steht da

> Far too often firewall administrators create a policy rule that essentially says “let my internal network transmit any and all traffic patterns out to the Internet”. Egress filtering limits this traffic flow to a reduced subset.

Ja das ist richtig. Aber es ist quatsch. Einerseits wird kritisiert, dass man auf dem LAN "allow any" gern konfiguriert um keinen Streß mit den Leuten zu haben. Andererseits drehen wir dann outbound auf dem WAN doch wieder den Hahn zu. Was soll denn der Unfug? Dann kann man auch direkt auf dem LAN ordentlich blocken, denn dann läuft das Paket nicht mal IN die Firewall rein. Warum soll ich Traffic den ich blocken will nicht direkt da aufhalten wo er entsteht? Und das schreiben sie selbst weiter unten:

> Certainly a restrictive policy is going to provide the highest level of security. The fewer ports you have
open, the better. This policy, however, is administratively prohibitive in many environments. If you can
go with a more restrictive policy, that should be your first choice.

Das Dokument bezieht sich auf althergebrachte Strukturen in denen oftmals mehr Firewalls oder Bastion Hosts (um richtig old school zu werden) gestellt wurden oder/und bei denen intern/auf dem Core nochmals gefiltert oder geroutet wird. Dann kann es vorkommen, dass ich auf dem LAN nicht direkt filtern kann oder will weil ich da nichts machen darf. Dann muss ich das quasi im Nachgang outbound machen. Aber das ist Kram der betrifft vielleicht komplexe Netzstrukturen in Firmen aber auch hier: heute sieht das ganz anders aus. Und wenn ich eh schon auf dem LAN filtern kann, macht für mich eben outbound filtering nur in sehr wenigen Ausnahmen Sinn.

Ich denke da muss man schlicht mit der Zeit gehen. Andere Zeiten, andere Gefahren und Angriffsvektoren. Und die muss man auch anders angehen.

> wie wird den konkret in und out in dieser gegeben Reihenfolge abgearbeitet? Solange alles dir=in war, war alles klar

Gar nicht. Regeln werden top down abgearbeitet und Ende. Out oder In ist völlig egal. Die werden nicht sortiert.


> wie gesagt, Malware und anderes Ungeziefer, das evtl. die Kiddies ahnungslos reinlassen und dann raus wollen um dann richtig nachzuladen.

Genau dafür:

* VLANs einführen
* Geräte in verschiedene VLANs/Zonen packen
* VLANs ordentlich mit Regeln verpacken
* Wenn du keinen eingehenden Traffic zulässt außer vllt VPN ist dein AngriffsVektor auf deine Clients fokussiert
* Überlegen/Analysieren, was da rumkreucht und das ordentlich absichern
* Regeln, IDS, DNS Blocking etc.

Aber mach dir mit eingehend/ausgehend und hier noch ne Regel und da noch eine dran nicht unnötig das Leben schwer, sondern bau die Regeln da wo sie direkt wirken und nicht erst "hinten raus" wenns schon fast durch ist Sowas wie VLAN Separation und Aufspaltung in kleine Netze und Inter-VLAN-Routing war 2004 auch noch nicht wirklich verbreitet. Das war eher die Zeit "Komm machen wir ein /16 dann haben wir genug Adressen". Sind die Kunden mit denen wir das heute zurückbauen und alles kleiner machen und isolieren