4. Das Einrichten der Firewall

4.1 Der Kernel

Eine Anleitung, wie man den Kernel neu kompiliert, findet sich im FreeBSD-Handbuch im Abschnitt „Building and Installing a Custom Kernel“. Der Rechner sollte allerdings nicht jetzt, sondern erst nach der vollständigen Konfiguration neu gestartet werden, um Probleme durch eine falsche Konfiguration zu vermeiden. Damit ipfw in den neuen Kernel aufgenommen wird, muss die Kernelkonfigurationsdatei nur um wenige, im folgenden erläuterte, Zeilen ergänzt werden.

Der ipfw-Code muss zunächst zum Kernel hinzugefügt werden.

options IPFIREWALL

Es soll möglich sein Pakete durch syslog zu loggen.

options IPFIREWALL_VERBOSE

Die Anzahl der maximal pro Regel geloggten Pakete soll standardmäßig auf 500 beschränkt sein.

options IPFIREWALL_VERBOSE_LIMIT=500

4.2 /etc/ipfw.rules

In dieser Datei wird der Hauptteil der ipfw-Regeln untergebracht. Der hier verwendete Name ist nicht bindend, durch Anpassen des Eintrags firewall_type in der rc.conf kann die Datei einen beliebigen anderen Namen bekommen. Die Datei darf sowohl Kommentare, die mit einem # eingeleitet werden, als auch Regeln für ipfw enthalten. Der Syntax der ipfw-Regeln ist auf der ipfw(8)-manpage ausführlich beschrieben.

Zuerst wird nun sämtlicher Verkehr, der über das Loopback-Interface läuft erlaubt und der Loopback Adressbereich vom restlichen Netzwerkverkehr isoliert.

add allow all from any to any via lo0
add deny all from any to 127.0.0.0/8
add deny ip from 127.0.0.0/8 to any

Als nächstes wird jetzt sämtlicher Netzwerkverkehr über das lokale Netzwerk-Interface erlaubt. Diese Regel kann bei einem Einzelrechner weggelassen werden.

add allow ip from any to any via fxp0

Für alle Verbindungen, die über das externe Interface tun0 laufen, soll das Stateful-Verhalten von ipfw genutzt werden, bei dem die Firewall Informationen über den Status von Verbindungen verfolgt. Wenn eine erlaubte Verbindung aus dem eigenen Netz heraus bzw. ins eigene Netz hinein initiiert wird, wird dazu eine dynamische Regel für diese Verbindung erstellt, die automatisch nach einer gewissen Zeit von Inaktivität oder nach dem Beenden der Verbindung wieder entfernt wird.

Es soll der Status von Verbindungen verfolgt werden.

add check-state

Bei eingehenden Paketen soll die Quelladresse in der Routingtabelle nachgeschlagen und überprüft werden, ob das Interface über das die Paket hereinkommen dasselbe ist, über das die Pakete zur entsprechenden Quelladresse herausgehen würden. Wenn dies nicht der Fall ist, werden sollen die Pakete fallengelassen werden. Diese i.A. als Anti-Spoofing bezeichnete Maßnahme filtert also hereinkommende Pakete mit gefälschten Absenderadressen aus.

Diese Regel ist aus Kompatibilitätsgründen auskommentiert, da die Option verrevpath nur für ipfw2 existiert und FreeBSD 5.1-RELEASE und höher benötigt wird.

#add deny ip from any to any in via tun0 not verrevpath

Pakete, die zwar zu einer etablierten Verbindung gehören, für die es aber keine dynamische Regel gibt, sollen fallengelassen werden.

add deny tcp from any to any via tun0 established

Verbindungen sollen aus dem eigenen Netz heraus initiiert werden können und ihr Status soll verfolgt werden.

add allow tcp from any to any keep-state out xmit tun0 setup

Um die Sicherheit zu erhöhen könnte man hier auch noch die Ports auf das nötigste beschränken.

Als nächstes sollen Verbindungen von außen zu einem, auf dem Firewall-Rechner laufenden SSH-Server, zugelassen werden.

add allow tcp from any to any 22 keep-state in recv tun0 setup

Ähnliche Regeln werden auch für UDP-Pakete erstellt, um DNS-, sowie NTP-Anfragen zu ermöglichen. Es ist zu beachten, dass mit dem UDP-Protokoll keine Verbindungen aufgebaut werden, sondern bloß Pakete von einem Ort zum anderen geschickt werden. ipfw simuliert also nur ein Stateful-Verhalten, indem es UDP-Pakete an einen anderen Rechner herauslässt und danach für eine bestimmte Zeit Pakete von diesem Rechner wieder entgegennimmt.

add allow udp from any to any 53,123 keep-state out xmit tun0

Schließlich werden noch Regeln für ICMP-Pakete erstellt. Zur Kommunikation mir anderen Rechnern im Internet ist es zumindest notwendig, dass ICMP-Pakete der Typen 3 (Destination Unreachable) und 4 (Source Quench) sowohl empfangen, als auch gesendet werden können. Weiterhin ist es sinnvoll ICMP-Pakete des Typs 8 (Echo Request) herauszulassen und den Typ 0 (Echo Reply) wieder hereinzulassen, um das pingen anderer Rechner zu ermöglichen.

add allow icmp from any to any icmptype 3,4
add allow icmp from any to any out icmptype 8
add allow icmp from any to any in icmptype 0

Da z.B. einige SMTP- oder FTP-Server während des Verbindungsaufbaus ident-Anfragen stellen, kann es sinnvoll sein, diese explizit mit einem RST-Paket zu beantworten anstatt sie einfach nur zu ignorieren. Ansonsten kann es nämlich zu Verzögerungen kommen, wenn die Gegenstelle eine gewisse Zeit lang auf eine Antwort wartet.

add reset tcp from any to any 113 in recv tun0

Zuletzt sollen alle übrigen Pakete ignoriert und geloggt werden.

add deny log ip from any to any

4.3 /etc/rc.conf

Wenn ein LAN Zugriff auf das Internet haben soll, sollte eine evtl. vorhandene Zeile ppp_nat="NO" gelöscht werden. Die NAT-Funktionalität des pppd ist standardmäßig aktiviert. IP-Forwarding muss zu diesem Zweck hier ebenfalls zugelassen werden.

gateway_enable="YES"

Als nächstes muss die Firewall aktiviert werden.

firewall_enable="YES"

Die Regeln in ipfw.rules werden durch rc.firewall eingelesen und zu Anfang um die erwähnten Einträge zum Loopback-Interface ergänzt, deshalb muss als Skript /etc/rc.firewall angegeben werden.

firewall_script="../../etc/rc.firewall"

Wenn als Firewall-Typ ein Dateiname an rc.firewall übergeben wird, so werden die Regeln aus dieser Datei gelesen.

firewall_type="../../etc/ipfw.rules"

Zuletzt lässt sich noch die Ausgabe der ipfw-Meldungen beim Starten des Skriptes verhindern, dies ist nur bei der Fehlersuche nützlich.

firewall_quiet="YES"

4.4 Übernahme der Einstellungen

Wenn der Kernel neu kompiliert und die Dateien entsprechend geändert bzw. erstellt wurden, sollte der Rechner neu gestartet werden. Danach kann als root mit ipfw show der Status der Firewall überprüft werden, es sollten dabei sowohl die geladenen Regeln, als auch statistische Daten über die Anzahl der Pakete und die Datenmenge, die eine Regel durchlaufen hat, angezeigt werden. Im Notfall kann durch das Ersetzen des Eintrags firewall_type="../../etc/ipfw.rules" durch firewall_type="open" und einen Neustart die Firewall deaktiviert werden.