![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
In diesem Abschnitt sind alle Details des eigentlichen Filters beschrieben (sf_filter.c). Jedesmal, wenn ein IP Paket gesendet oder empfangen wird, wird die Funktion sf_check_packet aufgerufen. Die Parameter sind ein Zeiger auf den Beginn des IP Headers, ein Zeiger auf das Device (Netzwerkinterface) und ein Feld von Flags, die anzeigen, ob eine Paket gesendet, empfangen oder weitergeleitet wird (forward). Die Funktion wird in den Files ip.c und tcp.c des Kernels aufgerufen. Die Rückgabewerte sind in den Files sf_kernel.h definiert, und informieren den Kernel darüber, ob ein Paket gelöscht, weitergeleitet oder eine ICMP Nachricht ausgesendet werden muß. Die Filterfunktion benachrichtigt den Kernel schnellstmöglich darüber, ob ein Paket erlaubt oder verboten ist. Die Filterfunktion führt nicht alle Tests in jedem Fall durch. Einige können vom Kernel übernommen werden (IP_defrag...).
Das erste Paket eines Hosts wird auf address spoofing hin überprüft. Für den Fall, daß es nicht vom Loopback Interface stammt, aber dort als Quelladresse oder Zieladresse die Loopbak Adresse eingetragen ist, wird das Paket verworfen. Wenn das Paket von der Firewall selber stammt, also eine IP-Adresse der Netzwerkinterfaces besitzt, oder Quell-und Zieladresse eine lokale IP - Nummer besitzen, ist nur noch der anti spoof test erforderlich. Dann kann das Paket passieren, und der Filter gibt den Wert SF_RC_ACCEPT zurück.
Nun muß in der HASH-Queue überprüft werden, ob das Interface internal oder external ist. Findet sich kein Wert in der HASH Queue, so wird die Funktion sf_inside() aufgerufen. Sie überprüft, ob die Interface-Adresse mit der internalnet Adresse übereinstimmt. Das Ergebnis wird in die HASH Queue geschrieben, es wird später ausgewertet.
Wenn ein Paket empfangen wird, wird die Quelladresse für eine Überprüfung des Quellcodes herangezogen, andernfalls wird die Zieladresse benutzt. Wenn die Adressen nicht der Adresse eines Hosts und nicht der des Loopback Interfaces entsprechen, müssen die Paketadressen und Interface Adressen entweder internal oder external sein. Wenn adress spoofing entdeckt wird, werden die internen Firewallregeln RULE_SPOOF_RECV oder RULE_SPOOF_XMIT aktiv. Die enthaltenen Informationen werden an den Firewall-Dämon übergeben. Die weiteren Paketinformationen werden dann verworfen.
Für den Fall, daß ein Paket weitergeleitet wird, kann die weitere Überprüfung nach der Überprüfung auf spoofing entfallen.
Wenn ein Fragment Offset in dem IP-Header gesetzt ist, wird die Paket-ID als HASH-Wert mit evtl. Einträgen in vorangegangenen Paketen verglichen und dem Filter mitgeteilt, ob ein Paket passieren darf, oder nicht. Die Einträge in der HASH Queue sind dem Timeout - Mechanismus unterworfen, der diese löscht, wenn längere Zeit keine Pakete mehr erfolgreich die Firewall durchlaufen haben. Der Timeout-Zähler beginnt von Neuem, wenn der Vergleich positiv war. Das Fragment muß auch hier nicht weiter überprüft werden, es wird automatisch intern weitergeleitet. Mit dem Eintreffen eines fragmentierten Paketes und dem Aufruf der Funktion SF_CHKFRAG wird ein neuer Eintrag in die HASH Queue vorgenommen, und der Timer zurückgesetzt.
Zugelassene TCP Verbindungen werden in HASH Queues gespeichert. Der HASH Schlüssel berechnet sich aus der Summe von Quelladresse, Zieladresse, und den zugehörigen Portnummern, modulo der im Quellcode angegebenen Primzahl (499 in sf_filter.c). Die Adressen sind zuvor in 32 Bit Integerwerte konvertiert worden. Die HASH Tabelle enthält den Status einer TCP Verbindung. Der Filter kann so schnell bestimmen, ob eine Verbindung besteht, ein Host die Verbindung abbrechen möchte, die Verbindung beendet ist.....
Ein eintreffendes Paket, welches einen Verbindungswunsch anzeigt, hat das SYN Flag gesetzt, nicht aber das ACK Flag. In diesem Falle ist die TCP Verbindung noch nicht in der HASH Queue gespeichert, mit Ausnahme von FTP Verbindungen. Der Rest des TCP Paketes wird übergangen und das TCP Paket wird auf Verletzungen gegen die Regeln überprüft.
Für den Fall, daß das TCP Paket zulässig ist, wird es mit den in der HASH Queue gespeicherten Pakete verglichen. Gehört es nicht zu anderen Paketen, so wird es verworfen. Es wird den Filter nicht passieren.
Angenommen, daß TCP Paket gehört zu einer erlaubten Verbindung. Das Paket muß dann überprüft werden, ob dieses Paket eine FTP - Verbindung darstellt. Dies wird durch Durchsuchung des Inhaltes nach dem "PORT" Befehl festgestellt. In diesem Falle wird ein neuer HASH Eintrag erzeugt. An dieser Stelle ist es möglich, weitere Protokolle zu implementieren, z.B. RPC, welches für Windows NT PDC, RSYNC, RSH....notwendig ist. Der Rest des TCP Codes ist selbsterklärend. Das Statusfeld und der Timer- Mechanismus sind entsprechend dem Mechanismus zu Behandlung der Flags im TCP Header implementiert.
Es ist möglich, zu einer bestehenden TCP Verbindung einen Timeout hinzuzufügen. Hiermit kann man Einträge in der HASH Queue löschen, die unterbrochen wurden, oder zu lange Wartezeiten zwischen den Paketen besitzen. Um dieses zu tun, muß bei der Herstellung einer Verbindung ein Timer initialisiert werden, der jedesmal, wenn ein Paket einer gültigen Verbindung passiert, von neuem beginnt, zu zählen (reset). Sicherlich würde dieser Mechanismus die Effektivität der Firewall beeinträchtigen und hängende Verbindungen möglicherweise unnötig beenden.
Für höhere Effizienz der Firewall werden nur neue TCP Verbindungen und Nicht-TCP Pakete analysiert. Die lineare Liste des Regelwerkes in der Firewall wird der Reihe nach mit dem Inhalt des Datenpaketes verglichen. Sobald eine Regel zutrifft, wird das Paket für weitere Untersuchungen markiert und gespeichert.
Die erste Untersuchung (Inspektion) gilt dem Protokoll. Die Protokollfelder des Regelwerkes werden mit denen des Paketes verglichen.
IGMP und ICMP Pakete werden einer gesonderten Untersuchung unterworfen, in der festgestellt wird, ob der Typ in den Regeln enthalten ist. Dieses muß in einem "switch" Statement (C,C++) erfolgen, weil eventuell weitere Typen in dem Paket in einer Bitmap enthalten sein könnten.
RIP Pakete werden ebenfalls einer gesonderten Behandlung unterzogen. Für den Falls das das Paket ein UDP Paket ist, und auf Port 520 zugreift, dann wird die Funktion check_rip() aufgerufen, um zu ermitteln, ob alle angekundigten Ziele in dem Regelwerk aufgelistet sind.
An dieser Stelle können beliebige Tests für Nicht TCP Protokolle eingefügt werden, z.B. weitere Routingprotokolle, wie OSPF...
Nach dem Test auf TTL, IP Optionen werden Quell- und Zieladresse, Ports...durch die Funktion sf_addr_match() auf Verletzungen der Regeln untersucht. Hier sind erklärende Kommentare im Quellcode eingefügt. Am Ende aller Untersuchungen zeigt die Variable "rule" auf die zutreffenden Regeln, oder auf NULL, wenn keine der Regeln zutreffend ist. Wenn eine Regel auf ein TCP Paket zutrifft, dann wird ein Eintrag in der HASH Queue für diese Verbindung vorgenommen. Wenn dann keine Log-Einträge mehr abzuarbeiten sind, kann der Filter seine Arbeit beenden.
Der Transfer der Log-Einträge vom Filter zum Firewall-Dämon erfolgt über einen Puffer im Firewall-Device. Falls der Puffer voll ist, werden alle Pakete verworfen, egal ob die Filterregeln zutreffen, oder nicht. Für die betroffenen Hosts erscheint dieses so, als wenn Pakete aus unbekannten Gründen verlorengegangen sind.
Log-Einträge bestehen aus dem Rückgabewert, der Regel ID, dem Namen des Devices und den ersten 176 Bytes des Paketes. Die Größe wurde so gewählt, daß zumindest alle Protokollheader aufgezeichnet werden, und die Gesamtgröße der Log-Struktur die maximale Größe für eine Speicherseite nicht überschreitet (Siehe sf_filter.h).
Nun wird der Firewall-Dämon aufweckt, damit die Filterfunktion den Rückgabewert einer zutreffenden Regel übergeben kann.
Wann immer das SFC Userprogramm gestartet wird, um Konfigurationen vorzunehmen, werden alle Informationen des Firewall-Dämons über das Firewall-Device an den Filter übergeben. Das Device ruft die Funktion sf_write_config() (in sf_filter.c) auf. Die Funktion fordert neuen Speicherraum an, und kopiert den gesamten Puffer hinein. Es muß berücksichtigt werden, daß der C-Compiler z.B. um 1025 Byte zu speichern, 2048 Byte anfordert. Wenn also ein bestehender Buffer von knapp über 1 MByte Größe kopiert werden muß, daß ca. 4 MByte tatsächlich benötigt werden. Die Firewall ist also immer mit genügend RAM auszustatten. Danach wird der Befehl interpretiert und die entsprechende Funktion aufgerufen.
sf_init() wird aufgerufen, wenn das Kernel Filtermodul eingefügt wird, um die HASH Queues zu initialisieren.
sf_del_all_timers wird aufgerufen, wenn das Filtermodul entladen wird. Alle aktiven Timer müssen beendet werden, damit Speicherplatz korrekt wieder freigegeben werden kann.
sf_clear, sf_add, sf_replace und sf_delete werden aufgerufen, um die lineare Liste des Regelwerkes bearbeiten zu können, sf_flush and sf_flush_all sind bereits in ihren Funktionen beschrieben worden.
Wenn immer der Befehl SF_COMMAND_FW_ADDR eingegeben wird, wird der Buffer kopiert. Hierfür ist die Funktion sf_write_config zuständig. Die Funktionen sf_rule_first und sf_rule_next werden für die Übergabe der Konfiguration an den aktuellen SFC Prozeß bei der Eingabe von "SFC SHOW" benötigt. Die nächste Regel, die übergeben wird, ist in rule_first_next gespeichert. Die Konfiguration wird also an den Filter übergeben, obwohl der Firewall-Dämon alle geraden aktiven Regeln kennt. Nur so kann der User sicher sein, daß die Ausgabe der momentanen Filterregeln, Variablen und Zustände auch tatsächlich dem momentanen Zustand der Firewall zu einem bestimmten Zeitpunkt entspricht. Die etwas schlechtere Performance während dieses Zeitpunktes der Abfrage ist hier nicht so wichtig, da der Befehl "SFC SHOW" nicht so häufig ausgeführt wird.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |