Firewall-Regelwerk
In einem Firewall-Regelwerk wird definiert, welcher Verkehr durch eine Firewall erlaubt und welcher verboten ist. Die Methode basiert auf Mandatory Access Control: Je nach Absender, Zustelladresse, Protokoll und Sendevorgang erlaubte Datenpakete dürfen passieren (engl. pass), verbotene werden abgelehnt (reject) oder verworfen (deny, drop). Dieser Schutzmechanismus ist selbst Ziel etlicher spezifischer Angriffsmöglichkeiten.
Grundlagen
Die Regeln werden für jedes Paket (bei Stateful Firewalls für jede neue Verbindung) der Reihe nach geprüft, und die erste zutreffende Regel wird angewendet. Die Reihenfolge der Regeln ist daher relevant.[1][2] Eine Firewall-Regel setzt sich meist aus sechs Komponenten zusammen:
- Absender-IP-Adresse (auch Netzwerk-Adressen wie z. B. 192.168.0.0/24)
- Ziel-IP-Adresse
- Netzwerkprotokoll (TCP, UDP, ICMP, …)
- Port-Nummer (bei TCP und UDP)
- Aktion (erlauben, verwerfen oder ablehnen)
- Protokollieren (engl. "log") ja/nein
Eine weitere mögliche Komponente ist bei TCP die Inspektion der Control-Flags. Durch die Kontrolle des ACK-Flags ist es möglich, einen Verbindungsaufbau nur in eine Richtung zuzulassen, so kann beispielsweise in Kombination mit einer Portregel ein Angreifer SSH nicht verwenden.
Manche Firewall-Systeme bieten darüber hinaus noch die Möglichkeit, einzelne Regeln zu kommentieren oder zeitabhängig zu aktivieren. Eine Möglichkeit des Kommentierens von Regeln, IP-Adressen und Diensten ist sehr nützlich, um unbenutzte Regeln oder Teile davon identifizieren und löschen zu können. Denn das Aufräumen eines unübersichtlich gewordenen Regelwerks nach der Methode Versuch und Irrtum ist auf einer produktiven Firewall praktisch unmöglich.
Die Port-Nummer hat nur beschränkt Einfluss darauf, welcher Dienst tatsächlich über diese Regel laufen darf. Es ist beispielsweise technisch möglich, eine SSH-Verbindung so zu konfigurieren, dass sie statt über ihren Standardport TCP 22 über TCP 80 für HTTP läuft. Dies kann nur eine Application Layer Firewall verhindern.
Bei größeren Regelwerken lässt sich die Übersichtlichkeit mit Systemen steigern, in denen sich Adressen oder Dienste in Gruppen zusammenfassen lassen, z. B. könnte eine Gruppe „Maildienste“ die Mitglieder SMTP, POP3 und IMAP haben. Eine andere Möglichkeit der Definition von IP-Adressen und Portnummern sind Zahlenbereiche, z. B. 10.0.0.30–10.0.0.40 oder Port 135–139. Bei IP-Adressen ist dies in der Verarbeitung allerdings langsamer, als Netzbereiche mit Netzmaske anzugeben.
Verwerfen, Ablehnen und Erlauben
Die Regeln einer Firewall legen fest, was mit einem Netzwerkpaket passieren soll, welches in das Muster eines Filters passt. Es wird zwischen den folgenden Aktionen unterschieden, die je nach Produkt unterschiedlich betitelt sein können:
DENY oder DROP (Verwerfen)
Das Paket wird verworfen, also nicht durchgelassen, ohne weiter darauf zu reagieren. Der Absender erhält keine Nachricht darüber, dass sein Verbindungsversuch blockiert wurde. Der Nachteil des Verwerfens ist, dass der Sender erst nach einem Timeout von dem missglückten Verbindungsversuch erfährt. Probleme bereitet dies mit dem Ident-Protokoll, das oft zusammen mit IRC und selten noch mit SMTP eingesetzt wird. Das Netzwerk wird durch zusätzliche Anfragen belastet, weil die Clients keine explizite Ablehnung erhalten und weiterhin versuchen, die Verbindung aufzubauen.[3] Zudem fällt das Debuggen, also die Suche nach Fehlerursachen, in einem Netz schwer, wenn die Systeme auf eine Anfrage nicht reagieren, statt eine Statusmeldung zurückzuschicken.
REJECT (Ablehnen)
Das Paket wird verworfen und dem Absender wird mitgeteilt, dass die Verbindung abgelehnt wurde. Generell entspricht das eher dem Standard bei der Kommunikation zwischen Netzwerkkomponenten.[3] Die Mitteilung erfolgt entweder über ICMP-Unreachable oder bei TCP mit einem Reset-Paket. Das Ablehnen hat den Vorteil, dass die beschriebenen Nebenwirkungen des einfachen Verwerfens ausbleiben. Es hat aber auch den Nachteil, dass bei der Verwendung von gefälschten IP-Adressen die Firewall selbst für Denial-of-Service-Angriffe missbraucht werden kann, indem sie den vermeintlichen Absender mit Ablehnungspaketen belastet. Einige Firewalls besitzen Funktionen wie ICMP-Rate-Limiting, die dieser Problematik entgegenwirken.[3]
ALLOW oder PASS (Erlauben)
Die Netzwerkanfrage ist erlaubt und wird durchgelassen. Diese Begriffe beziehen sich meist auf den ausgehenden Datenverkehr (also vom internen hin zum externen Netz, bzw. bei Personal Firewalls vom eigenen Computersystem ins Netz).
FORWARD oder PERMIT (Erlauben)
Die Netzwerkanfrage ist erlaubt und wird weitergeleitet, was die Möglichkeit einer Umleitung auf eine vom Administrator festgelegte Netzwerkadresse einschließt. Diese Begriffe beziehen sich vorwiegend auf den eingehenden Datenverkehr (also vom externen hin zum internen Netz, bzw. bei Personal Firewalls auf Anfragen aus dem Netz).
Sicherheitsgrundsätze
Das ideale Regelwerk einer Firewall ist immer so aufgebaut, dass grundsätzlich jeder Netzwerk-Verkehr verboten ist und die erwünschten Verbindungen erlaubt werden ("Whitelist"-Strategie).[4] Die andere Variante, nur unerwünschten Verkehr zu verbieten und alles andere zu erlauben, kann im schnellen Wandel der IT-Welt niemals als sicher betrachtet werden. Die Absender- und Ziel-Adressen werden in der Regel immer numerisch und nicht als DNS-Name angegeben, um zu verhindern, dass ein Angreifer durch Änderungen im DNS auf das Regelwerk Einfluss nehmen kann.
Protokolle ("logging")
Protokolldateien (umgangsspr: Logdateien) dienen der Nachvollziehbarkeit des Netzwerkverkehrs und der Fehlersuche. Die Protokollierung kann auf der Firewall selbst erfolgen, wenn diese eine eingebaute Festplatte hat, oder auf einem entfernten "Log-Host". In diesem Falle kommen teils proprietärere Protokolle oder Syslog zum Einsatz. Müssen die Log-Dateien revisionssicher aufbewahrt werden, empfiehlt sich ein System, das einen Log-Host benutzt und für den Fehlerfall lokal protokollieren kann.[5] Für die Auswertung von Log-Dateien ist es sehr hilfreich, wenn jeder Regel eine einzigartige Nummer zugewiesen werden kann, damit die Einträge den entsprechenden Regeln zugeordnet werden können.
Manche Firewalls loggen jedes einzelne Netzwerkpaket, andere erstellen einen Log-Eintrag pro Verbindung. Grundsätzlich protokolliert eine Firewall alle Verbindungen. Ausnahmen werden nur gemacht, wenn einzelne Regeln so viele Logeinträge produzieren, dass es zu technischen Problemen oder Geschwindigkeitseinbußen kommt. Dies kann z. B. bei Denial-of-Service-Angriffen passieren oder wenn Würmer im Netzwerk aktiv sind. Eine Möglichkeit, dies zu vermeiden, ist eine eigene Regel für diese Wurmangriffe, welche nicht protokolliert werden.
Stealth-Regel
Eine "Stealth"-Regel (deutsch etwa: „heimliche Regel“ oder „listige Regel“) dient dem Eigenschutz der Firewall und verbietet alle Verbindungen zu ihr selbst. Da die Reihenfolge der Regeln relevant ist, müssen davor noch die Administrations-Dienste für die Firewall erlaubt werden, damit diese Pakete nicht auch verworfen werden. Warum eine Stealth-Regel notwendig ist, wird aus folgendem Beispiel ersichtlich:
- Die Firewall hat auf einem Interface die IP-Adresse 10.0.0.1
- Es gibt eine Regel, die allen Firmen-PCs SSH-Verbindungen zu den Servern im Netz 10.0.0.0/24 erlaubt.
Da 10.0.0.1 auch ein Teil des Netzes 10.0.0.0/24 ist, dürften alle PCs in diesem Netz auf den SSH-Port der Firewall zugreifen, was die Firewall für Innentäter angreifbarer machen würde.
ICMP-Regeln
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:[6]
- 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)
Alle anderen ICMP-Typen werden nur nach Bedarf freigeschaltet, bei einer Firewall ins Internet restriktiver als bei einer zwischen zwei internen Netzen. Wegen des Missbrauchpotenzials ist der Typ ICMP-Redirect in der Regel gesperrt. Die Nachricht "ICMP Echo Request" eingehend zu erlauben erleichtert Außenstehenden zwar die Fehlersuche, ermöglicht Crackern aber auch das Auskundschaften des Netzes. Außerdem gibt es auch in "ICMP Echo" immer wieder Sicherheitslücken wie z. B. Ping of Death und andere.[7][8]
Werden ICMP-Unreachable-Fragmentation-Needed-Pakete an einem Punkt der Route gefiltert, zum Beispiel durch ein einfaches „ICMP deny“, kann es zu Übertragungsproblemen kommen, wie im Artikel Maximum Transmission Unit beschrieben.
Ausgehender Datenverkehr
Häufig wird die Kontrolle des ausgehenden Verkehrs vernachlässigt. So lassen viele Firewalls grundsätzlich ausgehenden Verkehr für alle Ports offen. Damit stehen Schadprogrammen auf simple Weise Kommunikationswege offen, die vom Betreiber der Maschine gar nicht erkannt werden – Spamversand ist ein typischer Fall. Auf einer gut konfigurierten Firewall sind solche Wege gesperrt. Beispielsweise sollte ausgehende Mail nur über den Mailserver möglich sein; alle anderen Wege sind gesperrt (Unter Linux/Netfilter kann man ausgehende Verbindungen an eine Benutzer- oder Gruppen-ID binden). Dann können Schadprogramme zwar immer noch senden, fallen aber in der Log-Datei schnell auf.
Quellen
- Das Firewall Ruleset (Protecus.de)
- [Firewall Rule Review - Ansatz und Möglichkeiten http://www.scip.ch/?labs.20120607] (scip.ch)
- Linux-Sicherheits-Kochbuch, ISBN 3-89721-364-8, S. 30
- Baustein NET.3.2 Firewall des IT-Grundschutz-Kompendiums
- BSI: Integration und IT-Revision von Netzübergängen (PDF; 576 kB)
- Verwendung und Missbrauch von ICMP (Memento des Originals vom 4. März 2016 im Internet Archive) Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. (Hakin9)
- Sicherheitslücken in Ciscos IOS (Heise.de, 25. Januar 2007)
- Ein Ping - und Solaris gerät in Panik (Heise.de, 31. Januar 2007)
