Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

notification level 10:
let pingcount:sourcehost := pingcount:sourcehost + 1 timeout 2;
if pingcount:sourcehost > 100 then
block all from sourcehost notification_level 0 timeout 600
endif;
Das Aufstellen von Filterregeln
In diesem Abschnitt werden alle oben nur definierten Filterregeln genauer abgehandelt. Es
wird ausdrücklich das Buch von Bellovin und Cheswick als "Bibel" für das Erstellen von
Filterregeln empfohlen. Im Kapitel firewallregeln sind aber auch die meisten dieser
Filterregeln noch einmal genauestens aufgelistet. Meiner Meinung nach ist die "Bibel" von
Bellovin und Cheswick inzwischen völlig veraltet, da sie sich ohnehin nur auf Probleme auf
Circuit-Level bezieht.
Die erste Frage die hier geklärt werden soll ist die Frage nach block oder reject von
Paketen.
In der Praxis ist diese Frage oft schwieriger zu beantworten, als es den Anschein hat.
Wenn ein Paket geblockt wird, also der Sender keine Fehlermeldung erhält, dann könnte
es sein, daß der Host meint, daß das Paket während der Übermittlung verloren gegangen
ist. Ein normaler Algorithmus in einem Programm oder Protokoll besitzt einen Timeout
Mechanismus, der nach einigen Versuchen abbricht. Wenn dieser eine ICMP Meldung
zurückerhält, in welcher der Host darüber informiert wird, daß ein Paket nicht ausgeliefert
werden kann (no route to host!), dann wird er sofort damit aufhören, welche zu senden.
Man sollte aber niemals Pakete unbedacht mit einer Angabe einer Fehlermeldung (reject)
ablehnen. Es könnte schließlich sein, daß die Anwendung, die die Pakete sendet, ICMP
Fehlermeldungen nicht interpretieren kann. In diesem Fall würde eine Flut von
Fehlermeldungen die freie Bandbreite der Leitungen unnötig belasten. Außerdem würde
von der Firewall eine Unzahl von Fehlermeldungen gesendet werden. Die gängigen
Implementierungen von TCP beachten sehr wohl ICMP Fehlermeldungen, aber in
Abhängigkeit der Meldung (host unreachable), könnte der Sender meinen, daß der Host
nur vorübergehend überlastet ist, und würde ständig die Pakete neu senden. Um also
wirklich eine Verbindung zurückzuweisen, ist es notwendig, im TCP Paket noch ein Flag
zu setzen, beispielsweise das RST Bit, welches das Ende einer TCP Verbindung
einleitet.(reset)
Viele Programme unterscheiden nicht zwischen den verschiedenen ICMP unreachable
Mitteilungen. Somit kann es passieren, daß ein Host völlig unerreichbar wird, was sicher
nicht so beabsichtigt ist. ICMP Fehlermeldungen sollten also niemals einfach mit einem
reject beantwortet werden. Um dieses Problem zu umgehen, benutzt die SINUS Firewall
die Option reject with best, was bedeutet, daß die TCP Pakete mit einem RST Flag
zurückgesandt werden. Eine ICMP port unreachable Nachricht wird für UDP und alle
sonstigen Pakete erzeugt.
Filtern von TCP Verbindungen
Wenn man die Regeln für TCP Pakete aufsetzt, gibt die from Adresse den Initiator der
Verbindung an. Antwortpakete aus dem Internet, z.B. sofern sie von innen initiiert worden
sind, dürfen die Firewall passieren. Sie haben alle das ACK Bit gesetzt. Ist der notification
level größer 0, dann wird nur zu Begin des Verbindungsaufbaues, also wenn das SYN Bit
gesetzt ist, ein Logeintrag erzeugt. Alle weiteren Antwortpakete werden nicht mehr
mitgeloggt.
Das FTP Protokoll erfordert eine spezielle Behandlung, da hier ein zweiter Datenkanal
geöffnet wird, welcher vom Server initiiert wird. Die erste Verbindung, die von innerhalb
geöffnet wurde enthält den PORT Befehl, der vom Server zum Client intern übermittelt
wird. Dieser Port ist derjenige, den der Server zwecks Datenaustasch mit dem Client zu
benutzen gedenkt. Eine normaler, dynamischer Paketfilter würde diesen PORT Befehl
Erstellt von Doc Gonzo - http://kickme.to/plugins