Index: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml +++ head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml @@ -3293,376 +3293,180 @@ IPFW - firewall + Firewall IPFW - Die IPFIREWALL - (IPFW) ist eine vom &os; Project - gesponserte Software-Firewall. Sie wurde und wird - freiwillig von Mitgliedern des &os; Projects geschrieben und - gewartet. Mit zustandslosen Regeln und einer Grammatik für - Regeln implementiert sie eine sogenannte Einfache - Zustandsgesteuerte Logik. - - Die Standardinstallation von IPFW enthält - einen beispielhaften Regelsatz - (/etc/rc.firewall und - /etc/rc.firewall6). Dieser ist eher - einfach gehalten; es ist nicht zu erwarten, dass dieser - ohne Modifikationen angewandt werden kann. Dieses Beispiel - nutzt keine zustandsorientierte Filterung, von der allerdings - die meisten Installationen profitieren sollten. Deshalb wird sich - dieser Abschnitt auch nicht auf diese Beispiele stützen. - - Die zustandslose IPFW Regel-Syntax ist durch ihre technisch - ausgefeilten Selektions-Fähigkeiten, die über das - Niveau der gebrächlichen Firewall-Installationsprogramme - weit hinausgehen, sehr mächtig. IPFW richtet sich an - professionelle oder technisch versierte Nutzer mit - weitergehenden Anforderungen an die Paket-Auswahl. Um die - Ausdrucksstärke der IPFW zu nutzen, ist sehr detailliertes - Wissen über die Art und Weise, wie verschiedene Protokolle ihre - jeweilige Paket-Header-Information erzeugen und nutzen, - erforderlich. Im Rahmen dieses Abschnitts ist es nicht möglich, - auf alle diese Punkte detailliert einzugehen. - - IPFW besteht aus sieben Komponenten: Hauptbestandteil ist der - Kernel Firewall Filter, ein Regel-Prozessor mit integrierter - Paket-Buchführung. Außerdem enthalten - ist eine Komponente zur Protokollierung der Aktivitäten der - Firewall (also ein Logfunktion). Weiters besteht die IPFW aus einer - Regel zum Umleiten des Datenverkehrs (divert), die - auch Network Address Translation (NAT) - unterstützt. Die restlichen Bestandteile dienen verschiedenen - fortgeschrittenen Zwecken. Der - Traffic Shaper &man.dummynet.4; - gestattet es beispielsweise, den Datenverkehr zu lenken, während - die fwd-Regel zum Weiterleiten von Datenpaketen - dient. Komplettiert wird IPFW durch Funktionen zum - Überbrücken von Netzwerkgrenzen - (Bridge-Funktion) sowie - ipstealth, das es gestattet, - bridging-Funktionen durchzuführen, ohne dabei das TTL-Feld im - IP-Paket zu erhöhen. IPFW unterstützt IPv4 und IPv6. + IPFW ist eine + Stateful-Firewall + für &os;, die sowohl IPv4 als auch + IPv6 unterstützt. Die Firewall setzt sich + aus mehreren Komponenten zusammen: dem Kernel Firewall + Filter-Prozessor mit integriertem Paket-Accounting, + Protokollfunktionen, NAT, dem + &man.dummynet.4; Traffic-Shaper, + sowie Weiterleitungs-, Bridge- und ipstealth-Funktionen. + + &os; enthält mit /etc/rc.firewall ein + Beispielregelwerk, welches mehrere Firewall-Typen für + gebräuchliche Szenarien definiert und unerfahrene Anwender + dabei unterstützen soll, ein geeignetes Regelwerk zu erstellen. + IPFW besitzt eine leistungsstarke + Syntax, mit der erfahrene Benutzer ihre eigenen Regeln + anfertigen können, um den Sicherheitsanforderungen der + jeweiligen Umgebung gerecht zu werden. + + Diser Abschnitt beschreibt, wie + IPFW aktiviert wird und bietet einen + Überblick über die Regelsyntax. Zudem werden mehrere Regelsätze + für gebräuchliche Konfigurationsszenarien vorgestellt. - IPFW aktivieren + <application>IPFW</application> aktivieren - IPFW - + IPFW aktivieren - IPFW ist in der &os;-Installation standardmäßig - als ein zur Laufzeit ladbares Kernelmodul enthalten, das - vom System automatisch geladen wird, wenn in der Datei - rc.conf die Option - firewall_enable="YES" gesetzt wird. Es ist - daher nicht notwendig, IPFW statisch in den Kernel zu - kompilieren. - - Während des Systemstart wird bei gesetzter Option - firewall_enable="YES" (in der Datei - rc.conf) folgende Nachricht ausgegeben: - - ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled - - Das Kernelmodul hat eine Protokollierungsfunktion. Um - diese zu aktivieren und einen Schwellwert für die - Protokollierung zu definieren, ist es erforderlich, folgende - Ausdrücke der /etc/sysctl.conf - hinzuzufügen: - - net.inet.ip.fw.verbose=1 -net.inet.ip.fw.verbose_limit=5 - - - - Kerneloptionen + Das &os; Basissystem enthält für + IPFW ein ladbares Kernelmodul, was + bedeutet, dass kein angepasster Kernel benötigt wird, um + IPFW zu benutzen. Kerneloptionen - IPFIREWALL Kerneloptionen - IPFIREWALL_VERBOSE Kerneloptionen - IPFIREWALL_VERBOSE_LIMIT - IPFW - + IPFW Kerneloptionen - Es ist für die Aktivierung von IPFW nicht zwingend - erforderlich, die folgenden Optionen in den Kernel zu - kompilieren. Es wird hier lediglich als - Hintergrundinformation aufgeführt. - - options IPFIREWALL - - Diese Option aktiviert IPFW als Bestandteil des - Kernels. - - options IPFIREWALL_VERBOSE - - Diese Option aktiviert die Funktion, alle Pakete, die durch - IPFW verarbeitet werden und bei denen das Schlüsselwort - log gesetzt ist, zu protokollieren. - - options IPFIREWALL_VERBOSE_LIMIT=5 - - Diese Option limitiert die Anzahl der durch &man.syslogd.8; - protokollierten Pakete auf das angegebene Maximum. Sie wird - in feindlichen Umgebungen verwandt, in denen die - Protokollierung der Firewall-Aktivität erwünscht - ist. Dadurch wird ein möglicher Denial-of-Service-Angriff - durch Überflutung von &man.syslogd.8; verhindert. - - - Kerneloptionen - - IPFIREWALL_DEFAULT_TO_ACCEPT - - - options IPFIREWALL_DEFAULT_TO_ACCEPT - - Diese Option erlaubt allen Paketen, die Firewall zu passieren. - Diese Einstellung kann beispielsweise bei der ersten Konfiguration - der Firewall hilfreich sein. - - - Kerneloptionen - - IPDIVERT - - - options IPDIVERT - - Dies aktiviert die Nutzung der - NAT-Funktionalität. - - - Die Firewall wird alle eingehenden oder ausgehenden - Pakete blockieren, wenn entweder die Kernel-Option - IPFIREWALL_DEFAULT_TO_ACCEPT fehlt oder - aber keine Regel, die die betreffenden Verbindungen explizit - gestattet, existiert. Dies enstpricht im Wesentlichen der - Einstellung default to deny - - - - - Optionen in <filename>/etc/rc.conf</filename> + Wenn Sie eine statische Unterstützung für + IPFW in den Kernel kompilieren + wollen, lesen Sie . Folgende + Optionen können in der Kernelkonfigurationsdatei verwendet + werden: - Der Eintrag + 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 +options IPDIVERT # enables NAT + + Um IPFW beim Systemstart zu + aktivieren, fügen Sie folgende Zeile in + /etc/rc.conf ein: firewall_enable="YES" - aktiviert die Firewall während des Systemstarts. - - Die Auswahl einer für &os; verfügbaren Firewall - erfolgt durch einen entsprechenden Eintrag in der Datei - /etc/rc.firewall, durch den der Firewalltyp - festgelegt wird. + Wenn Sie einen der von &os; zur Verfügung gestellten + Firewall-Profile benutzen möchten, fügen Sie eine weitere + Zeile hinzu, in der Sie das Profil bestimmen: firewall_type="open" - Konkret sind folgende Einträge erlaubt: + Folgende Profile stehen zur Verfügung: - open — gestattet jeglichen - Datenverkehr + open: gestattet jeglichen + Datenverkehr. - client — schützt nur die - jeweilige Maschine (Client/Mandant) + client: schützt lediglich diesen + Rechner. - simple — schützt das - gesamte Netzwerk + simple: schützt das gesamte + Netzwerk. - closed — unterbindet - jeglichen IP-Datenverkehr mit Ausnahme des Verkehrs - über die Loopback-Schnittstelle. + closed: blockiert den gesamten + IP-Datenverkehr, mit Ausnahme des + Verkehrs über die Loopback-Schnittstelle. - UNKNOWN — deaktiviert das - Laden von Firewallregeln + workstation: schützt lediglich + diesen Rechner und verwendet zustandsorientierte + Regeln. - filename - — absoluter Pfad zu einer Datei, in der die - Firewallregeln definiert sind + UNKNOWN: deaktiviert das Laden von + Firewallregeln. - - - Angepasste Regeln für &man.ipfw.8; können auf zwei - verschiedene Arten geladen werden. Einerseits kann man durch die - Variable firewall_type den absoluten Pfad - der Datei angeben, welche die Firewallregeln - (ohne weitere Optionen) für &man.ipfw.8; enthält. Ein - einfaches Beispiel für einen Regelsatz, der jeglichen - eingehenden und ausgehenden Datenverkehr blockiert, könnte - beispielsweise so aussehen: - - add deny in add deny out - - Andererseits ist es möglich, den Wert der - firewall_type-Variable mit dem absoluten - Pfad einer Datei zu belegen, die (als ausführbares Skript) - die &man.ipfw.8;-Kommandos enthält, die beim Booten - ausgeführt werden sollen. Ein gültiges Skript (das die - gleiche Funktion hat wie die Zeile im letzten Beispiel) könnte - beispielsweise so aussehen: - - #!/bin/sh -ipfw -q flush + + filename: + absoluter Pfad zu einer Datei, in der die Firewallregeln + definiert sind. + + -ipfw add deny in -ipfw add deny out + Wenn Sie firewall_type auf + client oder simple + setzen, müssen Sie die voreingestellten Regeln in + /etc/rc.firewall anpassen, damit sie + der Konfiguration des Systems entsprechen. + + Beachten Sie, dass das Profil filename + verwendet wird, um ein benutzerdefiniertes Regelwerk zu + laden. + + Eine alternative Möglichkeit, um ein benutzerdefiniertes + Regelwerk zu laden, bietet die Variable + firewall_script. Setzen Sie die Variable + auf den absoluten Pfad eines + ausführbaren Skripts, welches die Befehle + für IPFW enthält. Die Beispiele in + diesem Abschnitt gehen davon aus, dass + firewall_script auf + /etc/ipfw.rules gesetzt ist. - - Wenn die Variable firewall_type - entweder auf client oder - simple gesetzt ist, sollten die - Standardregeln in der Datei - /etc/rc.firewall geprüft und an die - Konfiguration der gegebenen Maschine angepasst werden. Beachten - Sie dabei bitte, dass die Beispiele dieses Kapitels davon - ausgehen, dass das firewall_script auf - /etc/ipfw.rules gesetzt ist. - + firewall_script="/etc/ipfw.rules" - Das Logging wird durch folgenden Eintrag aktiviert: + Die Protokollierung wird mit diesem Eintrag + aktiviert: firewall_logging="YES" - - Die Variable firewall_logging definiert - lediglich die sysctl-Variable als - net.inet.ip.fw.verbose = 1 (lesen Sie dazu - bitte auch den Abschnitt - des Handbuchs). Es gibt keine - rc.conf-Variable, mit der man - Protokollierungsschwellen setzen könnte. Dies kann - lediglich über &man.sysctl.8; geschehen, wobei Sie in - der Datei /etc/sysctl.conf nur - Werte > 1 angeben sollten: - - net.inet.ip.fw.verbose_limit=5 - - - Sollte Ihre Maschinen als Gateway fungieren (also mittels - &man.natd.8; Network Address - Translation (NAT) - durchführen), finden Sie weitere Optionen in - /etc/rc.conf. - - - - Der Befehl IPFW - - ipfw + Es existiert keine Variable für + /etc/rc.conf, um die Protokollierung zu + begrenzen. Um die Anzahl der Protokoll-Nachrichten pro + Verbindungsversuch zu begrenzen, legen Sie die Anzahl der + Einträge in /etc/sysctl.conf fest: + + net.inet.ip.fw.verbose_limit=5 + + Nachdem Sie die Änderungen gespeichert haben, können Sie + die Firewall starten. Um auch die Anzahl der + Protokoll-Nachrichten zu konfigurieren, setzen Sie mit + sysctl den gewünschten Wert: - Mit &man.ipfw.8; ist es möglich, im laufenden Betrieb - einzelne Regeln hinzuzufügen oder zu entfernen. Problematisch - ist allerdings, dass diese Änderungen verloren gehen, wenn - das System neu gestartet wird. Daher ist es empfehlenswert, - eigene Regeln in einer Datei zu definieren und diese zu laden, um - die Regeln der Firewall im laufenden Betrieb anzupassen. - - &man.ipfw.8; ist jedoch hilfreich, um die Regeln der laufenden - Firewall in der Konsole auszugeben. IPFW erzeugt dynamisch einen - Zähler, der jedes Paket, auf das eine Regel zutrifft, - zählt. Dadurch wird es möglich, die Funktion einer - Regel zu überprüfen. - - Eine sequentielle Liste aller Regeln erhalten Sie mit: - - &prompt.root; ipfw list - - Eine Liste aller Regeln inklusive des letzten Treffers - erhalten Sie durch den folgenden Befehl: - - &prompt.root; ipfw -t list - - Um eine Liste aller Regeln inklusive der Anzahl der Pakete, die - von einer Regel gefiltert wurden, zu erhalten, geben Sie - den folgenden Befehl ein: - - &prompt.root; ipfw -a list - - Eine Liste, die zusätzlich allen dynamischen Regeln - enthält, erhalten Sie mit: - - &prompt.root; ipfw -d list - - Um diese Liste um alle abgelaufenen Regeln zu - erweitern, ädern Sie diesen Befehl wie folgt ab: - - &prompt.root; ipfw -d -e list - - Alle Zähler auf Null zurücksetzen: - - &prompt.root; ipfw zero - - Es ist auch möglich, einen spezifischen Zähler - auszuwählen und zurückzusetzen: - - &prompt.root; ipfw zero NUM + &prompt.root; service firewall start +&prompt.root; sysctl net.inet.ip.fw.verbose_limit=5 - IPFW-Regeln - - Ein Regelwerk ist eine Menge von IPFW-Regeln, die in - Abhängigkeit von bestimmten Paketeigenschaften Pakete - entweder passieren lassen oder abweisen. Der - zustandshafte bidirektionale Transfer von Paketen zwischen - Rechnern wird als Sitzung bezeichnet. Das Regelwerk der Firewall - verarbeitet sowohl ankommende Pakete (aus dem öffentlichen - Internet) als auch Pakete, deren Ursprung in einer Antwort des - Systems auf empfangene Pakete liegt. Jeder - TCP/IP-Dienst (wie telnet, www, mail) ist - durch sein Protokoll und durch den priveligierten - (eingehenden) Port definiert. An einen spezifischen Dienst - adressierte Pakete kommen von einer Quelladresse und einem - unprivilegierten (high order) Port. Sie adressieren den - spezifischen Port des Dienstes an der Zieladresse. Alle weiter - oben aufgeführten Parameter (also Ports und Adressen) - können als Selektionskriterium zur Erzeugung von Regeln - genutzt werden, die ein Passieren der Firewall für oder - ein Blockieren von Diensten bewirken. - - - IPFW - - rule processing order - - - + <application>IPFW</application> Regel-Syntax Wenn ein Paket die Firewall betritt, also von der Firewall geprüft und verarbeitet wird, wird die @@ -3673,1099 +3477,907 @@ das Aktionsfeld der Regel ausgeführt und die Prüfung des Pakets beendet, nachfolgende Regeln werden also nicht mehr geprüft. Diese Suchmethode wird als erster - Treffer gewinnt bezeichnet. Falls keine Regel auf + Treffer gewinnt bezeichnet. Falls keine Regel auf das betreffende Paket zutrifft, wird die obligatorische - IPFW-Rückfallregel (also Regel 65535) angewendet und das - Paket wird ohne Rückantwort verworfen. - - - Die Prüfung der Regeln wird nach Treffern von mit - count, skipto und - tee parametrisierten Regeln ungeachtet - des erster Treffer gewinnt-Prinzips weiter - fortgeführt. - - - Die Anweisungen basieren auf der Nutzung von Regeln - mit den zustandsgesteuerten Optionen keep, - state, limit, - in und out. Diese - bilden die Basis für die Spezifikation von - Firewallregeln. - - - Bei der Arbeit mit Firewallregeln ist Vorsicht geboten. - Es ist sehr einfach, sich selbst auszuschließen. - - - - Syntax der Firewallregeln - - - IPFW - - rule syntax - - - Mit der in diesem Abschnitt dargestellten Syntax der - Regeln kann ein Standardregelsatz für eine - einschließende Firewall erstellt - werden. Für eine vollständige Beschreibung der - Regelsyntax lesen Sie bitte die Manualpage &man.ipfw.8; - - Regelausdrücke werden von links nach - rechts ausgewertet. Schlüsselwörter - werden in fetter Schrift dargestellt. Manche - Schlüsselworte beinhalten Unteroptionen, die wiederum - selbst aus Schlüsselworten samt Optionen bestehen - können. - - Kommentare sind mit einen führenden Doppelkreuz - (#) ausgezeichnet. Sie können am - Ende einer Regel oder in einzelnen, separaten Zeilen stehen. - Leerzeilen werden ignoriert. - - CMD RULE_NUMBER ACTION LOGGING SELECTION - STATEFUL - - - CMD - - Jede neue Regel benötigt das Präfix - add, um die Regel der internen - Tabelle hinzuzfügen. - - - - RULE_NUMBER - - Zu jeder Regel gehört eine Regelnummer zwischen 1 - und 65535. - - - - ACTION - - Eine Regel kann mit einer der vier folgenden Aktionen - verbunden sein, die ausgeführt werden, wenn ein Paket - den Selektionskriterien der Regel entspricht. - - allow | accept | pass | permit - - Alle diese Aktionen bewirken das Gleiche: Pakete, die - den Selektionskriterien der Regel entsprechen, verlassen den - Regelprüfungsabschnitt der Firewall und die - Regelprüfung wird beendet. - - check-state - - Diese Aktion prüft das Paket gegen die Regeln aus - den dynamischen Regeltabellen. Trifft ein - Selektionskriterium zu, wird die zur dynamischen Regel - gehörende Aktion ausgeführt. Anderenfalls wird - gegen die nächste Regel geprüft. Die - check-state-Regel selbst hat kein - Selektionskriterium. Sollte eine - check-state-Regel im Regelwerk fehlen, - wird gegen die erste keep-state- oder - limit-Regel in den dynamischen Regeln - geprüft. - - deny | drop - - Beide Schlüsselworte bewirken dieselbe Aktion: - Ein Paket, dass die Selektionskriterien der Regel - erfüllt, wird verworfen und die Regelprüfung - wird beendet. - - - - Protokollierung - - log oder - logamount + IPFW-Rückfallregel mit der Nummer + 65535 angewendet und das Paket wird ohne Rückantwort + verworfen. Wenn das Paket jedoch einer Regel mit dem + Schlüsselwort count, + skipto oder tee + entspricht, wird die Prüfung des Pakets weiter + fortgeführt. Weitere Details darüber, wie diese + Schlüsselwörter die Regelverarbeitung beeinflussen, finden Sie + in &man.ipfw.8;. - Erfüllt ein Paket die Selektionskriterien mit dem - Schlüsselwort log, wird dies von - &man.syslogd.8; mit der Annotation SECURITY protokolliert. - Dies erfolgt allerdings nur, wenn die Anzahl der - protokollierten Pakete der betreffenden Regel die im - logamount-Parameter definierte - Schwelle nicht übersteigt. Ist der Parameter - logamount nicht definiert, wird diese - Grenze aus der sysctl-Variable - net.inet.ip.fw.verbose_limit ermittelt. - Ist einer dieser beiden Werte auf Null - gesetzt, wird unbegrenzt protokolliert. Wurde hingegen - ein definierter Schwellenwert erreicht, wird die - Protokollierung deaktiviert. Um sie zu reaktivieren, - können Sie entweder den Protokoll- oder den - Paketzähler rücksetzen (und zwar über den - Befehl ipfw reset log). - - - Die Protokollierung findet statt, nachdem alle - Paketselektionskriterien geprüft und bevor die - daraus folgende, endgültige Aktion - (accept oder deny) - auf das Paket ausgeführt wird. Die Entscheidung, - welche Regel protokolliert werden soll, bleibt Ihnen - überlassen. - - - - - Selektion - - Die in diesem Abschnitt beschriebenen - Schlüsselwörter beschreiben die Attribute eines - Pakets, durch die bestimmt wird, ob eine Regel auf ein - Paket zutrifft. Die folgenden Attribute dienen der - Bestimmung des Protokolls und müssen in der angegebenen - Reihenfolge verwendet werden. - - udp | tcp | icmp - - Weitere in /etc/protocols - angegebene Protokolle werden ebenfalls erkannt und - können daher verwendet werden, um das Protokoll zu - definieren, gegen das Pakete geprüft werden. Die - Angabe des Protokolls ist verpflichtend. - - from src to dst - - Die Schlüsselwörter from - und to beziehen sich auf IP-Adressen und - definieren sowohl Ursprungs- als auch Zieladresse einer - Datenverbindung. Firewallregeln müssen Parameter - für den Ursprung und das Ziel - enthalten. Das Schlüsselwort any - steht für beliebige IP-Adressen. Bei - me handelt es sich um ein spezielles - Schlüsselwort, das alle IP-Adressen beschreibt, die - einer bestimmten Netzwerkschnittstelle Ihres Systems - (auf dem die Firewall läuft) zugeordnet sind. - Beispiele hierfür sind - from me to any, - from any to me, - from 0.0.0.0/0 to any , - from any to 0.0.0.0/0, - from 0.0.0.0 to any, - from any to 0.0.0.0 oder - from me to 0.0.0.0. IP-Adressen werden - entweder in CIDR-Notation - oder durch Punkte getrennt mit Suffixen - (192.168.2.101/24) für - die Netzmaske oder als einzelne numerische, durch Punkte - getrennte Adressen - (192.168.2.101) angegeben. - Die dafür notwendigen Berechnungen erleichtert der - Port net-mgmt/ipcalc. - Weiterführende Informationen finden sich auf - http://jodies.de/ipcalc. - - port number - - Bei der Verarbeitung von Protokollen wie - TCP oder UDP, die - Portnummern verwenden, muss die Portnummer des - betreffenden Dienstes angegeben werden. Anstelle der - Portnummer kann auch der in der Datei - /etc/services definierte Name des - Dienstes angegeben werden. - - in | out - - Diese Schlüsselwörter beziehen sich auf die - Richtung des Datenverkehrs. Jede Regel - muss eines dieser beiden - Schlüsselwörter enthalten. - - via IF - - Eine Regel mit dem Schlüsselwort - via IF betrifft nur Pakete, die über - die angegebene Schnittstellte geroutet werden (ersetzen Sie - IF durch den Namen Ihrer - Netzwerkschnittstelle). Die Angabe des - Schlüsselwortes via bewirkt, dass - die Netzwerkschnittstelle in die Regelprüfung - aufgenommen wird. - - setup - - Dieses obligatorische Schlüsselwort bezeichnet - die Anforderung des Sitzungsstarts für - TCP-Pakete. - - keep-state - - Dieses obligatorische Schlüsselwort bewirkt, - dass die Firewall eine dynamische Regel erzeugt, die - bidirektionalen Datenverkehr zwischen Ursprungs- und - Zieladresse sowie Ursprungs- und Zielport prüft, - der das gleiche Protokoll verwendet. - - limit {src-addr | src-port | dst-addr | - dst-port} - - Wird das Schlüsselwort limit - verwendet, sind nur N durch diese - Regel definierte Verbindungen erlaubt. Es können - dabei ein oder mehrere Ursprungs- und Zieladressen sowie - ein oder mehrere Ports angegeben werden. Die - Schlüsselwörter limit - und keep-state können nicht in - derselben Regel verwendet werden. Die Option - limit bewirkt dieselbe Zustandsteuerung - wie die Option keep-state, erweitert - diese jedoch um eigene Regeln. - - - - - Optionen für zustandsgesteuerte Regeln - - - IPFW - - stateful filtering - - - - - Eine zustandsgesteuerte Filterung behandelt Datenverkehr - als einen bidirektionalen Austausch von Datenpaketen (die eine - sogenannte Konversation innerhalb einer Sitzung darstellen). - Sie ist in der Lage, zu bestimmen, ob die Konversation von - originärem Sender und Empfänger gültigen - Prozeduren des bidirektionalen Pakettausches entspricht. - Pakete, die dem Muster von Konversationen in Sitzungen nicht - folgen, werden automatisch als Betrüger - abgelehnt. - - Die check-state-Option wird verwendet, - wo genau innerhalb des IPFW-Regelwerks die Prüfung - dynamischer Regeln stattfinden soll. Erfüllt ein - Datenpaket die Selektionskriterien der Regel, verlässt - das Paket die Firewall. Gleichzeitig wird eine neue - dynamische Regel erzeugt, die für das nächste Paket - der bidirektionalen Konversation in der Sitzung vorgesehen - ist. Falls ein Paket die (dyanmische) Regel nicht erfüllt, - wird es gegen die nächste Regel im Regelwerk - geprüft. - - Dynamische Regeln sind für einem sogenannten - SYN-flood-Angriff anfällig, - bei dem eine riesige Anzahl schwebender - dynamischer Regelprüfungungsinstanzen erzeugt wird. Um - einem solchen Angriff zu begegnen, wurde in &os; die neue - Option limit geschaffen. Diese Option - begrenzt die Anzahl der gleichzeitig möglichen - Sitzungen und/oder Konversationen. Es handelt sich dabei um - einen Zähler, der die Anzahl von Instanzen dynamischer - Regelprüfungen in Abhängigkeit von einer eindeutigen - Urspungs- und Quelladresskombination zählt. - Übersteigt der Zähler den durch - limit definierten Schwellenwert, wird - das Paket verworfen. - - - - Protokollierung von Firewall-Nachrichten - - - IPFW - - logging - - - Die Vorteile einer Protokollierung sind offensichtlich. - Sie ermöglicht nach Aktivierung von Regeln zu - untersuchen, welche Pakete verworfen wurden, von wo diese - stammen und für welche Systeme sie bestimmt waren. Diese - Informationen sind sehr nützlich bei der Erkennung - eventueller Angriffe sowie bei deren Abwehr. - - IPFW protokolliert nur jene Regeln, für die ein - Administrator dies explizit aktiviert. Ein Aktivieren - der Protolllfunktion führt also nicht dazu, dass - automatisch alle Regeln protokolliert werden. Vielmehr - entscheidet der Administrator der Firewall, welche Regeln - protokolliert werden sollen. Dazu wird die Option - log für diese Regeln aktiviert. Im - Regelfall werden nur deny-Regeln - protokolliert, beispielsweise die deny-Regel - für eintreffende ICMP-Nachrichten. - Üblicherweise wird die ipfw default deny - everything-Regel doppelt angelegt. Einmal mit und - einmal ohne aktivierte Option log. Dadurch - erhält man eine Auflistung aller Pakete, auf die keine - Regel zutraf. - - Protokollierung ist allerdings ein zweischneidiges - Schwert, bei mangelnder Vorsicht wird man mit einer enormen - Flut von Protokollierungsdaten förmlich - überschwemmt und belastet - zusätzlich die Festplatte des Systems durch rasch - wachsende Protokolldateien. DoS-Angriffe, die auf diese - Art und Weise Festplatten an die Kapazitätsgrenze treiben, - gehören zu den ältesten Angriffen überhaupt. - Außerdem werden Protokollnachrichten nicht nur an - &man.syslogd.8; geschickt, sondern auch auf einem - root-Terminal angezeigt. - - Die Kerneloption - IPFIREWALL_VERBOSE_LIMIT=5 begrenzt die - Anzahl gleicher Nachrichten an &man.syslogd.8; für - eine gegebene Regel auf fünf Nachrichten. Ist diese - Option im Kernel aktiviert, wird nach Erreichen der - festgelegten Anzahl die Protokollierung einer (sich - unmittelbar hintereinander wiederholenden) Nachricht auf den - angegebenen Schwellenwert begrenzt, da beispielsweise die - Speicherung von 200 gleichen Protokollnachrichten durch - &man.syslogd.8; sinnlos ist. Daher werden durch diesen - nur füf derartige Nachrichten protokolliert. Alle - weiteren derartigen Nachrichten werden nur gezählt und - deren Gesamtzahl wird schließlich von &man.syslogd.8; - durch folgenden Ausdruck ausgegeben: - - last message repeated 45 times - - Alle protokollierten Nachrichten für Datenpakete - werden in der Voreinstellung in die Datei - /var/log/security (die in der Datei - /etc/syslog.conf definiert wird), - geschrieben. - - - - Skripte zur Regeldefinition erstellen - - Die meisten fortgeschrittenen IPFW-Nutzer erzeugen eine - Datei, die die Regeln für die Firewall enthält, - um diese als Skript ausführen zu können. - Der Hauptvorteil einer derartigen Konfiguration ist es, dass - dadurch mehrere Regeln gleichzeitig geändert und - (re-)aktiviert werden können, ohne dass dazu das System - neu gestartet werden muss. Dies ist auch beim Testen von - Regeländerungen sehr hilfreich. Weil es sich bei der - Datei, in der die Regeln gespeichert sind, um ein Skript - handelt, ist es auch möglich, häufig verwendete - Werte/Befehle durch Aliase zu ersetzen und diese so in mehreren - Regeln zu nutzen. Diese Funktion wird im folgenden Beispiel - näher vorgestellt. - - Die Syntax des folgenden Skripts entspricht der Syntax von - &man.sh.1;, &man.csh.1; sowie &man.tcsh.1;. Felder, die - symbolisch substituiert werden, haben das Präfix - $ (das Dollarzeichen). Symbolische Felder haben dieses - $-Praefix nicht. Der Wert, mit dem das symbolische - Feld belegt wird, muss in - doppelten Anführungszeichen - eingeschlossen sein. - - Beginnen Sie Ihre Regeldatei wie folgt: - - ############### start of example ipfw rules script ############# -# -ipfw -q -f flush # Delete all rules -# Set defaults -oif="tun0" # out interface -odns="192.0.2.11" # ISP's DNS server IP address -cmd="ipfw -q add " # build rule prefix -ks="keep-state" # just too lazy to key this each time -$cmd 00500 check-state -$cmd 00502 deny all from any to any frag -$cmd 00501 deny tcp from any to any established -$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks -$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks -$cmd 00611 allow udp from any to $odns 53 out via $oif $ks -################### End of example ipfw rules script ############ - - Die Regeln in diesem Beispiel sind nicht wichtig. Wichtig - ist es, zu zeigen, wie die symbolische Substitution innerhalb - der Regeln verwendet wird. - - Wurde dieses Beispiel in der Datei - /etc/ipfw.rules gespeichert, so können - alle Regeln durch die Ausführung des folgenden Befehls - neu geladen werden: + + IPFW + Regel-Syntax + - &prompt.root; sh /etc/ipfw.rules + Bei der Erstellung der + IPFW-Regeln müssen die + Schlüsselwörter in der folgenden Reihenfolge geschrieben + werden. Einige Schlüsselwörter müssen zwingend angegeben + werden, während andere optional sind. Die Wörter in + Großbuchstaben repräsentieren Variablen und die Wörter in + Kleinbuchstaben müssen den Variablen vorangestellt + werden. Das Zeichen # wird benutzt, um + einen Kommentar einzuleiten und kann am Ende einer Regel oder + in einer eigenen Zeile stehen. Leerzeilen werden + ignoriert. + + CMD RULE_NUMBER set SET_NUMBER ACTION log + LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT + OPTIONS + + Dieser Abschnitt bietet einen Überblick über diese + Schlüsselwörter und deren Optionen. Es ist keine vollständige + Liste aller verfügbaren Optionen. Eine vollständige + Beschreibung der Regel-Syntax, die Sie verwenden können um + IPFW-Regeln zu erstellen, finden + Sie in &man.ipfw.8;. - Statt /etc/ipfw.rules können Sie - auch einen beliebigen anderen Namen und/oder Speicherort - verwenden. + + + CMD + + Jede Regel muss mit ipfw add + beginnen. + + - Alternativ könnten Sie die einzelnen Befehle dieses - Skripts auch manuell starten: + + RULE_NUMBER + + Jede Regel gehört zu einer Nummer zwischen + 1 und 65534. Die + Nummer wird verwendet, um die Reihenfolge der + Regelverarbeitung zu kennzeichnen. Es ist möglich, dass + mehrere Regeln dieselbe Nummer haben. In diesem Fall + werden sie entsprechend der Reihenfolge angewendet, in + der sie aufgenommen wurden. + + - &prompt.root; ipfw -q -f flush -&prompt.root; ipfw -q add check-state -&prompt.root; ipfw -q add deny all from any to any frag -&prompt.root; ipfw -q add deny tcp from any to any established -&prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state -&prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state -&prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state - + + SET_NUMBER + + Jede Regel ist einer Set-Nummer + zwischen 0 und 31 + zugeordnet. Sets können einzeln aktiviert oder + deaktiviert werden. Dies macht es möglich, eine Reihe + von Regeln schnell hinzuzufügen oder zu löschen. Wenn + SET_NUMBER nicht angegeben ist, wird + die Regel zu Set 0 + hinzugefügt. + + - - Zustandsgesteuertes Regelwerk + + ACTION + + Eine Regel kann mit einer der folgenden Aktionen + verknüpft werden. Die festgelegte Aktion wird + ausgeführt, wenn das Paket den Selektionskriterien der + Regel entspricht. + + allow | accept | pass | + permit: All diese Aktionen sind + gleichbedeutend und erlauben Pakete, die mit der Regel + übereinstimmen. + + check-state: Diese Aktion + überprüft die Regel in der dynamischen Zustandstabelle. + Bei einer Übereinstimmung wird die mit der dynamischen + Regel verknüpfte Aktion ausgeführt, andernfalls wird mit + der Prüfung gegen die nächste Regel fortgefahren. Die + Regel check-state hat selbst kein + Selektionskriterium. Sollte keine + check-state-Regel im Regelwerk + vorhanden sein, wird die dynamische Zustandstabelle beim + ersten Vorkommen einer keep-state- + oder limit-Regel überprüft. + + count: Aktualisiert die + Zähler für alle Pakete, die mit dieser Regel + übereinstimmen. Die Prüfung wird mit der nächsten Regel + fortgesetzt. + + deny | drop: Diese Aktionen + sind gleichbedeutend und verwerfen Pakete, die mit + dieser Regel übereinstimmen. - Das folgende Regelwerk (ohne - NAT-Funktionalität) ist ein Beispiel - dafür, wie man eine sehr sichere - einschließende Firewall aufsetzen kann. - Eine einschließende Firewall erlaubt es nur Diensten, - für die explizite Regeln existieren, die Firewall zu - passieren. Alle anderen Dienste und Pakete werden hingegen - blockiert. Firewalls, die ganze Netzwerksegmente schützen - sollen, benötigen mindestens zwei Netzwerkschnittstellen, - für die jeweils eigene Regeln definiert werden müssen, - damit die Firewall ordnungsgemäß funktioniert. - - Alle unixoiden Betriebssysteme (aber auch solche, die - Konzepte aus &unix; implementieren), darunter auch &os;, - verwenden die Schnittstelle lo0 mit - der IP-Adresse 127.0.0.1 zur - internen Kommunikation mit dem Betriebssystem. Die Firewall - muss so eingestellt sein, dass sie den Datenverkehr dieser - speziellen (und nur intern genutzten) Pakete ungehindert - durchlässt. - - Die Regeln, die den Zugriff auf eingehene und ausgehende - Verbindungen regeln, autorisieren und kontrollieren, - müssen mit der für die Verbindung zum - öffentlichen Internet verantwortlichen Schnittstelle - assoziiert werden. Bei dieser Schnittstelle kann es sich - beispielsweise um - PPP/tun0 oder - die Netzwerkkarte handelt, über, die mit Ihrem - DSL- oder Kabelmodem verbunden - ist. - - Falls mehr als eine Netzwerkkarte mit einem privaten - Netzwerk (hinter der Firewall) verbunden sind, müssen - die Firewallregeln für alle diese Schnittstellen - entstammenden Datenpakete freien und ungehinderten - Datenverkehr erlauben. - - Es ist sinnvoll, die Regeln in drei Abschnitte - aufzuteilen. Der erste Abschnitt enthält die freien, - von der Firewall nicht zu überwachenden - Netzwerkschnittstellen. Danach folgen die öffentlichen, - für den ausgehenden Verkehr verantwortlichen - Schnittstellen. Zuletzt kommen dann die Schnittstellen, - die für den eingehenden Datenverkehr verantwortlich - sind. - - Innerhalb der einzelnen Abschnitte ist es sinnvoll, die - am häufigsten verwendeten Regeln vor den seltener - verwendeten Regel zu platzieren. Jeder Abschnitt sollte - mit einer letzten Regel (die alle Pakete, auf die keine - Regel zutraf, verwirft) abgeschlossen werden. - - Der Abschnitt für den ausgehenden Datenverkehr des - folgenden Beispiels enthät nur - allow)-Regeln, in denen der Dienst, dem - der Zugriff auf das öffentliche Internet gewährt - wird, eindeutig definiert ist. Alle Regeln verwenden die - Optionen proto, port, - in/out, via sowie - keep state kodiert. Die - Regeln mit proto tcp verwenden - zusätzlich die Option setup, damit - die initiale, eine Sitzung beginnende Anfrage identifiziert - werden kann, damit die die Zustandsttabelle gefüllt - werden kann. - - Der Abschnitt für den eingehenden Datenverkehr - beginnt mit allen Regeln, die zur Blockierung - unerwünschten Datenverkehrs benötigt werden. - Für diese Vorgehensweise gibt es zwei Gründe: - Zum einen könnten bösartige Pakete legtitimen - Datenverker so sehr ähneln, dass sie die - Bedingungen von allow-Regeln erfüllen - und daher die Firewall passieren dürfen. Daher sollten - derartige Pakete direkt verworden werden. Zum anderen - sollten unerwünschte Pakete mit bekannten (und somit - uninteressanten Mustern) sofort ohne Rückmeldung blockiert - werden, anstatt erst von der letzten, generischen Regel - blockiert (und, was noch wichtiger ist, auch noch - protokolliert). Die letzte Regel jedes Abschnittes blockiert - und protokolliert; sie kann daher dazu verwendet werden, - vor Gericht haltbare Beweise zu erhalten, damit sie gegen - Personen vorgehen können, die versuchen, Ihre Systeme - anzugreifen. - - Achten Sie darauf, dass Sie keine Netwerkantworten für - geblockte Pakete senden. Diese müssen ohne - Rückmeldung verworfen werden, damit ein Angreifer keine - Informationen darüber erhält, ob seine Datenpakete - Ihr System erreicht hat. Je weniger Information ein Angreifer - über Ihr System erhält, desto sicherer ist Ihr - System. Datenpakete an Ports, die nicht bekannten Diensten - zugeordnet werden können, können über die Datei - /etc/services identifiziert werden. - Alternativ kann eine Anfrage an http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers - Klarheit über die Aufgabe/Funktion einer bestimmten Portnummer - bringen. Auf der Seite http://www.sans.org/security-resources/idfaq/oddports.php - kann man Information über bekannte Trojaner und von - diesen verwendete Portnummern erhalten. - + Es stehen noch weitere Aktionen zur Verfügung. + Einzelheiten finden Sie in &man.ipfw.8;. + + - - Ein Beispiel für einschließende - Regeln + + LOG_AMOUNT + + Erfüllt ein Paket die Selektionskriterien mit dem + Schlüsselwort log, wird dies von + &man.syslogd.8; mit der Annotation + SECURITY protokolliert. Dies erfolgt + allerdings nur, wenn die Anzahl der protokollierten + Pakete der betreffenden Regel die definierte + LOG_AMOUNT-Grenze nicht übersteigt. + Wenn LOG_AMOUNT nicht definiert ist, + wird die Grenze aus dem Wert von + net.inet.ip.fw.verbose_limit + benutzt. Ein Wert von 0 bedeutet + eine unbegrenzte Protokollierung. Wird eine definierte + Grenze erreicht, wird die Protokollierung für diese + Regel deaktiviert. Um die Protokollierung zu + reaktivieren, können Sie den Protokoll- oder Paketzähler + mit ipfw resetlog + zurücksetzen. + + + Die Protokollierung findet statt, nachdem alle + Selektionskriterien geprüft und bevor die endgültige + Aktion auf das Paket angewendet wird. Der + Administrator entscheidet, welche Regel protokolliert + werden soll. + + + - Das folgende Regelwerk (ohne - NAT-Funktionalität) beschreibt ein - vollständiges, einschließendes Regelwerk. Dieses - Regelwerk kann direkt auf Ihren eigenen Systemen eingesetzt - werden, wenn alle pass-Regeln - für von Ihnen nicht benötigten Dienste - auskommentiert werden. Falls Sie keine Protokollierung - benötigen, können Sie diese im Abschnitt für - den eingehenden Datenverkehr durch eine - deny deaktivieren. Die im Beispiel - verwendete Netzwerkschnittstelle dc0 - müssen Sie durch die auf Ihrem System für - ausgehenden Datenverkehr vorgesehenen Netzwerkschnittstelle - ersetzen. Im Falle von benutzergesteuertem - PPPs wäre dies - beispielsweise tun0. + + PROTO + + Dieser optionale Wert wird verwendet, um einen + beliebigen Protokollnamen oder -nummer aus + /etc/protocols gegen das Paket zu + prüfen. + + - Alle Regeln folgen einem bestimmten Muster. + + SRC + + Nach dem Schlüsslwortfrom muss + die Quelladresse stehen, oder ein Schlüsselwort, das die + Quelladresse darstellt. Eine Adresse wird dargestellt + duch any, me (jede + Adresse dieses Systems), me6 (jede + IPv6-Adresse dieses Systems), oder + table gefolgt von der Nummer der + Tabelle, welche die Adressen enthält. + IP-Adressen können in + CIDR-Notation geschrieben werden. + Beispielsweise 1.2.3.4/25 oder + 1.2.3.4:255.255.255.128. + + - + + SRC_PORT - Alle Ausdrücke, die eine Anfrage zum Beginn - einer zustandsgesteuerten darstellen, beinhalten den - Ausdruck keep-state. + Optional kann ein Quellport über eine Nummer oder + einen Namen aus /etc/services + spezifiziert werden. + + + DST - Alle Dienste aus dem öffentlichen Internet - beinhalten die Option limit, um - gegebenenfalls - flooding zu - unterbinden. + Nach dem Schlüsselwort to muss + die Zieladresse stehen, oder ein Schlüsselwort, das die + Zieladresse darstellt. Es können die gleichen + Schlüsselwörter und Adressen benutzt werden, die bereits + im SRC-Abschnitt beschrieben wurden. + + + DST_PORT - Alle Regeln bezeichnen die Richtung durch der - Ausdrücke in oder - out. + Optional kann ein Zielport über eine Nummer oder + einen Namen aus /etc/services + spezifiziert werden. + + + OPTIONS - Alle Regeln legen die verwendete - Netzwerkschnittstelle die Ausdrücke - via und - interface-name fest. + Nach der Quell- und Zieladresse können noch weitere + Optionen angegeben werden. Wie der Name bereits sagt, + sind OPTIONS optional. Häufig + verwendete Optionen sind in oder + out, mit denen die Richtug des + Pakets bestimmt wird, icmptypes + gefolgt vom Typ der ICMP-Nachricht, + sowie keep-state. + + Wenn ein Paket auf eine + keep-state-Regel zutrifft, wird + die Firewall eine dynamische Regel erstellen, die dem + bidirektionalen Datenverkehr zwischen den gleichen + Quell- und Zieladressen mit dem gleichen Protokoll + entspricht. + + Dynamische Regeln sind für einen sogenannten + SYN-flood-Angriff + anfällig, bei dem eine riesige Anzahl an dynamischen + Regeln erzeugt wird. Verwenden Sie die Option + limit, um einen solchen Angriff + entgegenzuwirken. Diese Option begrenzt die Anzahl + der gleichzeitig möglichen Sitzungen. Es handelt sich + dabei um einen Zähler, der die Anzahl von dynamischen + Regeln in Kombination mit der Quelladresse verfolgt. + Übersteigt der Zähler den durch limit + definierten Wert, wird das Paket verworfen. + + Es stehen noch viele weitere Optionen zur Verfügung. + &man.ipfw.8; enthält eine Beschreibung der einzelnen + Optionen. - + + + - Die folgenden Regeln werden in der Datei - /etc/ipfw.rules definiert. + + Beispiel für einen Regelsatz + + Dieser Abschnitt die Erstellung eines Firewall-Skripts + namens /etc/ipfw.rules mit + zustandsorientierten (stateful + Regeln. Alle Regeln in diesem Beispiel verwenden die Optionen + in und out, um die + Richtung des Pakets zu verdeutlichen. Zusätzlich wird + via + interface-name benutzt, um die + Schnittstelle für das Paket zu prüfen. + + + Bei den anfänglichen Tests mit dem Firewall-Regelsatz + sollten Sie vielleicht folgende Einstellung + vornehmen: + + net.inet.ip.fw.default_to_accept="1" + + Dies legt die Standardregel von &man.ipfw.8; etwas + großzügiger fest, als das voreingestellte + default deny ip from any to any. Dadurch + sinkt die Gefahr, sich nach einem Neustart des Systems + auszusperren. + + + Das Firewall-Skript beginnt mit einem Hinweis, dass es + sich um ein Bourne Shell-Skript handelt. Danach werden alle + vorhandenen Filterregeln gelöscht. Anschließend wird die + Variable cmd erstellt, sodass + ipfw add nicht jedes mal von Hand + eingegeben werden muss. Die Variable pif + repräsentiert die mit dem Internet verbundene + Schnittstelle. - ################ Start of IPFW rules file ############################### + #!/bin/sh # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" -pif="dc0" # public interface name of NIC - # facing the public Internet +pif="dc0" # interface name of NIC attached to Internet -################################################################# -# No restrictions on Inside LAN Interface for private network -# Not needed unless you have LAN. -# Change xl0 to your LAN NIC interface name -################################################################# -#$cmd 00005 allow all from any to any via xl0 + Jetzt folgen die eigentlichen Filterregeln. Diese ersten + beiden Regeln erlauben den Datenverkehr aus dem internen + Netzwerk und über die Loopback-Schnittstelle: + + # Change xl0 to LAN NIC interface name +$cmd 00005 allow all from any to any via xl0 -################################################################# # No restrictions on Loopback Interface -################################################################# -$cmd 00010 allow all from any to any via lo0 +$cmd 00010 allow all from any to any via lo0 -################################################################# -# Allow the packet through if it has previous been added to the -# the "dynamic" rules table by a allow keep-state statement. -################################################################# -$cmd 00015 check-state + Die nächste Regel erlaubt Pakete, für die ein Eintrag + in der dynamischen Zustandstabelle existiert: -################################################################# -# Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the -# firewall on the private network or from this gateway server -# destined for the public Internet. -################################################################# + $cmd 00101 check-state -# Allow out access to my ISP's Domain name server. -# x.x.x.x 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 + Die nächsten Regeln definieren, welche internen Rechner + Verbindungen zu anderen Rechnern im Internet aufbauen dürfen. + Hier werden wieder zustandsorientierte Regeln + verwendet: + + # Allow access to public DNS +# Replace x.x.x.x with the IP address of a public DNS server +# and repeat for each DNS server in /etc/resolv.conf $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state -# Allow out access to my ISP's DHCP server for cable/DSL configurations. -# This rule is not needed for .user ppp. 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 +# Allow access to ISP's DHCP server for cable/DSL configurations. +# Use the first rule and check log for IP address. +# Then, uncomment the second rule, input the IP address, and delete the first rule $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state -# Allow out non-secure standard www function +# Allow outbound HTTP and HTTPS connections $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state - -# Allow out secure www function https over TLS SSL $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state -# Allow out send & get email function +# Allow outbound email connections $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state -# Allow out FBSD (make install & CVSUP) functions -# Basically give user root "GOD" privileges. -$cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root - -# Allow out ping +# Allow outbound ping $cmd 00250 allow icmp from any to any out via $pif keep-state -# Allow out Time +# Allow outbound NTP $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state -# Allow out nntp news (i.e. news groups) -$cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state - -# Allow out secure FTP, Telnet, and SCP -# This function is using SSH (secure shell) +# Allow outbound SSH $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state -# Allow out whois -$cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state +# deny and log all other outbound connections +$cmd 00299 deny log all from any to any out via $pif -# deny and log everything else that.s trying to get out. -# This rule enforces the block all by default logic. -$cmd 00299 deny log all from any to any out via $pif - -################################################################# -# Interface facing Public Internet (Inbound Section) -# Check packets originating from the public Internet -# destined for this gateway server or the private network. -################################################################# - -# Deny all inbound traffic from non-routable reserved address spaces -$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP -$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP -$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP + Die folgenden Regeln steuern die Verbindungen von + Rechern aus dem Internet ins interne Netzwerk. Zuerst werden + Pakete verworfen, die typischerweise im Zusammenhang mit + Angriffen stehen. Danach werden bestimmte Arten von + Verbindungen erlaubt. Alle Dienste aus dem öffentlichen + Internet beinhalten die Option limit, um + Flooding zu unterbinden. + + # Deny all inbound traffic from non-routable reserved address spaces +$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP +$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP +$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #loopback -$cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback -$cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config +$cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback +$cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs -$cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect -$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast +$cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect +$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast -# Deny public pings -$cmd 00310 deny icmp from any to any in via $pif +# Deny public pings$ +$cmd 00310 deny icmp from any to any in via $pif$ +$ +# Deny ident$ +$cmd 00315 deny tcp from any to any 113 in via $pif$ +$ +# Deny all Netbios services.$ +$cmd 00320 deny tcp from any to any 137 in via $pif$ +$cmd 00321 deny tcp from any to any 138 in via $pif$ +$cmd 00322 deny tcp from any to any 139 in via $pif$ +$cmd 00323 deny tcp from any to any 81 in via $pif$ -# Deny ident -$cmd 00315 deny tcp from any to any 113 in via $pif - -# Deny all Netbios service. 137=name, 138=datagram, 139=session -# Netbios is MS/Windows sharing services. -# Block MS/Windows hosts2 name server requests 81 -$cmd 00320 deny tcp from any to any 137 in via $pif -$cmd 00321 deny tcp from any to any 138 in via $pif -$cmd 00322 deny tcp from any to any 139 in via $pif -$cmd 00323 deny tcp from any to any 81 in via $pif - -# Deny any late arriving packets +# Deny fragments $cmd 00330 deny all from any to any frag in via $pif # Deny ACK packets that did not match the dynamic rule table $cmd 00332 deny tcp from any to any established in via $pif -# Allow traffic in from ISP's DHCP server. This rule must contain -# the IP address of your ISP.s DHCP server as it.s 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. +# Allow traffic from ISP's DHCP server. +# Replace x.x.x.x with the same IP address used in rule 00120. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state -# Allow in standard www function because I have apache server +# Allow HTTP connections to internal web server $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 -# Allow in secure FTP, Telnet, and SCP from public Internet +# Allow inbound SSH connections $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 -# Allow in non-secure Telnet session from public Internet -# labeled non-secure because ID & PW are passed over public -# Internet as clear text. -# Delete this sample group if you do not have telnet server enabled. -$cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 - -# Reject & Log all incoming connections from the outside -$cmd 00499 deny log all from any to any in via $pif +# Reject and log all other incoming connections +$cmd 00499 deny log all from any to any in via $pif -# Everything else is denied by default -# deny and log all packets that fell through to see what they are -$cmd 00999 deny log all from any to any -################ End of IPFW rules file ############################### - + Die letzte Regel protokolliert alle Pakete, die mit + keiner Regel im Regelsatz übereinstimmen: - - Ein Beispiel für zustandshafte - <acronym>NAT</acronym>-Regeln - - - NAT - und IPFW - - - Es müssen einige zusätzliche - Konfigurationseinstellungen vorgenommen werden, um die - die NAT-Funktion von IPFW zu nutzen. Die - Kernelquellen müssen mit der Option - IPDIVERT (im IPFIREWALL-Abschnitt der - Kernelkonfigurationsdatei) neu gebaut werden, um den - benötigten angepassten Kernel zu erzeugen. - - Zusätzlich werden folgende Optionen in der - /etc/rc.conf benötigt: - - natd_enable="YES" # Enable NATD function -natd_interface="rl0" # interface name of public Internet NIC -natd_flags="-dynamic -m" # -m = preserve port numbers if possible - - Zustandshafte Regeln bei aktiviertem - divert natd (Network - Address Translation) verkomplizieren die - Formulierung des Regelwerkes beträchtlich. Damit Ihre - Firewall funktioniert, kommt es insbesondere auf die Position - der Ausdrücke check-state sowie - divert natd an. Sie können nicht - länger einen einfachen, kaskadierenden Ablauf verwenden - (also einen Regelsatz, bei dem einfach auf eine Regel nach der - anderen geprüft wird. Vielmehr wird der neue - Aktionstyp skipto benötigt. Dies - erfordert, dass jede Regel über eine eindeutige Nummer - verfügt, um so eindeutige Sprungziele zu erhalten. - - Im Folgenden wird anhand eines umkommentierten Beispiels - der Paketfluss durch das Regelwerk verdeutlicht. - - Die Verarbeitung beginnt mit der ersten Regel (also am - Anfang der Regeldatei. Sie setzt sich Regel für Regel - weiter fort, bis das Ende der Datei erreicht ist oder eine - Regel für das Paket einen Treffer erzielt und das Paket - so die Firewall verlassen kann. Achten Sie besonders auf die - Position der Regeln mit den Nummern - 100, 101, 450, 500 sowie - 510. Diese Regeln steuern die - Adressumsetzung ausgehender und eingehender Pakete, so dass - deren entsprechende Einträge in der Zustandstabelle immer - die private LAN-Adressen abbilden. Zusätzlich werden in - allen Regeln die Richtung des Pakets (eingehend oder - ausgehend) so die vom Paket zu verwendende Netzwerkschnittstelle - definiert. Ausgehende Anfragen, die eine Sitzung starten, rufen - immer skipto rule 500, damit - NAT verwendet werden kann. - - Nehmen wir nun an, dass ein Nutzer einen Webbrowser - verwendet, um eine Internetseite aufzurufen. Derartige - Anfragen werden in der Regel über Port 80 geleitet. Die - zugehörigen Pakete werden durch die Firewall verarbeitet. - Regel 100 trifft nicht zu, denn das Paket geht nach außen, - nicht nach innen. Regel 101 trifft ebenfalls nicht zu, denn es - handelt sich um das erste Paket. Folglich wird die Sitzung - erst initiiert und kann somit noch nicht in der - Zustandstabelle enthalten sein kann. Die erste Regel, die - zutrifft, ist Regel 125. Das Paket will das lokale Netzwerk - über die Schnittstelle zum öffentlichen Internet (das - heißt nach außen) verlassen, es hat aber noch die - Quelladresse des privaten lokalen Netzwerks. Da Regel 125 - zutrifft, werden zwei Aktionen ausgeführt: Die Option - keep-state bewirkt, dass das Paket in der - internen Tabelle für zustandshafte, dynamische Regeln - registriert wird. Danach wird der Aktionsteil der Regel - ausgeführt. Dieser ist Bestandteil der Informationen, die - in die in der Tabelle für dynamische Regeln aufgenommen - wird und lautet skipto rule 500. Die - Regel 500 führt NATs auf die - IP-Adresse des Paketes durch. Danach verlässt das Paket - das LAN nach außen in Richtung des öffentlichen - Internets. Dieser letzte Teil ist für funktionierendes - NAT von entscheidender Bedeutung. Nachdem dieses Paket - am Bestimmungsort angekommen ist, wird dort eine Antwort - generiert und zurückgeschickt. Dieses Paket wird auf die - gleiche Art und Weise durch das gegebene Regelwerk - verarbeitet. Dieses Mal trifft Regel 100 auf das Paket zu, - damit wird die Bestimmungsadresse auf die zugehörige - (lokale) LAN-Adresse (rück-)abgebildet. Danach wird es - von der check-state-Regel verarbeitet, - die Zustandstabelle erkennt, dass eine zugehörige - aktive Sitzung vorliegt und das Paket wird freigegeben - und in das LAN geleitet. Es wird innerhalb des LANs von dem PC, - der die zugehörige Sitzung hält, empfangen, der - ein neues Paket absendet und ein weiteres Datensegment vom - entfernten Server anfordert. Dieses Mal wird bei der - Prüfung der check-state-Regel ein - nach außen gehender zugehöriger Eintrag in der - Zustandstabelle gefunden und die entsprechende Aktion (also - skipto 500) wird ausgeführt. Das - Paket springt zu Regel 500 und wird durch diese Regel für - das öffentliche Internet freigegeben. - - Innerhalb des durch die Firewall geschützten - Netzwerks werden alle eingehenden Pakete, die zu einer - existierenden Sitzung gehören, durch die Regel - check-state sowie entsprechend platzierte - divert natd-Regeln verarbeitet. Die - notwendige Arbeit beschränkt sich darauf, alle - schlechten Pakete zu blockieren und nur - authorisierten Diensten zugehörige Pakete - durchzulassen. In Umkehrung des bisherigen Beispiels nehmen - wir nun, dass auf dem Rechner, auf dem die Firewall läuft, - auch ein Apache Webserver läuft, auf den von außen, - also aus dem öffentlichen Internet, zugegriffen werden - kann. Das erste von außen eintreffende Paket (das auch - eine neue Sitzung startet) erfüllt Regel 100. Die - Zieladresse des Paketes wird daher auf die LAN-Adresse des - Firewallrechners abgebildet. Das Paket wird dann weiter auf - alle in der Firewall definierten Regeln geprüft und trifft - schließlich auf Regel 425. Durch diese Regel werden - zwei Aktionen ausgelösst: Erstens wird aus dem Paket - eine dynamische Regel generiert und in die Zustandstabelle - geschrieben. Zusätzlich wird jedoch die Anzahl neuer - Sitzungsanfragen (von der gleichen Quell-IP-Adresse) auf - 2 begrenzt, um so DoS-Angriffe auf Dienste, - die auf diesem Port laufen, zu verhindern. Die Aktion dieser - Regel ist allow, daher wird das Paket - freigegeben und in das LAN weitergeleitet. Das als Antwort - generierte Paket wird durch die - check-state-Regel als zu einer Sitzung - gehörend erkannt. Damit wird es der Regel 500 - zugeführt, NAT wird durchgeführt - und über die Schnittstelle zum öffentlichen Internet - nach außen geroutet. + # Everything else is denied and logged +$cmd 00999 deny log all from any to any + - Beispiel 1 für einen Regelsatz: + + + <acronym>NAT</acronym> Konfiguration - #!/bin/sh -cmd="ipfw -q add" -skip="skipto 500" -pif=rl0 -ks="keep-state" -good_tcpo="22,25,37,43,53,80,443,110,119" + + + + Chern + Lee + + Beigetragen von + + + -ipfw -q -f flush + + NAT + und IPFW + -$cmd 002 allow all from any to any via xl0 # exclude LAN traffic -$cmd 003 allow all from any to any via lo0 # exclude loopback traffic + &os;s integrierter NAT-Daemon, + &man.natd.8;, arbeitet in Verbindung mit + IPFW, um + Network Address Translation + bereitzustellen. NAT wird verwendet, um + mehreren internen Rechnern, über eine einzige + IP-Adresse, eine gemeinsame Verbindung zum + Internet zu ermöglichen. + + Um dies zu tun, muss der mit dem Internet verbundene + &os;-Rechner als Gateway eingerichtet sein. Das System muss + über zwei Netzwerkschnittstellen verfügen, wobei eine + Schnittstelle mit dem Internet verbunden ist und die andere + mit dem internen Netzwerk. Jeder Rechner im internen Netzwerk + sollte eine RFC + 1918 konforme Adresse zugewiesen bekommen. Zudem + muss das Standard-Gateway der Rechner auf die interne + IP-Adresse des &man.natd.8;-Systems + gesetzt werden. + + Es ist noch ein wenig Konfiguration nötig, um die + NAT-Funktion von + IPFW zu aktivieren. Wenn das + System einen angepassten Kernel hat, muss die + Kernelkonfigurationsdatei die Zeile + option IPDIVERT sowie weitere + IPFIREWALL-Optionen, die in beschrieben sind, + enthalten. + + Um die NAT-Unterstützung beim Booten + zu aktivieren, müssen folgende Einträge in + /etc/rc.conf vorhanden sein: + + gateway_enable="YES" # enables the gateway +natd_enable="YES" # enables NAT +natd_interface="rl0" # specify interface name of NIC attached to Internet +natd_flags="-dynamic -m" # -m = preserve port numbers; additional options are listed in &man.natd.8; -$cmd 100 divert natd ip from any to any in via $pif -$cmd 101 check-state + + Es ist auch möglich eine Konfigurationsdatei zu + verwenden, welche die Optionen enthält, die an + &man.natd.8; übergeben werden: -# Authorized outbound packets -$cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks -$cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks -$cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks -$cmd 130 $skip icmp from any to any out via $pif $ks -$cmd 135 $skip udp from any to any 123 out via $pif $ks + natd_flags="-f /etc/natd.conf" + Die angegebene Datei muss die Konfigurationsoptionen + enthalten, eine Option pro Zeile. Zum Beispiel: -# Deny all inbound traffic from non-routable reserved address spaces -$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP -$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP -$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP -$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback -$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback -$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config -$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs -$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster -$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast + redirect_port tcp 192.168.0.2:6667 6667 +redirect_port tcp 192.168.0.3:80 80 -# Authorized inbound packets -$cmd 400 allow udp from xx.70.207.54 to any 68 in $ks -$cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 + Weitere Informationen zu dieser Konfigurationsdatei + finden Sie in &man.natd.8;. + + Als nächstes werden die NAT-Regeln + hinzugefügt. Wenn die Regeln zustandsorientiert sind, ist die + Platzierung der NAT-Regeln sehr wichtig und + die skipto-Aktion wird verwendet. Dies + erfordert, dass jede Regel über eine eindeutige Nummer + verfügt, um eindeutige Sprungziele zu erhalten. + + Das folgende Beispiel baut auf dem im vorherigen Abschnitt + gezeigten Firewall-Relgelsatz auf. Es werden einige neue + Einträge hinzugefügt und bestehende Regeln modifiziert, um + NAT zu konfigurieren. Zunächst werden + einige Variablen hinzugefügt, darunter Regelnummern, die + keep-state-Option und eine Liste mit + TCP-Ports um die Anzahl der Regeln zu + reduzieren: -$cmd 450 deny log ip from any to any + #!/bin/sh +ipfw -q -f flush +cmd="ipfw -q add" +skip="skipto 500" +pif=dc0 +ks="keep-state" +good_tcpo="22,25,37,53,80,443,110" -# This is skipto location for outbound stateful rules -$cmd 500 divert natd ip from any to any out via $pif -$cmd 510 allow ip from any to any + Die NAT-Regel für eingehende Pakete + wird nach den beiden Regeln, die das + interne Netzwerk und die Loopback-Schnittstelle erlauben und + vor der + check-state-Regel eingefügt. Es ist + wichtig, dass die Nummer der NAT-Regel + (in diesem Beispiel 100) höher ist, als + die beiden vorherigen Regeln und niedriger, als die + check-state-Regel: + + $cmd 005 allow all from any to any via xl0 # exclude LAN traffic +$cmd 010 allow all from any to any via lo0 # exclude loopback traffic +$cmd 100 divert natd ip from any to any in via $pif # NAT any inbound packets +# Allow the packet through if it has an existing entry in the dynamic rules table +$cmd 101 check-state + + Die Regeln für den ausgehenden Verkehr werden ebenfalls + modifiziert, um Aktionen mit der + $skipto-Variable zu erlauben und + anzuzeigen, dass die Prüfung mit der Regel + 500 fortgesetzt wird. Die sieben Regeln + für TCP wurden durch die Regel + 125 ersetzt, da die sieben erlaubten + ausgehenden Ports in der Variable + $good_tcp0 enthalten sind. + + # Authorized outbound packets +$cmd 120 $skip udp from any to x.x.x.x 53 out via $pif $ks +$cmd 121 $skip udp from any to x.x.x.x 67 out via $pif $ks +$cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks +$cmd 130 $skip icmp from any to any out via $pif $ks -######################## end of rules ################## + Die eingehenden Regeln bleiben unverändert, mit Ausnahme + der letzten Regel, in der das + via $pif entfert wird, um ein- und + ausgehende Pakete prüfen zu können. Nach der letzten Regel + für ausgehende Pakete muss die NAT-Regel + folgen. Die Regel muss eine höhere Nummer als die letzte + Regel haben und die Nummer muss über die + skipto-Aktion referenziert werden. In + diesem Regelsatz leitet die Regel mit der Nummer + 500 alle ausgehenden Pakete zur + Weiterverarbeitung an &man.natd.8; weiter. Die darauf + folgende Regel lässt alle von NAT + verarbeiteten Pakete passieren. + + $cmd 499 deny log all from any to any +$cmd 500 divert natd ip from any to any out via $pif # skipto location for outbound stateful rules +$cmd 510 allow ip from any to any + + In diesem Beispiel steuern die Regeln + 100, 101, + 125, 500 und + 510 die Adressübersetzung der ein- und + ausgehende Pakete, so dass immer die private + LAN IP-Adresse in der + dynamische Zustandstabelle registriert werden. + + Nehmen wir beispielsweise einen Web-Browser, der neue + HTTP-Sitzungen über Port 80 aufbaut. Wenn + nun das erste ausgehende Paket von der Firewall geprüft wird, + trifft es nicht auf Regel 100 zu, da das + Paket nach außen geleitet wird und nicht nach innen. Das + Paket trifft auch nicht auf Regel 101 zu, + da es das erste ist und somit noch nicht in der dynamischen + Zustandstabelle enthalten ist. Das Paket entspricht + schließlich Regel 125, da es ausgehend auf + einem erlaubten Port gesendet wird und von einer + IP-Adresse aus dem internen + LAN stammt. Für Pakete, die auf diese + Regel zutreffen, werden zwei Aktionen ausgeführt. Zuerst + wird durch die Aktion keep-state ein + dynamischer Eintrag in der Statustabelle erstellt und die + angegebene Aktion skipto 500 ausgeführt. + Als nächstes durchläuft das Paket NAT und + wird dann an das Internet gesendet. Nachdem dieses Paket am + Webserver angekommen ist, wird dort eine Antwort erzeugt und + zurückgeschickt. Dieses Paket wird wieder von oben nach unten + durch das Regelwerk geprüft. Dieses Mal trifft Regel + 100 auf das Paket zu und die Zieladresse + wird auf die zugehörige (lokale) + LAN-Adresse abgebildet. Danach wird das + Paket von der Regel check-state + verarbeitet. Die Zustandstabelle erkennt, dass eine + zugehörige aktive Sitzung vorliegt und das Paket wird + freigegeben und in das LAN geleitet. + + Für den eingehenden Datenverkehr muss der Regelsatz + unerwünschte Pakete blockieren und Pakete für autorisierte + Dienste durchlassen. Ein Paket, das mit einer Regel für den + eingehenden Datenverkehr übereinstimmt, wird in der + dynamischen Zustandstabelle eingetragen und dann an das + LAN freigegeben. Das Antwortpaket wird + von der Regel check-state als Paket einer + aktiven Sitzung erkannt. Das Paket wird dann von Regel + 500 per NAT + verarbeitet, bevor es über die externe Schnittstelle versendet + wird. - Das folgende Beispiel ist praktisch identisch mit dem ersten - Regelsatz. Allerdings wurden die Regel umfassend kommentiert und - umgeschrieben, damit sie für weniger erfahrene Benutzer - leichter verständlich werden. + + Weiterleitung von Ports - Beispiel 2 für einen Regelsatz: + Der Nachteil von &man.natd.8; ist, dass die Rechner im + LAN nicht aus dem Internet zugänglich + sind. Diese Rechner können zwar ausgehende Verbindungen + zur Außenwelt aufbauen, jedoch keine eingehenden + Verbindungen empfangen. Dies stellt ein Problem dar, wenn + Sie auf einem Rechner im LAN Dienste + anbieten möchten, die aus dem Internet erreichbar sein + sollen. In diesem Fall können Sie die Ports, welche über + das Internet erreichbar sein sollen, über die + &man.natd.8;-Maschine an den Rechner im + LAN weiterleiten. + + Angenommen es gibt einen IRC-Server + auf Rechner A und einen Webserver + auf Rechner B. Damit dies + funktioniert, müssen die Verbindungen auf den Ports 6667 + (IRC) und 80 (HTTP) + an die jeweiligen Rechner weitergeleitet werden. + + Die Syntax für + lautet: + + -redirect_port proto targetIP:targetPORT[-targetPORT] + [aliasIP:]aliasPORT[-aliasPORT] + [remoteIP[:remotePORT[-remotePORT]]] + + Für das obige Beispiel sollten die Argumente wie folgt + aussehen: + + -redirect_port tcp 192.168.0.2:6667 6667 + -redirect_port tcp 192.168.0.3:80 80 + + Damit werden die entsprechenden + TCP-Ports an die Rechner im + LAN weitergeleitet. + + Portbereiche können über + festgelegt werden. Zum Beispiel würde + tcp 192.168.0.2:2000-3000 + 2000-3000 alle Verbindungen auf die Ports + 2000 bis 3000 an die Ports 2000 bis 3000 an + Rechner A weiterleiten. + + Diese Optionen können über + natd_flags="" in + /etc/rc.conf direkt beim Start an + &man.natd.8; übergeben werden. Alternativ können die + Optionen in eine Konfigurationsdatei eingetragen + werden. - #!/bin/sh -################ Start of IPFW rules file ############################### -# Flush out the list before we begin. -ipfw -q -f flush + Weitere Konfigurationsmöglichkeiten sind in + &man.natd.8; beschrieben. + -# Set rules command prefix -cmd="ipfw -q add" -skip="skipto 800" -pif="rl0" # public interface name of NIC - # facing the public Internet + + Weiterleiten von Adressen -################################################################# -# No restrictions on Inside LAN Interface for private network -# Change xl0 to your LAN NIC interface name -################################################################# -$cmd 005 allow all from any to any via xl0 + Das Weiterleiten von Adressen ist nützlich, wenn + mehr als eine IP-Adresse zur Verfügung + steht. Jeder Rechner im LAN kann über + &man.natd.8; seine eigene externe + IP-Adresse zugewiesen bekommen. + &man.natd.8; wird dann den ausgehenden Datenverkehr der + Rechner aus dem LAN mit der + entsprechenden externen IP-Adresse + umschreiben. Auch der eingehenden Datenverkehr über die + externe IP-Adresse wird an die + entsprechenden Rechner im LAN + weitergeleitet. Diese Methode ist auch als + statisches NAT bekannt. Wenn Ihnen + beispielsweise die IP-Adressen + 128.1.1.1, + 128.1.1.2 und + 128.1.1.3 zur + Verfügung stehen, kann 128.1.1.1 als externe + Adresse der &man.natd.8;-Maschine verwendet werden, während + 128.1.1.2 und + 128.1.1.3 an + Rechner A und + Rechner B im LAN + weitergeleitet werden. + + Die Syntax für + lautet: + + -redirect_address localIP publicIP + + + + + + localIP + Die interne IP-Adresse des + Rechners im LAN. + + + + publicIP + Die externe IP-Adresse für + den entsprechenden Rechner im + LAN. + + + + + + Für das obige Beispiel sollten die Argumente wie + folgt aussehen: + + -redirect_address 192.168.0.2 128.1.1.2 +-redirect_address 192.168.0.3 128.1.1.3 + + Genau wie bei , werden + diese Argumente innerhalb der + /etc/rc.conf-Option + natd_flags="" angegeben, oder alternativ + über eine Konfigurationsdatei. Allerdings müssen beim + Weiterleiten von Adressen keine Ports umgeleitet werden, da + der gesamte eingehende Datenverkehr einer bestimmte + IP-Adresse weitergeleitet wird. + + Die externe IP-Adresse der + &man.natd.8;-Maschine muss auf der externen Schnittstelle + aktiv und mit einem Alias versehen sein. Weitere + Einzelheiten sind in &man.natd.8; beschrieben. + + -################################################################# -# No restrictions on Loopback Interface -################################################################# -$cmd 010 allow all from any to any via lo0 + + Das <application>IPFW</application> Kommando -################################################################# -# check if packet is inbound and nat address if it is -################################################################# -$cmd 014 divert natd ip from any to any in via $pif + + ipfw + -################################################################# -# Allow the packet through if it has previous been added to the -# the "dynamic" rules table by a allow keep-state statement. -################################################################# -$cmd 015 check-state + ipfw kann benutzt werden, um einzelne + Regeln im laufenden Betrieb hinzuzufügen oder zu entfernen. + Problematisch ist jedoch, dass diese Änderungen bei einem + Neustart des Systems verloren gehen. Daher ist es + empfehlenswert, eigene Regeln in einer Datei zu definieren + und diese zu laden, um die Regeln der Firewall im laufenden + Betrieb anzupassen. + + ipfw ist auch hilfreich, um die + geladenen Regeln der auf der Konsole auszugeben. + IPFW erzeugt dynamisch einen + Zähler, der jedes Paket, auf das eine Regel zutrifft, zählt. + Dadurch ist es möglich, die Funktion einer Regel zu + überprüfen. -################################################################# -# Interface facing Public Internet (Outbound Section) -# Check session start requests originating from behind the -# firewall on the private network or from this gateway server -# destined for the public Internet. -################################################################# + Eine Auflistung aller geladenen Regeln erhalten Sie + mit: -# Allow out access to my ISP's Domain name server. -# x.x.x.x 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 -$cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state + &prompt.root; ipfw list + Eine Auflistung aller Regeln inklusive des letzten + Treffers erhalten Sie mit: -# Allow out access to my ISP's DHCP server for cable/DSL configurations. -$cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state + &prompt.root; ipfw -t list -# Allow out non-secure standard www function -$cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state + Das nächste Beispiel zeigt Informationen über die Anzahl + der Pakete, die von einer Regel gefiltert wurden sowie die + Regel selbst. Der erste Spalte zeigt die Nummer der + Regel, gefolgt von der Anzahl der gefilterten Pakete + und der Anzahl der Pakete in Bytes. Zum Schluss steht die + Regel selbst: -# Allow out secure www function https over TLS SSL -$cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state + &prompt.root; ipfw -a list -# Allow out send & get email function -$cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state -$cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state + Das folgende Kommando zeigt zusätzlich alle dynamischen + Regeln an: -# Allow out FreeBSD (make install & CVSUP) functions -# Basically give user root "GOD" privileges. -$cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root + &prompt.root; ipfw -d list -# Allow out ping -$cmd 080 $skip icmp from any to any out via $pif keep-state + Um diese Auflistung um die abgelaufenen + Regeln zu erweitern, geben Sie folgendes Kommando ein: -# Allow out Time -$cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state + &prompt.root; ipfw -d -e list -# Allow out nntp news (i.e. news groups) -$cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state + Hiermit werden alle Zähler auf Null zurückgesetzt: -# Allow out secure FTP, Telnet, and SCP -# This function is using SSH (secure shell) -$cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state + &prompt.root; ipfw zero -# Allow out whois -$cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state + Es ist auch möglich, einen spezifischen Zähler + zurückzusetzen: -# Allow ntp time server -$cmd 130 $skip udp from any to any 123 out via $pif keep-state + &prompt.root; ipfw zero NUM -################################################################# -# Interface facing Public Internet (Inbound Section) -# Check packets originating from the public Internet -# destined for this gateway server or the private network. -################################################################# + + Protokollierung von Firewall-Nachrichten -# Deny all inbound traffic from non-routable reserved address spaces -$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP -$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP -$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP -$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback -$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback -$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config -$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs -$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster -$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast + Auch bei aktivierter Protokollierung wird + IPFW von selbst keine Regeln + protokollieren. Der Administrator muss entscheiden, welche + Regeln aus dem Regelwerk protokolliert werden sollen. In + diesen Regeln muss dann das Schlüsselwort + log hinzugefügt werden. Normalerweise + werden nur geblockte Pakete protokolliert. Es ist üblich, + die ipfw default deny everything-Regel am + Ende des Regelwerks mit dem Schlüsselwort + log zu duplizieren. Dadurch ist es + möglich, alle Pakete zu sehen, auf die keine Regel + zutraf. -# Deny ident -$cmd 315 deny tcp from any to any 113 in via $pif + Protokollierung ist allerdings ein zweischneidiges + Schwert. Bei mangelnder Vorsicht oder einem DoS-Angriff + wird die Festplatte mit einer enormen Flut von + Protokolldaten belastet. Protokoll-Nachrichten werden nicht + nur an &man.syslogd.8; geschickt, sondern auch auf der + Konsole angezeigt, was dann schnell lästig werden + kann. -# Deny all Netbios service. 137=name, 138=datagram, 139=session -# Netbios is MS/Windows sharing services. -# Block MS/Windows hosts2 name server requests 81 -$cmd 320 deny tcp from any to any 137 in via $pif -$cmd 321 deny tcp from any to any 138 in via $pif -$cmd 322 deny tcp from any to any 139 in via $pif -$cmd 323 deny tcp from any to any 81 in via $pif + Die Kerneloption + IPFIREWALL_VERBOSE_LIMIT=5 begrenzt die + Anzahl identischer Nachrichten an &man.syslogd.8; für eine + gegebene Regel auf fünf Nachrichten. Ist diese Option im + Kernel aktiviert, wird nach Erreichen den festgelegten + Anzahl die Protokollierung von aufeinanderfolgenden + Nachrichten auf den festgelegten Wert begrenzt, da + beispielsweise die Speicherung von 200 gleichen + Protokoll-Nachrichten sinnlos ist. Daher werden durch + diese Option nur fünf gleichartige Nachrichten + protokolliert. Alle weiteren Nachrichten werden nur gezählt + und deren Gesamtzahl wird schließlich von &man.syslogd.8; + wie folgt ausgegeben: + + Last message repeated 45 times + + Alle protokollierten Pakete werden in der Voreinstellung + in /var/log/security gespeichert. Dies + wird in /etc/syslog.conf + definiert. + -# Deny any late arriving packets -$cmd 330 deny all from any to any frag in via $pif + + Ein Firewall-Regelwerk erstellen -# Deny ACK packets that did not match the dynamic rule table -$cmd 332 deny tcp from any to any established in via $pif + Die meisten fortgeschrittenen + IPFW-Benutzer erzeugen eine + Datei, welche die Regeln für die Firewall enthält, um diese + als Skript ausführen zu können. Der Vorteil einer + derartigen Konfiguration besteht darin, dass dadurch mehrere + Regeln gleichzeitig geändert und aktiviert werden können, + ohne dass dazu das System neu gestartet werden muss. Dies + ist zudem beim Testen von Regeländerungen sehr hilfreich. + Weil es sich bei der Datei um ein Skript handelt, ist es + auch möglich, häufig verwendete Befehle durch Aliase zu + ersetzen und diese dann in mehreren Regeln zu nutzen. + + Die Syntax des folgenden Skripts entspricht der Syntax + von &man.sh.1;, &man.csh.1; sowie &man.tcsh.1;. Felder, die + symbolisch substituiert werden, haben das Präfix $ + (Dollarzeichen). Symbolische Felder haben das + $-Präfix nicht. Der Wert, mit dem das symbolische + Feld belegt wird, muss in doppelten Anführungszeichen + ("") stehen. -# Allow traffic in from ISP's DHCP server. This rule must contain -# the IP address of your ISP's DHCP server as it's 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. -$cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state + Die Datei mit den Regeln könnte wie folgt aufgebaut + sein: -# Allow in standard www function because I have Apache server -$cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 + ############### start of example ipfw rules script ############# +# +ipfw -q -f flush # Delete all rules +# Set defaults +oif="tun0" # out interface +odns="192.0.2.11" # ISP's DNS server IP address +cmd="ipfw -q add " # build rule prefix +ks="keep-state" # just too lazy to key this each time +$cmd 00500 check-state +$cmd 00502 deny all from any to any frag +$cmd 00501 deny tcp from any to any established +$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks +$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks +$cmd 00611 allow udp from any to $odns 53 out via $oif $ks +################### End of example ipfw rules script ############ -# Allow in secure FTP, Telnet, and SCP from public Internet -$cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 + Die Regeln in diesem Beispiel sind nicht wichtig. + Wichtig ist es, zu zeigen, wie die symbolische Substitution + innerhalb der Regeln verwendet wird. + + Wenn dieses Beispiel in + etc/ipfw.rules gespeichert wurde, so + könnten alle Regeln durch die Ausführung des folgenden + Kommandos neu geladen werden: -# Allow in non-secure Telnet session from public Internet -# labeled non-secure because ID & PW are passed over public -# Internet as clear text. -# Delete this sample group if you do not have telnet server enabled. -$cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 + &prompt.root; sh /etc/ipfw.rules -# Reject & Log all unauthorized incoming connections from the public Internet -$cmd 400 deny log all from any to any in via $pif + Anstelle von /etc/ipfw.rules kann + ein beliebig anderer Name oder Speicherort verwendet + werden. -# Reject & Log all unauthorized out going connections to the public Internet -$cmd 450 deny log all from any to any out via $pif + Alternativ können die einzelnen Befehle dieses Skripts + auch von Hand eingegeben werden: -# This is skipto location for outbound stateful rules -$cmd 800 divert natd ip from any to any out via $pif -$cmd 801 allow ip from any to any - -# Everything else is denied by default -# deny and log all packets that fell through to see what they are -$cmd 999 deny log all from any to any -################ End of IPFW rules file ############################### + &prompt.root; ipfw -q -f flush +&prompt.root; ipfw -q add check-state +&prompt.root; ipfw -q add deny all from any to any frag +&prompt.root; ipfw -q add deny tcp from any to any established +&prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state +&prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state +&prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state -