![[Inhalt]](../../Grundlagen/Firewall/images/toc.gif){kind=small}
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
In diesem Abschnitt befinden sich alle Informationen und häufig gestellten Fragen, die nicht in die oberen Abschnitte passen.
Hier sollte man sich Gedanken machen, wie man die Firewallregeln aufbaut. Sie können nach Geschwindigkeit und Übersichtlichkeit geordnet werden.
Für eine Modem- oder ISDN Verbindung sollte die Policy als erstes gesetzt werden, und dies bereits beim Booten des Systems. Hier könnte folgendes in dem Skript /etc/ppp/ip-up eingetragen sein:
# Vorher die ppp-in chain anlegen !
ipchains-restore -f < ppp-in.firewall
# Nun die DENY Regel durch ein Sprung auf die ppp-in chain ersetzen
ipchains -R input 1 -i ippp0 -j ppp-in
Im ip-down Skript müßte dann folgender Eintrag stehen:
ipchains -R input 1 -i ippp0 -j DENY
ICMP Pakete werden benutzt, um Fehler zu übermitteln, die bei anderen Protokollen aufgetreten sind, z.B. TCP und UDP. Hier gibt es verschiedenste Fehlermeldungen, z.B. destination-unreachable, Host unreachable oder No route to host. Ohne diese Fehlermeldung würde der Host immer wieder versuchen, den Server zu kontaktieren. Das kann eine erhebliche Belastung der Netzwerkbandbreite bedeuten. In einigen Fällen kann dies dazu führen, daß die Firewall "hängt".
Ein schwierigeres Problem ist die Rolle der ICMP Pakete in der MTU (Maximun Transfer Unit). Alle guten TCP/IP Stacks benutzen diese, um herauszufinden, welche maximalen Paketgrößen bei der Übertragung verwendet werden können, ohne daß diese fragmentiert werden müssen. Die Ermittlung erfolgt schrittweise, es werden Pakete in absteigender Paketgröße mit dem dont fragment bit gesetzt. Der Router würde dann zurückmelden: fragmentation needed. Wenn keine Fehlermeldung mehr kommt, dann ist die maximale Größe für ein Fragment erkannt worden. Werden also diese Fehlermeldungen gesperrt, dann ist mit Fehlern bei der Übertragung oder mit Einbrüchen der Performance zu rechnen.
Beim Sperren von DNS-Anfragen, sollte man wissen, daß die DNS-Server nicht immer die Daten über UDP austauschen. Wenn die Paketgröße 512 Byte überschreitet, dann wird eine TCP Verbindung hergestellt, die größere Datenmengen sicher übertragen kann. Hierzu wird der Port 53 TCP benötigt. Auch wenn DNS-Anfragen bereits über die Firewall hinweg funktionieren, bedeutet das nicht, daß auch komplexere Zonentransfers über UDP abgewickelt werden können.
Wenn DNS-Anfragen stets an dieselbe externe Quelle gerichtet sind,
Beispielsweise den DNS-Server des Providers, dann sollte dieser in der nameserver
Zeile der Datei /etc/resolv.conf eingetragen sein, oder, falls ein
caching nameserver im forward mode aktiviert wurde, dann
ist nur eine TCP Regel erforderlich.
Das klassische Problem beim Filtern von FTP ist, daß FTP zwei völlig unterschiedliche Modi besitzt, active mode und passive mode, auch PASV genannt. WWW-Browser melden sich standardmäßig im passiven Modus an. Da FTP über einen Steuer und einen Datenkanal (Port 20+21) die Daten austauscht, ergeben sich gewisse Probleme.
Im aktiven Modus versucht der Server, zu dem Client aktiv eine Verbindung für den Datenkanal aufzubauen. Die Firewall kann diesen Vorgang nicht erlauben, ohne Ports oberhalb von 1024 komplett frei zu schalten.
Im passiven Modus bestimmt der Client beide Kanäle, also für den Verbindungs - und den Datenkanal. Damit nicht aus versehen ein Port für X-Windows angesprochen wird, sind die Ports zwischen 6000 und 6010 zu sperren.
Für Linux Server war schon eine halbe Stunde nach der Veröffentlichung des Problems ein Patch im Internet verfügbar. Dieser Angriff basiert auf zu großen ICMP Paketen.
Um Server im Intranet oder Extranet gegen diesen Angriff zu sichern, müssen ICMP Fragmente gesperrt werden. Damit nicht das letzte Fragment die Server korrumpiert, müssen alle Fragmente gesperrt werden, also nicht nur das erste mit SYN Flag, sondern auch alle mit ACK Flag.
Teardrop und Bonk sind Angriffe, die hauptsächlich gegen Windows NT 4.0 Server gerichtet sind. Diese basieren auf überlappenden Fragmenten. Um diesen Angriff zu verhindern, müssen alle Fragmente gesperrt werden, oder es muß eine Reassemblierung im IP-Stack durchgeführt werden.
Einige altere TCP Stacks haben Probleme mit größeren Fragmenten von Paketen. Obige Maßnahmen sind bereits als Schutz ausreichend.
Manchmal ist es sinnvoll Filterregeln zu ändern. Hierzu sollte man folgendermaßen vorgehen. Ein Beispiel:
# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY
Die Änderungen:
# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#
Wenn sich die Änderungen auf eine einzige chain beziehen, dann sollte eine neue chain mit neuen Regeln angelegt werden, und dann diejenige Regeln in der input (oder anderen) chain geändert werden, so daß sie nun auf die neue chain zeigt.
IP Spoofing ist ein Angriff, bei dem Pakete mit falscher Absende- Adresse vorgetäuscht werden. Viele der exploits im Internet, die Teardrop, Ping of Death Angriffe ausführen, verwenden spoofing.
Der einfachste Weg ist die Überprüfung der Quell-IP - Nummer und dem zugehörigen Interface. Diese Überprüfung findet im IP Routing Code statt, also nicht in dem Firewall-Code selber. Um dieses zu überprüfen, sollte das Vorhandensein der Datei: /proc/sys/net/ipv4/conf/all/rp_filter überprüft werden. Wenn diese existiert, dann können die Regeln aktiviert werden.(Debian Users sollten diese Regeln in die Datei /etc/init.d/netbase eingeben.
# Allgemeiner anti spoofing Schutz
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "Setting up IP spoofing protection..."
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
echo "done."
else
echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED.
echo "CONTROL-D will exit from this shell and continue system startup."
echo
# Start a single user shell on the console
/sbin/sulogin $CONSOLE
fi
Falls dieses so nicht möglich ist, dann muß für jedes Interface eine eigene anti spoofing Regel aufgesetzt werden. Im Kernel von Linux 2.2 ist ein Schutz gegen Angriffe auf 127.x.x.0, also im loopback interface, standardmäßig aktiviert.
Angenommen, es existieren drei Interfaces eth0, eth1 und
ippp0. ifconfig wird die Netzwerkadressen und Netzmasken
anzeigen. Nun muß verhindert werden, daß Pakete mit falscher oder
gefälschter Absende - Adresse am falschen Interface eintreffen. Diese müssen
in der input chain gesperrt werden:
# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#
Die allgemeine Variante, spoofing vom Linux Kernel Routing Code zu aktivieren, ist die bessere, weil bei der Änderung der Netzwerkadresse die Firewallregeln nicht geändert werden müssen.
Für den Kernel Version 2.0 muß explizit noch eine anti spoofing Regel implementiert werden.
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
Paul Russel, der diese Anleitung im Original verfaßt hat, hat eine Bibliothek für Firewall- Erweiterungen geschrieben. Es basiert auf den Filtern im Firewall-Kernel und ermöglicht die Implementierung von Filtern mit User-Rechten. Diese Bibliothek heißt libfw
Dinge, wie stateful inspection, oft auch als dynamic firewalling bezeichnet, können mit dieser Bibliothek als Userdämon ausgeführt werden.
Die Fähigkeiten, Pakete zu markieren, wird von den kommerziellen Firewalls zumeist nicht richtig unterstützt. Unter LINUX kann so ein Quality of Service Dienst realisiert werden. Dieses ist bereits im Kernel unterstützt. Weitere Hinweise sind in der Dokumentation des Kernel-Codes zu finden.
Es existiert eine NAT Implementierung, offiziell ist diese aber für die Version 2.4 erst verfügbar.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |