Index: firewalls/chapter.xml =================================================================== --- firewalls/chapter.xml +++ firewalls/chapter.xml @@ -19,6 +19,7 @@ MichaelBunzelÜbersetzt von JohannKois BenjaminLukas + BjörnHeidotting @@ -1674,1621 +1675,6 @@ - - Die IPFILTER-Firewall (IPF) - - - firewall - - IPFILTER - - - Geschrieben wurde IPFILTER von Darren Reed. IPFILTER ist vom - Betriebssystem unabhängig: Es ist eine Open Source Anwendung, - die auf die Betriebssysteme &os;, NetBSD, OpenBSD, &sunos;, HP/UX - und &solaris; portiert wurde. IPFILTER wird aktiv betreut und - gepflegt. Es werden regelmäßig neue Versionen - herausgegeben. - - IPFILTER basiert auf einer kernelseitigen Firewall und einem - NAT Mechanismus, der durch Anwenderprogramme - betreut und gesteuert werden kann. Die Regeln der Firewall werden - mit dem Programm &man.ipf.8; gesetzt oder gelöscht. Für - die Manipulation der NAT Regeln verwendet man - &man.ipnat.8;. Mit &man.ipfstat.8; werden Laufzeitstatistiken der - kernelseitigen Anteile von IPFILTER aufgelistet. Und mit dem - Programm &man.ipmon.8; kann man die Aktionen von IPFILTER in die - Protokolldateien des Systems speichern. - - IPF funktionierte ursprünglich mit einer - Regel-Prozess-Logik à la die letzte Regel, die - passt, entscheidet und verwendete ausschließlich - Regeln ohne feste Zustände. Inzwischen wurde die - Regel-Prozess-Logik drastisch modernisiert: Es gibt eine - und eine zustandsorientierte Option. Die offizielle Dokumentation beinhaltet - leider nur die veralteten Parameter zur Regelerstellung - die neuen - Funktionen werden nur als Zusatzoptionen aufgelistet, was ihre - Vorteile beim Erstellen einer weit überlegenen und viel - sichereren Firewall völlig untergräbt. - - Die Anweisungen in diesem Kapitel basieren darauf, Regeln mit - den Optionen und - zu erstellen. Mit diesem Grundwissen wird man einen kompletten - einschließenden Regelsatz erstellen können. - - Für eine ausführliche Erläuterung der alten Methode - zur Regelverarbeitung schauen Sie bitte auf - http://www.munk.me.uk/ipf/ipf-howto.html oder - http://coombs.anu.edu.au/~avalon/ip-filter.html. - - Antworten auf häufige Fragen finden Sie unter - http://www.phildev.net/ipf/index.html. - - Und ein durchsuchbares Archiv der Mailingliste zu IPFILTER - gibt es unter http://marc.theaimsgroup.com/?l=ipfilter. - - - Aktivieren von IPF - - - IPFILTER - - enabling - - - &os; enthält IPF in der Standardversion als ladbares - Kernelmodul. Dieses Modul wird vom System automatisch geladen, - wenn in der rc.conf der Eintrag - ipfilter_enable="YES" angelegt wird. In dieser - ursprünglichen Konfiguration ist die Protokollierung aktiv - und die Option default pass all ("Pakete passieren - lassen") als Standard gesetzt. Um die block all - ("alles Blockieren") Option zu setzen, muss man nicht gleich - einen neuen Kernel bauen - es reicht, block all - als letzte Position des Regelsatzes aufzulisten. - - - - Kernel-Optionen - - - Kerneloptionen - - IPFILTER - - - - Kerneloptionen - - IPFILTER_LOG - - - - Kerneloptionen - - IPFILTER_DEFAULT_BLOCK - - - - IPFILTER - - Kerneloptionen - - - Es ist nicht unbedingt notwendig, IPF durch die folgenden - Optionen direkt in der Kernel einzubinden. Diese Möglichkeit - der Verwendung von IPF wird hier mehr als Hintergrundwissen angeboten. - Man sollte nur wissen, dass dadurch nicht mehr das Kernelmodul geladen - wird - und dementsprechend auch nicht mehr entladen werden kann. - - Die Beschreibung der einzelnen Optionen von IPF für die - Verwendung in der Kernelkonfiguration finden Sie auch in der Datei - /usr/src/sys/conf/NOTES. - - options IPFILTER -options IPFILTER_LOG -options IPFILTER_DEFAULT_BLOCK - - options IPFILTER aktiviert die Verwendung - der IPFILTER Firewall. - - options IPFILTER_LOG aktiviert den - Logging-Mechanismus. Das bedeutet, dass jedes Paket geloggt wird, - auf das eine Regel passt, die das Schlüsselwort - log enthält. Dazu wird der - Pseudo—Device ipl verwendet. - - options IPFILTER_DEFAULT_BLOCK ändert - das Verhalten der Firewall dahingehend, dass jedes Paket, dass nicht - explizit von einer pass Regel Zugang erhält, - abgewiesen, bzw. geblockt, wird. - - Diese Einstellungen werden erst aktiv, wenn der Kernel, in den sie - eingebunden wurden, kompiliert, installiert und gebootet wurde. - - - - Optionen in rc.conf - - Um IPF während des Bootvorgangs einzubinden, braucht man - lediglich die folgenden Zeilen der Datei - /etc/rc.conf anzufügen: - - ipfilter_enable="YES" # Startet IPF -ipfilter_rules="/etc/ipf.rules" # liest den Regelsatz aus einer Datei -ipmon_enable="YES" # Startet das IP-Monitor Log -ipmon_flags="-Ds" # D = Als Da:mon starten - # s = Protokollierung via syslog - # v = Protokollierung von tcp window, ack, seq - # n = Namen statt IP & port ausgeben - - - Falls sich hinter der Firewall ein lokales Netzwerk befindet, - das den reservierten privaten Adressbereich verwendet, müssen - die folgenden Zeilen zur Aktivierung von NAT - ebenfalls in /etc/rc.conf eingetragen - werden: - - gateway_enable="YES" # Aktivierung des LAN-Gateways -ipnat_enable="YES" # Startet die ipnat Funktion -ipnat_rules="/etc/ipnat.rules" # Liest die ipnat-Regeldefinitionen aus einer Datei - - - - - Der Befehl ipf - - ipf - - Mit dem Befehl &man.ipf.8; liest man die Datei, die den Regelsatz - enthält ein. Mit dem folgenden Befehl können Sie Ihre - eigenen, für Ihr System maßgeschneiderten Regeln einlesen - und so in einem Schritt alle Regeln der laufenden Firewall - ersetzen: - - &prompt.root; ipf -Fa -f /etc/ipf.rules - - bedeutet, dass alle intern gespeicherten - Tabellen mit Regeln gelöscht werden. - - gibt die Datei an, aus der die neuen Regeln - gelesen werden sollen. - - Mit diesen beiden Optionen erhalten Sie die Möglichkeit, - Änderungen an der Datei mit Ihrem Regelsatz vorzunehmen und - gleich die Firewall mit den neuen Regeln zu bestücken, ohne - den Rechner neu starten zu müssen. Da dieser Vorgang beliebig - wiederholt werden kann, ist es ein sehr bequemer Weg, neue Regeln - einzuarbeiten und zu testen. - - Um mehr über diese und weitere Optionen von &man.ipf.8; - zu erfahren, konsultieren Sie bitte die Manpage. - - &man.ipf.8; erwartet, dass es sich bei der Datei mit dem Regelsatz - um eine Standard-Textdatei handelt. Eine Datei, die ein Skript oder - Variablen enthält, wird nicht verarbeitet. - - Es gibt allerdings doch einen Weg, IPF Regeln mit Hilfe von - Skripten und Variablen zu erstellen. Weitere Informationen dazu - finden Sie unter . - - - - IPFSTAT - - ipfstat - - - IPFILTER - - statistics - - - Das normale Verhalten von &man.ipfstat.8; ist, die Zusammenfassung - der angefallenen Statistiken, die als Resultat der Anwendung von - nutzerspezifischen Regeln auf ein- und ausgehende Pakete seit dem - letzten Start der Firewall oder seit dem letzten Zurücksetzen - der Zähler auf Null durch das Kommando - ipf -Z angesammelt wurden, abzurufen und - anzuzeigen. - - Für weiterführende Informationen schauen Sie bitte - auf die Manpage von &man.ipfstat.8;! - - Die Ausgabe von &man.ipfstat.8;, wenn keine Parameter - übergeben wurden, sieht etwa so 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) - - Wenn die Option für - eingehend oder für - ausgehend übergeben wird, liefert das Kommando - eine entsprechende Liste von Filter-Regeln, die gerade installiert - sind und vom Kernel verwendet werden. - - ipfstat -in zeigt alle aktive Regeln - für eingehende Verbindungen zusammen mit ihren Nummern. - - ipfstat -on erledigt dasselbe für die - ausgehenden Verbindungen. - - Die Ausgabe sieht in etwa folgendermaßen aus: - - @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 - - ipfstat -ih zeigt die Tabelle der aktiven - Regeln für eingehende Verbindungen zusammen mit der Anzahl, - wie oft jeder einzelnen Regel entsprochen wurde. - - ipfstat -oh zeigt das Gleiche für - die ausgehenden Verbindungen. - - Hier wird die Ausgabe so oder so ähnlich aussehen: - - 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 - - Einer der wichtigsten Funktionen von ipfstat - wird über die Option bereitgestellt. Mit - ihr wird eine Statustabelle vergleichbar der Prozess-Tabelle - von &man.top.1; ausgegeben. Mit dieser Funktion erhalten Sie im - Falle eines Angriffs die Möglichkeit, die angreifenden Pakete - zu identifizieren, abzufangen und auszuwerten. Weitere Unteroptionen - eröffnen, die IP-Adresse, den Port oder das Protokoll, geteilt - nach Herkunft und Ziel, auszuwählen und dann in Echtzeit zu - beobachten. Lesen Sie dazu bitte auch die Manpage von - &man.ipfstat.8;. - - - - IPMON - - ipmon - - - IPFILTER - - logging - - - Damit der Befehl ipmon korrekt arbeiten kann, - muss die Option IPFILTER_LOG in die - Kernelkonfiguration eingearbeitet werden. Das Kommando selbst - arbeitet in zwei verschiedenen Modi. Für den nativen Modus - startet man ipmon auf der Kommandozeile ohne die - Option . - - Der Hintergrundmodus (daemon mode) dient der - Erstellung eines stetigen Systemprotokolls, so dass Einträge - vergangener Ereignisse inspiziert werden können. So sollen &os; - und IPFILTER entsprechend ihrer Konfiguration zusammen arbeiten. - &os; kann mit einem eingebauten Mechanismus Systemprotokolle - turnusmäßig abspeichern. Aus diesem Grund sollte man - besser &man.syslogd.8; verwenden anstatt die Protokollinformationen - in eine Datei zu schreiben, wie es als Standard vorgesehen ist. In - der Standard-rc.conf-Datei (im Ordner - /etc/defaults/) wird dem Eintrag - ipmon_flags die Option - übergeben: - - ipmon_flags="-Ds" # D = Als Da:mon starten -# s = Protokollierung via syslog -# v = Protokollierung von tcp window, ack, seq -# n = Namen statt IP & port ausgeben - - Die Vorteile des Protokollierens liegen auf der Hand: Sie - versetzen den Administrator in die Lage, nach einem Vorfall - Informationen abzurufen, etwa welche Pakete aussortiert wurden, - welche Adressen diese Pakete gesendet haben oder wohin sie gesendet - werden sollten. Alles in allem erhält er ein sehr gutes Werkzeug - zum Aufspüren von Angreifern. - - Jedoch, auch wenn die Protokollierung aktiviert ist, wird IPF - keine einzige Regel zum Protokollieren von alleine entwerfen und - umsetzen. Der Administrator der Firewall entscheidet, welche Regeln - in seinem Regelsatz mitgeschrieben werden sollen und er muss - dementsprechend das Schlüsselword log in - dieser Regel angeben. Normalerweise werden nur Treffer auf abweisende - Regeln protokolliert. - - Es ist üblich, als letzte Regel eine alles blockierende - Regel mit dem Schlüsselwort log in den - Regelsatz einzutragen. Dadurch erkennt man alle Pakete, die keiner - Regel im Regelsatz entsprachen. - - - - IPMON Logging - - Syslogd verwendet seine eigene Methode - zum Sortieren der gesammtelten Protokolldaten - spezielle Gruppierungen - namens facility und level. IPMON - verwendet im daemon-Modus als - facility den Wert security. Die - folgenden level können für eine genauere - Trennung der Protokolldaten verwendet werden: - - LOG_INFO - Alle zu protokollierenden Pakete -LOG_NOTICE - Protokollierte Pakete, die passieren durften -LOG_WARNING - Protokollierte Pakete, die blockiert wurden -LOG_ERR - Protokollierte Pakete, deren Headerdaten nicht komplett vorlagen - - Damit IPFILTER angewiesen werden kann, alle Protokolldaten in - die Datei /var/log/ipfilter.log zu schreiben, - muss diese erst erstellt werden. Folgendes Kommando - übernimmt diese Aufgabe: - - &prompt.root; touch /var/log/ipfilter.log - - Die Funktionen von &man.syslogd.8; werden durch Definition in - der Datei /etc/syslog.conf gesteuert. In dieser - Datei kann sehr weitläfig eingestellt werden, wie - syslog mit den Systemnachrichten umgehen - soll, die ihm von Anwendungen wie IPF übergeben werden. - - Fügen Sie folgende Definition in die Datei - /etc/syslog.conf ein, um die Protokollierung - für IPF via syslog zu aktivieren: - - security.* /var/log/ipfilter.log - - security.* bedeutet, dass alle Nachrichten - der Klasse security.* am angegebenen Ort (hier - eine Datei) geschrieben werden sollen. - - Um Änderungen an der Datei - /etc/syslog.conf zu aktivieren müssen Sie - den Rechner neu starten, oder den Befehl - - &prompt.root; /etc/rc.d/syslogd reload - - ausführen. - - Vergessen Sie nicht, /etc/newsyslog.conf - anzupassen, damit die neuen Protokolldateien, die eben konfiguriert - wurden, auch in den Rotationsturnus eingefügt werden! - - - - Die Formatierung der Logdatei - - Nachrichten, die durch ipmon erzeugt werden, - bestehen aus durch Leerstellen getrennten Datenfeldern. Folgende - Felder sind in allen Nachrichten enthalten: - - - - Das Datum der Paketerstellung. - - - - Die Uhrzeit der Paketerstellung in der Form - HH:MM:SS.F, mit Stunden, Minuten, Sekunden - und Sekundenbruchteilen, wobei letztere mehrere Stellen lang - sein können. - - - - Der Name der Schnittstelle, die das Paket verarbeitet hat, - bspw. dc0. - - - - Die Gruppe und die Nummer der angewandten Regel, bspw. - @0:17. - - - - Die ausgeführte Aktion: p für - passed (zugelassen), b für blockiert, - S für short packet (unvollständiger - Header), n für no match (gar keine Regel - wurde berührt) und L für Log-Regel. Die Reihe, in der - die Flags angezeigt werden ist: S, p, b, n, L. Ein groß - geschriebenes P oder B bedeutet, dass das Paket aufgrund einer - globalen Einstellung protokolliert wurde und nicht wegen einer - einzelnen Regel. - - - - Die Adressen. Diese bestehen aus drei Feldern: Der - Quelladresse mit Port (getrennt durch ein Komma), dem Symbol - -> und der Zieladresse. Also bspw. - 209.53.15.22,80 -> 198.64.221.18,1722. - - - - PR gefolgt vom Namen eines - Netzwerk-Protokolls oder dessen Nummer. Bspw. - PR tcp. - - - - len gefolgt von der Länge des Headers - und der Gesamtlänge des Paketes, beispielsweise - len 20 40. - - - - Wenn es sich um ein TCP-Paket handelt, wird - ein weiteres Feld, beginnend mit einem Querstrich und gefolgt von - Buchstaben, die den gesetzten Flags entsprechen, angezeigt. Lesen - Sie bitte die Manpage &man.ipmon.8; für eine Liste der Buchstaben - und deren Bedeutungen. - - Falls das Paket ein ICMP-Paket ist, werden zwei Felder am Ende - hinzugefügt - das erstere ist immer ICMP, das - zweite enthält die ICMP-Nachricht und den Nachrichtentyp, - getrennt durch einen Schrägstrich. ICMP 3/3 - steht beispielsweise für Port nicht - erreichbar. - - - - Die Erstellung eines Regelsatzes mit Variablen - - Erfahrenere IPF Anwender erstellen sich eine Datei, die die - Regeln enthält und gestalten diese als ein Skript, in dem - Variablen verwendet werden. Der wichtigste Vorteil besteht darin, - dass man lediglich den Wert der Variablen anpassen muss und diese, - sobald das Skript gestartet wird, durch die entsprechenden Werte - ersetzt und die Regeln entsprechend formuliert werden. In Skripten - kann man so häufig verwendete Werte einfach als Variable in - mehreren Regeln zuweisen. Am folgenden Beispiel soll das - verdeutlicht werden. - - Die Syntax dieses Skriptes ist kompatibel mit den Shells - &man.sh.1;, &man.csh.1; und &man.tcsh.1;. - - Variablen beginnen mit einem Dollar-Zeichen: - $Variablenname. Im Beispiel unten steht - $oif für die Variable, in der der Name - der Schnittstelle abgelegt wird, über die der Verkehr nach - außen erfolgt. - - In Variablenzuweisungen fehlt das beginnende $-Zeichen. - Alleine der Name der Variable wird angegeben, gefolgt von einem - Gleichheitszeichen, und dem Wert, der der Variablen zugewiesen werden - soll. Dieser muss in doppelten Anführungszeichen - ("") stehen. Also folgt eine Zuweisung dem Schema - Variablenname = "Wert". - - ############# Start of IPF rules script ######################## - -oif="dc0" # Name der Internet-Schnittstelle -odns="192.0.2.11" # IP des DNS-Servers unseres ISPs -myip="192.0.2.7" # die statische IP, die uns der ISP zugeteilt hat -ks="keep state" -fks="flags S keep state" - -# Sie haben die Wahl, aus diesem Skript eine eigene -# /etc/ipf.rules erstellen zu lassen oder es einfach -# direkt als Skript laufen zu lassen. -# -# Entfernen Sie dazu das eine Kommentarzeichen -# und kommentieren Sie die andere Zeile aus! -# -# 1) Diese Zeile verwenden Sie zur Erstellung von /etc/ipf.rules -#cat > /etc/ipf.rules << EOF -# -# 2) Diese Zeile, wenn Sie direkt mit dem Skript arbeiten wollen -/sbin/ipf -Fa -f - << EOF - -# Erlaubnis ausgehenden Verkehrs an den Nameserver des ISPs -pass out quick on $oif proto tcp from any to $odns port = 53 $fks -pass out quick on $oif proto udp from any to $odns port = 53 $ks - -# Erlaubnis ausgehenden unsicheren www-Verkehrs -pass out quick on $oif proto tcp from $myip to any port = 80 $fks - -# Erlaubnis ausgehenden sicheren www-Verkehrs https via TLS SSL -pass out quick on $oif proto tcp from $myip to any port = 443 $fks -EOF -################## End of IPF rules script ######################## - - Das ist schon alles. Die Regeln selbst sind im Beispiel nicht - so wichtig - achten Sie auf die Anwendung der Variablenzuweisung - am Anfang und die Verwendung der Variablen im Skript. Falls das - obige Beispiel in einer Datei namens - /etc/ipf.rules.script gespeichert wurde, - können die Regeln mit folgenden Kommando neu geladen - werden: - - &prompt.root; sh /etc/ipf.rules.script - - Es gibt ein Problem mit Regelsatz-Dateien, die Variablen - verwenden: IPF kann mit Variablen nichts anfangen - und kann derartige - Skripte nicht direkt einlesen. - - Unser kleines Skript kann daher nur auf eine der beiden folgenden - Weisen verwendet werden: - - - - Entfernen Sie das Kommentarzeichen der Zeile, die mit - cat beginnt. Kommentieren Sie die Zeile aus, - die mit /sbin/ipf beginnt. Schreiben Sie die - Zeile ipfilter_enable="YES" in die Datei - /etc/rc.conf und rufen Sie dann das Skript - auf, um /etc/ipf.rules zu erstellen oder - zu erneuern. - - - - Deaktivieren Sie IPFILTER in den Systemstart-Skripten, indem - Sie die Zeile ipfilter_enable="NO" in die - Datei /etc/rc.conf eintragen (was auch der - Standard-Einstellung entspricht). - - Fügen Sie ein Skript ähnlich dem folgenden in Ihr - Verzeichnis /usr/local/etc/rc.d/. Es - sinnvoll, dem Skript einen offensichtlichen Namen zu geben, wie - etwa ipf.loadrules.sh. Die Endung - .sh ist dabei verbindlich. - - #!/bin/sh -sh /etc/ipf.rules.script - - Die Zugriffsrechte für die Datei, die das Skript - enthält, müssen für den Eigentümer - root auf Lesen, Schreiben und Ausführen - gesetzt werden. - - &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh - - - - Wenn nun Ihr System startet, werden Ihre IPF-Regeln geladen. - - - - IPF Regelsätze - - Ein Regelsatz ist eine Gruppe von IPF-Regeln, die anhand der - Werte eines Netzwerkpaketes entscheiden, ob dieses Paket durchgelassen - oder blockiert wird. Der Austausch von Paketen erfolgt immer - zweiseitig in Form einer sogenannten Session. Der Regelsatz der - Firewall verarbeitet sowohl die eingehenden Pakete aus dem - öffentlichen Internet als auch die Pakete, die vom System als - Antwort auf die Ersteren gesendet werden. Jeder Dienst, der via - TCP/IP arbeitet, zum Beispiel - telnet, www oder - mail, ist vordefiniert durch sein Protokoll und - seinen privilegierten Port, an dem er auf Anfragen wartet und - reagieren kann. Pakete, die gezielt einen Dienst ansprechen sollen, - werden von einem unprivilegierten Port des Senders an einen konkreten - privilegierten Port des Zielsystems geschickt. Alle genannten - Parameter (Ports, Adressen usw.) können als Auswahlkriterien zum - erstellen von Regeln eingesetzt werden, die Dienste erlauben oder - blockieren. - - - IPFILTER - - rule processing order - - - IPF wurde ursprünglich mit einer Regel-Prozess-Logik - geschrieben, die ausschließlich statusfreie Regeln zuließ - und nach dem Prinzip die letzte Regel, die passt, - entscheidet arbeitete. Mit der Zeit erhielt IPF eine - Option sowie Option - für die Anwendung von zustandsorientierten Regeln, was die - Regel-Prozess-Logik signifikant modernisierte. - - Die Anweisungen in diesem Kapitel basieren auf der Verwendung - von Regeln, die diese beiden neuen Optionen verarbeiten. Dies ist - das Framework zur Entwicklung eines Firewallregelsatzes. - - - Wenn Sie mit einer Firewall arbeiten, seien Sie - sehr vorsichtig. Durch wenige Einstellungen - können Sie sich aus Ihrem System - aussperren. Wenn Sie auf der sicheren Seite - sein wollen, führen Sie die Firewall-Konfiguration direkt am - entsprechenden Gerät aus und nicht über eine - Netzwerkverbindung wie bspw. ssh. - - - - - IPF Regel-Syntax - - - IPFILTER - - rule syntax - - - Die Syntax zur Erstellung der Regeln, die hier vorgestellt wird, - ist dahingehend vereinfacht worden, dass sie ausschliesslich auf - den modernen Regelkontext, mit statusbehafteten Regeln und einer - die erste Regel, die passt, gewinnt-Logik, - zurückgreift. Um alles über die veraltete Syntax zu - erfahren, lesen Sie bitte die Man-Page von &man.ipf.8;. - - Ein #-Zeichen markiert den Beginn eines - Kommentars. Es darf nach nach einer Regel stehen oder als erstes - Zeichen einer Zeile. Leere Zeilen werden von der - Regel-Prozess-Logik ignoriert. - - Regeln enthalten Schlüsselwörter. Diese - Schlüsselwörter müssen in einer bestimmten Reihenfolge - von links nach rechts in einer Zeile erscheinen. Als solche - identifizierte Schlüsselwörter werden fett wiedergegeben. - Einige Schlüsselwörter haben Unteroptionen, die wiederum - selbst Schlüsselwörter sein und ebenfalls weiter - Unteroptionen einschließen können. - - - - - ACTION IN-OUT OPTIONS SELECTION STATEFUL PROTO - SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG - STATEFUL - - ACTION = block | pass - - IN-OUT = in | out - - OPTIONS = log | quick | on - interface-name - - SELECTION = proto value | - source/destination IP | port = number | flags flag-value - - PROTO = tcp/udp | udp | tcp | - icmp - - SRC_ADD,DST_ADDR = all | from - object to object - - OBJECT = IP address | any - - PORT_NUM = port number - - TCP_FLAG = S - - STATEFUL = keep state - - - ACTION - - Die ACTION bestimmt, was mit dem Paket passieren - soll, wenn der Rest der Regel zutrifft. Dieser Teil muss - für jede Regel angegeben werden. - - Das Schlüsselwort block gibt an, dass - das Paket verfallen soll, wenn die Auswahlparameter zutreffen. - - Das Schlüsselwort pass gibt an, dass - das Paket durch die Firewall durchgelassen werden soll, wenn die - Auswahlparameter zutreffen. - - - - IN-OUT - - Ebenfalls verbindlich ist die Angabe, welchen Teil der - Verbindung, Ein- oder Ausgang, die Regel beeinflussen soll. Das - nächste Schlüsselwort muss daher entweder - in, für eingehend, oder - out, für ausgehend, lauten - oder die Regel - wird aufgrund eines Syntaxfehlers nicht umgesetzt. - - in bedeutet, dass diese Regel auf eingehende - Pakete angewendet wird, die gerade an der dem öffentlichen - Internet zugewandten Schnittstelle empfangen wurden. - - out bedeutet, das diese Regel auf ausgehende - Pakete angewendet wird, also Pakete die gerade gesendet werden und - deren Zieladresse im öffentlichen Internet liegt. - - - - OPTIONS - - - Die Optionen müssen in der hier aufgeführten - Reihenfolge verwendet werden. - - - log bestimmt, dass die Kopfdaten des Paketes - an die Systemschnittstelle &man.ipl.4; geschrieben werden sollen. - Genaueres dazu weiter unten im Abschnitt LOGGING. - - quick bestimmt, dass, - wenn die Auswahlkriterien der Regel auf das - Paket zutreffen, keine weiteren Regeln ausgewertet werden. So - vermeidet man das Abarbeiten des gesamten Regelsatzes. Diese Option - ist eine verbindliche Vorraussetzung der modernen - Regel-Prozess-Logik. - - on bestimmt den Namen der Schnittstelle, - der als Auswahlkriterium hinzugefügt werden soll. Die Namen - aller verfügbaren Schnittstellen werden durch den Befehl - &man.ifconfig.8; angezeigt. wenn man diese Option verwendet, - passt die Regeln nur auf Pakete, die durch diese Schnittstelle - empfangen (in) oder gesendet - (out) wurden. Für die modernisierte - Regel-Prozess-Logik ist die Verwendung dieser Option - verbindlich. - - Wenn ein Paket protokolliert wird, werden die Kopfdaten in - die Pseudo-Schnittstelle &man.ipl.4; geschrieben. Folgende Parameter - können zusätzlich übergeben werden, müssen dazu - aber direkt nach dem Schlüsselwort log und in - gleicher Reihenfolge stehen: - - body bestimmt, dass die ersten 128 Bytes des - Paketinhaltes zusätzlich zu den Kopfdaten protokolliert - werden. - - 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. - - - - SELECTION - - Die Schlüsselwörter, die in diesem Abschnitt - vorgestellt werden, dienen zur Beschreibung von Attributen, anhand - derer geprüft und entschieden wird, ob eine Regel zutrifft - oder nicht. Es gibt ein Schlüsselwort, und das hat mehrere - Optionen, von denen eine ausgewählt werden muss. Die - folgenden allgemeinen Attribute können beliebig zum Erstellen - einer Regel verwendet werden, allerdings nur in der vorgestellten - Reihenfolge: - - - - PROTO - - proto ist das Schlüsselwort für - das im Paket angewendete Protokoll. Als Option ein Protokoll aus - Auswahlkriterium übergeben. Diese Option ist verbindlich, wenn - man die moderne Regel-Prozess-Logik verwendet. - - tcp/udp | udp | tcp | icmp oder irgendein - Protokollname, der in der Datei /etc/protocols - zu finden ist, kann übergeben werden. Außerdem kann das - Schlüsselwort tcp/udp verwendet werden, wenn - sowohl TCP als auch UDP von der - Regel betroffen sein sollen. Dieses Schlüsselwort wurde - eingeführt, um Duplikate sonst identischer Regeln zu - vermeiden. - - - - SRC_ADDR/DST_ADDR - - Das Schlüsselwort all ist ein Synonym - für from any to any ohne weitere - Auswahlkriterien. - - from src to dst: Die Schlüsselwörter - from und to dienen zur Angabe - von Quelle und Ziel in Form von IP-Adressen oder -Bereichen. - Innerhalb einer Regel muss immer beides angegeben werden. - Statt einer Adresse kann auch das Schlüsselwort - any übergeben werden, das für jede - beliebige IP-Adresse steht. Zum Beispiel: - from any to any oder - from 0.0.0.0/0 to any oder - from any to 0.0.0.0/0 oder - from 0.0.0.0 to any oder - from any to 0.0.0.0 bedeuten alle das - Gleiche. - - IP-Bereiche können nur in der CIDR-Notation angegeben - werden. Der Port net-mgmt/ipcalc - hilft Ihnen bei der Berechnung der richtigen Angaben. - Weiterführende Informationen zu CIDR finden Sie auf der Webseite - von ipcalc. - - - - PORT - - Wenn ein Port als Auswahlkriterium übergeben wurde, bei - Quelle und/oder Ziel, wird er nur bei TCP und - UDP Paketen verwendet. Angegeben werden kann - entweder die Portnummer oder der Dienstname aus - /etc/services. Die Verwendung der - Portoption mit dem to-Objekt ist verbindlich - für die Verwendung der modernisierten Regel-Prozess-Logik. - Ein Beispiel für die Filterung Paketen von allen Quell-IPs mit - beliebiger Portnummer auf beliebige Ziel-IPs mit der Portnummer 80 - (dem www-Port): - from any to any port = 80. - - - - Einfache Portvergleiche können auf verschiedenen Wegen - erfolgen. Mehrere Vergleichsoperatoren stehen dafür zur - Verfügung. Genauso können Bereiche angegeben - werden. - - port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" - | "ne" | "lt" | "gt" | "le" | "ge". - - Um einen Bereich anzugeben: port "<>" | "><" - - - Genau wie die Trefferspezifikation für Quelle und Ziel - sind auch die beiden folgenden Parameter obligatorisch bei der - Verwendung der modernen Regel-Prozess-Logik. - - - - - <acronym>TCP</acronym>_FLAG - - Flags spielen nur beim Filtern von TCP eine - Rolle. Die Buchstaben entsprechen jeweils einem möglichen - Flag, dass in den Kopfdaten der TCP-Pakete - geprueft werden soll. - - Die moderne Regel-Prozess-Logik verwendet den Parameter - flags S um eine Anfrage zum Start einer - TCP-Session zu identifizieren. - - - - STATEFUL - - keep state zeigt bei einer Passage-Regel an, - dass für alle Pakete, die die Selektion erfolgreich durchlaufen, - Stateful Filtering eingerichtet werden - soll. - - - Diese Option ist obligatorisch für die Verwendung der - modernen Prozess-Regel-Logik. - - - - - - Stateful Filtering - - - IPFILTER - - stateful filtering - - - - - Stateful filtering treats traffic as a bi-directional - exchange of packets comprising a session conversation. When - activated, keep-state dynamically generates internal rules for - each anticipated packet being exchanged during the - bi-directional session conversation. It has sufficient matching - capabilities to determine if the session conversation between the - originating sender and the destination are following the valid - procedure of bi-directional packet exchange. Any packets that - do not properly fit the session conversation template are - automatically rejected as impostors. - - Keep state will also allow ICMP packets related to a - TCP or UDP session through. So if you get - ICMP type 3 code 4 in response to some web surfing allowed out - by a keep state rule, they will be automatically allowed in. - Any packet that IPF can be certain is part of an active - session, even if it is a different protocol, will be let - in. - - What happens is: - - Packets destined to go out through the interface connected to the - public Internet are first checked against the dynamic state - table. If the packet matches the next expected packet - comprising an active session conversation, then it exits the - firewall and the state of the session conversation flow is - updated in the dynamic state table. Packets that do not belong to - an already active session, are simply checked against the outbound - ruleset. - - Packets coming in from the interface connected to the public - Internet are first checked against the dynamic state table. If - the packet matches the next expected packet comprising an - active session conversation, then it exits the firewall and - the state of the session conversation flow is updated in the - dynamic state table. Packets that do not belong to an already active - session, are simply checked against the inbound ruleset. - - When the conversation completes it is removed from the - dynamic state table. - - Stateful filtering allows you to focus on blocking/passing - new sessions. If the new session is passed, all its subsequent - packets will be allowed through automatically and any impostors - automatically rejected. If a new session is blocked, none of - its subsequent packets will be allowed through. Stateful - filtering has technically advanced matching abilities - capable of defending against the flood of different attack - methods currently employed by attackers. - - - - - - Inclusive Ruleset Example - - The following ruleset is an example of how to code a very - secure inclusive type of firewall. An inclusive firewall only - allows services matching pass rules through, and blocks all - others by default. Firewalls intended to protect other machines, - also called network firewalls, should have at least - two interfaces, which are generally configured to trust one side - (the LAN) and not the other (the public Internet). Alternatively, - a firewall might be configured to protect only the system it is - running on—this is called a - host based firewall, and is particularly appropriate - for servers on an untrusted network. - - All &unix; flavored systems including &os; are designed to - use interface lo0 and IP address - 127.0.0.1 for internal - communication within the operating system. The firewall rules - must contain rules to allow free unmolested movement of these - special internally used packets. - - The interface which faces the public Internet is the one - to place the rules that authorize and control access of the outbound - and inbound connections. This can be your user PPP - tun0 interface or your NIC that is - connected to your DSL or cable modem. - - In cases where one or more NICs are cabled to private network - segments, those interfaces may require rules to allow packets - originating from those LAN interfaces transit to each other and/or - to the outside (Internet). - - The rules should be organized into three major - sections: first trusted interfaces, then the public - interface outbound, and last the public untrusted interface inbound. - - The rules in each of the public interface sections should - have the most frequently matched rules placed before less - commonly matched rules, with the last rule in the section - blocking and logging all packets on that interface and - direction. - - The Outbound section in the following ruleset only - contains pass rules which contain selection values that - uniquely identify the service that is authorized for public - Internet access. All the rules have the quick, on, - proto, port, and keep state options set. The proto - tcp rules have the flag option included to identify the - session start request as the triggering packet to activate the - stateful facility. - - The Inbound section has all the blocking of undesirable - packets first, for two different reasons. The first is that - malicious packets may be partial matches for legitimate traffic. - These packets have to be discarded rather than allowed in, based on - their partial matches against allow rules. - The second reason is that known and uninteresting rejects may be - blocked silently, rather than being caught and logged by the last - rules in the section. The final rule in each section, blocks and - logs all packets and can be used to create the legal evidence needed - to prosecute the people who are attacking your system. - - Another thing that should be taken care of, is to ensure there is no - response returned for any of the undesirable traffic. Invalid - packets should just get dropped and vanish. This way the attacker - has no knowledge if his packets have reached your system. The - less the attackers can learn about your system, the more - time they must invest before actually doing something bad. - Rules that include a log first option, will only - log the event the first time they are triggered. This option is - included in the sample nmap OS fingerprint rule. - The security/nmap utility is - commonly used by attackers who attempt to identify the operating - system of your server. - - Any time there are logged messages on a rule with - the log first option, an ipfstat -hio - command should be executed to evaluate how many times the rule has - actually matched. Large number of matches usually indicate that the - system is being flooded (i.e.: under attack). - - The /etc/services file may be used to - lookup unknown port numbers. Alternatively, - visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers - and do a port number lookup to find the purpose of a particular - port number. - - Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. - - The following ruleset creates a complete and very secure - inclusive type of firewall ruleset that has been - tested on production systems. It can be easily modified for your - own system. Just comment out any pass rules for - services that should not be authorized. - - To avoid logging unwanted messages, - just add a block rule in the inbound section. - - The dc0 interface name has to be changed - in every rule to the real interface name of the NIC - card that connects your system to the public Internet. For - user PPP it would be tun0. - - Add the following statements to - /etc/ipf.rules: - - ################################################################# -# No restrictions on Inside LAN Interface for private network -# Not needed unless you have LAN -################################################################# - -#pass out quick on xl0 all -#pass in quick on xl0 all - -################################################################# -# No restrictions on Loopback Interface -################################################################# -pass in quick on lo0 all -pass out quick on lo0 all - -################################################################# -# Interface facing Public Internet (Outbound Section) -# Match session start requests originating from behind the -# firewall on the private network -# or from this gateway server destined for the public Internet. -################################################################# - -# Allow out access to my ISP's Domain name server. -# xxx must be the IP address of your ISP's DNS. -# Dup these lines if your ISP has more than one DNS server -# Get the IP addresses from /etc/resolv.conf file -pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state -pass out quick on dc0 proto udp from any to xxx port = 53 keep state - -# Allow out access to my ISP's DHCP server for cable or DSL networks. -# This rule is not needed for 'user ppp' type connection to the -# public Internet, so you can delete this whole group. -# Use the following rule and check log for IP address. -# Then put IP address in commented out rule & delete 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 out non-secure standard www function -pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state - -# Allow out secure www function https over TLS SSL -pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state - -# Allow out send & get email function -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 out Time -pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state - -# Allow out nntp news -pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state - -# Allow out gateway & LAN users' non-secure FTP ( both passive & active modes) -# This function uses the IPNAT built in FTP proxy function coded in -# the nat rules file to make this single rule function correctly. -# If you want to use the pkg_add command to install application packages -# on your gateway system you need this rule. -pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state - -# Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements) -# This function is using SSH (secure shell) -pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state - -# Allow out insecure Telnet -pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state - -# Allow out FreeBSD CVSup -pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state - -# Allow out ping to public Internet -pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state - -# Allow out whois from LAN to public Internet -pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state - -# Block and log only the first occurrence of everything -# else that's trying to get out. -# This rule implements the default block -block out log first quick on dc0 all - -################################################################# -# Interface facing Public Internet (Inbound Section) -# Match packets originating from the public Internet -# destined for this gateway server or the private network. -################################################################# - -# 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 a bunch of different nasty things. ############ -# That I do not want to see in the log - -# Block frags -block in quick on dc0 all with frags - -# Block short tcp packets -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 nmap OS fingerprint attempts -# Log first occurrence of these so I can get their IP address -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 -block in quick on dc0 proto icmp all icmp-type 8 - -# Block ident -block in quick on dc0 proto tcp from any to any port = 113 - -# Block all Netbios service. 137=name, 138=datagram, 139=session -# Netbios is MS/Windows sharing services. -# Block MS/Windows hosts2 name server requests 81 -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 - -# Allow traffic in from ISP's DHCP server. This rule must contain -# the IP address of your ISP's DHCP server as it is the only -# authorized source to send this packet type. Only necessary for -# cable or DSL configurations. This rule is not needed for -# 'user ppp' type connection to the public Internet. -# This is the same IP address you captured and -# used in the outbound section. -pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state - -# Allow in standard www function because I have apache server -pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state - -# Allow in non-secure Telnet session from public Internet -# labeled non-secure because ID/PW passed over public Internet as clear text. -# Delete this sample group if you do not have telnet server enabled. -#pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state - -# Allow in secure FTP, Telnet, and SCP from public Internet -# This function is using SSH (secure shell) -pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state - -# Block and log only first occurrence of all remaining traffic -# coming into the firewall. The logging of only the first -# occurrence avoids filling up disk with Denial of Service logs. -# This rule implements the default block. -block in log first quick on dc0 all -################### End of rules file ##################################### - - - - <acronym>NAT</acronym> - - NAT - - - IP masquerading - - NAT - - - - network address translation - - NAT - - - NAT stands for Network Address - Translation. To those familiar with &linux;, this concept is - called IP Masquerading; NAT and IP - Masquerading are the same thing. One of the many things the - IPF NAT function enables is the ability to - have a private Local Area Network (LAN) behind the firewall - sharing a single ISP assigned IP address on the public - Internet. - - You may ask why would someone want to do this. ISPs - normally assign a dynamic IP address to their non-commercial - users. Dynamic means that the IP address can be different each - time you dial in and log on to your ISP, or for cable and DSL - modem users, when the modem is power cycled. This dynamic IP - address is used to identify your system to the public Internet. - - Now lets say you have five PCs at home and each one needs - Internet access. You would have to pay your ISP for an - individual Internet account for each PC and have five phone - lines. - - With NAT only a single account is needed - with your ISP. The other four PCs may then be cabled to a switch and - the switch to the NIC in your &os; system which is going to - service your LAN as a gateway. NAT will - automatically translate the private LAN IP address for each - separate PC on the LAN to the single public IP address as it - exits the firewall bound for the public Internet. It also does - the reverse translation for returning packets. - - There is a special range of IP addresses reserved for - NATed private LANs. According to - RFC 1918, the following IP ranges may be used for private nets - which will never be routed directly to the public - Internet: - - - - - - - - - - - - Start IP 10.0.0.0 - - - - - Ending IP 10.255.255.255 - - - - Start IP 172.16.0.0 - - - - - Ending IP 172.31.255.255 - - - - Start IP 192.168.0.0 - - - - - Ending IP 192.168.255.255 - - - - - - - - IP<acronym>NAT</acronym> - - - NAT - - and IPFILTER - - - ipnat - - NAT rules are loaded by using the - ipnat command. Typically the - NAT rules are stored in - /etc/ipnat.rules. See &man.ipnat.8; for - details. - - When changing the NAT rules after - NAT has been started, make your changes to - the file containing the NAT rules, then run the ipnat command with - the flags to delete the internal in use - NAT rules and flush the contents of the - translation table of all active entries. - - To reload the NAT rules issue a command - like this: - - &prompt.root; ipnat -CF -f /etc/ipnat.rules - - To display some statistics about your - NAT, use this command: - - &prompt.root; ipnat -s - - To list the NAT table's current - mappings, use this command: - - &prompt.root; ipnat -l - - To turn verbose mode on, and display information relating - to rule processing and active rules/table entries: - - &prompt.root; ipnat -v - - - - IP<acronym>NAT</acronym> Rules - - NAT rules are very flexible and can - accomplish many different things to fit the needs of commercial - and home users. - - The rule syntax presented here has been simplified to what - is most commonly used in a non-commercial environment. For a - complete rule syntax description see the &man.ipnat.5; manual - page. - - The syntax for a NAT rule looks - something like this: - - map IF LAN_IP_RANGE -> PUBLIC_ADDRESS - - The keyword map starts the rule. - - Replace IF with the external - interface. - - The LAN_IP_RANGE is what your - internal clients use for IP Addressing, usually this is - something like 192.168.1.0/24. - - The PUBLIC_ADDRESS can either - be the external IP address or the special keyword - 0/32, which means to use the IP address - assigned to IF. - - - - How <acronym>NAT</acronym> works - - A packet arrives at the firewall from the LAN with a public - destination. It passes through the outbound filter rules, - NAT gets its turn at the packet and applies - its rules top down, first matching rule wins. - NAT tests each of its rules against the - packet's interface name and source IP address. When a packet's - interface name matches a NAT rule then the - source IP address (i.e.: private LAN IP address) of the packet - is checked to see if it falls within the IP address range - specified to the left of the arrow symbol on the - NAT rule. On a match the packet has its - source IP address rewritten with the public IP address - obtained by the 0/32 keyword. - NAT posts an entry in its internal - NAT table so when the packet returns from - the public Internet it can be mapped back to its original - private IP address and then passed to the filter rules for - processing. - - - - Enabling IP<acronym>NAT</acronym> - - To enable IPNAT add these statements to - /etc/rc.conf. - - To enable your machine to route traffic between - interfaces: - - gateway_enable="YES" - - To start IPNAT automatically each - time: - - ipnat_enable="YES" - - To specify where to load the IPNAT rules - from: - - ipnat_rules="/etc/ipnat.rules" - - - - <acronym>NAT</acronym> for a very large LAN - - For networks that have large numbers of PC's on the LAN or - networks with more than a single LAN, the process of funneling - all those private IP addresses into a single public IP address - becomes a resource problem that may cause problems with the - same port numbers being used many times across many - NATed LAN PC's, causing collisions. There - are two ways to relieve this resource problem. - - - Assigning Ports to Use - - - - - A normal NAT rule would look like: - - map dc0 192.168.1.0/24 -> 0/32 - - In the above rule the packet's source port is unchanged - as the packet passes through IPNAT. By - adding the portmap keyword, - IPNAT can be directed to only use source ports in the specified range. - For example the following rule will tell - IPNAT to modify the source port to be - within the range shown: - - map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 - - Additionally we can make things even easier by using the - auto keyword to tell - IPNAT to determine by itself which ports - are available to use: - - map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto - - - - Using a Pool of Public Addresses - - In very large LANs there comes a point where there are just too - many LAN addresses to fit into a single public address. If a block - of public IP addresses is available, these addresses can be used as - a pool, and IPNAT may pick one of - the public IP addresses as packet-addresses are mapped on their way - out. - - For example, instead of mapping all packets through a single - public IP address, as in: - - map dc0 192.168.1.0/24 -> 204.134.75.1 - - A range of public IP addresses can be specified either with a - netmask: - - map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 - - or using CIDR notation: - - map dc0 192.168.1.0/24 -> 204.134.75.0/24 - - - - - Port Redirection - - A very common practice is to have a web server, email - server, database server and DNS server each segregated to a - different PC on the LAN. In this case the traffic from these - servers still have to be NATed, but there - has to be some way to direct the inbound traffic to the - correct LAN PCs. IPNAT has the redirection - facilities of NAT to solve this problem. - For example, assuming a web server operating on LAN address 10.0.10.25 and using a single public IP - address of 20.20.20.5 the rule would - be coded as follows: - - rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 - - or: - - rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 - - or for a LAN DNS Server on LAN address of 10.0.10.33 that needs to receive - public DNS requests: - - rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp - - - - FTP and <acronym>NAT</acronym> - - FTP is a dinosaur left over from the time before the - Internet as it is known today, when research universities were - leased lined together and FTP was used to share files among - research Scientists. This was a time when data security was - not a consideration. Over the years the FTP protocol became - buried into the backbone of the emerging Internet and its - username and password being sent in clear text was never - changed to address new security concerns. FTP has two flavors, - it can run in active mode or passive mode. The difference is - in how the data channel is acquired. Passive mode is more - secure as the data channel is acquired by the ordinal ftp - session requester. For a real good explanation of FTP and the - different modes see http://www.slacksite.com/other/ftp.html. - - - IP<acronym>NAT</acronym> Rules - - IPNAT has a special built in FTP proxy - option which can be specified on the NAT - map rule. It can monitor all outbound packet traffic for FTP - active or passive start session requests and dynamically - create temporary filter rules containing only the port number - really in use for the data channel. This eliminates the - security risk FTP normally exposes the firewall to from - having large ranges of high order port numbers open. - - This rule will handle all the traffic for the internal - LAN: - - map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp - - This rule handles the FTP traffic from the - gateway: - - map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp - - This rule handles all non-FTP traffic from the internal - LAN: - - map dc0 10.0.10.0/29 -> 0/32 - - The FTP map rule goes before our regular map rule. All - packets are tested against the first rule from the top. - Matches on interface name, then private LAN source IP - address, and then is it a FTP packet. If all that matches - then the special FTP proxy creates temp filter rules to let - the FTP session packets pass in and out, in addition to also - NATing the FTP packets. All LAN packets - that are not FTP do not match the first rule and fall - through to the third rule and are tested, matching on - interface and source IP, then are - NATed. - - - - IP<acronym>NAT</acronym> FTP Filter Rules - - Only one filter rule is needed for FTP if the - NAT FTP proxy is used. - - Without the FTP Proxy, the following three rules will be - needed: - - # 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 - - - - IPFW @@ -3361,7 +1747,7 @@ Optionen können in der Kernelkonfigurationsdatei verwendet werden: - options IPFIREWALL # enables IPFW + options IPFIREWALL # enables IPFW options IPFIREWALL_VERBOSE # enables logging for rules with log keyword options IPFIREWALL_VERBOSE_LIMIT=5 # limits number of logged packets per-entry options IPFIREWALL_DEFAULT_TO_ACCEPT # sets default policy to pass what is not explicitly denied @@ -4380,4 +2766,1047 @@ + + + IPFILTER (IPF) + + + Firewall + IPFILTER + + + IPFILTER, auch als + IPF bekannt, ist eine + plattformübergreifende Open Source Firewall, die auf + mehrere Betriebssysteme portiert wurde, einschließlich + &os;, 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 &os;. Es werden auch + Firewallregeln mit den Optionen quick und + keep state vorgestellt. + + + <application>IPF</application> aktivieren + + + IPFILTER + aktivieren + + + IPF ist in &os; als ladbares + Kernelmodul enthalten. Das bedeutet, dass Sie keinen + angepassten Kernel erzeugen müssen um + IPF zu aktivieren. + + + Kerneloptionen + IPFILTER + + + + Kerneloptionen + IPFILTER_LOG + + + + Kerneloptionen + IPFILTER_DEFAULT_BLOCK + + + + IPFILTER + Kerneloptionen + + + Benutzer, die IPF lieber + statisch in den Kernel kompilieren, sollten den Anweisungen in + 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: + + &prompt.root; 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: + + &prompt.root; 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 &man.ipf.8; + beschrieben. + + + + <application>IPF</application> Regel-Syntax + + + IPFILTER + Regel-Syntax + + + 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. &man.ipf.5; enthält eine + vollständige Beschreibung der Syntax und einige + Beispiele zur Erstellung von + IPF-Regeln. + + + + ACTION + + + 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ähl 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. + + + + + DIRECTION + + + Als nächstes muss für jede Regel explizit die + Richtung mit einem der folgenden Schlüsselwörter + angeben 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. + + + + + OPTIONS + + + 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 &man.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: 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 &man.ipf.5;. + + + + + PROTO_TYPE + + + 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. + + + + + SRC_ADDR + + + 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. + &man.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. + + + + + SCR_PORT + + + 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). + + + + + DST_ADDR + + + 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. + + + + + DST_PORT + + + 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. + + + + + TCP_FLAG|ICMP_TYPE + + + 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. &man.ipf.5; enthält eine Auflistung + der zulässigen Typen. + + + + + STATE + + + 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. &man.ipf.5; enthält eine Liste der + verfügbaren Optionen und deren Beschreibungen. + + + + + + + Beispielregelsatz + + Dieser Abschnitt beschreibt die Erstellung eines + Regelsatzes, welcher nur entsprechende Dienste erlaubt und + alle anderen Verbindungen blockiert. + + &os; 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 + + + + <acronym>NAT</acronym> Konfiguration + + 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 + &man.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: + + map IF 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 + aus, um die aktuellen + NAT-Regeln und den Inhalt der dynamischen + Zuordnungstabelle zu löschen. Geben Sie + zusammen mit dem + NAT-Regelsatz an: + + &prompt.root; ipnat -CF -f /etc/ipnat.rules + + Statistiken zu NAT lassen sich wie + folgt anzeigen: + + &prompt.root; ipnat -s + + Die aktuellen Zuordnungen der + NAT-Tabelle geben Sie mit diesem Kommando + aus: + + &prompt.root; ipnat -l + + Ausführliche Informationen erhalten Sie mit: + + &prompt.root; ipnat -v + + + + <application>IPF</application> Statistiken + + ipfstat + + IPFILTER + Statistiken + + + IPF enthält mit &man.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 + (eingehend) oder + (ausgehend) angegeben, wird der Befehl die entsprechende + Liste mit den derzeit vom Kernel benutzten Filterregeln + anzeigen. Um auch die Regelnummern zu sehen, muss + 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 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 &man.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 &man.ipfstat.8; für + weitere Informationen. + + + + <application>IPF</application> Protokollierung + + + ipmon + + + + IPFILTER + Protokollierung + + + 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 . + + Um eine kontinuierliche Protokolldatei bereitzustellen, + läuft dieses Kommando normalerweise im Daemon-Modus, damit + auch ältere Ereignisse nachverfolgt werden können. Da &os; + mit &man.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: + + &prompt.root; 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 &man.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 &man.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. + +