Online Suche im Handbuch

LITTLE-IDIOT NETWORKING

12.10 Interne Abläufe der Firewall

Hier nur ein Überblick darüber, welche Prozesse innerhalb der Firewall stattfinden:

1. Der Bytecounter für jede Regel wird um die Größe des Headers oder des Gesamtpaketes erhöht.
2. Der Paketzähler wird erhöht
3. Es wird auf Wunsch ein Logeintrag vorgenommen
4. Auf Wunsch wird der TCP Header mit dem ToS Feld verändert.
5. Auf Wunsch wird ein Paket in einer Liste vermerkt. (nicht in der Version 2.0)
6. Die Anweisungen nach der Regel werden analysiert, um zu entscheiden, was mit dem Paket passieren soll.

Regel - Anweisungen

Die Regel Anweisungen sind für den Kernel bestimmt, damit dieser darüber informiert ist, was mit dem Paket zu geschehen hat, auf welches eine Regel zutrifft. ipchains benutzt hierbei die Option -j (jump-to) für die Angabe einer Ziels. Der Name des Ziels darf nur max. 8 Buchstaben lang sein, wobei Groß-und Kleinschreibung unterschieden wird.

Die Einfachste Anweisung ist diejenige, wo kein Ziel angegeben wird. Diese wird oft auch accounting rule genannt, weil sie nur zum Zählen von Paketen, dem Accounting geeignet ist:

ipchains -A input -s 192.168.1.1

Diese Regel zählt alle Pakete von dem Host 192.168.1.1 mit. Der Befehl ipchains -L -v zeigt die Summe von Bytes und Paketen an, die das Interface passiert haben, nachdem die Regel zutreffend war. Es läßt sich somit nach Port, Zieladresse und Quelladresse das Datenaufkommen zählen.

Es gibt sechs spezielle Anweisungen. Die ersten drei sind bereits bekannt, diese sind ACCEPT, REJECT und DENY. ACCEPT besagt, das das Paket passieren kann. DENY verwirft das Paket in aller Stille, REJECT verwirft das Paket ebenso, generiert aber eine ICMP Nachricht, Code Nummer 3.

Die vierte ist die Anweisung MASQ. Sie beauftragt den Kernel, die Absendeadresse, also die Quell IP - Nummer durch die IP - Nummer des eingehenden Interfaces zu ersetzen. Hier zu muß der Kernel mit der Option masquerading kompiliert worden sein. Für die genaue Beschreibung siehe den Abschnitt Unterschiede zwischen ipchains und ipfwadm. Diese Anweisung ist nur zulässig für Pakete, die die forward chain durchlaufen. Der Zweck dieser Regel ist es, interne IP - Nummern nicht in das Internet zu verraten, um einem Angreifer möglichst wenig Informationen über die Zahl und den Ort der Hosts im Intranet zu verraten.

Die fünfte Anweisung ist die Option REDIRECT. Diese besagt, daß der Kernel das Paket auf einen lokalen Port umleiten soll. Diese Anweisung wird nur für TCP und UDP Pakete ausgeführt. Als Ergänzung kann nach der Regel -j REDIRECT ein Port angegeben werden, auch wenn das Paket an einen anderen Port weitergeleitet wurde. Diese Anweisung kann nur in der input chain verwendet werden. Sinnvoll kann diese Option zur Umleitung von Paketen auf Port 80 auf einen Proxy-Server auf Port 8080 sein. Bei UDP Paketen können diese an den UDP nach TCP Umsetzer (udprelay) übergeben werden, um Protokolle, wie NFS, NIS/YP sicherer gegen Angriffe zu machen. Diese Option kann auch auf Filter zeigen, die auf der Firewall installiert wurden, um JAVA und Active-X aus dem Datenstrom herauszufiltern, ohne auf einen Proxy verzichten zu müssen, quasi als Kaskade von Proxy und Filter. Bitte beachten: Diese Option funktioniert zuverlässig nur mit der Kernelversion 2.2 . Ein Update von RedHat Linux 5.2 auf die neue Kernelversion ist aber problemlos. Updates und Patches findet man auf den Seiten von RedHat.

Zum Schluß kommt die Anweisung RETURN. Diese Anweisung besagt, daß alle folgenden Regeln über gangen werden können. Weitere Details in dem Abschnitt Aufsetzen der Policy.

Alle weiteren Anweisungen, die nicht diesen sechs entsprechen zeigen auf eine User definierte Regel. Die Bedeutung dieser Anweisungen wird in Anweisungen, die auf eine chain wirken. Das Paket wird alle Regeln in der chain durchlaufen, bis sich eine Regel findet, die beschreibt, was mit dem Paket geschehen soll.

Dieses Beispiel zeigt Regeln, die keinen Sinn ergeben:

         input                           test

        ----------------------------    ----------------------------

        | Rule1: -p ICMP -j REJECT |    | Rule1: -s 192.168.1.1    |

        |--------------------------|    |--------------------------|

        | Rule2: -p TCP -j Test    |    | Rule2: -d 192.168.1.1    |

        |--------------------------|    ----------------------------

        | Rule3: -p UDP -j DENY    |

        ----------------------------

Man denke sich ein TCP Paket, welches als Quell-IP - Nummer die Adresse 192.168.1.1 besitzt und an die Adresse 1.2.3.4 gerichtet ist. Es betritt die input chain, und wird von Regel Nummer 2 als Zutreffend erkannt. Danach wechselt es zur test chain. Hier trifft die Regel Nummer 1 bereits zu, aber es ist keine Anweisung definiert. Danach durchläuft das Paket die test chain bis zum Ende und kehrt wieder in die input chain zurück. Hier passiert das Paket die Regel Nummer 3, die aber ebenfalls nicht zutrifft. Was danach mit dem Paket passieren soll, beschreibt die Policy.

Ein kleines Diagramm:

                                v    __________________________

         `input'                |   /    `Test'                v

        ------------------------|--/    -----------------------|----

        | Rule1                 | /|    | Rule1                |   |

        |-----------------------|/-|    |----------------------|---|

        | Rule2                 /  |    | Rule2                |   |

        |--------------------------|    -----------------------v----

        | Rule3                 /--+___________________________/

        ------------------------|---

                                v

In dem Abschnitt Organisation der Firewallregeln werden Wege beschrieben, wie man User definierte chains effizient einsetzen kann.

Logging packets.

Ein Nebeneffekt der Paketfilterung ist das Mitloggen von Paketen, falls die Regel mit der Option -l definiert wurde. Nun werden alle Pakete mit protokolliert. Hierfür muß der Kernel Log-Dämon aktiviert werden (klogd). In den Handbüchern man klogd oder man dmesg werden die Eigenschaften genauer beschrieben.

Manipulationen im Paket-Header

Es gibt insgesamt vier selten gebrauchte Bits in dem Paket-Header, die Type of Service ToS-Bits genannt werden. Sie beeinflussen die Art, wie Pakete behandelt werden. Die vier Bits beschreiben folgende Funktionen:

• Minimum Delay
• Maximum Throughput
• Maximum Reliability
• Minimum Cost

Es darf laut Definition nur eines der Bits gesetzt sein. Der Autor des Code Abschnittes beschreibt seine Eigenschaften so:

Besonders das Flag "Minimum Delay" ist für mich besonders wichtig. Ich schalte es ein, um "interaktive" Pakete in meinem Upstream von dem Linux Router zu handeln. Ich selber habe nur ein 33k6 Modem. Linux gibt den Paketen in drei verschiedenen Queues besondere Prioritäten. So bekomme ich auch noch während eines Downloads noch akzeptable Antwortzeiten für interaktive Dinge. Die Performance könnte ein wenig besser sein, wenn da nicht eine so große Queue in dem Treiber für die serielle Karte wäre, aber die Latenzzeiten sind nun nur noch im Bereich von 1.5 Sekunden.

Allgemein behindern sich telnet und ftp Datenströme aufgrund ihrer unterschiedlichen Bits. Während FTP Datenströme stets auf maximalen Durchsatz ausgelegt sind, ist telnet auf minimale Verzögerungszeiten ausgelegt. Um beides unter einen Hut zu bekommen, sollten folgende Regeln eingesetzt werden.

ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10

ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10

ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08

Der Option -t folgen zwei zusätzliche Parameter, die beide in hexadezimaler Schreibweise angegeben sind. Sie erlauben es, mit den TOS Bits zu spielen. Die erste Maske wird mit den TOS Bits in dem Paket über AND verknüpft, während die zweite Maske mit den TOS Bits über XOR verknüpft sind:

TOS Name                Value           Typical Uses



Minimum Delay           0x01 0x10       ftp, telnet

Maximum Throughput      0x01 0x08       ftp-data

Maximum Reliability     0x01 0x04       snmp

Minimum Cost            0x01 0x02       nntp

Andi Kleen hat deren Einsatz so beschrieben:

Es könnte sinnvoll sein, einen Parameter zu dem TX Queue Längenparameter in ifconfig hinzuzufügen, und diesen um die TOS Bits noch zu erweitern. Die Standardmäßige Länge der Queue kann für Ethernet Karten noch getuned werden, für Modems ist dieser viel zu lang und das macht ihn für den 3-Wege Scheduler unbrauchbar. (Dessen Queues auf TOS basieren) Eine gute Idee ist es , diesen auf Werte zwischen 4 und 10 auf einem Modem oder einer ISDN-Karte zu setzen: Bei Kanal - Bündelung ist eine größere Queue nötig. In den Kerneln 2.1 (und 2.2) ist es ein ifconfig Flag, was gesetzt werden muß (mit den aktuellen nettools), in Versionen 2.0 erfordert es einen Kernel Patch, um die Werte zu ändern.

Um das bestmögliche Ergebnis zu erzielen, muß man ein wenig herum experimentieren. Wenn die Queues zu klein sind, dann werden die Pakete verworfen. Natürlich hängen die Resultate auch davon ab, ob die Anwendungsprogramme auch ohne TOS Änderungen kooperieren. In dem Fall, daß sie nicht kooperieren, sind Änderungen bei den TOS Flags nötig. (alle mit Linux mitgelieferten Programme sind aber kooperierend)

Diese Art Tuning ist als Aprilscherz 99 von der Zeitschrift c´t beschreiben worden. Tatsächlich ist hier aber auch ein Funken Wahrheit dran. Man kann seinem WWW-Server bei einem Provider so erhebliche Priorität vor benachbarten Servern geben, insbesondere wenn diese mit in ein- und derselben Collision Domain stehen. In vielen Fällen werden ausgehende Datenpakete von diesem Server von CISCO´s vorrangig geroutet.

Markierung eines Paketes

Dieses erlaubt komplexe und leistungsfähige Kombinationen mit Alexey Kuznetsov's neuer QoS Implementierung (Quality of Service), ebenso, wie das Forwarding in dem Kernel 2.2, in welchem Pakete markiert werden können.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING