Grundlagen der Firewalltechnik
Keywords: Buch

> Nächste Seite: Filtern von eingehenden Paketen Aufwärts: Crashkurs Firewallaufbau unter Linux Vorherige Seite: Grundlagen Inhalt
> Unterabschnitte
> - Die Voreinstellung für Paketfilter
> - REJECT oder DENY
> - Zusammenfassung

> # Grundlagen der Firewalltechnik

> Die hier vorgestellte Firewall ist eine sogenannte Paketfilter-Firewall. Dabei geht es also darum, die im letzten Kapitel angesprochenen Pakete zu bewerten und anhand verschiedener Kriterien zu entscheiden, ob ein Paket passieren darf, oder nicht.

> Eine solche Paketfilter-Firewall arbeitet in der von uns besprochenen Linux-Version mit einer Liste von Annahme- oder Ablehnungskriterien. Daraus entstehen sogenannte Regeln, die genau bestimmen, ob ein Paket passieren darf oder nicht. Diese Kriterien sind

> - Netzwerkschnittstelle
> - IP-Adressen
> - TCP/UDP Portnummern bzw. ICMP Nachrichtentypen
> - SYN- und ACK-Flags
> - Die Flußrichtung (eingehendes oder abgehendes Paket)
> All diese Informationen zeigen, daß die Firewall also auf der Vermittlungs- und Transportschicht des TCP/IP-Schichtenmodells arbeitet.

> Für beide Flußrichtungen (ankommend - Input und abgehend - Output) stehen jeweils eigene Filter zur Verfügung. Der grundlegende Mechanismus ist dabei der, daß für beide Richtungen eine ganze Anzahl von hintereinanderfolgenden Regeln existieren, die hintereinander abgearbeitet werden. So entsteht eben eine sogenannte Kette (engl. chain) von Regeln, daher der Name ip-chains.

> Diese Kette von Regeln wird solange abgearbeitet, bis entweder eine Regel zutrifft, oder das Ende der Kette erreicht ist.

> Bild 3..1: Input- und Output-Chains

> # Die Voreinstellung für Paketfilter

> Aus dem letzten Bild kann der Eindruck entstehen, daß die Regeln grundsätzlich so aufgebaut sind, daß sie einzelne Pakete ablehnen, ansonsten aber alle anderen annehmen. Das ist natürlich möglich, aber weder notwendig, noch empfehlenswert. Linux-Firewalls bieten zwei verschiedene Strategien an, nach denen die Firewall arbeitet - die sogenannten Policies:
> - Grundsätzlich wird alles abgewiesen; nur explizit durch Regeln zugelassene Pakete werden akzeptiert. Diese Policy heißt DENY.
> - Grundsätzlich wird alles akzeptiert; nur explizit durch Regeln verbotene Pakete werden abgewiesen. Der Name dieser Policy ist ACCEPT.
> Vor- und Nachteile beider Strategien liegen auf der Hand. Die erste Version ist sicherlich die, die mehr Sicherheit und Kontrolle bietet, jedoch auch wesentlich mehr Arbeit bei der Einrichtung erfordert. Wir müssen für alle denkbaren Arten von Netzverkehr Regeln definieren, sonst werden die entsprechenden Pakete ja nicht durchgelassen.

> Die zweite Methode (ACCEPT) ist bei der Einrichtung natürlich wesentlich einfacher, sie bietet aber von sich aus wesentlich mehr Angriffsfläche. Um mit dieser Methode eine hinreichend sichere Firewall aufzubauen, müssten wir alle denkbaren Angriffstypen kennen, um sie entsprechend abzuweisen. Und damit wäre es wieder mindestens so viel Arbeit, wie das Einrichten der DENY-Methode.

> Zusammengefasst muß also gesagt werden, daß - zumindestens für Pakete, die aus dem unsicheren Netz ins sichere gelangen sollen - die Strategie DENY vorzuziehen ist.

> Auf den beiden folgenden Seiten sind die beiden unterschiedlichen Strategien nochmal als Flußdiagramme dargestellt.

> Bild 3..2: Die DENY-Policy

> Bild 3..3: Die ACCEPT-Policy

> # REJECT oder DENY

> Die Linux-Firewall Mechanismen erlauben neben den beiden bereits besprochenen Policies ACCEPT und DENY eine dritte, REJECT. Dabei handelt es sich im Wesentlichen um eine Mutation von DENY, also der Ablehnung eines Paketes. Ein Paket kann entweder einfach verworfen werden, das entspricht hier dem DENY, oder es wird zwar abgelehnt, jedoch erhält der Absender des Paketes eine Fehlermeldung mit Begründung. Diese Methode wird als REJECT (ablehnen) bezeichnet.

> Wird ein Paket also durch ein REJECT abgelehnt, so erhält der Absender des Paketes eine ICMP Fehlermeldung, wird es durch DENY abgelehnt, so verwirft die Firewall das Paket einfach und gibt keinerlei Rückmeldung an den Sender des Paketes weiter.

> Es ist eigentlich - zumindestens in einem System mit hohen Sicherheitsanforderungen - immer besser, Pakete mit DENY einfach zu verwerfen, als eine Fehlermeldung zurückzugeben. Das hat drei Gründe:

> - Durch eine Fehlermeldung wird der Datenverkehr auf dem Netz unnötig vergrößert.
> - Fehlermeldungen können als Teil einer Denial-of-Service-Attack Strategie eingesetzt werden. Wenn etwa ein Angreifer, der einen Rechner im Internet blockieren will, seine IP-Adresse auf die des zu blokierenden Rechners fälscht und anschließend tausende von bei Ihnen verbotenen Anfragen macht, dann wird Ihr Rechner tausende von Fehlermeldungen nicht an den Rechner des Angreifers, sondern an den zu blockierenden Rechner schicken.
> - Fehlermeldungen - und seien sie an sich noch so wenig aussagekräftig - können einem potenziellen Angreifer doch zumindestens Informationen geben, die er besser gar nicht hat. Etwa alleine die Existenz einer Firewall oder ähnliches.

> # Zusammenfassung

> Zusammenfassend können wir also feststellen, daß es zwei wesentliche Strategien (Policies) gibt, die eine Paketfilter-Firewall ausmachen. Entweder wir nehmen alle Pakete, außer explizit verbotenen, an - Policy ACCEPT, oder wir verweigern die Annahme aller Pakete außer explizit erlaubten - Policy DENY.

> Zum Umgang mit einzelnen Paketen stehen uns drei Methoden zur Verfügung:

> ACCEPT
>   Das Paket wird angenommen
> DENY
>   Das Paket wird stillschweigend verworfen
> REJECT
>   Das Paket wird abgelehnt, aber es wird eine ICMP-Fehlermeldung an den Absender zurückgeschickt.

> Grundsätzlich unterscheiden wir zwischen der Input- und Output-Chain, also der Kette von Regeln für eingehende bzw. ausgehende Pakete.

> Nächste Seite: Filtern von eingehenden Paketen Aufwärts: Crashkurs Firewallaufbau unter Linux Vorherige Seite: Grundlagen Inhalt