Nachtrag zu Besser Filtern mit IP Tables
Rendundanz bei Filterregeln kann nicht schaden -- im Gegenteil: Sie schützt gegen Fehler und legt die Latte für Angreifer noch ein Stück höher.
Es kamen einige Nachfragen zum Sinn und Zweck der im Listing aufgeführten DROP-Regeln für $BAD_TCP und $BAD_UDP.
# bad ports -- never ever (teilweise redundant)
BAD_TCP="135:139 445 1433 2049 5999:6063"
for i in $BAD_TCP; do
iptables -A FORWARD -p tcp --dport $i -j DROP
iptables -A FORWARD -p tcp --sport $i -j DROP
done
Diese seien doch überflüssig und würden durch die FORWARD-Policy DROP bereits gefiltert. Das stimmt nur zum Teil.
Installiert man beispielsweise nachträglich ein IPSec-Gateway auf der Firewall, kommen diese Regeln unter Umständen zum Einsatz. Der bereits entschlüsselte Verkehr zwischen dem externen LAN und dem geschützten Netz wird dabei zwischen dem lokalen IPSec-Interface ipsec0 auf der Firewall und deren interner Netzwerkschnittstelle eth0 weitergeleitet. Die Regel
iptables -A FORWARD -m state --state NEW -i ! ppp0 -j ACCEPT
betrachtet ipsec0 als lokales Interface, sodass ein Verbindungsaufbau aus dem externen Netz ins lokale möglich ist -- was auch so sein soll. Oft möchte man allerdings trotzdem nicht, dass aus dem externen Netz Zugriffe auf SMB- oder NFS-Freigaben möglich sind. Dies verhindern die vorangestellten DROP-Regeln.
Das war beim ursprünglichen Zusammenstellen der Regeln noch gar nicht so beabsichtigt (der IPSec-Zugang kam erst später). Die Überlegungen dabei waren eher grundsätzlicher Natur. Wenn man weiß: Diese Art von Verkehr sollte keinesfalls über die Firewall gehen, dann sollte man das auch so hinschreiben und sich nicht darauf verlassen, dass irgendeine Default-Regel das später hoffentlich abfängt. Sonst kann es immer wieder passieren, dass eine nachträgliche Änderung am System diese Policy zunichte macht - wie es das IPSec-Beispiel eindrücklich illustriert. Gerade in Sicherheitsfragen schadet Redundanz nicht - im Gegenteil: Sie schützt vor versehentlicher Fehlkonfiguration und legt die Latte für Angreifer nochmal ein Stück höher.
Wer es genau nimmt, wird im Übrigen schon die Formulierung der ACCEPT-Regel über "! ppp0" kritisieren - und das zurecht. Denn diese setzt voraus, dass es nur ein externes Interface gibt. Auf ein später hinzukommendes Interface trifft die ACCEPT-Regel ebenfalls zu, was unter Umständen einen Verbindungsaufbau von außen ermöglicht. Besser wäre es, diesen für die Schnittstellen lo und eth0 (und ipsec0) explizit zu gestatten.
In dieselbe Kategorie fällt übrigens auch die Unsitte, auf einer Firewall Dienste einzurichten (oder nicht abzuschalten) und den Zugang zu diesen dann über Paketfilterregeln zu sperren, frei nach dem Motto: "Meine Statefull-Firewall erlaubt doch ohnehin nur eingehende Verbindungen von Innen". Falsch! Bei einer solchen Annahme sind Fehler vorprogrammiert. Fügt man irgendwann später eine Regel ein, hat man diese Überlegungen unter Umständen nicht mehr im Kopf und konfiguriert sich versehentlich ein riesiges Loch in die Firewall.
Auf einer Firewall laufen nur die unbedingt notwendigen Dienste! Und wenn ein Dienst für das LAN benötigt wird, dann darf dieser nur an die Netzwerkschnittstellen gebunden sein, auf denen er tatsächlich angesprochen werden soll; im Zweifelsfall eben nur das Loopback-Interface lo und eventuell die interne Netzwerkschnittstelle eth0. Gegen eventuelle Konfigurationsfehler zum Beispiel durch versehentliches Überschreiben der Konfigurationsdatei bei einem Update schützt dann noch eine zusätzliche, redundante DROP-Regel.
Einen Überblick, welche Dienste auf welchen Schnittstellen lauschen, liefert:
netstat -pltun
Steht bei der Ausgabe unter "Local Address" dann "0.0.0.0", ist der Dienst über alle Schnittstellen zu erreichen. Viele Server unterstützen mittlerweile Konfigurationen, die auf bestimmte Schnittstellen beschränkt sind. Den OpenSSH-Server kann man beispielsweise über die Anweisung
ListenAddress 192.168.1.1
in /etc/ssh/sshd_config ausschließlich an die interne Netzwerkschnittstelle binden, den Mail-Server Exim beschränkt
local_interfaces = 127.0.0.1
in/etc/exim/exim.conf auf das Loopback-Interface. Für andere Server-Dienste muss man die entsprechenden Konfigurationsoptionen der Dokumentation entnehmen. (ju)
