Die IPFIREWALL (IPFW) ist eine vom FreeBSD Project gesponserte Software-Firewall. Sie wurde und wird freiwillig von Mitgliedern des FreeBSD Projects geschrieben und gewartet. Mit zustandslosen Regeln und einer Grammatik für Regeln implementiert sie eine sogenannte „Einfache Zustandsgesteuerte Logik“.
Die Standardinstallation von IPFW enthält
einen beispielhaften Regelsatz
(/etc/rc.firewall
und
/etc/rc.firewall6
). Dieser ist eher
einfach gehalten; es ist nicht zu erwarten, dass dieser
ohne Modifikationen angewandt werden kann. Dieses Beispiel
nutzt keine zustandsorientierte Filterung, von der allerdings
die meisten Installationen profitieren sollten. Deshalb wird sich
dieser Abschnitt auch nicht auf diese Beispiele stützen.
Die zustandslose IPFW Regel-Syntax ist durch ihre technisch ausgefeilten Selektions-Fähigkeiten, die über das Niveau der gebrächlichen Firewall-Installationsprogramme weit hinausgehen, sehr mächtig. IPFW richtet sich an professionelle oder technisch versierte Nutzer mit weitergehenden Anforderungen an die Paket-Auswahl. Um die Ausdrucksstärke der IPFW zu nutzen, ist sehr detailliertes Wissen über die Art und Weise, wie verschiedene Protokolle ihre jeweilige Paket-Header-Information erzeugen und nutzen, erforderlich. Im Rahmen dieses Abschnitts ist es nicht möglich, auf alle diese Punkte detailliert einzugehen.
IPFW besteht aus sieben Komponenten: Hauptbestandteil ist der
Kernel Firewall Filter, ein Regel-Prozessor mit integrierter
Paket-Buchführung. Außerdem enthalten
ist eine Komponente zur Protokollierung der Aktivitäten der
Firewall (also ein Logfunktion). Weiters besteht die IPFW aus einer
Regel zum Umleiten des Datenverkehrs (divert
), die
auch Network Address Translation (NAT)
unterstützt. Die restlichen Bestandteile dienen verschiedenen
fortgeschrittenen Zwecken. Der
Traffic Shaper dummynet(4)
gestattet es beispielsweise, den Datenverkehr zu lenken, während
die fwd
-Regel zum Weiterleiten von Datenpaketen
dient. Komplettiert wird IPFW durch Funktionen zum
Überbrücken von Netzwerkgrenzen
(Bridge-Funktion) sowie
ipstealth, das es gestattet,
bridging-Funktionen durchzuführen, ohne dabei das TTL-Feld im
IP-Paket zu erhöhen. IPFW unterstützt IPv4 und IPv6.
IPFW ist in der FreeBSD-Installation standardmäßig
als ein zur Laufzeit ladbares Kernelmodul enthalten, das
vom System automatisch geladen wird, wenn in der Datei
rc.conf
die Option
firewall_enable="YES"
gesetzt wird. Es ist
daher in der Regel nicht notwendig, IPFW statisch in den Kernel zu
kompilieren. Es sei denn, man benötigt die
NAT-Funktionalität.
Während des Systemstart wird bei gesetzter Option
firewall_enable="YES"
(in der Datei
rc.conf
) folgende Nachricht ausgegeben:
Das Kernelmodul hat eine Protokollierungsfunktion. Um
diese zu aktivieren und einen Schwellwert für die
Protokollierung zu definieren, ist es erforderlich, folgende
Ausdrücke der /etc/sysctl.conf
hinzuzufügen:
IPFW muss nicht durch einkompilieren bestimmter, im folgenden konkretisierter Optionen in den Kernel aktiviert werden, es sei denn, man benötigt NAT-Funktionalität. Die erforderlichen Optionen werden deshalb hier lediglich als Hintergrundinformation aufgeführt.
Diese Option aktiviert IPFW als Bestandteil des Kernels.
Diese Option aktiviert die Funktion, alle Pakete, die durch
IPFW verarbeitet werden und bei denen das Schlüsselwort
log
gesetzt ist, zu protokollieren.
Diese Option limitiert die Anzahl der durch syslogd(8) protokollierten Pakete auf das angegebene Maximum. Sie wird in feindlichen Umgebungen verwandt, in denen die Protokollierung der Firewall-Aktivität erwünscht ist. Dadurch wird ein möglicher Denial-of-Service-Angriff durch Überflutung von syslogd(8) verhindert.
Diese Option erlaubt allen Paketen, die Firewall zu passieren. Diese Einstellung kann beispielsweise bei der ersten Konfiguration der Firewall hilfreich sein.
Dies aktiviert die Nutzung der NAT-Funktionalität.
Die Firewall wird alle eingehenden oder ausgehenden
Pakete blockieren, wenn entweder die Kernel-Option
IPFIREWALL_DEFAULT_TO_ACCEPT
fehlt oder
aber keine Regel, die die betreffenden Verbindungen explizit
gestattet, existiert. Dies enstpricht im Wesentlichen der
Einstellung „default to deny“
Der Eintrag
aktiviert die Firewall während des Systemstarts.
Die Auswahl einer für FreeBSD verfügbaren Firewall
erfolgt durch einen entsprechenden Eintrag in der Datei
/etc/rc.firewall
, durch den der Firewalltyp
festgelegt wird.
Konkret sind folgende Einträge erlaubt:
open
— gestattet jeglichen
Datenverkehr
client
— schützt nur die
jeweilige Maschine (Client/Mandant)
simple
— schützt das
gesamte Netzwerk
closed
— unterbindet
jeglichen IP-Datenverkehr mit Ausnahme des Verkehrs
über die Loopback-Schnittstelle.
UNKNOWN
— deaktiviert das
Laden von Firewallregeln
— absoluter Pfad zu einer Datei, in der die
Firewallregeln definiert sindfilename
Angepasste Regeln für ipfw(8) können auf zwei
verschiedene Arten geladen werden. Einerseits kann man durch die
Variable firewall_type
den absoluten Pfad
der Datei angeben, welche die Firewallregeln
(ohne weitere Optionen) für ipfw(8) enthält. Ein
einfaches Beispiel für einen Regelsatz, der jeglichen
eingehenden und ausgehenden Datenverkehr blockiert, könnte
beispielsweise so aussehen:
Andererseits ist es möglich, den Wert der
firewall_type
-Variable mit dem absoluten
Pfad einer Datei zu belegen, die (als ausführbares Skript)
die ipfw(8)-Kommandos enthält, die beim Booten
ausgeführt werden sollen. Ein gültiges Skript (das die
gleiche Funktion hat wie die Zeile im letzten Beispiel) könnte
beispielsweise so aussehen:
Wenn die Variable firewall_type
entweder auf client
oder
simple
gesetzt ist, sollten die
Standardregeln in der Datei
/etc/rc.firewall
geprüft und an die
Konfiguration der gegebenen Maschine angepasst werden. Beachten
Sie dabei bitte, dass die Beispiele dieses Kapitels davon
ausgehen, dass das firewall_script
auf
/etc/ipfw.rules
gesetzt ist.
Das Logging wird durch folgenden Eintrag aktiviert:
Die Variable firewall_logging
definiert
lediglich die sysctl-Variable als
net.inet.ip.fw.verbose = 1
(lesen Sie dazu
bitte auch den Abschnitt Abschnitt 31.6.1, „IPFW aktivieren“
des Handbuchs). Es gibt keine
rc.conf
-Variable, mit der man
Protokollierungsschwellen setzen könnte. Dies kann
lediglich über sysctl(8) geschehen, wobei Sie in
der Datei /etc/sysctl.conf
nur
Werte > 1 angeben sollten:
Sollte Ihre Maschinen als Gateway fungieren (also mittels
natd(8) Network Address
Translation (NAT)
durchführen), finden Sie in Abschnitt
Abschnitt 32.9, „NAT - Network Address Translation“ weitere Optionen für die
/etc/rc.conf
.
Mit ipfw(8) ist es möglich, im laufenden Betrieb einzelne Regeln hinzuzufügen oder zu entfernen. Problematisch ist allerdings, dass diese Änderungen verloren gehen, wenn das System neu gestartet wird. Daher ist es empfehlenswert, eigene Regeln in einer Datei zu definieren und diese zu laden, um die Regeln der Firewall im laufenden Betrieb anzupassen.
ipfw(8) ist jedoch hilfreich, um die Regeln der laufenden Firewall in der Konsole auszugeben. IPFW erzeugt dynamisch einen Zähler, der jedes Paket, auf das eine Regel zutrifft, zählt. Dadurch wird es möglich, die Funktion einer Regel zu überprüfen.
Eine sequentielle Liste aller Regeln erhalten Sie mit:
#
ipfw list
Eine Liste aller Regeln inklusive des letzten Treffers erhalten Sie durch den folgenden Befehl:
#
ipfw -t list
Um eine Liste aller Regeln inklusive der Anzahl der Pakete, die von einer Regel gefiltert wurden, zu erhalten, geben Sie den folgenden Befehl ein:
#
ipfw -a list
Eine Liste, die zusätzlich allen dynamischen Regeln enthält, erhalten Sie mit:
#
ipfw -d list
Um diese Liste um alle „abgelaufenen“ Regeln zu erweitern, ädern Sie diesen Befehl wie folgt ab:
#
ipfw -d -e list
Alle Zähler auf Null zurücksetzen:
#
ipfw zero
Es ist auch möglich, einen spezifischen Zähler auszuwählen und zurückzusetzen:
#
ipfw zero NUM
Ein Regelwerk ist eine Menge von IPFW-Regeln, die in Abhängigkeit von bestimmten Paketeigenschaften Pakete entweder passieren lassen oder abweisen. Der zustandshafte bidirektionale Transfer von Paketen zwischen Rechnern wird als Sitzung bezeichnet. Das Regelwerk der Firewall verarbeitet sowohl ankommende Pakete (aus dem öffentlichen Internet) als auch Pakete, deren Ursprung in einer Antwort des Systems auf empfangene Pakete liegt. Jeder TCP/IP-Dienst (wie telnet, www, mail) ist durch sein Protokoll und durch den priveligierten (eingehenden) Port definiert. An einen spezifischen Dienst adressierte Pakete kommen von einer Quelladresse und einem unprivilegierten (high order) Port. Sie adressieren den spezifischen Port des Dienstes an der Zieladresse. Alle weiter oben aufgeführten Parameter (also Ports und Adressen) können als Selektionskriterium zur Erzeugung von Regeln genutzt werden, die ein Passieren der Firewall für oder ein Blockieren von Diensten bewirken.
Wenn ein Paket die Firewall „betritt“, also von der Firewall geprüft und verarbeitet wird, wird die erste Regel des Regelwerkes auf das Paket angewandt. Auf diese Weise wird in aufsteigender Reihenfolge der Regelnummer mit allen weiteren Regeln verfahren. Falls die Selektionsparameter einer Regel auf ein Paket zutreffen, wird das Aktionsfeld der Regel ausgeführt und die Prüfung des Pakets beendet, nachfolgende Regeln werden also nicht mehr geprüft. Diese Suchmethode wird als „erster Treffer gewinnt“ bezeichnet. Falls keine Regel auf das betreffende Paket zutrifft, wird die obligatorische IPFW-Rückfallregel (also Regel 65535) angewendet und das Paket wird ohne Rückantwort verworfen.
Die Prüfung der Regeln wird nach Treffern von mit
count
, skipto
und
tee
parametrisierten Regeln ungeachtet
des „erster Treffer gewinnt“-Prinzips weiter
fortgeführt.
Die Anweisungen basieren auf der Nutzung von Regeln
mit den zustandsgesteuerten Optionen keep
,
state
, limit
,
in
und out
. Diese
bilden die Basis für die Spezifikation von
Firewallregeln.
Bei der Arbeit mit Firewallregeln ist Vorsicht geboten. Es ist sehr einfach, sich selbst auszuschließen.
Mit der in diesem Abschnitt dargestellten Syntax der Regeln kann ein Standardregelsatz für eine „einschließende“ Firewall erstellt werden. Für eine vollständige Beschreibung der Regelsyntax lesen Sie bitte die Manualpage ipfw(8)
Regelausdrücke werden „von links nach rechts“ ausgewertet. Schlüsselwörter werden in fetter Schrift dargestellt. Manche Schlüsselworte beinhalten Unteroptionen, die wiederum selbst aus Schlüsselworten samt Optionen bestehen können.
Kommentare sind mit einen führenden Doppelkreuz
(#
) ausgezeichnet. Sie können am
Ende einer Regel oder in einzelnen, separaten Zeilen stehen.
Leerzeilen werden ignoriert.
CMD RULE_NUMBER ACTION LOGGING SELECTION
STATEFUL
Jede neue Regel benötigt das Präfix
add
, um die Regel der internen
Tabelle hinzuzfügen.
Eine Regel kann mit einer der vier folgenden Aktionen verbunden sein, die ausgeführt werden, wenn ein Paket den Selektionskriterien der Regel entspricht.
allow | accept | pass | permit
Alle diese Aktionen bewirken das Gleiche: Pakete, die den Selektionskriterien der Regel entsprechen, verlassen den Regelprüfungsabschnitt der Firewall und die Regelprüfung wird beendet.
check-state
Diese Aktion prüft das Paket gegen die Regeln aus
den dynamischen Regeltabellen. Trifft ein
Selektionskriterium zu, wird die zur dynamischen Regel
gehörende Aktion ausgeführt. Anderenfalls wird
gegen die nächste Regel geprüft. Die
check-state
-Regel selbst hat kein
Selektionskriterium. Sollte eine
check-state
-Regel im Regelwerk fehlen,
wird gegen die erste keep-state
- oder
limit
-Regel in den dynamischen Regeln
geprüft.
deny | drop
Beide Schlüsselworte bewirken dieselbe Aktion: Ein Paket, dass die Selektionskriterien der Regel erfüllt, wird verworfen und die Regelprüfung wird beendet.
log
oder
logamount
Erfüllt ein Paket die Selektionskriterien mit dem
Schlüsselwort log
, wird dies von
syslogd(8) mit der Annotation SECURITY protokolliert.
Dies erfolgt allerdings nur, wenn die Anzahl der
protokollierten Pakete der betreffenden Regel die im
logamount
-Parameter definierte
Schwelle nicht übersteigt. Ist der Parameter
logamount
nicht definiert, wird diese
Grenze aus der sysctl
-Variable
net.inet.ip.fw.verbose_limit
ermittelt.
Ist einer dieser beiden Werte auf „Null“
gesetzt, wird unbegrenzt protokolliert. Wurde hingegen
ein definierter Schwellenwert erreicht, wird die
Protokollierung deaktiviert. Um sie zu reaktivieren,
können Sie entweder den Protokoll- oder den
Paketzähler rücksetzen (und zwar über den
Befehl ipfw reset log
).
Die Protokollierung findet statt, nachdem alle
Paketselektionskriterien geprüft und bevor die
daraus folgende, endgültige Aktion
(accept
oder deny
)
auf das Paket ausgeführt wird. Die Entscheidung,
welche Regel protokolliert werden soll, bleibt Ihnen
überlassen.
Die in diesem Abschnitt beschriebenen Schlüsselwörter beschreiben die Attribute eines Pakets, durch die bestimmt wird, ob eine Regel auf ein Paket zutrifft. Die folgenden Attribute dienen der Bestimmung des Protokolls und müssen in der angegebenen Reihenfolge verwendet werden.
udp | tcp | icmp
Weitere in /etc/protocols
angegebene Protokolle werden ebenfalls erkannt und
können daher verwendet werden, um das Protokoll zu
definieren, gegen das Pakete geprüft werden. Die
Angabe des Protokolls ist verpflichtend.
from src to dst
Die Schlüsselwörter from
und to
beziehen sich auf IP-Adressen und
definieren sowohl Ursprungs- als auch Zieladresse einer
Datenverbindung. Firewallregeln müssen Parameter
für den Ursprung und das Ziel
enthalten. Das Schlüsselwort any
steht für beliebige IP-Adressen. Bei
me
handelt es sich um ein spezielles
Schlüsselwort, das alle IP-Adressen beschreibt, die
einer bestimmten Netzwerkschnittstelle Ihres Systems
(auf dem die Firewall läuft) zugeordnet sind.
Beispiele hierfür sind
from me to any
,
from any to me
,
from 0.0.0.0/0 to any
,
from any to 0.0.0.0/0
,
from 0.0.0.0 to any
,
from any to 0.0.0.0
oder
from me to 0.0.0.0
. IP-Adressen werden
entweder in CIDR-Notation
oder durch Punkte getrennt mit Suffixen
(192.168.2.101/24
) für
die Netzmaske oder als einzelne numerische, durch Punkte
getrennte Adressen
(192.168.2.101
) angegeben.
Die dafür notwendigen Berechnungen erleichtert der
Port net-mgmt/ipcalc
.
Weiterführende Informationen finden sich auf
http://jodies.de/ipcalc.
port number
Bei der Verarbeitung von Protokollen wie
TCP oder UDP, die
Portnummern verwenden, muss die Portnummer des
betreffenden Dienstes angegeben werden. Anstelle der
Portnummer kann auch der in der Datei
/etc/services
definierte Name des
Dienstes angegeben werden.
in | out
Diese Schlüsselwörter beziehen sich auf die Richtung des Datenverkehrs. Jede Regel muss eines dieser beiden Schlüsselwörter enthalten.
via IF
Eine Regel mit dem Schlüsselwort
via IF
betrifft nur Pakete, die über
die angegebene Schnittstellte geroutet werden (ersetzen Sie
IF
durch den Namen Ihrer
Netzwerkschnittstelle). Die Angabe des
Schlüsselwortes via
bewirkt, dass
die Netzwerkschnittstelle in die Regelprüfung
aufgenommen wird.
setup
Dieses obligatorische Schlüsselwort bezeichnet die Anforderung des Sitzungsstarts für TCP-Pakete.
keep-state
Dieses obligatorische Schlüsselwort bewirkt, dass die Firewall eine dynamische Regel erzeugt, die bidirektionalen Datenverkehr zwischen Ursprungs- und Zieladresse sowie Ursprungs- und Zielport prüft, der das gleiche Protokoll verwendet.
limit {src-addr | src-port | dst-addr |
dst-port}
Wird das Schlüsselwort limit
verwendet, sind nur N
durch diese
Regel definierte Verbindungen erlaubt. Es können
dabei ein oder mehrere Ursprungs- und Zieladressen sowie
ein oder mehrere Ports angegeben werden. Die
Schlüsselwörter limit
und keep-state
können nicht in
derselben Regel verwendet werden. Die Option
limit
bewirkt dieselbe Zustandsteuerung
wie die Option keep-state
, erweitert
diese jedoch um eigene Regeln.
Eine zustandsgesteuerte Filterung behandelt Datenverkehr als einen bidirektionalen Austausch von Datenpaketen (die eine sogenannte Konversation innerhalb einer Sitzung darstellen). Sie ist in der Lage, zu bestimmen, ob die Konversation von originärem Sender und Empfänger gültigen Prozeduren des bidirektionalen Pakettausches entspricht. Pakete, die dem Muster von Konversationen in Sitzungen nicht folgen, werden automatisch als „Betrüger“ abgelehnt.
Die check-state
-Option wird verwendet,
wo genau innerhalb des IPFW-Regelwerks die Prüfung
dynamischer Regeln stattfinden soll. Erfüllt ein
Datenpaket die Selektionskriterien der Regel, verlässt
das Paket die Firewall. Gleichzeitig wird eine neue
dynamische Regel erzeugt, die für das nächste Paket
der bidirektionalen Konversation in der Sitzung vorgesehen
ist. Falls ein Paket die (dyanmische) Regel nicht erfüllt,
wird es gegen die nächste Regel im Regelwerk
geprüft.
Dynamische Regeln sind für einem sogenannten
SYN-flood-Angriff anfällig,
bei dem eine riesige Anzahl „schwebender“
dynamischer Regelprüfungungsinstanzen erzeugt wird. Um
einem solchen Angriff zu begegnen, wurde in FreeBSD die neue
Option limit
geschaffen. Diese Option
begrenzt die Anzahl der gleichzeitig möglichen
Sitzungen und/oder Konversationen. Es handelt sich dabei um
einen Zähler, der die Anzahl von Instanzen dynamischer
Regelprüfungen in Abhängigkeit von einer eindeutigen
Urspungs- und Quelladresskombination zählt.
Übersteigt der Zähler den durch
limit
definierten Schwellenwert, wird
das Paket verworfen.
Die Vorteile einer Protokollierung sind offensichtlich. Sie ermöglicht nach Aktivierung von Regeln zu untersuchen, welche Pakete verworfen wurden, von wo diese stammen und für welche Systeme sie bestimmt waren. Diese Informationen sind sehr nützlich bei der Erkennung eventueller Angriffe sowie bei deren Abwehr.
IPFW protokolliert nur jene Regeln, für die ein
Administrator dies explizit aktiviert. Ein Aktivieren
der Protolllfunktion führt also nicht dazu, dass
automatisch alle Regeln protokolliert werden. Vielmehr
entscheidet der Administrator der Firewall, welche Regeln
protokolliert werden sollen. Dazu wird die Option
log
für diese Regeln aktiviert. Im
Regelfall werden nur deny
-Regeln
protokolliert, beispielsweise die deny
-Regel
für eintreffende ICMP-Nachrichten.
Üblicherweise wird die „ipfw default deny
everything“-Regel doppelt angelegt. Einmal mit und
einmal ohne aktivierte Option log
. Dadurch
erhält man eine Auflistung aller Pakete, auf die keine
Regel zutraf.
Protokollierung ist allerdings ein zweischneidiges Schwert, bei mangelnder Vorsicht wird man mit einer enormen Flut von Protokollierungsdaten förmlich überschwemmt und belastet zusätzlich die Festplatte des Systems durch rasch wachsende Protokolldateien. DoS-Angriffe, die auf diese Art und Weise Festplatten an die Kapazitätsgrenze treiben, gehören zu den ältesten Angriffen überhaupt. Außerdem werden Protokollnachrichten nicht nur an syslogd(8) geschickt, sondern auch auf einem root-Terminal angezeigt.
Die Kerneloption
IPFIREWALL_VERBOSE_LIMIT=5
begrenzt die
Anzahl gleicher Nachrichten an syslogd(8) für
eine gegebene Regel auf fünf Nachrichten. Ist diese
Option im Kernel aktiviert, wird nach Erreichen der
festgelegten Anzahl die Protokollierung einer (sich
unmittelbar hintereinander wiederholenden) Nachricht auf den
angegebenen Schwellenwert begrenzt, da beispielsweise die
Speicherung von 200 gleichen Protokollnachrichten durch
syslogd(8) sinnlos ist. Daher werden durch diesen
nur füf derartige Nachrichten protokolliert. Alle
weiteren derartigen Nachrichten werden nur gezählt und
deren Gesamtzahl wird schließlich von syslogd(8)
durch folgenden Ausdruck ausgegeben:
Alle protokollierten Nachrichten für Datenpakete
werden in der Voreinstellung in die Datei
/var/log/security
(die in der Datei
/etc/syslog.conf
definiert wird),
geschrieben.
Die meisten fortgeschrittenen IPFW-Nutzer erzeugen eine Datei, die die Regeln für die Firewall enthält, um diese als Skript ausführen zu können. Der Hauptvorteil einer derartigen Konfiguration ist es, dass dadurch mehrere Regeln gleichzeitig geändert und (re-)aktiviert werden können, ohne dass dazu das System neu gestartet werden muss. Dies ist auch beim Testen von Regeländerungen sehr hilfreich. Weil es sich bei der Datei, in der die Regeln gespeichert sind, um ein Skript handelt, ist es auch möglich, häufig verwendete Werte/Befehle durch Aliase zu ersetzen und diese so in mehreren Regeln zu nutzen. Diese Funktion wird im folgenden Beispiel näher vorgestellt.
Die Syntax des folgenden Skripts entspricht der Syntax von sh(1), csh(1) sowie tcsh(1). Felder, die symbolisch substituiert werden, haben das Präfix $ (das Dollarzeichen). Symbolische Felder haben dieses $-Praefix nicht. Der Wert, mit dem das symbolische Feld belegt wird, muss in „doppelten Anführungszeichen“ eingeschlossen sein.
Beginnen Sie Ihre Regeldatei wie folgt:
Die Regeln in diesem Beispiel sind nicht wichtig. Wichtig ist es, zu zeigen, wie die symbolische Substitution innerhalb der Regeln verwendet wird.
Wurde dieses Beispiel in der Datei
/etc/ipfw.rules
gespeichert, so können
alle Regeln durch die Ausführung des folgenden Befehls
neu geladen werden:
#
sh /etc/ipfw.rules
Statt /etc/ipfw.rules
können Sie
auch einen beliebigen anderen Namen und/oder Speicherort
verwenden.
Alternativ könnten Sie die einzelnen Befehle dieses Skripts auch manuell starten:
#
ipfw -q -f flush
#
ipfw -q add check-state
#
ipfw -q add deny all from any to any frag
#
ipfw -q add deny tcp from any to any established
#
ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state
#
ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state
#
ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state
Das folgende Regelwerk (ohne NAT-Funktionalität) ist ein Beispiel dafür, wie man eine sehr sichere „einschließende“ Firewall aufsetzen kann. Eine einschließende Firewall erlaubt es nur Diensten, für die explizite Regeln existieren, die Firewall zu passieren. Alle anderen Dienste und Pakete werden hingegen blockiert. Firewalls, die ganze Netzwerksegmente schützen sollen, benötigen mindestens zwei Netzwerkschnittstellen, für die jeweils eigene Regeln definiert werden müssen, damit die Firewall ordnungsgemäß funktioniert.
Alle unixoiden Betriebssysteme (aber auch solche, die
Konzepte aus UNIX® implementieren), darunter auch FreeBSD,
verwenden die Schnittstelle lo0
mit
der IP-Adresse 127.0.0.1
zur
internen Kommunikation mit dem Betriebssystem. Die Firewall
muss so eingestellt sein, dass sie den Datenverkehr dieser
speziellen (und nur intern genutzten) Pakete ungehindert
durchlässt.
Die Regeln, die den Zugriff auf eingehene und ausgehende
Verbindungen regeln, autorisieren und kontrollieren,
müssen mit der für die Verbindung zum
öffentlichen Internet verantwortlichen Schnittstelle
assoziiert werden. Bei dieser Schnittstelle kann es sich
beispielsweise um
PPP/tun0
oder
die Netzwerkkarte handelt, über, die mit Ihrem
DSL- oder Kabelmodem verbunden
ist.
Falls mehr als eine Netzwerkkarte mit einem privaten Netzwerk (hinter der Firewall) verbunden sind, müssen die Firewallregeln für alle diese Schnittstellen entstammenden Datenpakete freien und ungehinderten Datenverkehr erlauben.
Es ist sinnvoll, die Regeln in drei Abschnitte aufzuteilen. Der erste Abschnitt enthält die freien, von der Firewall nicht zu überwachenden Netzwerkschnittstellen. Danach folgen die öffentlichen, für den ausgehenden Verkehr verantwortlichen Schnittstellen. Zuletzt kommen dann die Schnittstellen, die für den eingehenden Datenverkehr verantwortlich sind.
Innerhalb der einzelnen Abschnitte ist es sinnvoll, die am häufigsten verwendeten Regeln vor den seltener verwendeten Regel zu platzieren. Jeder Abschnitt sollte mit einer letzten Regel (die alle Pakete, auf die keine Regel zutraf, verwirft) abgeschlossen werden.
Der Abschnitt für den ausgehenden Datenverkehr des
folgenden Beispiels enthät nur
allow
)-Regeln, in denen der Dienst, dem
der Zugriff auf das öffentliche Internet gewährt
wird, eindeutig definiert ist. Alle Regeln verwenden die
Optionen proto
, port
,
in/out
, via
sowie
keep state
kodiert. Die
Regeln mit proto tcp
verwenden
zusätzlich die Option setup
, damit
die initiale, eine Sitzung beginnende Anfrage identifiziert
werden kann, damit die die Zustandsttabelle gefüllt
werden kann.
Der Abschnitt für den eingehenden Datenverkehr
beginnt mit allen Regeln, die zur Blockierung
unerwünschten Datenverkehrs benötigt werden.
Für diese Vorgehensweise gibt es zwei Gründe:
Zum einen könnten bösartige Pakete legtitimen
Datenverker so sehr ähneln, dass sie die
Bedingungen von allow
-Regeln erfüllen
und daher die Firewall passieren dürfen. Daher sollten
derartige Pakete direkt verworden werden. Zum anderen
sollten unerwünschte Pakete mit bekannten (und somit
uninteressanten Mustern) sofort ohne Rückmeldung blockiert
werden, anstatt erst von der letzten, generischen Regel
blockiert (und, was noch wichtiger ist, auch noch
protokolliert). Die letzte Regel jedes Abschnittes blockiert
und protokolliert; sie kann daher dazu verwendet werden,
vor Gericht haltbare Beweise zu erhalten, damit sie gegen
Personen vorgehen können, die versuchen, Ihre Systeme
anzugreifen.
Achten Sie darauf, dass Sie keine Netwerkantworten für
geblockte Pakete senden. Diese müssen ohne
Rückmeldung verworfen werden, damit ein Angreifer keine
Informationen darüber erhält, ob seine Datenpakete
Ihr System erreicht hat. Je weniger Information ein Angreifer
über Ihr System erhält, desto sicherer ist Ihr
System. Datenpakete an Ports, die nicht bekannten Diensten
zugeordnet werden können, können über die Datei
/etc/services
identifiziert werden.
Alternativ kann eine Anfrage an http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Klarheit über die Aufgabe/Funktion einer bestimmten Portnummer
bringen. Auf der Seite http://www.sans.org/security-resources/idfaq/oddports.php
kann man Information über bekannte Trojaner und von
diesen verwendete Portnummern erhalten.
Das folgende Regelwerk (ohne
NAT-Funktionalität) beschreibt ein
vollständiges, einschließendes Regelwerk. Dieses
Regelwerk kann direkt auf Ihren eigenen Systemen eingesetzt
werden, wenn alle pass
-Regeln
für von Ihnen nicht benötigten Dienste
auskommentiert werden. Falls Sie keine Protokollierung
benötigen, können Sie diese im Abschnitt für
den eingehenden Datenverkehr durch eine
deny
deaktivieren. Die im Beispiel
verwendete Netzwerkschnittstelle dc0
müssen Sie durch die auf Ihrem System für
ausgehenden Datenverkehr vorgesehenen Netzwerkschnittstelle
ersetzen. Im Falle von benutzergesteuertem
PPPs wäre dies
beispielsweise tun0
.
Alle Regeln folgen einem bestimmten Muster.
Alle Ausdrücke, die eine Anfrage zum Beginn
einer zustandsgesteuerten darstellen, beinhalten den
Ausdruck keep-state
.
Alle Dienste aus dem öffentlichen Internet
beinhalten die Option limit
, um
gegebenenfalls
flooding zu
unterbinden.
Alle Regeln bezeichnen die Richtung durch der
Ausdrücke in
oder
out
.
Alle Regeln legen die verwendete
Netzwerkschnittstelle die Ausdrücke
via
und
interface-name
fest.
Die folgenden Regeln werden in der Datei
/etc/ipfw.rules
definiert.
Es müssen einige zusätzliche
Konfigurationseinstellungen vorgenommen werden, um die
die NAT-Funktion von IPFW zu nutzen. Die
Kernelquellen müssen mit der Option
IPDIVERT
(im IPFIREWALL-Abschnitt der
Kernelkonfigurationsdatei) neu gebaut werden, um den
benötigten angepassten Kernel zu erzeugen.
Zusätzlich werden folgende Optionen in der
/etc/rc.conf
benötigt:
Zustandshafte Regeln bei aktiviertem
divert natd
(Network
Address Translation) verkomplizieren die
Formulierung des Regelwerkes beträchtlich. Damit Ihre
Firewall funktioniert, kommt es insbesondere auf die Position
der Ausdrücke check-state
sowie
divert natd
an. Sie können nicht
länger einen einfachen, kaskadierenden Ablauf verwenden
(also einen Regelsatz, bei dem einfach auf eine Regel nach der
anderen geprüft wird. Vielmehr wird der neue
Aktionstyp skipto
benötigt. Dies
erfordert, dass jede Regel über eine eindeutige Nummer
verfügt, um so eindeutige Sprungziele zu erhalten.
Im Folgenden wird anhand eines umkommentierten Beispiels der Paketfluss durch das Regelwerk verdeutlicht.
Die Verarbeitung beginnt mit der ersten Regel (also am
Anfang der Regeldatei. Sie setzt sich Regel für Regel
weiter fort, bis das Ende der Datei erreicht ist oder eine
Regel für das Paket einen Treffer erzielt und das Paket
so die Firewall verlassen kann. Achten Sie besonders auf die
Position der Regeln mit den Nummern
100, 101, 450, 500
sowie
510
. Diese Regeln steuern die
Adressumsetzung ausgehender und eingehender Pakete, so dass
deren entsprechende Einträge in der Zustandstabelle immer
die private LAN-Adressen abbilden. Zusätzlich werden in
allen Regeln die Richtung des Pakets (eingehend oder
ausgehend) so die vom Paket zu verwendende Netzwerkschnittstelle
definiert. Ausgehende Anfragen, die eine Sitzung starten, rufen
immer skipto rule 500
, damit
NAT verwendet werden kann.
Nehmen wir nun an, dass ein Nutzer einen Webbrowser
verwendet, um eine Internetseite aufzurufen. Derartige
Anfragen werden in der Regel über Port 80 geleitet. Die
zugehörigen Pakete werden durch die Firewall verarbeitet.
Regel 100 trifft nicht zu, denn das Paket geht nach außen,
nicht nach innen. Regel 101 trifft ebenfalls nicht zu, denn es
handelt sich um das erste Paket. Folglich wird die Sitzung
erst initiiert und kann somit noch nicht in der
Zustandstabelle enthalten sein kann. Die erste Regel, die
zutrifft, ist Regel 125. Das Paket will das lokale Netzwerk
über die Schnittstelle zum öffentlichen Internet (das
heißt nach außen) verlassen, es hat aber noch die
Quelladresse des privaten lokalen Netzwerks. Da Regel 125
zutrifft, werden zwei Aktionen ausgeführt: Die Option
keep-state
bewirkt, dass das Paket in der
internen Tabelle für zustandshafte, dynamische Regeln
registriert wird. Danach wird der Aktionsteil der Regel
ausgeführt. Dieser ist Bestandteil der Informationen, die
in die in der Tabelle für dynamische Regeln aufgenommen
wird und lautet skipto rule 500
. Die
Regel 500 führt NATs auf die
IP-Adresse des Paketes durch. Danach verlässt das Paket
das LAN nach außen in Richtung des öffentlichen
Internets. Dieser letzte Teil ist für funktionierendes
NAT von entscheidender Bedeutung. Nachdem dieses Paket
am Bestimmungsort angekommen ist, wird dort eine Antwort
generiert und zurückgeschickt. Dieses Paket wird auf die
gleiche Art und Weise durch das gegebene Regelwerk
verarbeitet. Dieses Mal trifft Regel 100 auf das Paket zu,
damit wird die Bestimmungsadresse auf die zugehörige
(lokale) LAN-Adresse (rück-)abgebildet. Danach wird es
von der check-state
-Regel verarbeitet,
die Zustandstabelle erkennt, dass eine zugehörige
aktive Sitzung vorliegt und das Paket wird freigegeben
und in das LAN geleitet. Es wird innerhalb des LANs von dem PC,
der die zugehörige Sitzung hält, empfangen, der
ein neues Paket absendet und ein weiteres Datensegment vom
entfernten Server anfordert. Dieses Mal wird bei der
Prüfung der check-state
-Regel ein
nach außen gehender zugehöriger Eintrag in der
Zustandstabelle gefunden und die entsprechende Aktion (also
skipto 500
) wird ausgeführt. Das
Paket springt zu Regel 500 und wird durch diese Regel für
das öffentliche Internet freigegeben.
Innerhalb des durch die Firewall geschützten
Netzwerks werden alle eingehenden Pakete, die zu einer
existierenden Sitzung gehören, durch die Regel
check-state
sowie entsprechend platzierte
divert natd
-Regeln verarbeitet. Die
notwendige Arbeit beschränkt sich darauf, alle
„schlechten“ Pakete zu blockieren und nur
authorisierten Diensten zugehörige Pakete
durchzulassen. In Umkehrung des bisherigen Beispiels nehmen
wir nun, dass auf dem Rechner, auf dem die Firewall läuft,
auch ein Apache Webserver läuft, auf den von außen,
also aus dem öffentlichen Internet, zugegriffen werden
kann. Das erste von außen eintreffende Paket (das auch
eine neue Sitzung startet) erfüllt Regel 100. Die
Zieladresse des Paketes wird daher auf die LAN-Adresse des
Firewallrechners abgebildet. Das Paket wird dann weiter auf
alle in der Firewall definierten Regeln geprüft und trifft
schließlich auf Regel 425. Durch diese Regel werden
zwei Aktionen ausgelösst: Erstens wird aus dem Paket
eine dynamische Regel generiert und in die Zustandstabelle
geschrieben. Zusätzlich wird jedoch die Anzahl neuer
Sitzungsanfragen (von der gleichen Quell-IP-Adresse) auf
2
begrenzt, um so DoS-Angriffe auf Dienste,
die auf diesem Port laufen, zu verhindern. Die Aktion dieser
Regel ist allow
, daher wird das Paket
freigegeben und in das LAN weitergeleitet. Das als Antwort
generierte Paket wird durch die
check-state
-Regel als zu einer Sitzung
gehörend erkannt. Damit wird es der Regel 500
zugeführt, NAT wird durchgeführt
und über die Schnittstelle zum öffentlichen Internet
nach außen geroutet.
Beispiel 1 für einen Regelsatz:
Das folgende Beispiel ist praktisch identisch mit dem ersten Regelsatz. Allerdings wurden die Regel umfassend kommentiert und umgeschrieben, damit sie für weniger erfahrene Benutzer leichter verständlich werden.
Beispiel 2 für einen Regelsatz:
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.