Quelltext der Seite Firewall-Regelwerk

{{Belege fehlen|Der Artikel enthält zwar einige EN, weite Abschnitte sind aber vollkommen unbelegt. Außerdem wäre Literatur zum Thema allgemein und nicht nur zu spezifischen Aussagen wünschenswert.}}

In einem '''Firewall-Regelwerk''' wird definiert, welcher Verkehr durch eine [[Firewall]] erlaubt und welcher [[verbot]]en 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 Packet Inspection|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.<ref>[https://www.protecus.de/Firewall_Security/ruleset.html Das Firewall Ruleset] (Protecus.de)</ref><ref>{{Internetquelle |autor=Marc Ruef, Rocco Gagliardi |url=https://www.scip.ch/?labs.20120607 |titel=Firewall Rule Review – Ansatz und Möglichkeiten |werk=scip.ch |datum=2012-07-06 |sprache=de |abruf=2024-04-28}}</ref>
Eine Firewall-Regel setzt sich meist aus sechs Komponenten zusammen:
# Absender-[[IP-Adresse]] (auch Netzwerk-Adressen wie z.&nbsp;B. 192.168.0.0/24 oder Firewall-Gruppen)
# [[Zielmarke|Ziel]]-IP-Adresse
# [[Netzwerkprotokoll]] ([[Transmission Control Protocol|TCP]], [[User Datagram Protocol|UDP]], [[Internet Control Message Protocol|ICMP]], …)
# [[Port (Protokoll)|Port]]-Nummer (bei TCP und UDP)
# Aktion (erlauben, verwerfen oder ablehnen)
# [[Logdatei|Protokollieren]] (engl. "log") ja/nein

Eine weitere mögliche Komponente ist bei TCP die Inspektion der [[Transmission Control Protocol#Verbindungsaufbau|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 [[Secure Shell|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 [[Netzwerkdienst|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 [[Firewall#Proxy Firewall (auch Application Layer Firewall)|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.&nbsp;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.&nbsp;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 [[Internet Relay Chat|IRC]] und selten noch mit [[Simple Mail Access Protocol|SMTP]] eingesetzt wird. Das Netzwerk wird durch zusätzliche Anfragen belastet, weil die Clients keine explizite Ablehnung erhalten und weiterhin versuchen, die Verbindung aufzubauen.<ref name="ISBN_3-89721-364-8">''Linux-Sicherheits-Kochbuch'', ISBN 3-89721-364-8, S. 30</ref> 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.<ref name="ISBN_3-89721-364-8"/> Die Mitteilung erfolgt entweder über [[Internet Control Message Protocol|ICMP]]-Unreachable oder bei [[Transmission Control Protocol|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|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.<ref name="ISBN_3-89721-364-8"/>

==== 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).<ref>Baustein NET.3.2 Firewall des [https://www.bsi.bund.de/grundschutz IT-Grundschutz-Kompendiums]</ref> 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 [[Domain Name System|DNS]]-Name angegeben, um zu verhindern, dass ein Angreifer durch Änderungen im DNS auf das Regelwerk Einfluss nehmen kann.

=== Protokolle ("logging") ===

Protokolldateien (umgangsspr: [[Logdatei]]en) 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 [[Revisionssicherheit|revisionssicher]] aufbewahrt werden, empfiehlt sich ein System, das einen Log-Host benutzt und für den Fehlerfall lokal protokollieren kann. 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.&nbsp;B. bei [[Denial of Service|Denial-of-Service]]-Angriffen passieren oder wenn [[Computerwurm|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 [[Administrator (Rolle)|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 [[Secure Shell|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 ===

[[Internet Control Message Protocol|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:<ref> {{Internetquelle |autor=Antonio Merola |url=https://www.computec.ch/archiv/dokumente/netzwerke/verwendung_und_missbrauch_von_icmp.pdf |titel=Verwendung und Missbrauch von ICMP |werk=computec.ch |datum=2006 |format=PDF; 1,2 MB |sprache=de |abruf=2024-04-28}}</ref>
* 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 (Datenübertragung)|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 [[Cracker (Computersicherheit)|Crackern]] aber auch das Auskundschaften des Netzes. Außerdem gibt es auch in "ICMP Echo" immer wieder [[Sicherheitslücke]]n wie z.&nbsp;B. [[Ping of Death]] und andere.<ref>{{Internetquelle |autor=Dirk Knop |url=https://www.heise.de/news/Sicherheitsluecken-in-Ciscos-IOS-138366.html |titel=Sicherheitslücken in Ciscos IOS |werk=heise online |datum=2007-01-25 |sprache=de |abruf=2024-04-28}}</ref><ref>{{Internetquelle |autor=Daniel Bachfeld |url=https://www.heise.de/news/Ein-Ping-und-Solaris-geraet-in-Panik-140956.html |titel=Ein Ping - und Solaris gerät in Panik |werk=heise online |datum=2007-01-31 |sprache=de |abruf=2024-04-28}}</ref>

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.

== Einzelnachweise ==
<references />

== Siehe auch ==
* [[Paketfilter]]
* [[Stateful Packet Inspection]]

[[Kategorie:IT-Sicherheit]]
[[Kategorie:Rechnernetze]]