![[Inhalt]](toc.gif)
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Der vorhergehende Abschnitt handelte über das Firewall-Device. Das Device ist im übrigen auch in der Lage, Schreibzugriffe zu handeln. Alle Schreibzugriffe werden als Befehle für die Filterfunktion interpretiert. Um ein Durcheinander in den Filtertabellen zu vermeiden, werden alle Schreibzugriffe nach einer magischen Signatur durchsucht. Wenn diese nicht der Fall wäre, so könnten die Filtereinstellungen per Zufall verändert werden.
Der Firewall-Dämon erzeugt und löscht Filterregel, indem er einfach in das Firewall-Device hineinschreibt. So ist es möglich, daß Firewalls im Cluster sich über die dynamischen und statischen Filterregeln austauschen.
Der Filter kann von außen durch das SFC Userprogramm und die JAVA-Applets die Filterfunktion umkonfigurieren. Hierzu wird das Firewall-Device im write only Modus geöffnet. Während des Datentransfers wird die Verarbeitung der eintreffenden Pakete eingestellt, um eine Vermischung mit bestehenden Regeln zu vermeiden.
Der User muß stets über die gerade aktivierten Filterregeln informiert sein können. Hierzu genügt es, mit dem sfc Userbefehl die aktiven Regeln aus dem Kernel Filter Modul auszulesen.
Wenn das Firewall-Device einen Lesezugriff bemerkt (im Gegensatz zu schreib/lese und schreib Zugriff), sendet es die aktiven Regeln an das sfc Programm.
Das Firewall-Device ist während eines Zugriffs nicht deinstallierbar.
Der Firewall-Dämon bemerkt, ob bereits ein solcher installiert ist. Der Quellcode dieses Dämons ist in mehrere Files aufgespalten. sfc.c, sf_log.c, sf_spy.c:
Immer dann, wenn das SFC Programm gestartet wird, prüft es nach, ob es nicht mit Supervisor - Rechen gestartet wurde. Danach erst durchsucht es das Konfigurationsfile, soweit vorhanden. Es überprüft weiterhin, ob der Firewall-Dämon bereits läuft. Das File firewall.pid enthält die Prozess-ID (ps xa) des laufenden Firewall-Dämons. Diese ProzessID wird benötigt, den Dämon anzuhalten, zu rekonfigurieren und user Befehle anzuzeigen.
Der Firewall-Dämon reagiert auf alle Signale, bis auf SIGKILL und SIGSTOP. Die Signale des Signalhandlers (kill) wirken sich auf alle Funktionen der Firewall aus.
Über den Signalhändler werden Timeouts von dynamischen Firewallregeln und Variablen (Alarmfunktion) geregelt, das Programm beendet (SIGTERM), und eine Kopie initiiert (SIGUSR2), sowie Variablen in eine Firewall Pipe geschrieben.
Das Signal SIGUSR2 wird von dem SFC Programm gesendet, z.B. um Variablen anzuzeigen (sfc show). Der Firewall-Dämon forkt dann, um einen Schnappschuß seines momentanen Zustandes festzuhalten. Andernfalls würden sich Variablen während des Auslesens verändern, der Zustand wäre nicht eindeutig. Da nun der User mit dem SFC Programm in Ruhe den Zustand betrachten und analysieren kann, kann auch der Firewall-Dämon weiter laufen. Es ist allerdings zu beachten, daß gerade bei Hispeed Netzwerken genügend RAM zur Verfügung steht.
Die Firewall Pipe ist eine "named pipe" und wird dazu benutzt, um diejenigen Daten, wie Variablen, dynamische Regeln von der Kopie des Firewall-Dämons zu erhalten. Da die Daten aus dem Firewall-Device zu dem laufenden Firewall-Dämon gehören, kann nur über dieses Ersatzdevice der Zustand der momentanen Kopie des Firewall-Dämons abgerufen werden. Diese steht unter der Kontrolle des SFC Programms.
Sehr wichtig ist zu erwähnen, daß der Firewall-Dämon niemals auf die Beendigung seiner Kinder (child) wartet. Damit keine Zombies entstehen, muß dieser immun gegen das Signal SIGCHLD sein. Er ignoriert dieses, da ein Returnwert der Children (error, successfully terminated) ohne Belang ist. Diese Verhalten veranlaßt das Betriebssytem, die Prozesstabelle zu bereinigen und belegte Plätze aus der Tablle zu entfernen. Das Aufsetzen der Signaltabelle erfolgt in der Funktion start_log.
Der Firewall-Dämon benutzt auf dem Host installierte Programme, um E-Mails o.ä. zu versenden, counter intelligence Programme zu starten, oder irgendwelche Prozesse auszuführen, die mit Userrechten ausgeführt werden können. Da der Firewall-Dämon ein unprivilegierter Prozess ist, kann er auch keine privilegierten Programme starten, oder Befehlsparameter übernehmen, die von einem anderen Host übermittelt wurden. Es sollte aber stets berücksichtigt werden, daß der Firewall-Dämon über die Kernelroutine "system()" Programme startet. Die Ausführung von Programmen übergeben an den Firewall-Dämon Rückgabewerte, die zu einem "buffer overflow" führen können. Aus diesem Grund werden "control character" aus den Rückgabedaten herausgefiltert. Endlose Datenströme als Rückgabewert (dev/random) werden nach einem Timout beendet. Die maximale Zahl der Einträge in Prozeßtabellen ist begrenzt.
Der Firewall-Dämon muß viel mit Timeouts arbeiten. Da viele Ereignisse und deren Dauer von anderen Ereignissen abhängig sind, besitzt die Firewall einen Eventmanager. Timeouts werden hierin in einer linearen Liste festgehalten, der Event Queue (event_queue). Hierin werden auch Funktionsadressen und deren Parameter festgehalten. (struct timeout in sf_log.c). Um ein Ereignis hinzuzufügen, wird die add_event() Funktion benutzt. Sie benutzt den Alarm-Mechanismus und definiert den Timeout des nachsten Ereignisses. Wenn vom Signalhändler das SIGALARM Signal an die Funktion "catch_alarm()" gesendet wird, dann wird der nächstfolgende Timeout für einen Befehl abgearbeitet. Falls der Firewall-Dämon in diesem Moment zu beschäftigt sein sollte, wird die Ausführung des Befehls von der Funktion "process_alarm" ausgeführt. Der Firewall-Dämon wird hierzu unterbrochen.
Timeouts werden für folgende Funktionen eingesetzt:
Timeouts sind in dem File sf_custom.h definiert und sollten entsprechend den Anforderungen beim Einsatz in Hochleisungs - Netzwerken angepaßt werden.
Der Firewall-Dämon schreibt alle Error - Meldungen in die Logfiles und sendet ggf. E-Mails an den User, z.B. wenn der freie Speicherplatz auf der Festplatte den Wert von 2 MByte unterschreitet. Wenn alle diese Funktionsaufrufe versagen, dann schreibt der Firewall-Dämon die letzten Meldungen auf die Konsole und unterbricht allen Netzwerkverkehr.
Der Firewall-Dämon übergibt Nachrichten sowohl an den SYSLOGD und schreibt in sein eigenes Logfile. Während der SYSLOGD automatisch mehrfache Einträge bereinigt (last message repeated...times), mußte dieses Verhalten in den Firewall-Dämon expliziert hinein programmiert werden. (flogf() Funktion). Wenn der Firewall einen Eintrag im Logfile vornimmt, so wird vorher überprüft, ob diese Nachricht bereits existiert. Falls dies zutrifft, wird ein Zähler angeworfen, der solange hochzählt, bis eine andere Nachricht erscheint. In diesem Falle werden in das Logfile die Zahl der Ereignisse und deren Dauer geschrieben, bevor die neue Nachricht geschrieben wird. Dies ist kein Schutz vor schnell wechselnden Angriffsmethoden mit wechselnden gespooften IP-Adressen. Hiergegen gibt es keinen Schutz. Für den Fall, daß keine Ereignisse eintreten, wird in ein Eintrag periodisch erzwungen, als Kontrolle der Funktionsfähigkeit der Log-Funktion.
Variablen werden in einem Array des Typs struct gespeichert. Es ist für die korrekte Zuordnung der Variablen zu Netzwerken, Hosts... notwendig, daß jeder Eintrag als Struktur erfolgt. Es existieren zu jedem Variablennamen also eine Vielzahl von Untereinträgen. Um diese Unterteilung von Variablen vornehmen zu können, kann eine dynamische Liste von Hosts jeder einzelnen Variablen zugeordnet werden. Der Eintrag in das Array wird dann zu dem Kopf der Liste, dem Rooteintrag. In jedem Rooteintrag wird das Adressfeld nicht berücksichtigt. Es enthält aber die Summe aller Einträge in der Hostliste und die Timeout-Werte der jeweils am längsten lebenden Einträge darin. Wenn also ein Variable mit einem Timeout versehen wird (firewall.conf), wird der Wert 0 zurückgegeben. Hierbei ist im Gegensatz zu den dynamischen Filterregeln kein alarm oder Signal erforderlich. Wenn ein neues Element an die Liste der Hosts angefügt wird, wird die Liste zuerst nach Elementen durchsucht, die veraltet sind. Wenn ein solches gefunden wird, wird dieser Eintrag aufgefrischt, andernfalls wird ein neuer angelegt. Diese Funktionen befinden sich in dem File sf_daemon.c
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |