HA-fähige Firewall mit OpenBSD/PF (Packet Filter)

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.