12.5 Fallstricke mit Kernel Optionen für LINUX 2.0 und 2.2
Die Vielzahl von Adaptern und möglichen Kernel-Einstellungen sind für
Anfänger nicht nur verwirrend, sondern können auch die Firewall völlig
unsicher machen. Hier eine Diskussion der Probleme bei einigen Kernel -
Einstellungen:
- Fast Switching Ein Problem beim Tuning von LINUX sind die sogenannten Jumbo Frames oder Large Frames, die mit einer MTU > 9000 Bytes arbeiten. Es
gibt im Kernel von LINUX 2.0 und 2.2 eine Option zusammen mit dem Einsatz
von Myrinet, DEC, 3COM GIGABIT Adapter, die es erlaubt, diese sogenannten
Jumbo-Pakete direkt über den PCI-BUS von Adapter zu Adapter weiterzuleiten.
Diese Option wird im Kernel von LINUX 2.0 oder 2.2 "fast switching" genannt und
verhindert, daß der Kernel bzw. die Firewall - Routinen überhaupt angesprochen
werden. Das bringt natürlich einen erheblichen Gewinn an Geschwindigkeit.
Pakete mit kleiner MTU (< 1500) werden hingegen in jedem Falle gefiltert, Jumbo Frames
in Abhängigkeit der Kernel - Einstellungen nicht. Das steht zwar nirgendwo in der Dokumentation von LINUX, aber im
Quellcode (Ich habe lange danach gesucht, warum Jumbo Frames nicht gefiltert
werden....).
- Ein weiteres Problem betrifft Kernel 2.2 und die Option IP: advanced
router. Hier kann versehentlich die Option rp_filter für
Spoofing - Detection abgeschaltet werden (z.B. mit sysctrl). Dieses sollte
man erst gar nicht zulassen, indem man diese Option abschaltet und den Kernel
neu kompiliert.
- Die Option optimize as router not host bei den Kerneln 2.0 und
2.2 sollte unbedingt ausgeschaltet werden, da hierbei wichtige Prüfsummen - Checks auf
IP-Ebene sonst entfallen. Dies ist insbesondere bei Einsatz von IPFWADM und IPCHAINS
zwar mit kleinen Geschwindigkeitseinbußen verbunden, verhindert aber eine
Vielzahl von möglichen Angriffen. Ohne Überprüfung der IP-Checksumme können
Angreifer geziel Pakete konstruieren, die Server hinter der Firewall mit
einem DoS Angriff belegen.
- IP: large routing tables muß aktiviert werden, wenn man mehr
als 64 Routing-Einträge verwalten muß.
- IP: verbose route monitoring Übergibt ausführliche Routing Informationen
an den SYSLOGD.
- IP: policy routing ermöglicht das Routing nicht anhand der
Ziel-Adresse, sondern auch anhand der Quelladresse. Dies ermöglicht es,
Pakete für einzelne Hosts getrennt zu routen, und diese eventuell speziell
zu filtern.
- ARPD support kann ausgeschaltet bleiben, es sei denn, man
muß in großen Netzwerken den ARPD einsetzen, da der Kernel nur eine
bestimmte Anzahl von Adressen behält. Diese Option beschleunigt LINUX, wenn
viele Clients auf den Server/Router/Firewall zugreifen, da nicht jedesmal
ein ARP Broadcast für eine vergessen Hardwareadresse ausgesandt wird. Auch
die Netzwerklast wird durch den Einsatz des ARPD geringer. Das macht sich
insbesondere beim Einsatz von Netzwerkkarten mit zu kleinem ARP Cache
bemerkbar.
- GRE tunnels over IP (Kernel 2.2) erlauben das Tunneln von
IPv6 CISCO Router Informationen über IPv4. Da diese Pakete (IPv6 oder IPv4) nicht gefiltert
werden können, ist entweder die Option auszuschalten, oder man muß IPSec
Protokolle einsetzen.
- GRE broadcast over IP erlaubt es, CISCO Broadcast Protokolle über LINUX
Router hinweg zu transportieren. Mit aktivierten GRE Einstellungen kann man
mit LINUX Unternehmen vernetzen, und dafür sorgen, daß alle CISCO Router
weiterhin untereinander kommunizieren können, z.B. für die Überwachung einer
Security Policy unternehmensweit.
- IP: tunneling erlaubt nach dem SUN Standard IPoverIP Pakete
zu versenden. Damit kann man über eine ISDN Standleitung Netzwerke
miteinander verbinden.
- Multicast Routing ist eine interessante Einstellung. Wenn die Pakete
zulassen werden, können IP-Pakete an Hosts im Netzwerk adressiert werden, indem
diese in Multicast Pakete verpackt werden. Diese Pakete werde teilweise
schon in den Netzwerkkarten mit voller Hardwareunterstützung geroutet (DEC,
SMC, HP, WAVELAN). Diese Option sollte entweder ausgeschaltet werden, oder
sie erfordert den Einsatz einer zweiten Firewall im Intranet, welche
Multicast Pakete unterbindet, jedoch die in der ersten Firewall entpackten
IP-Pakete (Video/Musik) zu den Hosts im Intranet weiterleitet und überprüft.
Auch dies ist ein Grund, warum gute Firewall - Konstruktionen immer aus zwei Firewalls
bestehen müssen. Wer nur eine Firewall einsetzt, der sollte Multicasting
unter allen Umständen ausschalten, da ansonsten Angreifer mit IPoverIP
Paketen zu Servern hinter der Firewall durchdringen können.
- Die Option IP: equal cost multipath erlaubt es,
für Subnetze getrennte Routen einzutragen. Damit könnte es Probleme bei
SOURCE ROUTED PAKETS geben. Abschalten.
- IP: verbose route monitoring unbedingt anschalten. Man erhält
wertvolle Informationen über das Routing (nur wenn man mehrere
Netzwerkkarten (>2) betreibt, natürlich)
- Die Option IP:firewall packet netlink device dient dazu, die
Statusinformationen beim Einsatz von IPCHAINS auszulesen, um z.B.
counter intelligence Maßnahmen zu ergreifen. Siehe hierzu auch den
entsprechenden Abschnitt bei der SINUS Firewall. Diese Option kann auch dazu
verwendet werden, Pakete für bestimmte Netze an ein Device zu übergeben, wo
sie z.B. verschlüsselt oder gefiltert werden können. Auch als Monitor ist
diese Option verwendbar, z.B. mit TCPDUMP. Abschalten.
- IP: Always defragment ist obligatorisch immer einzuschalten, da
ansonsten Angriffe mit Fragment-Offsets drohen. Auch Masquerading
funktioniert nicht ohne diese Option.
- IP: Transparent PROXY ist soweit ok, sofern nicht spezielle
Protokolle, wie z.B. FTP, SSL-3 oder Real-Video eingesetzt werden. Diese
funktionieren natürlich nicht. Siehe Abschnitt über Protokolle.
- IP: Masquerading wird unweigerlich mit der Option IP: fast
network address translation kollidieren. NAT ist eine Adaption von N:M
Hosts, Masquerading eine Adaption von 1:M Hosts. Da Masquerading mehr
spezielle Protokolle unterstützt, sollte man Masquerading gegenüber NAT
bevorzugen.
- IP: FAST NETWORK ADDRES TRANSLATION ermöglicht es, M interne
Hosts auf N externen Hosts abzubilden. Hierbei ist M<=N. Es erfolgt eine
automatische Übersetzung von IP-Adressen. Diese Option schützt vor nichts,
kann aber ganz praktisch sein, weil man nicht alle Clients umkonfigurieren
muß, wenn man z.B. verschiedene Netzwerke (auch das Internet) über eine Standleitung
anbindet.
- IP: ICMP masquerading unterstützt masquerading für ICMP
Protokolle, wie z.B. PING. Abschalten, insbsondere beim Einsatz von LINUX
als ISDN Router, da ansonsten LINUX häufiger als nötig die Verbindung
aufbaut.
- IP: ipautofw masquerade support erlaubt masquerading für
Protokolle, wie z.B. PPTP, für die es keine offizielle Unterstützung gibt.
Abschalten.
- IP: ipportfw masquerade support erlaubt allgemein das
forwarding von Paketen über Netzwerkkarten hinweg. Abschalten.
- IP: ipmarkfw masquerade support erlaubt das forwarding von
Paketen mit Masquerading z.B. auch für Subnetze. Hierzu muß die Option IP: use FWMARK aktiviert
sein. Abschalten.
- IP: Kernel level autoconfiguration sollte ausgeschaltet
werden, da ansonsten jemand von außerhalb die ARP-Tabellen einsehen kann.
(Etwas tricky, aber es geht)
- Syn cookies sollte man ausschalten, zumal diese einen Angriff nur
dann verhindern, wenn der Angreifer mit LINUX und aktivierten SYN Cookies
arbeitet. Ansonsten sind diese für DoS anfällig.
- IP: Drop source routed frames sollte obligatorisch eingeschaltet sein.
- Allow large windows erlaubt einen DoS Angriff in schnellen Netzwerken
(größer nx100 MBit), ansonsten ist dagegen nichts zu sagen, die Performance wird
erhöht.
- Bridging sollte unbedingt ausgeschaltet werden, da ansonsten
die Pakete nicht mehr gefiltert werden.
- Forwarding between high speed interfaces ist ähnlich dem
fast switching, allerdings mit Kontrolle über Bandbreiten. Diese
Option sollte vorsichtshalber ausgeschaltet bleiben, da noch keine
Erfahrungen vorliegen. Das Problem mit Jumbo Frames ist hier kritisch.
- IP: use TOS ist eine Option, die es erlaubt, dynamisch Bandbreiten
in Anhängigkeit des Protokolls zu regeln und z.B. das Routing dementsprechend anzupassen. Dies birgt immer
die Gefahr, daß asymmetrische Routen auftauchen, welche in Firewalls zu
Fehlermeldungen führen können. Ansonsten ist hiergegen nichts einzuwenden,
besonders nicht, wenn man nur mit 2 Netzwerkadaptern arbeitet. (2 sind immer
gut, 3 ist immer einer zuviel)
- LOADABLE Module Support ist immer auszuschalten, da eventuell
jemand z.B. einen buffer overflow Attack im Appletalk Treiber
entdecken könnte. Dann bräuchte er nur ein Appletalk Paket an die Firewall
zu senden, diese würde den Treiber dynamisch laden - den Rest kann man sich
denken.
- Bei schnellen GIGABIT Netzwerk-Adaptern besteht immer das Problem von
Windows Oversize/Large Windows. Man sollte
hier entsprechend vorsichtig sein.
- socket filtering ermöglicht es Usern, eigene Filter zu
starten....Ausschalten.