Hochverfügbare Firewalls gelten als hohe Kunst im Netzwerkschutz. Dank Clustering bleibt das Netz online, selbst wenn eine Firewall ausfällt. OpenBSD/PF (Maskottchen: Kugelfisch) besitzen gegenüber dem bekannteren Duo Linux/Netfilter einige Vorzüge. Der Artikel erklärt das Setup – für Linuxer verständlich.

Ein guter Ruf eilt OpenBSD [1] voraus: Es gilt als äußerst sicher und empfiehlt sich für Firewalls als interessante Alternative zu Linux. Für hohe Sicherheitsanforderungen bringt es viele Techniken mit, von zufällig gewählten Speicheradressen über zufällige Prozess-IDs (Abbildung 1) und zufällige TCP-Sequenznummern bis zu ausgefeiltem Buffer-Overflow-Schutz. Auch die Philosophie passt: Ein schlankes System mit aufwändigen Code-Audits, um Sicherheitslücken aufzuspüren. Das Team um Theo de Raadt will erklärterweise “das sicherste Betriebssystem” [2] entwickeln.

Das Leben danach

Nach der Installation (Kasten “OpenBSD-Installation” ) ist OpenBSD ähnlich wie Linux zu administrieren: Admin-Benutzer anlegen, SSH-Daemon konfigurieren, nicht benötigte Dienste abschalten, fehlende nachinstallieren und konfigurieren. Die im Kasten erwähnte Manpage »man 8 afterboot« hilft weiter.

OpenBSD kennt kein Runlevel-Konzept (Ausnahme: Single User Mode). Entsprechend einfach ist die Struktur der Start-Konfigurationsdateien (»man rc«). Die Einstellungen sind verteil auf »/etc/rc.conf« (nicht ändern), »/etc/rc.conf.local« (eigene Konfiguration) und »/etc/rc.local« (eigene Startanweisungen).

Die Firewalls in diesem Artikel verzichten auf den Internet-Superserver Inetd, der lokale Sendmail-Daemon startet ohne Flags und die PF-Firewall mit einer eigenen Regeldatei. Dazu sind folgende Einträge in »/etc/rc.conf.local« nötig:

inetd=NO
sendmail_flags=NO
pf=YES
pf_rules=/etc/pf/firewall-pf.conf

Zwei weitere Files enthalten Kommandos für den Shutdown (»/etc/rc.shutdown«) und solche, die vor dem Wechsel des Securelevel (»/etc/rc.securelevel«) laufen. Die vier Sicherheitsebenen beschränken die Funktionsweise des Systems zunehmend, so verbietet Securelevel 2 zum Beispiel jede Änderung von Firewallregeln, ohne einen Neustart auszuführen.

Wer weitere Dienste installieren will, beispielsweise SNMP, kompiliert entweder einen so genannten Port (»man 7 ports«) oder installiert mit »pkg_add« ein Binary-Paket. Beides geht leicht von der Hand und klappt auch via Internet. Die OpenBSD-Community empfiehlt das Paketsystem.

Gepflegter Purismus

Bei der Konfiguration des Netzwerks nach der Erstinstallationsroutine fällt der von OpenBSD gepflegte Purismus auf. Für jedes Netzwerk-Interface ist eine eigene Datei zuständig. Ihr Name beginnt mit »hostname« (mit diesem String, nicht mit dem Namen des Hosts) und sie trägt die Interface-Bezeichnung als Suffix, beispielsweise »/etc/hostname.fxp0«. Ihr Inhalt entspricht den typischen »ifconfig«-Parametern: Art der Schnittstelle, IP-Adresse, Subnetz- und gegebenenfalls Broadcast-Adresse sowie weitere Optionen:

inet 10.0.0.1 255.0.0.0 NONE

Die Bootskripte lesen den Inhalt aus und konfigurieren das Interface passend. Nachträglich geht das auch mit einem Aufruf von »sh /etc/netstart fxp0«. Der Hostname des Systems steht in »/etc/myname«, sein Standardgateway in »/etc/mygate«. Die nachfolgend beschriebenen virtuellen CARP-Schnittstellen für das Failover-Setup werden auf gleiche Weise konfiguriert.

Das von Linux bekannte Sysctl dient auch auf OpenBSD der Kernelkonfiguration zur Laufzeit. Die Parameter stehen in »/etc/sysctl.conf«. Dort finden sich auch auskommentierte Zeilen für das Aktivieren von IPv4- und IPv6-Forwarding sowie Einstellungen, die das CARP-System braucht:

net.inet.carp.allow=1
net.inet.carp.preempt=1
net.inet.carp.log=0
net.inet.carp.arpbalance=0

Das Common Address Redundancy Protocol (CARP, [5]) ist eine freie Implementierung des von Patenten belasteten VRRP (Virtual Router Redundancy Protocol). CARP eignet sich für Cluster mit zwei oder mehr Knoten. Die portierbare UCARP-Variante (Unix CARP, [6]) läuft auch auf Linux-Systemen.

CARP wurde im Rahmen des OpenBSD-Projekts neu entwickelt und erstmals in OpenBSD 3.5 integriert. Es weist einem Cluster von mindestens zwei Maschinen des gleichen Subnetzes zusätzlich zu einer virtuellen IP- auch eine virtuelle MAC-Adresse zu (Abbildung 3). Die Nodes tauschen ihre CARP-Informationen kryptographisch signiert aus.

Abbildung 1: Die OpenBSD-Firewall benutzt zufällige Prozess-IDs. Daher sind bereits auf einem frisch gestarteten System IDs mit stark unterschiedlichen Werten anzutreffen.

Ein Cluster-Node verhält sich als Master, der zweite als Backup. Der Vorteil: Im Gegensatz zu einer Linux/Heartbeat-Lösung muss beim Ausfall des CARP-Masters das Ersatzsystem keine geänderte IP/MAC-Adressbeziehung im Netz propagieren. Das Backupsystem übernimmt die Kombination aus MAC und IP vom Master. Ein weiterer praktischer Nebeneffekt der virtuellen MAC-Adresse ist die Möglichkeit, ARP- und IP-Pakete an beiden Nodes anzunehmen, die sich gegenseitig sichern. Das führt zu transparentem ARP-Loadbalancing.

cd /usr
CVSROOT=anoncvs@anoncvs.example.org:/cvs
export CVSROOT
cvs -d$CVSROOT checkout -rOPENBSD_3_7 -P src

cd /usr/src/sys/arch/i386/conf
config GENERIC
cd ../compile/GENERIC
make clean && make depend && make
make install

rm -rf /usr/obj/*
cd /usr/src
make obj
cd /usr/src/etc
env DESTDIR=/ make distrib-dirs
cd /usr/src
make build

Um einen weiteren Single Point of Failure (SPoF) zu vermeiden, arbeiten HA-Firewalls oft an getrennten Switches (Abbildung 4, LAN- und DMZ-Anbindungen), die via Spanning Tree Protocol (STP) verbunden sind. Diese Technik kann mit CARP aber Probleme bereiten, nach dem Wechsel von Backup auf Master und umgekehrt vergehen dann etliche Sekunden Umschaltzeit.

Die Lösung: Alle Switch-Ports, an denen die Firewalls angeschlossen sind, müssen sich im so genannten Forwarding State befinden. Je nach Switch lautet das Kommando dafür »port fast« oder »fast link«, die Hersteller konnten sich auf keinen einheitlichen Namen einigen.

01 # ifconfig carp0
02 carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
03         carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 50
04         inet 172.16.3.254 netmask 0xfffffe00 broadcast 172.16.3.255

01 # ifconfig carp0
02 carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
03         carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
04         inet 172.16.3.254 netmask 0xfffffe00 broadcast 172.16.3.255

01 # ifconfig carp0
02 carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
03         carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 100
04         inet 172.16.3.254 netmask 0xfffffe00 broadcast 172.16.3.255

01 # Lasse allen Traffic aus 192.168.0.0/24 auf 192.168.0.1 inklusive Rückverbindung zu
02 pass in on em0 from 192.168.0.0/24 to 192.168.0.1 keep state label "test"
03 #
04 # Erlaube SMTP von 172.16.2.254 nach 130.60.1.11 und logge die Verbindung
05 pass in log inet proto tcp from 172.16.2.254 port >= 1024 to 130.60.1.11 port 25 keep state

Im Beispielnetz soll eine HA-Firewall drei Segmente bedienen: LAN, DMZ und Internet-Uplink (siehe Tabelle 1 und Abbildung 4). Die Konfiguration der CARP-Schnittstellen gleicht der einer gewöhnlichen Netzwerkkarte. Mit Ausnahme des »advskew«-Werts sind die Parameter auf beiden Firewalls identisch:

echo "inet 172.16.3.254 255.255.254.0 U
  172.16.3.255 advskew 50 vhid 1 pass U
  hs3el9ja+e3 carpdev em0" > U
  /etc/hostname.carp0
sh /etc/netstart carp0

Advskew gibt die Wertigkeit eines Systems gegenüber dem anderen an. Je höher dessen Wert, desto niedriger ist seine Priorität. Der Backup-Node braucht also einen höheren Advskew als der Master. Hinter »vhid« verbirgt sich die Virtual Host ID, mit ihr lassen sich Nodes und ihre CARP-Interfaces einander zuordnen. Der »pass«-Wert authentifiziert die zwischen den Nodes ausgetauschten CARP-Nachrichten, »carpdevice« nennt das physikalische Interface, das dem virtuellen zugrunde liegt.

Nach diesen Schritten ist CARP für ein Segment bereits fertig konfiguriert. Das System sollte auf der virtuellen IP 172.16.3.254 Pings beantworten. Ein »ifconfig carp0« zeigt den Status »MASTER« auf einem Knoten und »BACKUP« auf dem zweiten (siehe Listings 1a und 1b).

Abbildung 2: Das Cross-Plattform-Werkzeug Firewall-Builder unterstützt alle PF-Optionen, die das Normalisieren des Netzwerkverkehrs steuern.

Abbildung 3: CARP stellt für den Cluster nicht nur eine virtuelle IP, sondern auch eine virtuelle MAC-Adresse zur Verfügung. Nach dem Failover reagiert das Backupsystem auf diese IP und MAC.

Simulanten

Um einen Ausfall der ersten Firewall zu simulieren, genügt es, deren CARP-Interface zu entfernen: »ifconfig carp0 down && ifconfig carp0 destroy«. Die virtuelle IP bleibt trotzdem pingbar, weil Firewall 2 von Backup auf Master wechselt (Listing 1c, Zeile 3). Die Umschaltzeit beträgt weniger als eine Sekunde – Heartbeat braucht dafür mit etwa zwölf Sekunden deutlich länger.

Die anderen CARP-Devices beider Firewalls werden analog konfiguriert. Wichtig ist der oben erwähnte Sysctl-Parameter »net.inet.carp.preempt«. Er stellt sicher, dass beim Ausfall eines einzigen Interface alle anderen den Status ebenfalls wechseln.

PF statt IPtables

Der Paketfilter PF [7] ist das Pendant zu Linux\’ Netfilter und seit Version 3.0 fester Bestandteil von OpenBSD. Er ersetzt den Vorläufer IPfilter (Ipf), der wegen seiner Lizenzprobleme aus dem OpenBSD-Projekt entfernt wurde. PF gilt als ausgereift und reich an ausgefeilten Features, die unter Linux ihresgleichen suchen (und gelegentlich in zusätzlichen Tools und Kernelpatches auch finden).

PF beherrscht mit der Scrubbing-Technik das Normalisieren des Netzverkehrs, integriertes Traffic Shaping (Packet Queueing and Priorization) und Anchors für das dynamische Ändern von Regeln. Listen, Makros und Tabellen machen die ohnehin einfache Syntax der PF-Regelsätze noch lesbarer (Listing 2).

Abbildung 4: Master und Backup synchronisieren sich über PFsync, für diese wichtige Aufgabe verwenden sie eine eigene Netzwerkkarte (»em2«). LAN und DMZ sind über je zwei Switches an die CARP-isierten Interfaces (»em0« und »em1«) angeschlossen. Beim Ausfall eines Master-Interface schalten alle CARPs auf Backup um.

Zudem kennt PF alle NAT-Varianten, Stateful Filtering (auch für Stateless UDP) sowie State-Synchronisation mit PFsync, mit dessen Hilfe ein Firewall-Takeover via CARP vollständig transparent erfolgt: Alle Tabellen, die den Status der aktuellen Verbindungen vorhalten, synchronisiert PFsync fortlaufend zur Backup-Firewall. Das Netfilter-Äquivalent »ct_sync« für Linux befindet sich dagegen noch in der Entwicklung.

Bequemer mit FW-Builder

Wer FW-Builder ([8] und der Artikel in diesem Heft) zur Firewall-Administration nutzt, wechselt besonders leicht von Netfilter zu PF oder umgekehrt. Das Programm schreibt Regelsätze für beide Firewalls aus einer identischen Policy, die Policy-Compiler machen\’s möglich. Theoretisch reicht es, in den FW-Builder-Settings von IPtables auf PF zu wechseln und die Interfacenamen anzupassen. Probleme gibt es nur mit Regeln, die an mehrere Interfaces gebunden sind. FW-Builder kreiert für Netfilter automatisch »INPUT«-, »OUTPUT«- und »FORWARD«-Chains. Da Letztere bei PF fehlen, dürfen Regeln, die für mehrere Interfaces gelten, nur in der globalen Policy stehen.

Leider unterstützt der PF-Policy-Compiler von FW-Builder zurzeit weder MAC-Adressen-Matching noch Traffic Shaping oder Anchors. Mit etwas Scripting-Kunst und der Hilfe des Prolog-Dialogs gelingt es aber, Anchors manuell einzufügen. Scrubbing unterstützt FW-Builder bereits (Abbildung 2). Sehr praktisch ist, dass das Tool die PF-Regeln in Form von Tables generiert, was die Größe der Regelsatzdatei im Vergleich zu IPtables glatt halbiert. Der volle Funktionsumfang von PF erschließt sich nur mit manuellem Regeldesign. Beim Einstieg und Verständnis der Syntax hilft FW-Builder aber allemal – es generiert übersichtliche und sogar kommentierte Regelsätze.

Die Regeln müssen noch auf die Firewalls gelangen und dort aktiv werden. Im Gegensatz zu IPtables übergibt das »pfctl«-Werkzeug nicht jede Regel einzeln an den Kernel, es erwartet vielmehr eine vollständige Konfigurationsdatei. FW-Builder erstellt zu ihrem Laden ein eigenes kleines Skript.

Ein Blick in die Pfctl-Manpage offenbart eine Fülle von Optionen. Die Angabe von »-e« schaltet PF ein, »-d« deaktiviert es wieder. Dabei gehen States, Tables und Chains nicht verloren – sehr praktisch fürs Testen. Ein weiteres Schmankerl ist »pftop«. Das Tool per »pkg_add« nachzuinstallieren lohnt: Es zeigt alle denkbaren Daten von PF zur Laufzeit in Form des bekannten »top«-Programms an.

FTP nur per Proxy

Das altbekannte Problem “FTP via Firewall und dann auch noch NAT” ([9], [10]) macht OpenBSD heute noch zu schaffen. Leider ist kein Modul verfügbar, das dem »ip_nat_ftp« von Netfilter entspräche. Ohne FTP-Proxy klappt weder aktives noch passives FTP. Der mitgeliefert Proxy ist in seiner Funktion allerdings beschränkt und arbeitet nur, wenn entweder ausgehender Traffic auf allen Ports erlaubt ist oder das so genannte Policy Based Tagging von PF zum Einsatz kommt.

Restriktivere Umgebungen, die den ausgehenden Verkehr einschränken, sind mit dem FTP-Proxy von Camiel Dobbelaar [11] deutlich besser aufbauen. Er ist einfach zu konfigurieren, versteht sich prächtig mit PF und ermöglicht dadurch problemloses Active/Passive-FTP.

Für standhafte Firewalls gehört es sich, nur explizit erlaubten Verkehr durchzulassen. Sie müssen zusätzlich zur normalen Policy das IP-Protokoll 112 erlauben, um nicht versehentlich CARP-Nachrichten auszufiltern, die die Nodes untereinander austauschen. Gleiches gilt für den PFsync-Verkehr, der beide Firewalls auf dem aktuellen State-Table-Stand hält. Hier müssen Pakete des IP-Protokolls 240 von und zu den noch zu definierenden PFsync-Devices erlaubt sein. Die PFsync-Schnittstelle – wie könnte es anders sein – wird in der Datei »/etc/hostname.pfsync0« konfiguriert:

up syncdev em2

Nach dem Aufruf »sh /etc/netstart pfsync0« ist das Sync-Interface aktiv. Das Beispiel verwendet ein dediziertes Interface ausschließlich für den PFsync-Traffic. Wer mit Netzwerkkarten nicht klotzen will und lieber eine in Servern ohnehin meist überflüssige USB-Schnittstelle benutzen möchte, wirft einen kurzen Blick auf die durch »apropos usb|grep -i ether« generierte Liste und lässt seiner Phantasie freien Lauf.

Tolles Trio: CARP, PF, PFsync

CARP, PF und PFsync sind damit konfiguriert und der Firewall-Cluster ist einsatzbereit. Fehlt nur noch das Logging. PF-Logeinträge gehen nicht durch den Syslogd, vielmehr ist das Spezialdevice »pflog0« zuständig. Es schreibt ebenfalls Dateien nach »/var/log/«, allerdings im Tcpdump-Format. Diese Logfiles und das Log-Device selbst lassen sich per Tcpdump inspizieren:

tcpdump -n -e -ttt -i pflog0
tcpdump -n -e -ttt -r /var/log/pflog
tcpdump -n -e -ttt -i pflog0 port 80 and U
  host 192.168.1.3

Wer lieber Syslog und Ascii-Logdateien verwendet, findet im PF-Handbuch, Kapitel “Aufzeichnen”, eine gute Anleitung zur automatisierten Konvertierung.

Immer da

Hochverfügbare Firewallsysteme sind mit OpenBSD und PF leicht zu realisieren. Dank der Secure-by-Default-Philosophie ist OpenBSD bereits nach der Installation ein enorm sicheres und gehärtetes System. Das puristische und konsequent durchdachte BSD-Design trägt nicht nur zur Sicherheit, sondern auch zur Benutzerfreundlichkeit bei. In puncto Performance und Stabilität steht OpenBSD nicht hinten an (siehe Kasten “Belastungstest”), lediglich die schlechtere Hardware-Unterstützung steht auf der Negativliste. (fjl)

Abbildung 5: Links: Beim 60 Sekunden dauernden Netfilter-Test TCP_STREAM bremst OpenBSD/PF die Datenströme nur unwesentlich stärker als Linux/Netfilter. Rechts: 128 Byte geschickt und 16 KByte empfangen: OpenBSD/PF und Linux/Netfilter liegen beim realitätsnahen CRR-Test fast gleichauf.