IPFILTER, auch als IPF bekannt, ist eine plattformübergreifende Open Source Firewall, die auf mehrere Betriebssysteme portiert wurde, einschließlich FreeBSD, NetBSD, OpenBSD und Solaris™.
IPFILTER basiert auf einer kernelseitigen Firewall und einem NAT-Mechanismus, der durch Anwenderprogramme gesteuert und überwacht werden kann. Firewallregeln werden mit ipf gesetzt oder gelöscht. Für die Manipulation der NAT-Regeln wird ipnat benutzt. Mit ipfstat werden Laufzeitstatistiken der kernelseitigen Anteile von IPFILTER aufgelistet. Mit ipmon können die Aktionen von IPFILTER in Protokolldateien gespeichert werden.
IPF wurde ursprünglich mit der
Verarbeitungslogik „die letzte passende Regel
gewinnt“ geschrieben und verwendete ausschließlich
Regeln ohne feste Zustände. Inzwischen wurde
IPF modernisiert und unterstützt nun
auch die Optionen quick
und
keep state
.
Antworten auf häufige Fragen finden Sie unter
http://www.phildev.net/ipf/index.html
. Ein Archiv
der IPFILTER Mailingliste steht unter
http://marc.info/?l=ipfilter
zur Verfügung.
Dieser Abschnitt des Handbuchs konzentriert sich auf
IPF unter FreeBSD. Es werden auch
Firewallregeln mit den Optionen quick
und
keep state
vorgestellt.
IPF ist in FreeBSD als ladbares Kernelmodul enthalten. Das bedeutet, dass Sie keinen angepassten Kernel erzeugen müssen um IPF zu aktivieren.
Benutzer, die IPF lieber statisch in den Kernel kompilieren, sollten den Anweisungen in Kapitel 8, Konfiguration des FreeBSD-Kernels folgen. Die folgenden Kerneloptionen stehen zur Verfügung:
options IPFILTER options IPFILTER_LOG options IPFILTER_LOOKUP options IPFILTER_DEFAULT_BLOCK
options IPFILTER
aktiviert die
Unterstützung für IPFILTER.
options IPFILTER_LOG
aktiviert die
Protokollierung über die Pseudo-Schnittstelle
ipl
für Firewallrelgen, die das
Schlüsselwort log
enthalten.
IPFILTER_LOOKUP
aktiviert
IP-Pools, um die Suche nach
IP-Adressen zu beschleunigen.
IPFILTER_DEFAULT_BLOCK
ändert das
Verhalten der Firewall dahingehend, dass jedes Paket, das
nicht explizit von einer pass
-Regel
Zugang erhält, geblockt wird.
Um IPF während des Bootens zu
aktivieren, müssen folgende Einträge in
/etc/rc.conf
hinzugefügt werden. Diese
Einträge aktivieren ebenfalls die Protokollierung und die
Regel default pass all
. Um diese
Voreinstellung zu ändern, ohne einen neuen Kernel zu
übersetzen, müssen Sie am Ende der Firewallregeln eine
block all
Regel hinzufügen.
ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file ipmon_enable="YES" # Start IP monitor log ipmon_flags="-Ds" # D = start as daemon # s = log to syslog # v = log tcp window, ack, seq # n = map IP & port to names
Wenn die NAT-Funktionalität benötigt wird, müssen auch diese Zeilen hinzugefügt werden:
gateway_enable="YES" # Enable as LAN gateway ipnat_enable="YES" # Start ipnat function ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat
Jetzt können Sie IPF starten:
#
service ipfilter start
Um die Firewallregeln zu laden, übergeben Sie den Namen
des Regelwerks an ipf
. Mit dem folgenden
Kommando ersetzen Sie alle aktuell geladenen Regeln:
#
ipf -Fa -f /etc/ipf.rules
-Fa
löscht zunächst alle internen
Regeln und mit -f
wird die Datei angegeben,
welche die zu ladenen Regeln enthält.
Damit haben Sie die Möglichkeit, Änderungen an der laufenden Firewall zu machen, ohne dass das System neu gestartet werden muss. Da dieser Vorgang beliebig oft wiederholt werden kann, ist es ein sehr bequemer Weg neue Regeln zu testen.
Diese und weitere Optionen sind in ipf(8) beschrieben.
Mit der hier beschriebenen Regel-Syntax können
zustandsorientierte Regeln erstellt werden. Beim Erstellen
von Regeln ist zu beachten, dass Regeln ohne das Schlüsselwort
quick
der Reihe nach geprüft werden und
„die letzte zutreffende Regel“ angewendet wird.
Das bedeutet, dass selbst dann, wenn die erste zutreffende
Regel eine pass
-Regel ist, das Paket
dennoch geblockt wird, falls später eine
block
-Regel zutrifft. Beispielregelsätze
finden Sie in
/usr/share/examples/ipfilter
.
Beim Erstellen von Regeln wird das Zeichen
#
verwendet, um einen Kommentar bis zum
Ende der Zeile einzuleiten. Leere Zeilen werden
ignoriert.
Die Schlüsselwörter, die in den Regeln verwendet werden, müssen in einer bestimmten Reihenfolge geschrieben werden, von links nach rechts. Einige Schlüsselwörter sind verbindlich, andere sind optional. Einige Schlüsselwörter haben Unteroptionen, die wiederum selbst Schlüsselwörter sind und ebenfalls weitere Unteroptionen einschließen können. Die Reihenfolge der Schlüsselwörter ist wie folgt, wobei die Wörter in Großbuchstaben eine Variable darstellen und die Wörter in Kleinbuchstaben der Variable vorangestellt werden müssen:
ACTION DIRECTION OPTIONS proto PROTO_TYPE
from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT
TCP_FLAG|ICMP_TYPE keep state STATE
Dieser Abschnitt beschreibt jedes dieser Schlüsselwörter und ihre Optionen. Es ist jedoch keine vollständige Liste aller möglichen Optionen. ipf(5) enthält eine vollständige Beschreibung der Syntax und einige Beispiele zur Erstellung von IPF-Regeln.
Dieses Schlüsselwort bestimmt, was mit dem Paket zu tun ist, wenn es auf eine Regel zutrifft. Jede Regel muss dieses Schlüsselwort enthalten. Die folgenden Aktionen werden erkannt:
block
: Das Paket wird
verworfen.
pass
: Das Paket wird
durchgelassen.
log
: Das Paket wird
protokolliert.
count
: Zählt die Anzahl der
Pakete und die Bytes. Die kann einen Hinweis darauf
geben, wie oft Pakete auf diese Regel zutreffen.
auth
: Das Paket geht in eine
Warteschlange zur Weiterverarbeitung durch ein anderes
Programm.
call
: Ermöglicht den Zugriff auf
eingebaute IPF-Funktionen,
die komplexere Aktionen ermöglichen.
decapsulate
: Entfernt alle
Header, um den Inhalt des Pakets zu verarbeiten.
Als nächstes muss für jede Regel explizit die Richtung mit einem der folgenden Schlüsselwörter angegeben werden:
in
: Die Regel wird auf ein
eingehendes Paket angewendet.
out
: Die Regel wird auf ein
ausgehendes Paket angewendet.
all
: Die Regel gilt für beide
Richtungen.
Wenn das System mehrere Schnittstellen ausweist,
kann die Schnittstelle zusammen mit der Richtung
angegeben werden. Ein Beispiel wäre
in on fxp0
.
Optionen müssen nicht zwingend angegeben werden. Falls jedoch mehrere Optionen angegeben werden, müssen sie in der hier gezeigten Reihenfolge verwendet werden.
log
: Wenn die Firewall die
angegebene Aktion durchführt, werden die Kopfdaten des
Pakets auf der Pseudo-Schnittstelle ipl(4)
protokolliert.
quick
: Wenn ein Paket mit dieser
Regel übereinstimmt, wird die Aktion für diese Regel
ausgeführt und die Regelprüfung stoppt an dieser
Stelle.
on
: Auf dieses Schlüsselwort muss
der Name der Schnittstelle folgen. Die Regel trifft nur
dann zu, wenn das Paket auf der angegebenen
Schnittstelle in die angegebene Richtung geht.
Wenn das Schlüsselwort log
verwendet wird, können die folgenden Ausdrücke in
dieser Reihenfolge benutzt werden:
body
: die ersten 128 Bytes des
Paketinhaltes werden zusätzlich zu den Kopfdaten
protokolliert.
first
: trifft nur zu, wenn das
Schlüsselwort log
zusammen mit
keep-state
verwendet wird. Es
bestimmt, dass nur das auslösende Paket protokolliert
wird und nicht jedes weitere Paket, dass von der
gespeicherten Status-Regel betroffen ist.
Es stehen noch weitere Optionen zur Rückmeldung von Fehlern verfügbar. Ausführliche Details finden Sie in ipf(5).
Der Protokolltyp ist optional. Er ist jedoch
zwingend erforderlich, falls die Regel einen
SRC_PORT oder DST_PORT angeben muss da es den Typ des
Protokolls bestimmt. Wenn Sie das Protokoll angeben,
verwenden Sie das Schlüsselwort
proto
, gefolgt von der
Protokollnummer oder dem Namen aus
/etc/protocols
. Zum Beispiel
tcp
, udp
, oder
icmp
. Wenn PROTO_TYPE angegeben
wird und SCR_PORT oder DST_PORT ausgelassen werden,
stimmen alle Portnummern für dieses Protokoll mit dieser
Regel überein.
Das Schlüsselwort from
ist
verpflichtend und darauf folgt das Schlüsselwort, das
die Quelle des Pakets darstellt. Die Quelle kann ein
Rechnername, eine IP-Adresse gefolgt
von der CIDR-Maske, ein Adresspool
oder das Schlüsselwort all
sein.
ipf(5) enthält einige Beispiele.
IP-Bereiche können nur in der
CIDR-Notation angegeben werden. Der
Port oder das Paket net-mgmt/ipcalc
hilft bei der Berechnung der richtigen
CIDR-Maske. Weiterführende
Informationen finden Sie auf der Webseite
http://jodies.de/ipcalc
.
Die Portnummer der Quelle ist optional. Wenn sie
jedoch verwendet wird, muss in der Regel zuerst
PROTO_TYPE angegeben werden. Die Portnummer muss auch
auf das Schlüsselwort proto
folgen.
Es werden verschiedene Vergleichsoperatoren
unterstützt: =
(gleich),
!=
(nicht gleich),
<
(kleiner als),
>
(größer als),
<=
(kleiner als oder gleich)
>=
(größer als oder
gleich).
Um Portbereiche anzugeben, schreiben Sie zwei
Portnummern zwischen <>
(kleiner als und größer als),
><
(größer als und kleiner
als), oder :
(größer als oder gleich
und kleiner als oder gleich).
Das Schlüsselwort to
ist
verpflichtend und darauf folgt das Schlüsselwort,
welches das Ziel des Pakets darstellt. Dieses Ziel kann
ein Rechnername, eine IP-Adresse
gefolgt von der CIDR-Maske, ein
Adresspool oder das Schlüsselwort all
sein.
Die Portnummer des Ziels ist optional. Wenn sie
jedoch verwendet wird, muss in der Regel zuerst
PROTO_TYPE angegeben werden. Die Portnummer muss auch
auf das Schlüsselwort proto
folgen.
Wenn tcp
als PROTO_TYPE verwendet
wird, können bestimmte TCP-Flags
angegeben werden, die den Zustand einer Verbindung
bestimmen. Mögliche Flags sind:
S
(SYN),
A
(ACK),
P
(PSH),
F
(FIN),
U
(URG),
R
(RST),
C
(CWN) und
E
(ECN).
Wenn icmp
als PROTO_TYPE
verwendet wird, kann der ICMP-Typ mit
angegeben werden. ipf(5) enthält eine Auflistung
der zulässigen Typen.
Wenn eine pass
-Regel das
Schlüsselwort keep state
enthält,
wird IPF einen Eintrag in
der dynamischen Zustandstabelle hinzufügen, damit
nachfolgende Pakete dieser Verbindung ebenfalls
durchgelassen werden. IPF
kann den Zustand für TCP,
UDP und
ICMP-Sitzungen verfolgen.
IPF wird jedes Paket, das
zu einer aktiven Sitzung gehört, durchlassen, auch
wenn ein anderes Protokoll verwendet wird.
Pakete, die über die Schnittstelle zum öffentlichen Internet raus gehen, werden von IPF zuerst gegen die dynamische Zustandstabelle geprüft. Wenn das nächste Paket dieser aktiven Sitzung mit dem vorherigen Paket übereinstimmt, verlässt dieses Paket die Firewall und der Status wird in der dynamischen Zustandstabelle aktualisiert. Pakete, die nicht zu einer aktiven Sitzung gehören, werden gegen ausgehende Regeln geprüft. Eingehende Pakete von der Schnittstelle zum öffentlichen Internet werden gegen die dynamische Zustandstabelle geprüft. Wenn das nächste Paket mit der aktiven Sitzung übereinstimmt, verlässt dieses Paket die Firewall und der Status wird in der dynamischen Zustandstabelle aktualisiert. Pakete, die nicht zu einer aktiven Sitzung gehören, werden gegen eingehende Regeln geprüft.
Mehrere Schlüsselwörter können an
keep state
angefügt werden. Bei der
Verwendung dieser Schlüsselwörter werden verschiedene
Optionen gesetzt, um die zustandsorientierte Filterung
zu steuern. ipf(5) enthält eine Liste der
verfügbaren Optionen und deren Beschreibungen.
Dieser Abschnitt beschreibt die Erstellung eines Regelsatzes, welcher nur entsprechende Dienste erlaubt und alle anderen Verbindungen blockiert.
FreeBSD verwendet die Loopback-Schnittstelle
(lo0
) und die
IP-Adresse 127.0.0.1
zur internen
Kommunikation. Der Regelsatz muss Regeln enthalten, die
Pakete für diesen internen Verkehr ermöglichen:
# no restrictions on the loopback interface pass in quick on lo0 all pass out quick on lo0 all
Die mit dem Internet verbundene Schnittstelle wird für die Autorisierung und den Zugriff aller ein- und ausgehenden Verbindungen verwendet. Wenn eine oder mehrere Schnittstellen mit privaten Netzwerken verbunden sind, müssen Regeln existieren, die den Datenverkehr aus dem LAN zwischen den internen Netzwerken oder ins Internet erlauben. Der Regelsatz sollte in drei Bereiche unterteilt werden: vertrauenswürdige interne Schnittstellen, ausgehende Verbindungen über die öffentlichen Schnittstellen und eingehende Verbindungen über die öffentliche Schnittstelle.
Diese beiden Regeln erlauben den gesamten Datenverkehr
über eine vertrauenswürdige
LAN-Schnittstelle namens
xl0
:
# no restrictions on inside LAN interface for private network pass out quick on xl0 all pass in quick on xl0 all
Die Regeln für den ein- und ausgehenden Verkehr der öffentlichen Schnittstelle sollten in einer bestimmten Reihenfolge geschrieben werden. Zuerst Regeln, die häufiger übereinstimmen, danach Regeln, die seltener übereinstimmen. Die letzte Regel blockiert und protokolliert alle Pakete auf der Schnittstelle.
Der folgende Regelsatz definiert die ausgehenden Regeln
der öffentlichen Schnittstelle dc0
.
Die Regeln prüfen den Zustand und identifizieren bestimmte
Dienste, auf die die internen Systeme zugreifen dürfen. Alle
Regeln verwenden das Schlüsselwort quick
und geben die passenden Portnummern und ggf. auch die
Zieladressen an.
# interface facing Internet (outbound) # Matches session start requests originating from or behind the # firewall, destined for the Internet. # Allow outbound access to public DNS servers. # Replace x.x.x. with address listed in /etc/resolv.conf. # Repeat for each DNS server. pass out quick on dc0 proto tcp from any to x.x.x. port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # Allow access to ISP's specified DHCP server for cable or DSL networks. # Use the first rule, then check log for the IP address of DHCP server. # Then, uncomment the second rule, replace z.z.z.z with the IP address, # and comment out the first rule pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Allow HTTP and HTTPS pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Allow email pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Allow NTP pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Allow FTP pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Allow SSH pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Allow ping pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Block and log everything else block out log first quick on dc0 all
Die folgenden Beispielregeln für den eingehenden Verkehr auf der öffentlichen Schnittstelle blockieren zuerst alle unerwünschten Pakete. Dies reduziert die Anzahl der Pakete, die durch die letzte Regel protokolliert werden.
# interface facing Internet (inbound) # Block all inbound traffic from non-routable or reserved address spaces block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP block in quick on dc0 from 127.0.0.0/8 to any #loopback block in quick on dc0 from 0.0.0.0/8 to any #loopback block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast # Block fragments and too short tcp packets block in quick on dc0 all with frags block in quick on dc0 proto tcp all with short # block source routed packets block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Block OS fingerprint attempts and log first occurrence block in log first quick on dc0 proto tcp from any to any flags FUP # Block anything with special options block in quick on dc0 all with ipopts # Block public pings and ident block in quick on dc0 proto icmp all icmp-type 8 block in quick on dc0 proto tcp from any to any port = 113 # Block incoming Netbios services block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81
Wenn eine Regel mit der Option
log first
protokolliert wird, können Sie
mit ipfstat -hio
prüfen, wie viele
Übereinstimmungen es für diese Regel gibt. Eine große Anzahl
von Übereinstimmungen kann darauf hindeuten, dass das System
angegriffen wird.
Die restlichen Regeln definieren, welche Verbindungen aus dem Internet kommend hergestellt werden dürfen. Die letzte Regel blockiert alle Verbindungen, die nicht ausdrücklich von vorhergehenden Regeln erlaubt wurden.
# Allow traffic in from ISP's DHCP server. Replace z.z.z.z with # the same IP address used in the outbound section. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Allow public connections to specified internal web server pass in quick on dc0 proto tcp from any to x.x.x.x port = 80 flags S keep state # Block and log only first occurrence of all remaining traffic. block in log first quick on dc0 all
Um NAT zu aktivieren, fügen Sie
folgende Zeilen in /etc/rc.conf
hinzu.
Geben Sie den Namen der Datei an, welche die
NAT-Regeln enthält:
gateway_enable="YES" ipnat_enable="YES" ipnat_rules="/etc/ipnat.rules"
NAT-Regeln sind sehr flexibel, um den Bedürfnissen von kommerziellen Anwendern und Heimanwendern gerecht zu werden. Die hier vorgestellte Regelsyntax wurde vereinfacht, um die gemeinsame Nutzung zu demonstrieren. Eine vollständige Beschreibung der Syntax finden Sie in ipnat(5).
Die grundlegende Syntax für eine
NAT-Regel ist wie folgt.
map
leitet die Regel ein und
IF
sollte durch den Namen der externen
Schnittstelle ersetzt werden:
mapIF
LAN_IP_RANGE
->PUBLIC_ADDRESS
LAN_IP_RANGE
ist ein Bereich
von IP-Adressen, der von den internen
Rechnern verwendet wird. In der Regel ist dies ein privater
Bereich, beispielsweise 192.168.1.0/24
.
PUBLIC_ADDRESS
kann entweder eine
statische externe IP-Adresse sein, oder das
Schlüsselwort 0/32
, welches der
zugewiesenen IP-Adresse für
IF
entspricht.
Wenn ein Paket aus dem LAN mit einem
öffentlichen Ziel an der IPF
Firewall ankommt, werden zunächst die Regeln für den
ausgehenden Verkehr geprüft. Danach wird das Paket an das
NAT-Regelwerk geleitet, wo es von oben nach
unten gelesen und geprüft wird, wobei die erste
übereinstimmende Regel gewinnt.
IPF testet jede
NAT-Regel gegen die Schnittstelle und die
Quell-IP-Adresse des Pakets. Wenn der
Schnittstellenname des Pakets mit einer
NAT-Regel übereinstimmt, wird geprüft, ob
die Quell-IP-Adresse des Pakets auf den
Bereich in LAN_IP_RANGE
passt.
Wenn dies der Fall ist, wird die
Quell-IP-Adresse des Pakets mit der Adresse
aus PUBLIC_ADDRESS
überschrieben. IPF speichert die
Einträge in seiner internen NAT-Tabelle, so
dass wenn das Paket aus dem Internet zurückkehrt, es der
ursprünglichen privaten IP-Adresse
zugeordnet werden kann, bevor es von den weiteren
Firewallregeln geprüft wird.
Bei Netzwerken mit einer großen Anzahl von Systemen oder mehreren Subnetzen, steigert sich der Ressourcenverbrauch für das Umschreiben der IP-Adressen. Es existieren zwei Methoden, um dieses Problem zu umgehen.
Bei der ersten Methode wird ein Portbereich definiert, der
für die Quell-Ports verwendet wird. Durch das Hinzufügen des
Schlüsselworts portmap
kann
NAT angewiesen werden, nur Quell-Ports aus
dem angegebenen Bereich zu benutzen:
map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000
Alternativ kann das Schlüsselwort auto
verwendet werden. Dadurch ermittelt NAT
selbstständig die zur Verfügung stehenden Ports:
map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto
Mit der zweiten Methode wird ein Pool von öffentlichen Adressen verwendet. Dies ist nützlich, wenn es viele Systeme im Netzwerk gibt und ein Block öffentlicher IP-Adressen verfügbar ist. Aus diesem Pool kann NAT dann IP-Adressen für die ausgehenden Pakete auswählen.
Der Bereich der öffentlichen IP-Adressen kann mit einer Netzmaske oder der CIDR-Notation festgelegt werden. Die folgenden Regeln sind identisch:
map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 map dc0 192.168.1.0/24 -> 204.134.75.0/24
Es ist gängige Praxis, öffentlich zugängliche Web- oder
Mail-Server getrennt von den internen Netzwerksegmenten zu
betreiben. Der Verkehr von diesen Servern muss dennoch von
NAT bearbeitet werden und die Portumleitung
ist erforderlich, um den eingehenden Datenverkehr an den
richtigen Server zu leiten. Verwenden Sie beispielsweise
folgende Regel, um den eingehenden Verkehr auf der
öffentlichen IP-Adresse 20.20.20.5
dem internen
Server mit der Adresse 10.0.10.25
zuzuordnen:
rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80
Wenn dies der einzige Webserver im Netz ist, würde auch
folgende Regel funktionieren, die alle
HTTP-Anfragen an 10.0.10.25
umleitet:
rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80
IPF enthält einen FTP-Proxy, der zusammen mit NAT benutzt werden kann. Dieser Proxy überwacht den ausgehenden Datenverkehr für aktive und passive Verbindungsanfragen und erstellt dynamische Filterregeln, welche die Portnummern des jeweiligen FTP-Datenkanal enthalten. Dadurch entfällt die Notwendigkeit, viele Ports für FTP-Verbindungen zu öffnen.
In diesem Beispiel verwendet die erste Regel den Proxy für ausgehende FTP-Verbindungen aus dem internen LAN. Die zweite Regel übergibt den FTP-Datenverkehr von der Firewall an das Internet und die dritte Regel handhabt den restlichen Datenverkehr aus dem internen LAN:
map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp map dc0 10.0.10.0/29 -> 0/32
FTP map
-Regeln
stehen vor den NAT-Regeln. Wenn ein Paket
mit der FTP-Regel übereinstimmt, erstellt
der FTP-Proxy eine temporäre Filterregel,
damit die Pakete durchgelassen und von NAT
verarbeitet werden können. Alle Pakte aus dem
LAN, die nicht für FTP
bestimmt sind, werden von NAT verarbeitet,
wenn sie mit der dritten Regel übereinstimmen.
Ohne den FTP-Proxy würden stattdessen
folgende Regeln benötigt. Beachten Sie, dass ohne den Proxy
alle Ports oberhalb von 1024
freigegeben
werden müssen:
# Allow out LAN PC client FTP to public Internet # Active and passive modes pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Allow out passive mode data channel high order port numbers pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state$ # Active mode let data channel in from FTP server pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state
Nachdem die Datei mit den NAT-Regeln
bearbeitet wurde, führen Sie ipnat
mit
-CF
aus, um die aktuellen
NAT-Regeln und den Inhalt der dynamischen
Zuordnungstabelle zu löschen. Geben Sie
-f
zusammen mit dem
NAT-Regelsatz an:
#
ipnat -CF -f /etc/ipnat.rules
Statistiken zu NAT lassen sich wie folgt anzeigen:
#
ipnat -s
Die aktuellen Zuordnungen der NAT-Tabelle geben Sie mit diesem Kommando aus:
#
ipnat -l
Ausführliche Informationen erhalten Sie mit:
#
ipnat -v
IPF enthält mit ipfstat(8)
ein Werkzeug, mit dem Statistiken abgerufen und angezeigt
werden können. Die Zahlen beziehen sich auf den Zeitpunkt, an
dem die Firewall zuletzt gestartet wurde, beziehungsweise die
Statistik mit ipf -Z
zurückgesetzt
wurde.
Die Ausgabe von ifstat
sieht in etwa
wie folgt aus:
input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0)
Es stehen viele Optionen zur Verfügung. Wird entweder
-i
(eingehend) oder -o
(ausgehend) angegeben, wird der Befehl die entsprechende
Liste mit den derzeit vom Kernel benutzten Filterregeln
anzeigen. Um auch die Regelnummern zu sehen, muss
-n
angegeben werden. Zum Beispiel zeigt
ipfstat -on
die Tabelle für ausgehende
Regeln und die Regelnummer an:
@1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state
Wenn Sie der Regel ein -h
voranstellen,
wird der Zähler für die jeweilige Regel ausgegeben. Zum
Beispiel gibt ipfstat -oh
die ausgehenden
Regeln inklusive der Zähler aus:
2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state
Benutzen Sie ipfstat -t
um die
Zustandstabelle in einem top(1) ähnlichen Format
anzuzeigen. Unterliegt die Firewall einem Angriff, bietet
diese Option die Möglichkeit, die entsprechenden Pakete zu
identifizieren. Mit den optionalen Flags können
IP-Adressen, Ports oder Protokolle in
Echtzeit überwacht werden. Lesen Sie ipfstat(8) für
weitere Informationen.
IPF enthält mit
ipmon
ein Werkzeug, mit dem die
Protokolle der Firewall in menschenlesbarer Form gespeichert
werden können. Dies erfordert jedoch, dass
options IPFILTER_LOG
in die
Kernelkonfigurationsdatei hinzugefügt wird. Folgen Sie dazu
den Anweisungen in Kapitel 8, Konfiguration des FreeBSD-Kernels.
Um eine kontinuierliche Protokolldatei bereitzustellen,
läuft dieses Kommando normalerweise im Daemon-Modus, damit
auch ältere Ereignisse nachverfolgt werden können. Da FreeBSD
mit syslogd(8) ein Werkzeug besitzt, das automatisch
Protokolldateien rotiert, wird in der Voreinstellung für
ipmon_flags
-Ds
in
rc.conf
verwendet:
ipmon_flags="-Ds" # D = start as daemon # s = log to syslog # v = log tcp window, ack, seq # n = map IP & port to names
Protokollierung bietet die im Nachhinein die Möglichkeit festzustellen, welche Pakete verworfen wurden, von welchen Adressen diese Pakete kamen und wohin sie gehen sollten. Diese Informationen sind hilfreich beim Aufspüren von Angreifern.
Nachdem die Protokollierung in
/etc/rc.conf
aktiviert und mit
service ipmon start
gestartet wurde, wird
IPF Regeln aufzeichnen, welche das
Schlüsselwort log
enthalten. Der
Firewalladministrator entscheidet, welche Regeln protokolliert
werden. In der Regel werden nur geblockte Pakete
protokolliert. Es ist üblich, das Schlüsselwort
log
in der letzten Regel des Regelsatzes
mit aufzunehmen. Dies macht es möglich, alle Pakete zu sehen,
die mit keiner Regel des Regelsatzes übereinstimmten.
In der Voreinstellung verwendet
ipmon -Ds
local0
als
Protokoll-Facility. Die folgenden Level können verwendet
werden, um die erfassten Daten weiter aufzuspalten:
LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short due to an incomplete header
Damit IPF alle Daten
protokolliert, legen Sie zunächst eine neue Datei
/var/log/ipfilter.log
an:
#
touch /var/log/ipfilter.log
Um alle Nachrichten in der angegebenen Datei zu
protokollieren, fügen Sie den folgenden Eintrag in
/etc/syslog.conf
ein:
local0.* /var/log/ipfilter.log
Führen Sie service syslogd reload
aus,
damit syslogd(8) /etc/syslog.conf
neu einliest, um die Änderungen zu aktivieren.
Denken Sie daran, auch
/etc/newsyslog.conf
anzupassen, damit das
neue Protokoll rotiert wird.
Die von ipmon
generierten Nachrichten
bestehen aus Daten, welche durch Leerzeichen getrennt sind.
Alle Nachrichten enthalten die folgenden Felder:
Das Datum, an dem das Paket empfangen wurde.
Die Uhrzeit, wann das Paket empfangen wurde. Das Format ist HH:MM:SS.F (Stunden, Minuten, Sekunden und Sekundenbruchteile).
Der Name der Schnittstelle, die das Paket verarbeitet hat.
Die Gruppen- und Regelnummer im Format
@0:17
.
Die Aktion: p
für durchgelassene
Pakete, b
für blockierte Pakete,
S
für kurze Pakete,
n
für Pakete auf die keine Regel zutraf
und L
für Pakete die protokolliert
wurden.
Die Adressen werden in drei Felder unterteilt: die
Quelladresse und der Port getrennt durch Komma, das
Zeichen ->, sowie die Zieladresse und Port. Zum
Beispiel 209.53.17.22,80 ->
198.72.220.17,1722
.
PR
, gefolgt vom Namen oder Nummer
des Protokolls. Zum Beispiel
PR tcp
.
len
, gefolgt von der Größe des
Headers und der Gesamtgröße des Pakets. Zum Beispiel
len 20 40
.
Wenn es sich beim dem Paket um ein TCP-Paket handelt, gibt es ein zusätzliches Feld, das mit einem Bindestrich beginnt und die Buchstaben der entsprechenden Flags enthält. Eine Liste der Flags und deren Buchstaben finden Sie in ipf(5).
Wenn es sich beim dem Paket um ein
ICMP-Paket handelt, gibt es zwei
zusätzliche Felder: das erste Feld ist immer
„icmp“ und das zweite Feld enthält die
ICMP-Nachricht und den Nachrichten-Code,
getrennt durch einen Schrägstrich. Beispielswiese
icmp 3/3
für die Nachricht
Port unreachable.
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>.