Firewall Reaktion

Firewalls reglementieren, welche Pakete von einer Quelle zum Ziel und zurück dürfen und welche nicht. Diese Seite beschreibt, wie eine Firewall auf nicht erlaubte Pakete reagieren kann.

Verboten und dann?

Wir gehen nun davon aus, dass eine Quelle ein Paket an eine Ziel-Adresse sendet. Eine Firewall kann eigentlich nur eine der Optionen nutzen:

Reaktion Beschreibung

Allow

Verbindung wird erlaubt

Das ist z.B. der Default bei SOHO-Routern und Firewalls, um nichts zu verhindern. Interessanterweise ist es wohl auch auf einigen Enterprise Firewalls der Default, denn sonst müsste es nicht so viele Anleitungen geben, wie man QUIC unterbinden kann.

DROP

Die Firewall sieht das Paket und verwirft es einfach. Das geht schnell und erfordert keine weitere Generierung und Rücksendung einer Antwort. Das Zurücksenden könnte sogar ein Problem werden, wenn die Quell-IP gefälscht ist und die Firewall damit Pakete an eine unbeteiligte dritte Station sendet. Pakete aus dem Internet würde ich auch einfach verwerfen lassen. Das ist aber kein Schutz gegen Portscans etc., denn ein Angreifer hat ja Zeit und wartet nicht zwingend auf eine negative Antwort. Ich kenne Administratoren, die sogar zum Internet nicht erlaubte Verbindungen aktiv ablehnen.

REJECT

Aktiv Ablehnen bedeutet, dass die Firewall eine Rückmeldung an den Absender gibt. Es gibt aber je nach Protokoll unterschiedliche Möglichkeiten, dem Absender des Pakets eine Information zukommen zu lassen. Darauf gehe ich gleich je nach Protokoll weiter ein.

Ein Reject ist auf jeden Fall meine Empfehlung, wenn die Quelle in internes und damit bekanntes System ist. Fehlende Freischaltungen lassen sich dann auf der Quelle anhand von Logs, Traces etc. sehr viel schneller ermitteln, als wenn jemand auf "Timeouts" wartet.

Einige Firewalls bieten hier noch deutlich mehr Flexibilität und auch abweichende Benennungen (REJECT, DISCARD etc.). Damit stellt sich die Frage, welchen Einfluss solche Einstellungen auf einen Client haben. Denken Sie einmal an das Protokolle QUIC - HTTP/3 und den damit verbundenen QUIC Handshake. Der Client startet per HTTP/TCP und bekommt die Information, das der Webserver auch QUIC anbietet .Der Browser versucht dann QUIC/UDP und je nach Firewall und Implementierung auf dem Browser geht es langsamer oder schneller.

In einem Testfeld habe ich einer OPNSense die verschiedenen Einstellungen durchprobiert und versucht ein unterschiedliches Verhalten zu ermitteln.

Natürlich muss ein Firewall-Administrator pro Regel auch entscheiden, ob ihm diese Ablehnungen einen Eintrag in einem Protokoll wert sind. Die nächste Frage ist natürlich, wie so eine Ablehnung aussehen kann. Auch hier gibt es je nach Protokoll gleich mehrere Optionen.

TCP Ablehnung

Zuerst sollten Sie sich noch einmal den regulären Verbindungsaufbau einer TCP-Verbindung auf TCP SYN ACK RES anschauen, da TCP-Verbindungen von den meisten Diensten genutzt werden.

Dies gilt so für einfache "Paketfilter"-Firewalls. Die besseren Firewalls analysieren die Nutzdaten und lassen dazu oft die ersten paar Pakete passieren bis Sie die Payload klassifizieren können. Es kann daher passieren, dass eine Verbindung "erst einmal" zustande kommt aber dann nach einigen Paketen unterbrochen wird.

Allerdings gibt es auch hier mehrere Optionen, wie eine Firewall bei TCP eine Verbindung beenden kann.

Details Beschreibung

Drop

Am einfachsten ist es, die Pakete einfach nicht mehr weiter zu routen. Der Client bekommt am Anfang gar keine SYN/ACK-Quittung und gibt irgendwann dann auf.

Wenn Sie genau wissen, wohin ein Client zugreift, können Sie in Wireshark und Co auf diese Pakete filtern und das Verhalten erklären. Wenn Sie das Client-Protokoll oder die Gegenstelle aber nicht genau wissen oder es sehr viele Adressen sind, dann kann es knifflig werden, solche Fehler zu erkennen.

TCP Reset

Daher ist eine Antwort an interne Systeme mein Wunsch an eine Firewall. Das hilft nicht nur dem Applikationsverantwortlichen bei der Analyse von Verbindungsproblemen sondern teilt auch der Anwender aktiv mit, dass dieser Weg verbaut ist. Die Anwendung kann dann andere Optionen versuchen oder eine aussagekräftige Fehlermeldung liefern.

Allerdings müssen Sie als Troubleshooter hier immer damit rechnen, dass ein IP-Spoofing passiert. Das Beispiel hier zeigt einen versuchten SSH-Zugriff auf github.com, welcher aber von der Corporate Firewall blockiert wurde. Die Firewall hat sich aber nicht mit ihrer IP-Adresse gemeldet, sondern sich als github.com ausgegeben.

Das ist aber in Ordnung, weil ansonsten vielleicht die Zuordnung der Antwort auf die ausgehende Verbindung wieder an anderer Stelle gestört würde.

Bei bereits bestehenden Verbindungen kann eine Firewall ein Reset an die eine Seite oder andere Seite oder beide Seiten senden.

TCP NACK

Anstatt mit einem TCP-RESET kann eine Firewall oder ein System auch ein NACK senden. Das Paket ist aber untypisch, da es eher Paketverluste meldet. Die Pakete kommen also eher bei bestehenden Verbindungen aber nicht bei einem neuen Verbindungsaufbau. Sie eignen sich daher nicht um eine Blockade zu melden. Eine Firewall könnte aber einem Client oder einem Server damit einen Paketverlust simulieren und damit die Verbindung drosseln. Nett ist das aber nicht.

Beim Beginn oder während einer TCP-Connection kann eine Firewall am besten per TCP-Reset die Verbindung unterbrechen oder verhindern.

ICMP als Rückmeldung

Bei TCP kann die Verbindung über einen TCP-Reset gemeldet werden. Neben TCP gibt es mit ICMP ein Signalisierungsprotokolle, welches zur Steuerung der generellen Kommunikation genutzt wird. Router informieren sich darüber über Pakete die zu groß sind ("Fragmentation needed") oder zu IP-Adressen gehen, zu denen es keinen Leitweg gibt ("No Route") oder einfach zu lange unterwegs sind ("TTL Exceeded/Hopcount Exceeded").

Es gibt aber auch ICMP Pakete, die von Hosts auf der Gegenseite gesendet werden können. Eine Auswahl davon kann eine Hinweis auf eine "Nichterreichbarkeit" geben. Hier eine Auswahl der denkbaren ICMP-Rückmeldungen:

Type Code Status

3

0

Zielnetzwerk nicht erreichbar

3

1

Ziel-Host nicht erreichbar

3

2

Ziel-Protokoll nicht erreichbar

3

3

Ziel-Port nicht erreichbar

3

5

Route fehlgeschlagen

3

6

Zielnetzwerk unbekannt

3

7

Zielhost unbekannt

3

9

Kommunikation mit Zielnetzwerk wurde administrative verweigert

3

10

Kommunikation mit Zielhost wurde administrative verweigert

3

11

Zielnetzwerk für Service nicht erreichbar

3

12

Zielhost für Service nicht erreichbar

3

13

Kommunikation wurde administrativ verweigert

11

0

TTL abgelaufen

Einige Rückmeldung wie z.B. "TTL Abgelaufen" führen den Client und einen nach Fehlern suchenden Admin natürlich auf eine falsche Fährte und sollten daher nur beim Fehlen von Alternativen in Erwägung gezogen werden.

Die Frage bleibt nun natürlich, wie ein Client die ICMP-Meldung zuordnen kann.

Der Client baut z.B. eine Verbindung von einem "SourceIP:Port" zu einem "DestinationIP:Port" auf. Die ICMP-Meldung geht aber an den Computer zurück und hat nichts mit der eigentlichen Verbindung zu tun. Der Client, welcher die Verbindung initiiert, muss als versuchen die ICMP-Meldung auf eine ausgehende Verbindung zuzuordnen. Das kann nicht zu 100% klappen aber wenn der ICMP die gleiche IP-Adresse nutzt, wie der eigentlich angesprochene Host, dann kann dies ein guter Hinweis sein.

Bei einem ICMP-Ping kann ein Client die Rückantwort sehr gut zu einem ausgehenden Paket zuordnen, da es sowohl eine Identifier als auch Sequencenummer gibt:

Damit können sie auch mehrere ICMP-Pakete an das gleiche Ziel senden und jede Rückantwort eindeutig zuordnen.

UDP und Timeout

Im Gegensatz zu TCP gibt es bei UDP aber keinen Handshake und UDP ist prinzipiell kein "gesichertes" Protokoll, wenn es um Paketverluste, Veränderungen oder der Reihenfolge der Zustellung geht. Das ist Aufgabe des auf UDP aufsetzenden Protokolls. Bei Audio/Video ist dies sogar gewollt, dass der Empfänger die verschiedenen Einschränkungen (Jitter, Paketverlust) bei der Übertragung erkennen kann. Nur dann kann er dem Absender die Rückmeldung senden und damit die Bandbreite über Wechsel der Auflösungen, Framerate, Audioqualität (Stereo/Mono, Wideband(Narrowband) etc. beeinflussen.

Sollte eine Firewall aber die Übertragung von bestimmten UDP-Verbindungen aber blockieren, dann kann Sie das Paket verwerfen oder dem Absender per ICMP eine Rückmeldung senden. Eine Rückmeldung als Antwort auf das UDP-Paket ebenfalls per UDP ist nur möglich, wenn die Firewall das darin gesprochene Protokoll kennt und das Protokoll so eine Ablehnung auch unterstützt. Das ist aber eher nicht der Fall und so kommt es auf die Korrekte Zuordnung einer ICMP-Rückmeldung zum UDP-Versand an.

Beim "Drop" des Pakets hingegen kommt es dann auf die "UDP Timeout" des individuellen Protokolls an, d.h. ab wann der Absender eine ausbleibende Rückantwort als Fehler ansieht. Das Paketverluste bei UDP quasi "normal" sind, Muss die Anwendung und das von ihr über UDP genutzte Protokoll entscheiden, wie damit umgegangen wird. Ein Audio/Video-Paket wird ein VoIP-Client sicher nicht noch mal senden, denn Ton und Bild sind "vergänglich". Beim Verbindungsaufbau muss der Client aber etwas mehr Zeit aufwenden, um die grundlegende Möglichkeit einer Verbindung überhaupt auszuloten. Das werden dann wohl eher mehrere UDP-Pakete gesendet, die dann alle nicht beantwortet werden. Wenn eine Verbindung aber einmal zustande gekommen ist, dann sind gelegentliche Verluste wieder normal und werden je nach Protokoll behandelt. Wenn sie schon Webseiten, also "Daten" nicht mehr nur er HTTP/TCP übertragen, sondern schon per QUIC - HTTP/3, dann sichert QUIC über Retransmits etc. die fehlerfreie Übertragung zu.

Knifflig sind hier "Next Generation Firewalls", die sich nicht nur an Ports sondern an den erkannten Protokollen orientieren und dazu am Anfang einige Pakete passieren lassen, ehe Sie dann ggfls. die Verbindung verspätet blockieren. Der Client könnte dann denken, das UDP funktionieren müsste und nicht kurz darauf komplett einbricht.

Zuletzt gibt es natürlich immer noch den NAT-Timeout oder Session-Timeout. Eine UDP-Verbindung ist in der Regel bidirektional aber auf ein vom Initiator gesendetes Paket muss die Gegenseite nicht sofort antworten. Damit stellt sich für eine Firewall die Frage, nach welcher Zeit eine NAT-Zuordnung gelöscht und der Port anderweitig verwendet werden kann, weil keine Pakete mehr zu erwarten sind. Bei TCP schreibt eine RFC einen TCP Session Timeout / TCP Idle Timeout von bis zu 2 Stunden vor. Bei UDP ist ein Timeout von 120 Sekunden üblich. Das ist auch ein Grund für z.B. ComfortNoise bei VoIP, wo ein Client auch bei Stille ab und an Paket sendet.

Mit solchen "Problemen" muss ein Client bzw. die Software, welche UDP nutzt, natürlich auch zurecht kommen. In einer Beschreibung zu den Anforderungen an QUIC im Netzwerk steht z.B.:

No application listening: If there is no process listening on that UDP port, the host will generate an ICMP or ICMP6 error (destination unreachable, port unreachable), or due to policy reasons may not react at all. Most operating systems allow non-privileged applications to receive and parse ICMP errors, allowing the QUIC stack to (partially) validate the returned ICMP error [ICMPTest], depending on the length of the returned ICMP message.
Quelle: https://danwing.github.io/quic-network-req/draft-wing-quic-network-req-00.html

Wenn ein Client eine Verbindung zu einem Port öffnet, kann eine Firewall sehr wohl einen IMCP auf den Port senden. Das sollte ein Client schon zuordnen können.

Allerdings gibt es hier noch ein Risiko für DDoS-Attacken. Bei UDP-Paketen ist es relativ einfach die Source-IP-Adresse zu fälschen. Ich kann als Angreifer ein sehr kleines Paket an ein Ziel senden und hoffen, dass diese an die vorgebliche Absenderadresse ein etwas größeren ICMP-Paket sendet. Allerdings sind auch die ICMP-Statuspakete nicht so immens groß, dass davon ein Risiko ausgehen sollte. Dennoch gibt es Firewalls und Betriebssysteme, die ein ICMP-Limit haben und nur eine gewisse Anzahl dieser Meldungen pro Zeiteinheit senden.

Firewall Blackhole

Natürlich möchte ein Firewall Admin sein System "sicher" gestalten und dazu gehört auch, dass man gegenüber einem Angreifer nichts verrät. Wer z.B. auf einen Verbindungsversuch direkt mit einem "Nein hier nicht" antwortet, signalisiert dem Angreifer, dass es einen Filter gibt und er diesen Port nicht weiter versuchen muss. Meine Erfahrung ist aber, dass sich dadurch niemand genauso wenig abhalten lässt, wie bei einem DROP. Sicher kostet es den Angreifer etwas mehr Zeit eine TCP-Syn-Zugriff erst nach einem Timeout abzubrechen. Aber bei den heutigen Geschwindigkeiten ist das kein ernstes Argument mehr. Von extern kann ich das akzeptieren aber von internen Clients eigentlich nicht.

Auch das Filtern von Rückmeldungen zu ausgehenden Verbindungen, also ICMP-Antworten) halte ich wenig, denn Sie bauen sich damit ein "Blackole", d.h. ein sprichwörtliches "schwarzes Loch", aus dem nichts mehr zurückkommt oder sie die Rückantworten selbst wieder abweisen. Das macht eine Fehlersuche sehr schwer, da auch ein Traceroute und andere Tools dann nicht mehr funktionieren.

Sie können aber bei Firewall mehr als nur "Pass", "Block" und "Reject" einstellen, denn wie bei einem Reject reagiert wird, ist noch mal ein anderes Thema. Ich habe keine Übersicht aller gängigen Firewalls und deren Standardverhalten und beschränke mich hier auf eine Auswahl


Quelle: https://docs.opnsense.org/manual/firewall.html#action

Hier ist gut zu sehen, dass auf UDP-Pakete auch beim REJECT kein Paket zurück gesendet wird. Allerdings basiert OPENSense auf FreeBSD und dort gibt es sehr wohl eine Einstellmöglichkeit zum Verhaltenüber die Shell und SYSCTL

sysctl net.inet.tcp.blackhole=0
The default is 2 which means not to send ICMP port unreachable. If I change it to 0 the firewall will behave like any regular FreeBSD host. On WAN the pf rules will take care of DROP instead of REJECT, so I am still more or less safe from port scans.
https://forum.opnsense.org/index.php?topic=25999.0

Die Werte bedeuten:

2 = TCP Reset
1 = Auf ein TCp SYN-Paket wird keine Antwort gesendet
0 = ICMP Rückmeldung

sysctl net.inet.tcp.blackhole=0
sysctl net.inet.udp.blackhole=0

Wer hingegen mit IPFW arbeitet, kann die Rückantwort pro Regel angeben:

Auch die IPTables erlauben die Definition des "Reject-Verhaltens" pro Regel:



https://ipset.netfilter.org/iptables-extensions.man.html

REJECT This module has the same effect as `DROP', except that the sender is sent an ICMP `port unreachable' error message. Note that the ICMP error message is not sent if (see RFC 1122):
Quelle: Linux 2.4 Packet Filtering HOWTO https://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.txt

Application Abbruch

Selbst habe ich es noch nicht Live gesehen aber es gibt Applikationen, die das gleiche Protokoll nutzen. Als Beispiel nutze ich z.B. QUIC - HTTP/3, welches über das UDP-Protokoll und Port 443 seine Daten überträgt. Die gleiche Kombination aus Protokoll und Port wird aber auch von DTLS genutzt, welches z.B. Cisco AnyConnect verwenden. Auch gibt es SIP-Implementationen, die TLS über UDP verwenden und angeblich nutzt auch das in der HomeAutomation genutzte Protokoll "Thread" ebenfalls UDP über Port 443. Auch Citrix RDP over URL nutzt DTLS/UDP über Port 443

Eine bessere Firewall sollte dann nicht jedes Paket über diesen Port pauschal erst einmal gleich behandeln, sondern vielleicht in das Paket weiter reinschauen oder sogar ein paar Pakete zulassen und anhand des Handshakes die Applikation zu erkennen. Das kann zum Teil an Format der Pakete erfolgen, z.B. bei QUIC oder DTLS. Solange eine Verschlüsselung mit TLS 1.2 oder niedriger aufgebaut wird, kann eine Firewall auch das vom Server übermittelte Zertifikat auslesen und damit auf die Applikation schließen.

Wenn die Firewall und das Protokoll es zulassen würden, könnte die Firewall bei einem Verbot dem Client nicht einfach nur ein "ICMP not reachable" oder ein TCP Reset senden, sondern sich als Gegenstelle ausgeben und eine Protokollkompatible aussagekräftige Meldung zurücksenden.

Ich bin mal gespannt, wann ich entsprechende Traces sehe, bei denen ein Verbindungsaufbau nach einigen Paketen abgebrochen wird.

TCP Timeout

Eine Firewall muss sich aber nicht nur über eine Reaktion beim Verbindungsaufbau Gedanken machen. Auch das Ende einer Verbindung kann sie unterschiedlich behandeln. Wenn ein Server nicht mehr erreichbar ist, dann wird ein Client natürlich immer wieder eine Verbindung versuchen aber irgendwann aufgeben. Wenn der Client dann von seiner Seite die Verbindung abbaut, bekommt die Firewall das "RESET" bzw. "FIN"-Paket mit und kann ihrerseits die Verbindung in ihrer "Stateful Inspection table" entfernen. Das ist insbesondere beim Einsatz von NAT (Siehe 65535 Port-Limit) wichtig. Wenn der Server auf ein Paket des Client mit einem RESET/FIN antwortet, dann sieht die Firewall ebenfalls einen geplanten Verbindungsabbau und kann diese protokollieren und den Speicher frei geben.

Es gibt aber den Fall, dass ein Client einfach verschwindet. Das ist gar nicht so selten, z.B. wenn ein Notebook den Funkbereich verlässt oder der Anwender das USB-C-Kabel zur Dockingunit abzieht und damit das Netzwerk trennt. Die Firewall bekommt dies nicht sofort mit aber nach einiger Zeit schlägt ein TCP Session Timeout / TCP Idle Timeout zu und die Firewall muss nun überlegen, ob Sie die Verbindung in ihrem Speicher einfach so löscht.

Es gibt Firewalls, die speziell bei NAT auch eine TCP-Flusskontrolle übernehmen und einfach ein TCP Keepalive-Paket an die beiden Kommunikationspartner senden um zu sehen, ob diese noch erreichbar sind und die Verbindung beider besteht. Wenn es sich die Firewall einfacher machen will, dann kann Sie einfach ein TCP RESET an die Parteien senden und die Verbindung löschen. Es liegt dann an den Endpunkten, die Verbindung ggfls. neu aufzubauen.

Es soll aber auch Firewalls geben, die nach Ablauf eines Inaktivitäts-Timers einfach die Verbindung ohne Meldung löschen. Die beiden Endpunkte gehen davon aus, dass die Verbindung weiterhin besteht und warten auf Pakete. Das Verhalten kennen wir von Exchange und Outlook, wenn Outlook auf neue Mails von Exchange Online wartet aber die nach einigen Minuten auf den ausstehenden HTTP-Request ankommende Antwort von Exchange Online wird von der Firewall verworfen, weil in der NAT-Verbindungstabelle kein Eintrag mehr vorhanden ist. Microsoft forder einen Mindest-timeout von 120 Sekunden (Office 365 Netzwerk Empfehlungen)

Weitere Links