Private Feuerwände
Paketfilter-Firewall
Alte Regeln weg und neue her
Beim Aufsetzen der Firewall vermeidet es Komplikationen, wenn man eventuell bereits systemseitig vorgefertigte Firewall-Konfigurationen abschaltet. Damit lautet der erste Eintrag in der Datei, in der wir die Firewall bauen
iptables -F
Anschließend sperren wir, unserer Default-Policy folgend, alles ab. Da davon der komplette Netzwerkverkehr betroffen ist, sollte man beim Erstaufruf des Firewall-Skripts direkt an der Konsole des Firewall-Rechners sitzen:
iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP
Unsere erste Regel gilt dem WWW. Beim dort verwendeten HTTP baut ein Client auf unserem Computer, beispielsweise Netscape, eine Verbindung zu einem Web-Server auf. Dieser arbeitet in der Regel hinter dem Port 80. Anhand dieser Nummer erkennt die Firewall, dass es sich vermutlich um eine HTTP-Verbindung handelt.
Zum Erstellen der Regel kommt wieder der Befehl iptables zum Einsatz. Um TCP-Datenverkehr (-p tcp) an den "Destination Port" 80 (--dport 80, in der Regel also HTTP-Server) rauszulassen (-j ACCEPT), gibt man Folgendes ein:
iptables -A OUTPUT -p tcp --sport 1024: --dport 80 -j ACCEPT
-A OUTPUT hängt die neue Regel an die OUTPUT-Chain an. --sport 1024: steht für Source Port; dieser muss in der Regel mindestens 1024 sein, aber durch den angehängten Doppelpunkt sind auch alle darüberliegenden Ports erlaubt. Jetzt können wir ein Paket an einen Web-Server schicken, allerdings kommen die Antworten noch nicht zu uns durch.
Theoretisch könnte man für diese Antworten eine exakt symmetrische Regel konstruieren, und viele Leute gehen genau so vor. Diese lautet
iptables -A INPUT -p tcp --sport 80 --dport 1024: ! --syn -j ACCEPT
Absender- und Empfängerports sind vertauscht. Neu ist die Option ! --syn, also "nicht --syn". --syn prüft bestimmte Flags im Header des TCP-Pakets und erkennt damit das allererste Paket einer neuen Verbindung. Die Option ! --syn verweigert also den Aufbau einer neuen Verbindung, während Pakete erlaubt werden, die zu bestehenden Verbindungen gehören. Programme auf unserem Computer dürfen fremde Rechner kontaktieren, aber nicht umgekehrt.
Mir persönlich ist es etwas zu viel Aufwand, alle Regeln doppelt zu halten. Im Bewusstsein, dass ich damit potenziell mehr Pakete zulasse, als ich eigentlich will, begnüge ich mich mit einer einzigen Regel für alle ankommenden TCP-Pakete sämtlicher Protokolle:
iptables -A INPUT -p tcp --dport 1024: ! --syn -j ACCEPT
Sofern ein Paket nicht eine neue Verbindung aufbauen will, sind alle Pakete an unsere Clients erlaubt, egal, von welchem Absender-Port.
Kasten 2: Überwachung von Verbindungen
Über die iptables-Option ! --syn in den Regeln der INPUT-Chain filtert man Pakete heraus, die eine neue Verbindung aufbauen wollen, und lässt nur Daten aus bereits bestehenden Verbindungen zu. So dürfen eigene Clients einen fremden Dienst benutzen, während der umgekehrte Weg blockiert bleibt.
Dabei handelt es sich jedoch um einen ganz primitiven Mechanismus. Theoretisch könnten beliebige fremde Computer Pakete an uns schicken, solange diese nicht einen Verbindungsaufbau initiieren. Wir verlassen uns darauf, dass der Kernel solche zusätzlichen Pakete ignoriert.
Trickreicher ist die Verwendung eines separaten Moduls zur Überwachung des Verbindungszustands. Wenn wir das tun, merkt sich die Linux-Firewall alle bestehenden TCP-Verbindungen. Sobald nun ein Paket ankommt, prüft sie, ob es zu einer bekannten Verbindung gehört, und lässt es gegebenenfalls ohne weitere Rückfragen zu. Auf die Regeln mit ! --syn können wir nun verzichten.
Dieses Modul wird durch zwei iptables-Befehle aktiviert:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Es werden alle Pakete angenommen, die entweder Teil einer bestehenden Verbindung sind oder als "verwandt" erkannt werden. "Verwandt" sind beispielsweise ICMP-Fehlermeldungen oder auch die besonderen Datenkanäle einer FTP-Sitzung.
Regeln für die üblichen Verdächtigen
Entsprechend gestaltet man die Regeln für die üblichen Netzwerkdienste. Aus Platzgründen finden Sie das komplette Firewall-Skript [3] auf der Heft-CD. Für typische Benutzer interessant sind folgende Ports:
- 21 – FTP (Dateiübertragung)
- 22 – SSH (SecureShell)
- 23 – telnet (unsichere Alternative zu SSH)
- 25 – SMTP (Mail-Versand)
- 43 – whois (Verzeichnis der Inhaber und Betreiber von Internet-Domains)
- 53 – DNS (Zuordnung von Domain-Namen und IP-Adressen)
- 79 – finger (Abfrage von Benutzerinformationen)
- 110 – POP3 (Mail-Empfang)
- 119 – NNTP (Usenet-News-Versand und -Empfang)
- 143 – IMAP (Mail-Empfang)
- 443 – HTTPS (abgesicherte WWW-Verbindungen)
- 554 – RealPlayer G2 (Audio- und Video-Übertragungen)
Die Regeln dafür sehen aus wie das für Port 80 beschriebene Muster. Eine Ausnahme macht FTP: Für jede Dateiübertragung wird hierbei eine eigene TCP-Verbindung unter Verwendung eines der oberen Ports aufgebaut. Im klassischen, aktiven FTP-Modus handelt es sich dabei um Verbindungen vom FTP-Server zurück zu uns. Das ist – außer mit dem in Kasten 2 vorgestellten Modul zur Verbindungsüberwachung – recht unsicher und daher unerwünscht.
Der heute fast ausschließlich eingesetzte passive Modus baut eine Verbindung vom FTP-Client zu einem der oberen Ports auf dem FTP-Server auf. Vom Standpunkt größtmöglicher Sicherheit ist das zwar immer noch nicht ideal, aber zumindest akzeptabel. Hierfür benutzen wir
iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -j ACCEPT
und die von mir vorgeschlagene "bequeme" INPUT-Regel, die alle Protokolle abdeckt.
Einem Freund empfehlen
