![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Hier nur ein Überblick darüber, welche Prozesse innerhalb der Firewall stattfinden:
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.
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.
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:
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.Soweit die Hinweise auf die TOS Manipulationen für Modem und ISDN Verbindungen. Hierzu muß nur die Syntax in dem /etc/ppp/ip-ip Skript in ifconfig $1 txqueuelen verändert werden. Die einzusetzende Zahl hängt ganz von der Anwendung und der Modemgeschwindigkeit ab.
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.
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 |