D7084.diff
No OneTemporary
Actions

Size

106 KB

Referenced Files

None

Subscribers

None

D7084.diff
View Options

	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 @@
	<title>IPFW</title>

	<indexterm>
	- <primary>firewall</primary>
	+ <primary>Firewall</primary>

	<secondary>IPFW</secondary>
	</indexterm>

	- <para>Die <emphasis>IPFIREWALL</emphasis>
	- (<acronym>IPFW</acronym>) 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 <quote>Einfache
	- Zustandsgesteuerte Logik</quote>.</para>
	-
	- <para>Die Standardinstallation von IPFW enthält
	- einen beispielhaften Regelsatz
	- (<filename>/etc/rc.firewall</filename> und
	- <filename>/etc/rc.firewall6</filename>). 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.</para>
	-
	- <para>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.</para>
	-
	- <para>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 (<literal>divert</literal>), die
	- auch Network Address Translation (<acronym>NAT</acronym>)
	- unterstützt. Die restlichen Bestandteile dienen verschiedenen
	- fortgeschrittenen Zwecken. Der
	- <foreignphrase>Traffic Shaper</foreignphrase> &man.dummynet.4;
	- gestattet es beispielsweise, den Datenverkehr zu lenken, während
	- die <literal>fwd</literal>-Regel zum Weiterleiten von Datenpaketen
	- dient. Komplettiert wird IPFW durch Funktionen zum
	- Überbrücken von Netzwerkgrenzen
	- (<foreignphrase>Bridge</foreignphrase>-Funktion) sowie
	- <foreignphrase>ipstealth</foreignphrase>, das es gestattet,
	- bridging-Funktionen durchzuführen, ohne dabei das TTL-Feld im
	- IP-Paket zu erhöhen. IPFW unterstützt IPv4 und IPv6.</para>
	+ <para><application>IPFW</application> ist eine
	+ <foreignphrase>Stateful-Firewall</foreignphrase>
	+ für &os;, die sowohl <acronym>IPv4</acronym> als auch
	+ <acronym>IPv6</acronym> unterstützt. Die Firewall setzt sich
	+ aus mehreren Komponenten zusammen: dem Kernel Firewall
	+ Filter-Prozessor mit integriertem Paket-Accounting,
	+ Protokollfunktionen, <acronym>NAT</acronym>, dem
	+ &man.dummynet.4; <foreignphrase>Traffic-Shaper</foreignphrase>,
	+ sowie Weiterleitungs-, Bridge- und ipstealth-Funktionen.</para>
	+
	+ <para>&os; enthält mit <filename>/etc/rc.firewall</filename> ein
	+ Beispielregelwerk, welches mehrere Firewall-Typen für
	+ gebräuchliche Szenarien definiert und unerfahrene Anwender
	+ dabei unterstützen soll, ein geeignetes Regelwerk zu erstellen.
	+ <application>IPFW</application> besitzt eine leistungsstarke
	+ Syntax, mit der erfahrene Benutzer ihre eigenen Regeln
	+ anfertigen können, um den Sicherheitsanforderungen der
	+ jeweiligen Umgebung gerecht zu werden.</para>
	+
	+ <para>Diser Abschnitt beschreibt, wie
	+ <application>IPFW</application> aktiviert wird und bietet einen
	+ Überblick über die Regelsyntax. Zudem werden mehrere Regelsätze
	+ für gebräuchliche Konfigurationsszenarien vorgestellt.</para>

	<sect2 xml:id="firewalls-ipfw-enable">
	- <title>IPFW aktivieren</title>
	+ <title><application>IPFW</application> aktivieren</title>

	<indexterm>
	- <primary>IPFW</primary>
	-
	+ <primary><application>IPFW</application></primary>
	<secondary>aktivieren</secondary>
	</indexterm>

	- <para>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
	- <filename>rc.conf</filename> die Option
	- <varname>firewall_enable="YES"</varname> gesetzt wird. Es ist
	- daher nicht notwendig, IPFW statisch in den Kernel zu
	- kompilieren.</para>
	-
	- <para>Während des Systemstart wird bei gesetzter Option
	- <varname>firewall_enable="YES"</varname> (in der Datei
	- <filename>rc.conf</filename>) folgende Nachricht ausgegeben:</para>
	-
	- <screen>ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled</screen>
	-
	- <para>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 <filename>/etc/sysctl.conf</filename>
	- hinzuzufügen:</para>
	-
	- <programlisting>net.inet.ip.fw.verbose=1
	-net.inet.ip.fw.verbose_limit=5</programlisting>
	- </sect2>
	-
	- <sect2 xml:id="firewalls-ipfw-kernel">
	- <title>Kerneloptionen</title>
	+ <para>Das &os; Basissystem enthält für
	+ <application>IPFW</application> ein ladbares Kernelmodul, was
	+ bedeutet, dass kein angepasster Kernel benötigt wird, um
	+ <application>IPFW</application> zu benutzen.</para>

	<indexterm>
	<primary>Kerneloptionen</primary>
	-
	<secondary>IPFIREWALL</secondary>
	</indexterm>

	<indexterm>
	<primary>Kerneloptionen</primary>
	-
	<secondary>IPFIREWALL_VERBOSE</secondary>
	</indexterm>

	<indexterm>
	<primary>Kerneloptionen</primary>
	-
	<secondary>IPFIREWALL_VERBOSE_LIMIT</secondary>
	</indexterm>

	<indexterm>
	- <primary>IPFW</primary>
	-
	+ <primary><application>IPFW</application></primary>
	<secondary>Kerneloptionen</secondary>
	</indexterm>

	- <para>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.</para>
	-
	- <programlisting>options IPFIREWALL</programlisting>
	-
	- <para>Diese Option aktiviert IPFW als Bestandteil des
	- Kernels.</para>
	-
	- <programlisting>options IPFIREWALL_VERBOSE</programlisting>
	-
	- <para>Diese Option aktiviert die Funktion, alle Pakete, die durch
	- IPFW verarbeitet werden und bei denen das Schlüsselwort
	- <literal>log</literal> gesetzt ist, zu protokollieren.</para>
	-
	- <programlisting>options IPFIREWALL_VERBOSE_LIMIT=5</programlisting>
	-
	- <para>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.</para>
	-
	- <indexterm>
	- <primary>Kerneloptionen</primary>
	-
	- <secondary>IPFIREWALL_DEFAULT_TO_ACCEPT</secondary>
	- </indexterm>
	-
	- <programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT</programlisting>
	-
	- <para>Diese Option erlaubt allen Paketen, die Firewall zu passieren.
	- Diese Einstellung kann beispielsweise bei der ersten Konfiguration
	- der Firewall hilfreich sein.</para>
	-
	- <indexterm>
	- <primary>Kerneloptionen</primary>
	-
	- <secondary>IPDIVERT</secondary>
	- </indexterm>
	-
	- <programlisting>options IPDIVERT</programlisting>
	-
	- <para>Dies aktiviert die Nutzung der
	- <acronym>NAT</acronym>-Funktionalität.</para>
	-
	- <note>
	- <para>Die Firewall wird alle eingehenden oder ausgehenden
	- Pakete blockieren, wenn entweder die Kernel-Option
	- <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> fehlt oder
	- aber keine Regel, die die betreffenden Verbindungen explizit
	- gestattet, existiert. Dies enstpricht im Wesentlichen der
	- Einstellung <quote>default to deny</quote></para>
	- </note>
	- </sect2>
	-
	- <sect2 xml:id="firewalls-ipfw-rc">
	- <title>Optionen in <filename>/etc/rc.conf</filename></title>
	+ <para>Wenn Sie eine statische Unterstützung für
	+ <application>IPFW</application> in den Kernel kompilieren
	+ wollen, lesen Sie <xref linkend="kernelconfig"/>. Folgende
	+ Optionen können in der Kernelkonfigurationsdatei verwendet
	+ werden:</para>

	- <para>Der Eintrag</para>
	+ <programlisting>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</programlisting>
	+
	+ <para>Um <application>IPFW</application> beim Systemstart zu
	+ aktivieren, fügen Sie folgende Zeile in
	+ <filename>/etc/rc.conf</filename> ein:</para>

	<programlisting>firewall_enable="YES"</programlisting>

	- <para>aktiviert die Firewall während des Systemstarts.</para>
	-
	- <para>Die Auswahl einer für &os; verfügbaren Firewall
	- erfolgt durch einen entsprechenden Eintrag in der Datei
	- <filename>/etc/rc.firewall</filename>, durch den der Firewalltyp
	- festgelegt wird.</para>
	+ <para>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:</para>

	<programlisting>firewall_type="open"</programlisting>

	- <para>Konkret sind folgende Einträge erlaubt:</para>
	+ <para>Folgende Profile stehen zur Verfügung:</para>

	<itemizedlist>
	<listitem>
	- <para><literal>open</literal> — gestattet jeglichen
	- Datenverkehr</para>
	+ <para><literal>open</literal>: gestattet jeglichen
	+ Datenverkehr.</para>
	</listitem>

	<listitem>
	- <para><literal>client</literal> — schützt nur die
	- jeweilige Maschine (Client/Mandant)</para>
	+ <para><literal>client</literal>: schützt lediglich diesen
	+ Rechner.</para>
	</listitem>

	<listitem>
	- <para><literal>simple</literal> — schützt das
	- gesamte Netzwerk</para>
	+ <para><literal>simple</literal>: schützt das gesamte
	+ Netzwerk.</para>
	</listitem>

	<listitem>
	- <para><literal>closed</literal> — unterbindet
	- jeglichen IP-Datenverkehr mit Ausnahme des Verkehrs
	- über die Loopback-Schnittstelle.</para>
	+ <para><literal>closed</literal>: blockiert den gesamten
	+ <acronym>IP</acronym>-Datenverkehr, mit Ausnahme des
	+ Verkehrs über die Loopback-Schnittstelle.</para>
	</listitem>

	<listitem>
	- <para><literal>UNKNOWN</literal> — deaktiviert das
	- Laden von Firewallregeln</para>
	+ <para><literal>workstation</literal>: schützt lediglich
	+ diesen Rechner und verwendet zustandsorientierte
	+ Regeln.</para>
	</listitem>

	<listitem>
	- <para><filename>filename</filename>
	- — absoluter Pfad zu einer Datei, in der die
	- Firewallregeln definiert sind</para>
	+ <para><literal>UNKNOWN</literal>: deaktiviert das Laden von
	+ Firewallregeln.</para>
	</listitem>
	- </itemizedlist>
	-
	- <para>Angepasste Regeln für &man.ipfw.8; können auf zwei
	- verschiedene Arten geladen werden. Einerseits kann man durch die
	- Variable <varname>firewall_type</varname> den absoluten Pfad
	- der Datei angeben, welche die <emphasis>Firewallregeln</emphasis>
	- (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:</para>
	-
	- <programlisting>add deny in add deny out</programlisting>
	-
	- <para>Andererseits ist es möglich, den Wert der
	- <varname>firewall_type</varname>-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:</para>
	-
	- <programlisting>#!/bin/sh

	-ipfw -q flush
	+ <listitem>
	+ <para><filename><replaceable>filename</replaceable></filename>:
	+ absoluter Pfad zu einer Datei, in der die Firewallregeln
	+ definiert sind.</para>
	+ </listitem>
	+ </itemizedlist>

	-ipfw add deny in
	-ipfw add deny out</programlisting>
	+ <para>Wenn Sie <literal>firewall_type</literal> auf
	+ <literal>client</literal> oder <literal>simple</literal>
	+ setzen, müssen Sie die voreingestellten Regeln in
	+ <filename>/etc/rc.firewall</filename> anpassen, damit sie
	+ der Konfiguration des Systems entsprechen.</para>
	+
	+ <para>Beachten Sie, dass das Profil <literal>filename</literal>
	+ verwendet wird, um ein benutzerdefiniertes Regelwerk zu
	+ laden.</para>
	+
	+ <para>Eine alternative Möglichkeit, um ein benutzerdefiniertes
	+ Regelwerk zu laden, bietet die Variable
	+ <literal>firewall_script</literal>. Setzen Sie die Variable
	+ auf den absoluten Pfad eines
	+ <emphasis>ausführbaren Skripts</emphasis>, welches die Befehle
	+ für <application>IPFW</application> enthält. Die Beispiele in
	+ diesem Abschnitt gehen davon aus, dass
	+ <literal>firewall_script</literal> auf
	+ <filename>/etc/ipfw.rules</filename> gesetzt ist.</para>

	- <note>
	- <para>Wenn die Variable <varname>firewall_type</varname>
	- entweder auf <literal>client</literal> oder
	- <literal>simple</literal> gesetzt ist, sollten die
	- Standardregeln in der Datei
	- <filename>/etc/rc.firewall</filename> geprüft und an die
	- Konfiguration der gegebenen Maschine angepasst werden. Beachten
	- Sie dabei bitte, dass die Beispiele dieses Kapitels davon
	- ausgehen, dass das <varname>firewall_script</varname> auf
	- <filename>/etc/ipfw.rules</filename> gesetzt ist.</para>
	- </note>
	+ <programlisting>firewall_script="/etc/ipfw.rules"</programlisting>

	- <para>Das Logging wird durch folgenden Eintrag aktiviert:</para>
	+ <para>Die Protokollierung wird mit diesem Eintrag
	+ aktiviert:</para>

	<programlisting>firewall_logging="YES"</programlisting>

	- <warning>
	- <para>Die Variable <varname>firewall_logging</varname> definiert
	- lediglich die sysctl-Variable als
	- <varname>net.inet.ip.fw.verbose = 1</varname> (lesen Sie dazu
	- bitte auch den Abschnitt <xref linkend="firewalls-ipfw-enable"/>
	- des Handbuchs). Es gibt keine
	- <filename>rc.conf</filename>-Variable, mit der man
	- Protokollierungsschwellen setzen könnte. Dies kann
	- lediglich über &man.sysctl.8; geschehen, wobei Sie in
	- der Datei <filename>/etc/sysctl.conf</filename> nur
	- Werte > 1 angeben sollten:</para>
	-
	- <programlisting>net.inet.ip.fw.verbose_limit=5</programlisting>
	- </warning>
	-
	- <para>Sollte Ihre Maschinen als Gateway fungieren (also mittels
	- &man.natd.8; <foreignphrase>Network Address
	- Translation</foreignphrase> (<acronym>NAT</acronym>)
	- durchführen), finden Sie weitere Optionen in
	- <filename>/etc/rc.conf</filename>.</para>
	- </sect2>
	-
	- <sect2 xml:id="firewalls-ipfw-cmd">
	- <title>Der Befehl IPFW</title>
	-
	- <indexterm><primary><command>ipfw</command></primary></indexterm>
	+ <para>Es existiert keine Variable für
	+ <filename>/etc/rc.conf</filename>, um die Protokollierung zu
	+ begrenzen. Um die Anzahl der Protokoll-Nachrichten pro
	+ Verbindungsversuch zu begrenzen, legen Sie die Anzahl der
	+ Einträge in <filename>/etc/sysctl.conf</filename> fest:</para>
	+
	+ <programlisting>net.inet.ip.fw.verbose_limit=5</programlisting>
	+
	+ <para>Nachdem Sie die Änderungen gespeichert haben, können Sie
	+ die Firewall starten. Um auch die Anzahl der
	+ Protokoll-Nachrichten zu konfigurieren, setzen Sie mit
	+ <command>sysctl</command> den gewünschten Wert:</para>

	- <para>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.</para>
	-
	- <para>&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.</para>
	-
	- <para>Eine sequentielle Liste aller Regeln erhalten Sie mit:</para>
	-
	- <screen>&prompt.root; <userinput>ipfw list</userinput></screen>
	-
	- <para>Eine Liste aller Regeln inklusive des letzten Treffers
	- erhalten Sie durch den folgenden Befehl:</para>
	-
	- <screen>&prompt.root; <userinput>ipfw -t list</userinput></screen>
	-
	- <para>Um eine Liste aller Regeln inklusive der Anzahl der Pakete, die
	- von einer Regel gefiltert wurden, zu erhalten, geben Sie
	- den folgenden Befehl ein:</para>
	-
	- <screen>&prompt.root; <userinput>ipfw -a list</userinput></screen>
	-
	- <para>Eine Liste, die zusätzlich allen dynamischen Regeln
	- enthält, erhalten Sie mit:</para>
	-
	- <screen>&prompt.root; <userinput>ipfw -d list</userinput></screen>
	-
	- <para>Um diese Liste um alle <quote>abgelaufenen</quote> Regeln zu
	- erweitern, ädern Sie diesen Befehl wie folgt ab:</para>
	-
	- <screen>&prompt.root; <userinput>ipfw -d -e list</userinput></screen>
	-
	- <para>Alle Zähler auf Null zurücksetzen:</para>
	-
	- <screen>&prompt.root; <userinput>ipfw zero</userinput></screen>
	-
	- <para>Es ist auch möglich, einen spezifischen Zähler
	- auszuwählen und zurückzusetzen:</para>
	-
	- <screen>&prompt.root; <userinput>ipfw zero NUM</userinput></screen>
	+ <screen>&prompt.root; <userinput>service firewall start</userinput>
	+&prompt.root; <userinput>sysctl net.inet.ip.fw.verbose_limit=<replaceable>5</replaceable></userinput></screen>
	</sect2>

	<sect2 xml:id="firewalls-ipfw-rules">
	- <title>IPFW-Regeln</title>
	-
	- <para>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
	- <acronym>TCP/IP</acronym>-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.</para>
	-
	- <indexterm>
	- <primary>IPFW</primary>
	-
	- <secondary>rule processing order</secondary>
	- </indexterm>
	-
	- <!-- Needs rewording to include note below -->
	+ <title><application>IPFW</application> Regel-Syntax</title>

	<para>Wenn ein Paket die Firewall <quote>betritt</quote>, 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 <quote>erster
	- Treffer gewinnt</quote> bezeichnet. Falls keine Regel auf
	+ Treffer gewinnt</quote> 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.</para>
	-
	- <note>
	- <para>Die Prüfung der Regeln wird nach Treffern von mit
	- <literal>count</literal>, <literal>skipto</literal> und
	- <literal>tee</literal> parametrisierten Regeln ungeachtet
	- des <quote>erster Treffer gewinnt</quote>-Prinzips weiter
	- fortgeführt.</para>
	- </note>
	-
	- <para>Die Anweisungen basieren auf der Nutzung von Regeln
	- mit den zustandsgesteuerten Optionen <literal>keep</literal>,
	- <literal>state</literal>, <literal>limit</literal>,
	- <literal>in</literal> und <literal>out</literal>. Diese
	- bilden die Basis für die Spezifikation von
	- Firewallregeln.</para>
	-
	- <warning>
	- <para>Bei der Arbeit mit Firewallregeln ist Vorsicht geboten.
	- Es ist sehr einfach, sich selbst auszuschließen.</para>
	- </warning>
	-
	- <sect3 xml:id="firewalls-ipfw-rules-syntax">
	- <title>Syntax der Firewallregeln</title>
	-
	- <indexterm>
	- <primary>IPFW</primary>
	-
	- <secondary>rule syntax</secondary>
	- </indexterm>
	-
	- <para>Mit der in diesem Abschnitt dargestellten Syntax der
	- Regeln kann ein Standardregelsatz für eine
	- <quote>einschließende</quote> Firewall erstellt
	- werden. Für eine vollständige Beschreibung der
	- Regelsyntax lesen Sie bitte die Manualpage &man.ipfw.8;</para>
	-
	- <para>Regelausdrücke werden <quote>von links nach
	- rechts</quote> 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.</para>
	-
	- <para>Kommentare sind mit einen führenden Doppelkreuz
	- (<literal>#</literal>) ausgezeichnet. Sie können am
	- Ende einer Regel oder in einzelnen, separaten Zeilen stehen.
	- Leerzeilen werden ignoriert.</para>
	-
	- <para><replaceable>CMD RULE_NUMBER ACTION LOGGING SELECTION
	- STATEFUL</replaceable></para>
	-
	- <sect4>
	- <title>CMD</title>
	-
	- <para>Jede neue Regel benötigt das Präfix
	- <literal>add</literal>, um die Regel der internen
	- Tabelle hinzuzfügen.</para>
	- </sect4>
	-
	- <sect4>
	- <title>RULE_NUMBER</title>
	-
	- <para>Zu jeder Regel gehört eine Regelnummer zwischen 1
	- und 65535.</para>
	- </sect4>
	-
	- <sect4>
	- <title>ACTION</title>
	-
	- <para>Eine Regel kann mit einer der vier folgenden Aktionen
	- verbunden sein, die ausgeführt werden, wenn ein Paket
	- den Selektionskriterien der Regel entspricht.</para>
	-
	- <para><parameter>allow \| accept \| pass \| permit</parameter></para>
	-
	- <para>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.</para>
	-
	- <para><parameter>check-state</parameter></para>
	-
	- <para>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
	- <literal>check-state</literal>-Regel selbst hat kein
	- Selektionskriterium. Sollte eine
	- <literal>check-state</literal>-Regel im Regelwerk fehlen,
	- wird gegen die erste <literal>keep-state</literal>- oder
	- <literal>limit</literal>-Regel in den dynamischen Regeln
	- geprüft.</para>
	-
	- <para><parameter>deny \| drop</parameter></para>
	-
	- <para>Beide Schlüsselworte bewirken dieselbe Aktion:
	- Ein Paket, dass die Selektionskriterien der Regel
	- erfüllt, wird verworfen und die Regelprüfung
	- wird beendet.</para>
	- </sect4>
	-
	- <sect4>
	- <title>Protokollierung</title>
	-
	- <para><parameter>log</parameter> oder
	- <parameter>logamount</parameter></para>
	+ <application>IPFW</application>-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 <literal>count</literal>,
	+ <literal>skipto</literal> oder <literal>tee</literal>
	+ 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;.</para>

	- <para>Erfüllt ein Paket die Selektionskriterien mit dem
	- Schlüsselwort <literal>log</literal>, 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
	- <literal>logamount</literal>-Parameter definierte
	- Schwelle nicht übersteigt. Ist der Parameter
	- <literal>logamount</literal> nicht definiert, wird diese
	- Grenze aus der <command>sysctl</command>-Variable
	- <varname>net.inet.ip.fw.verbose_limit</varname> ermittelt.
	- Ist einer dieser beiden Werte auf <quote>Null</quote>
	- 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 <command>ipfw reset log</command>).</para>
	-
	- <note>
	- <para>Die Protokollierung findet statt, nachdem alle
	- Paketselektionskriterien geprüft und bevor die
	- daraus folgende, endgültige Aktion
	- (<literal>accept</literal> oder <literal>deny</literal>)
	- auf das Paket ausgeführt wird. Die Entscheidung,
	- welche Regel protokolliert werden soll, bleibt Ihnen
	- überlassen.</para>
	- </note>
	- </sect4>
	-
	- <sect4>
	- <title>Selektion</title>
	-
	- <para>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.</para>
	-
	- <para><parameter>udp \| tcp \| icmp</parameter></para>
	-
	- <para>Weitere in <filename>/etc/protocols</filename>
	- 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.</para>
	-
	- <para><parameter>from src to dst</parameter></para>
	-
	- <para>Die Schlüsselwörter <literal>from</literal>
	- und <literal>to</literal> beziehen sich auf IP-Adressen und
	- definieren sowohl Ursprungs- als auch Zieladresse einer
	- Datenverbindung. Firewallregeln müssen Parameter
	- für den Ursprung <emphasis>und</emphasis> das Ziel
	- enthalten. Das Schlüsselwort <literal>any</literal>
	- steht für beliebige IP-Adressen. Bei
	- <literal>me</literal> 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
	- <literal>from me to any</literal>,
	- <literal>from any to me</literal>,
	- <literal>from 0.0.0.0/0 to any </literal>,
	- <literal>from any to 0.0.0.0/0</literal>,
	- <literal>from 0.0.0.0 to any</literal>,
	- <literal>from any to 0.0.0.0</literal> oder
	- <literal>from me to 0.0.0.0</literal>. IP-Adressen werden
	- entweder in <acronym>CIDR</acronym>-Notation
	- oder durch Punkte getrennt mit Suffixen
	- (<systemitem class="ipaddress">192.168.2.101/24</systemitem>) für
	- die Netzmaske oder als einzelne numerische, durch Punkte
	- getrennte Adressen
	- (<systemitem class="ipaddress">192.168.2.101</systemitem>) angegeben.
	- Die dafür notwendigen Berechnungen erleichtert der
	- Port <package>net-mgmt/ipcalc</package>.
	- Weiterführende Informationen finden sich auf
	- <uri xlink:href="http://jodies.de/ipcalc">http://jodies.de/ipcalc</uri>.</para>
	-
	- <para><parameter>port number</parameter></para>
	-
	- <para>Bei der Verarbeitung von Protokollen wie
	- <acronym>TCP</acronym> oder <acronym>UDP</acronym>, die
	- Portnummern verwenden, muss die Portnummer des
	- betreffenden Dienstes angegeben werden. Anstelle der
	- Portnummer kann auch der in der Datei
	- <filename>/etc/services</filename> definierte Name des
	- Dienstes angegeben werden.</para>
	-
	- <para><parameter>in \| out</parameter></para>
	-
	- <para>Diese Schlüsselwörter beziehen sich auf die
	- Richtung des Datenverkehrs. Jede Regel
	- <emphasis>muss</emphasis> eines dieser beiden
	- Schlüsselwörter enthalten.</para>
	-
	- <para><parameter>via IF</parameter></para>
	-
	- <para>Eine Regel mit dem Schlüsselwort
	- <literal>via IF</literal> betrifft nur Pakete, die über
	- die angegebene Schnittstellte geroutet werden (ersetzen Sie
	- <literal>IF</literal> durch den Namen Ihrer
	- Netzwerkschnittstelle). Die Angabe des
	- Schlüsselwortes <literal>via</literal> bewirkt, dass
	- die Netzwerkschnittstelle in die Regelprüfung
	- aufgenommen wird.</para>
	-
	- <para><parameter>setup</parameter></para>
	-
	- <para>Dieses obligatorische Schlüsselwort bezeichnet
	- die Anforderung des Sitzungsstarts für
	- <acronym>TCP</acronym>-Pakete.</para>
	-
	- <para><parameter>keep-state</parameter></para>
	-
	- <para>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.</para>
	-
	- <para><parameter>limit {src-addr \| src-port \| dst-addr \|
	- dst-port}</parameter></para>
	-
	- <para>Wird das Schlüsselwort <literal>limit</literal>
	- verwendet, sind nur <literal>N</literal> 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 <literal>limit</literal>
	- und <literal>keep-state</literal> können nicht in
	- derselben Regel verwendet werden. Die Option
	- <literal>limit</literal> bewirkt dieselbe Zustandsteuerung
	- wie die Option <literal>keep-state</literal>, erweitert
	- diese jedoch um eigene Regeln.</para>
	- </sect4>
	- </sect3>
	-
	- <sect3>
	- <title>Optionen für zustandsgesteuerte Regeln</title>
	-
	- <indexterm>
	- <primary>IPFW</primary>
	-
	- <secondary>stateful filtering</secondary>
	- </indexterm>
	-
	- <!-- XXX: duplicated -->
	-
	- <para>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 <quote>Betrüger</quote>
	- abgelehnt.</para>
	-
	- <para>Die <literal>check-state</literal>-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.</para>
	-
	- <para>Dynamische Regeln sind für einem sogenannten
	- <foreignphrase>SYN-flood</foreignphrase>-Angriff anfällig,
	- bei dem eine riesige Anzahl <quote>schwebender</quote>
	- dynamischer Regelprüfungungsinstanzen erzeugt wird. Um
	- einem solchen Angriff zu begegnen, wurde in &os; die neue
	- Option <literal>limit</literal> 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
	- <literal>limit</literal> definierten Schwellenwert, wird
	- das Paket verworfen.</para>
	- </sect3>
	-
	- <sect3>
	- <title>Protokollierung von Firewall-Nachrichten</title>
	-
	- <indexterm>
	- <primary>IPFW</primary>
	-
	- <secondary>logging</secondary>
	- </indexterm>
	-
	- <para>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.</para>
	-
	- <para>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
	- <literal>log</literal> für diese Regeln aktiviert. Im
	- Regelfall werden nur <literal>deny</literal>-Regeln
	- protokolliert, beispielsweise die <literal>deny</literal>-Regel
	- für eintreffende <acronym>ICMP</acronym>-Nachrichten.
	- Üblicherweise wird die <quote>ipfw default deny
	- everything</quote>-Regel doppelt angelegt. Einmal mit und
	- einmal ohne aktivierte Option <literal>log</literal>. Dadurch
	- erhält man eine Auflistung aller Pakete, auf die keine
	- Regel zutraf.</para>
	-
	- <para>Protokollierung ist allerdings ein zweischneidiges
	- Schwert, bei mangelnder Vorsicht wird man mit einer enormen
	- Flut von Protokollierungsdaten förmlich
	- <emphasis>überschwemmt</emphasis> 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.</para>
	-
	- <para>Die Kerneloption
	- <varname>IPFIREWALL_VERBOSE_LIMIT=5</varname> 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:</para>
	-
	- <programlisting>last message repeated 45 times</programlisting>
	-
	- <para>Alle protokollierten Nachrichten für Datenpakete
	- werden in der Voreinstellung in die Datei
	- <filename>/var/log/security</filename> (die in der Datei
	- <filename>/etc/syslog.conf</filename> definiert wird),
	- geschrieben.</para>
	- </sect3>
	-
	- <sect3 xml:id="Firewalls-ipfw-rules-script">
	- <title>Skripte zur Regeldefinition erstellen</title>
	-
	- <para>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.</para>
	-
	- <para>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
	- &dollar; (das Dollarzeichen). Symbolische Felder haben dieses
	- &dollar;-Praefix nicht. Der Wert, mit dem das symbolische
	- Feld belegt wird, muss in
	- <quote>doppelten Anführungszeichen</quote>
	- eingeschlossen sein.</para>
	-
	- <para>Beginnen Sie Ihre Regeldatei wie folgt:</para>
	-
	- <programlisting>############### 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
	-&dollar;cmd 00500 check-state
	-&dollar;cmd 00502 deny all from any to any frag
	-&dollar;cmd 00501 deny tcp from any to any established
	-&dollar;cmd 00600 allow tcp from any to any 80 out via &dollar;oif setup &dollar;ks
	-&dollar;cmd 00610 allow tcp from any to &dollar;odns 53 out via &dollar;oif setup &dollar;ks
	-&dollar;cmd 00611 allow udp from any to &dollar;odns 53 out via &dollar;oif &dollar;ks
	-################### End of example ipfw rules script ############</programlisting>
	-
	- <para>Die Regeln in diesem Beispiel sind nicht wichtig. Wichtig
	- ist es, zu zeigen, wie die symbolische Substitution innerhalb
	- der Regeln verwendet wird.</para>
	-
	- <para>Wurde dieses Beispiel in der Datei
	- <filename>/etc/ipfw.rules</filename> gespeichert, so können
	- alle Regeln durch die Ausführung des folgenden Befehls
	- neu geladen werden:</para>
	+ <indexterm>
	+ <primary><application>IPFW</application></primary>
	+ <secondary>Regel-Syntax</secondary>
	+ </indexterm>

	- <screen>&prompt.root; <userinput>sh /etc/ipfw.rules</userinput></screen>
	+ <para>Bei der Erstellung der
	+ <application>IPFW</application>-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 <literal>#</literal> wird benutzt, um
	+ einen Kommentar einzuleiten und kann am Ende einer Regel oder
	+ in einer eigenen Zeile stehen. Leerzeilen werden
	+ ignoriert.</para>
	+
	+ <para><replaceable>CMD RULE_NUMBER set SET_NUMBER ACTION log
	+ LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT
	+ OPTIONS</replaceable></para>
	+
	+ <para>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
	+ <application>IPFW</application>-Regeln zu erstellen, finden
	+ Sie in &man.ipfw.8;.</para>

	- <para>Statt <filename>/etc/ipfw.rules</filename> können Sie
	- auch einen beliebigen anderen Namen und/oder Speicherort
	- verwenden.</para>
	+ <variablelist>
	+ <varlistentry>
	+ <term>CMD</term>
	+ <listitem>
	+ <para>Jede Regel muss mit <parameter>ipfw add</parameter>
	+ beginnen.</para>
	+ </listitem>
	+ </varlistentry>

	- <para>Alternativ könnten Sie die einzelnen Befehle dieses
	- Skripts auch manuell starten:</para>
	+ <varlistentry>
	+ <term>RULE_NUMBER</term>
	+ <listitem>
	+ <para>Jede Regel gehört zu einer Nummer zwischen
	+ <literal>1</literal> und <literal>65534</literal>. 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.</para>
	+ </listitem>
	+ </varlistentry>

	- <screen>&prompt.root; <userinput>ipfw -q -f flush</userinput>
	-&prompt.root; <userinput>ipfw -q add check-state</userinput>
	-&prompt.root; <userinput>ipfw -q add deny all from any to any frag</userinput>
	-&prompt.root; <userinput>ipfw -q add deny tcp from any to any established</userinput>
	-&prompt.root; <userinput>ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state</userinput>
	-&prompt.root; <userinput>ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state</userinput>
	-&prompt.root; <userinput>ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state</userinput></screen>
	- </sect3>
	+ <varlistentry>
	+ <term>SET_NUMBER</term>
	+ <listitem>
	+ <para>Jede Regel ist einer <emphasis>Set</emphasis>-Nummer
	+ zwischen <literal>0</literal> und <literal>31</literal>
	+ 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
	+ <literal>SET_NUMBER</literal> nicht angegeben ist, wird
	+ die Regel zu Set <literal>0</literal>
	+ hinzugefügt.</para>
	+ </listitem>
	+ </varlistentry>

	- <sect3>
	- <title>Zustandsgesteuertes Regelwerk</title>
	+ <varlistentry>
	+ <term>ACTION</term>
	+ <listitem>
	+ <para>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.</para>
	+
	+ <para><parameter>allow \| accept \| pass \|
	+ permit</parameter>: All diese Aktionen sind
	+ gleichbedeutend und erlauben Pakete, die mit der Regel
	+ übereinstimmen.</para>
	+
	+ <para><parameter>check-state</parameter>: 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 <literal>check-state</literal> hat selbst kein
	+ Selektionskriterium. Sollte keine
	+ <literal>check-state</literal>-Regel im Regelwerk
	+ vorhanden sein, wird die dynamische Zustandstabelle beim
	+ ersten Vorkommen einer <literal>keep-state</literal>-
	+ oder <literal>limit</literal>-Regel überprüft.</para>
	+
	+ <para><parameter>count</parameter>: Aktualisiert die
	+ Zähler für alle Pakete, die mit dieser Regel
	+ übereinstimmen. Die Prüfung wird mit der nächsten Regel
	+ fortgesetzt.</para>
	+
	+ <para><parameter>deny \| drop</parameter>: Diese Aktionen
	+ sind gleichbedeutend und verwerfen Pakete, die mit
	+ dieser Regel übereinstimmen.</para>

	- <para>Das folgende Regelwerk (ohne
	- <acronym>NAT</acronym>-Funktionalität) ist ein Beispiel
	- dafür, wie man eine sehr sichere
	- <quote>einschließende</quote> 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.</para>
	-
	- <para>Alle unixoiden Betriebssysteme (aber auch solche, die
	- Konzepte aus &unix; implementieren), darunter auch &os;,
	- verwenden die Schnittstelle <filename>lo0</filename> mit
	- der IP-Adresse <systemitem class="ipaddress">127.0.0.1</systemitem> 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.</para>
	-
	- <para>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
	- <acronym>PPP</acronym>/<filename>tun0</filename> oder
	- die Netzwerkkarte handelt, über, die mit Ihrem
	- <acronym>DSL</acronym>- oder Kabelmodem verbunden
	- ist.</para>
	-
	- <para>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.</para>
	-
	- <para>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.</para>
	-
	- <para>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.</para>
	-
	- <para>Der Abschnitt für den ausgehenden Datenverkehr des
	- folgenden Beispiels enthät nur
	- <literal>allow</literal>)-Regeln, in denen der Dienst, dem
	- der Zugriff auf das öffentliche Internet gewährt
	- wird, eindeutig definiert ist. Alle Regeln verwenden die
	- Optionen <literal>proto</literal>, <literal>port</literal>,
	- <literal>in/out</literal>, <literal>via</literal> sowie
	- <literal>keep state</literal> kodiert. Die
	- Regeln mit <literal>proto tcp</literal> verwenden
	- zusätzlich die Option <literal>setup</literal>, damit
	- die initiale, eine Sitzung beginnende Anfrage identifiziert
	- werden kann, damit die die Zustandsttabelle gefüllt
	- werden kann.</para>
	-
	- <para>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 <literal>allow</literal>-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.</para>
	-
	- <para>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
	- <filename>/etc/services</filename> identifiziert werden.
	- Alternativ kann eine Anfrage an <uri xlink:href="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers">http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers</uri>
	- Klarheit über die Aufgabe/Funktion einer bestimmten Portnummer
	- bringen. Auf der Seite <uri xlink:href="http://www.sans.org/security-resources/idfaq/oddports.php">http://www.sans.org/security-resources/idfaq/oddports.php</uri>
	- kann man Information über bekannte Trojaner und von
	- diesen verwendete Portnummern erhalten.</para>
	- </sect3>
	+ <para>Es stehen noch weitere Aktionen zur Verfügung.
	+ Einzelheiten finden Sie in &man.ipfw.8;.</para>
	+ </listitem>
	+ </varlistentry>

	- <sect3>
	- <title>Ein Beispiel für einschließende
	- Regeln</title>
	+ <varlistentry>
	+ <term>LOG_AMOUNT</term>
	+ <listitem>
	+ <para>Erfüllt ein Paket die Selektionskriterien mit dem
	+ Schlüsselwort <literal>log</literal>, wird dies von
	+ &man.syslogd.8; mit der Annotation
	+ <literal>SECURITY</literal> protokolliert. Dies erfolgt
	+ allerdings nur, wenn die Anzahl der protokollierten
	+ Pakete der betreffenden Regel die definierte
	+ <literal>LOG_AMOUNT</literal>-Grenze nicht übersteigt.
	+ Wenn <literal>LOG_AMOUNT</literal> nicht definiert ist,
	+ wird die Grenze aus dem Wert von
	+ <varname>net.inet.ip.fw.verbose_limit</varname>
	+ benutzt. Ein Wert von <literal>0</literal> 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 <command>ipfw resetlog</command>
	+ zurücksetzen.</para>
	+
	+ <note>
	+ <para>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.</para>
	+ </note>
	+ </listitem>
	+ </varlistentry>

	- <para>Das folgende Regelwerk (ohne
	- <acronym>NAT</acronym>-Funktionalität) beschreibt ein
	- vollständiges, einschließendes Regelwerk. Dieses
	- Regelwerk kann direkt auf Ihren eigenen Systemen eingesetzt
	- werden, wenn alle <literal>pass</literal>-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
	- <literal>deny</literal> deaktivieren. Die im Beispiel
	- verwendete Netzwerkschnittstelle <filename>dc0</filename>
	- müssen Sie durch die auf Ihrem System für
	- ausgehenden Datenverkehr vorgesehenen Netzwerkschnittstelle
	- ersetzen. Im Falle von benutzergesteuertem
	- <acronym>PPP</acronym>s wäre dies
	- beispielsweise <filename>tun0</filename>.</para>
	+ <varlistentry>
	+ <term>PROTO</term>
	+ <listitem>
	+ <para>Dieser optionale Wert wird verwendet, um einen
	+ beliebigen Protokollnamen oder -nummer aus
	+ <filename>/etc/protocols</filename> gegen das Paket zu
	+ prüfen.</para>
	+ </listitem>
	+ </varlistentry>

	- <para>Alle Regeln folgen einem bestimmten Muster.</para>
	+ <varlistentry>
	+ <term>SRC</term>
	+ <listitem>
	+ <para>Nach dem Schlüsslwort<literal>from</literal> muss
	+ die Quelladresse stehen, oder ein Schlüsselwort, das die
	+ Quelladresse darstellt. Eine Adresse wird dargestellt
	+ duch <literal>any</literal>, <literal>me</literal> (jede
	+ Adresse dieses Systems), <literal>me6</literal> (jede
	+ <acronym>IPv6</acronym>-Adresse dieses Systems), oder
	+ <literal>table</literal> gefolgt von der Nummer der
	+ Tabelle, welche die Adressen enthält.
	+ <acronym>IP</acronym>-Adressen können in
	+ <acronym>CIDR</acronym>-Notation geschrieben werden.
	+ Beispielsweise <literal>1.2.3.4/25</literal> oder
	+ <literal>1.2.3.4:255.255.255.128</literal>.</para>
	+ </listitem>
	+ </varlistentry>

	- <itemizedlist>
	+ <varlistentry>
	+ <term>SRC_PORT</term>
	<listitem>
	- <para>Alle Ausdrücke, die eine Anfrage zum Beginn
	- einer zustandsgesteuerten darstellen, beinhalten den
	- Ausdruck <literal>keep-state</literal>.</para>
	+ <para>Optional kann ein Quellport über eine Nummer oder
	+ einen Namen aus <filename>/etc/services</filename>
	+ spezifiziert werden.</para>
	</listitem>
	+ </varlistentry>

	+ <varlistentry>
	+ <term>DST</term>
	<listitem>
	- <para>Alle Dienste aus dem öffentlichen Internet
	- beinhalten die Option <literal>limit</literal>, um
	- gegebenenfalls
	- <foreignphrase>flooding</foreignphrase> zu
	- unterbinden.</para>
	+ <para>Nach dem Schlüsselwort <literal>to</literal> 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.</para>
	</listitem>
	+ </varlistentry>

	+ <varlistentry>
	+ <term>DST_PORT</term>
	<listitem>
	- <para>Alle Regeln bezeichnen die Richtung durch der
	- Ausdrücke <literal>in</literal> oder
	- <literal>out</literal>.</para>
	+ <para>Optional kann ein Zielport über eine Nummer oder
	+ einen Namen aus <filename>/etc/services</filename>
	+ spezifiziert werden.</para>
	</listitem>
	+ </varlistentry>

	+ <varlistentry>
	+ <term>OPTIONS</term>
	<listitem>
	- <para>Alle Regeln legen die verwendete
	- Netzwerkschnittstelle die Ausdrücke
	- <literal>via</literal> und
	- <replaceable>interface-name</replaceable> fest.</para>
	+ <para>Nach der Quell- und Zieladresse können noch weitere
	+ Optionen angegeben werden. Wie der Name bereits sagt,
	+ sind <literal>OPTIONS</literal> optional. Häufig
	+ verwendete Optionen sind <literal>in</literal> oder
	+ <literal>out</literal>, mit denen die Richtug des
	+ Pakets bestimmt wird, <literal>icmptypes</literal>
	+ gefolgt vom Typ der <acronym>ICMP</acronym>-Nachricht,
	+ sowie <literal>keep-state</literal>.</para>
	+
	+ <para>Wenn ein Paket auf eine
	+ <parameter>keep-state</parameter>-Regel zutrifft, wird
	+ die Firewall eine dynamische Regel erstellen, die dem
	+ bidirektionalen Datenverkehr zwischen den gleichen
	+ Quell- und Zieladressen mit dem gleichen Protokoll
	+ entspricht.</para>
	+
	+ <para>Dynamische Regeln sind für einen sogenannten
	+ <foreignphrase>SYN-flood</foreignphrase>-Angriff
	+ anfällig, bei dem eine riesige Anzahl an dynamischen
	+ Regeln erzeugt wird. Verwenden Sie die Option
	+ <literal>limit</literal>, 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 <literal>limit</literal>
	+ definierten Wert, wird das Paket verworfen.</para>
	+
	+ <para>Es stehen noch viele weitere Optionen zur Verfügung.
	+ &man.ipfw.8; enthält eine Beschreibung der einzelnen
	+ Optionen.</para>
	</listitem>
	- </itemizedlist>
	+ </varlistentry>
	+ </variablelist>
	+ </sect2>

	- <para>Die folgenden Regeln werden in der Datei
	- <filename>/etc/ipfw.rules</filename> definiert.</para>
	+ <sect2>
	+ <title>Beispiel für einen Regelsatz</title>
	+
	+ <para>Dieser Abschnitt die Erstellung eines Firewall-Skripts
	+ namens <filename>/etc/ipfw.rules</filename> mit
	+ zustandsorientierten (<foreignphrase>stateful</foreignphrase>
	+ Regeln. Alle Regeln in diesem Beispiel verwenden die Optionen
	+ <literal>in</literal> und <literal>out</literal>, um die
	+ Richtung des Pakets zu verdeutlichen. Zusätzlich wird
	+ <literal>via</literal>
	+ <replaceable>interface-name</replaceable> benutzt, um die
	+ Schnittstelle für das Paket zu prüfen.</para>
	+
	+ <note>
	+ <para>Bei den anfänglichen Tests mit dem Firewall-Regelsatz
	+ sollten Sie vielleicht folgende Einstellung
	+ vornehmen:</para>
	+
	+ <programlisting>net.inet.ip.fw.default_to_accept="1"</programlisting>
	+
	+ <para>Dies legt die Standardregel von &man.ipfw.8; etwas
	+ großzügiger fest, als das voreingestellte
	+ <literal>default deny ip from any to any</literal>. Dadurch
	+ sinkt die Gefahr, sich nach einem Neustart des Systems
	+ auszusperren.</para>
	+ </note>
	+
	+ <para>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 <literal>cmd</literal> erstellt, sodass
	+ <literal>ipfw add</literal> nicht jedes mal von Hand
	+ eingegeben werden muss. Die Variable <literal>pif</literal>
	+ repräsentiert die mit dem Internet verbundene
	+ Schnittstelle.</para>

	- <programlisting>################ Start of IPFW rules file ###############################
	+ <programlisting>#!/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</programlisting>

	-#################################################################
	-# No restrictions on Inside LAN Interface for private network
	-# Not needed unless you have LAN.
	-# Change xl0 to your LAN NIC interface name
	-#################################################################
	-#&dollar;cmd 00005 allow all from any to any via xl0
	+ <para>Jetzt folgen die eigentlichen Filterregeln. Diese ersten
	+ beiden Regeln erlauben den Datenverkehr aus dem internen
	+ Netzwerk und über die Loopback-Schnittstelle:</para>
	+
	+ <programlisting># Change xl0 to LAN NIC interface name
	+&dollar;cmd 00005 allow all from any to any via xl0

	-#################################################################
	# No restrictions on Loopback Interface
	-#################################################################
	-&dollar;cmd 00010 allow all from any to any via lo0
	+&dollar;cmd 00010 allow all from any to any via lo0</programlisting>

	-#################################################################
	-# Allow the packet through if it has previous been added to the
	-# the "dynamic" rules table by a allow keep-state statement.
	-#################################################################
	-&dollar;cmd 00015 check-state
	+ <para>Die nächste Regel erlaubt Pakete, für die ein Eintrag
	+ in der dynamischen Zustandstabelle existiert:</para>

	-#################################################################
	-# 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.
	-#################################################################
	+ <programlisting>&dollar;cmd 00101 check-state</programlisting>

	-# 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
	+ <para>Die nächsten Regeln definieren, welche internen Rechner
	+ Verbindungen zu anderen Rechnern im Internet aufbauen dürfen.
	+ Hier werden wieder zustandsorientierte Regeln
	+ verwendet:</para>
	+
	+ <programlisting># 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
	&dollar;cmd 00110 allow tcp from any to x.x.x.x 53 out via &dollar;pif setup keep-state
	&dollar;cmd 00111 allow udp from any to x.x.x.x 53 out via &dollar;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
	&dollar;cmd 00120 allow log udp from any to any 67 out via &dollar;pif keep-state
	#&dollar;cmd 00120 allow udp from any to x.x.x.x 67 out via &dollar;pif keep-state

	-# Allow out non-secure standard www function
	+# Allow outbound HTTP and HTTPS connections
	&dollar;cmd 00200 allow tcp from any to any 80 out via &dollar;pif setup keep-state
	-
	-# Allow out secure www function https over TLS SSL
	&dollar;cmd 00220 allow tcp from any to any 443 out via &dollar;pif setup keep-state

	-# Allow out send & get email function
	+# Allow outbound email connections
	&dollar;cmd 00230 allow tcp from any to any 25 out via &dollar;pif setup keep-state
	&dollar;cmd 00231 allow tcp from any to any 110 out via &dollar;pif setup keep-state

	-# Allow out FBSD (make install & CVSUP) functions
	-# Basically give user root "GOD" privileges.
	-&dollar;cmd 00240 allow tcp from me to any out via &dollar;pif setup keep-state uid root
	-
	-# Allow out ping
	+# Allow outbound ping
	&dollar;cmd 00250 allow icmp from any to any out via &dollar;pif keep-state

	-# Allow out Time
	+# Allow outbound NTP
	&dollar;cmd 00260 allow tcp from any to any 37 out via &dollar;pif setup keep-state

	-# Allow out nntp news (i.e. news groups)
	-&dollar;cmd 00270 allow tcp from any to any 119 out via &dollar;pif setup keep-state
	-
	-# Allow out secure FTP, Telnet, and SCP
	-# This function is using SSH (secure shell)
	+# Allow outbound SSH
	&dollar;cmd 00280 allow tcp from any to any 22 out via &dollar;pif setup keep-state

	-# Allow out whois
	-&dollar;cmd 00290 allow tcp from any to any 43 out via &dollar;pif setup keep-state
	+# deny and log all other outbound connections
	+&dollar;cmd 00299 deny log all from any to any out via &dollar;pif</programlisting>

	-# deny and log everything else that.s trying to get out.
	-# This rule enforces the block all by default logic.
	-&dollar;cmd 00299 deny log all from any to any out via &dollar;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
	-&dollar;cmd 00300 deny all from 192.168.0.0/16 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 00301 deny all from 172.16.0.0/12 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 00302 deny all from 10.0.0.0/8 to any in via &dollar;pif #RFC 1918 private IP
	+ <para>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 <literal>limit</literal>, um
	+ <foreignphrase>Flooding</foreignphrase> zu unterbinden.</para>
	+
	+ <programlisting># Deny all inbound traffic from non-routable reserved address spaces
	+&dollar;cmd 00300 deny all from 192.168.0.0/16 to any in via &dollar;pif #RFC 1918 private IP
	+&dollar;cmd 00301 deny all from 172.16.0.0/12 to any in via &dollar;pif #RFC 1918 private IP
	+&dollar;cmd 00302 deny all from 10.0.0.0/8 to any in via &dollar;pif #RFC 1918 private IP
	&dollar;cmd 00303 deny all from 127.0.0.0/8 to any in via &dollar;pif #loopback
	-&dollar;cmd 00304 deny all from 0.0.0.0/8 to any in via &dollar;pif #loopback
	-&dollar;cmd 00305 deny all from 169.254.0.0/16 to any in via &dollar;pif #DHCP auto-config
	+&dollar;cmd 00304 deny all from 0.0.0.0/8 to any in via &dollar;pif #loopback
	+&dollar;cmd 00305 deny all from 169.254.0.0/16 to any in via &dollar;pif #DHCP auto-config
	&dollar;cmd 00306 deny all from 192.0.2.0/24 to any in via &dollar;pif #reserved for docs
	-&dollar;cmd 00307 deny all from 204.152.64.0/23 to any in via &dollar;pif #Sun cluster interconnect
	-&dollar;cmd 00308 deny all from 224.0.0.0/3 to any in via &dollar;pif #Class D & E multicast
	+&dollar;cmd 00307 deny all from 204.152.64.0/23 to any in via &dollar;pif #Sun cluster interconnect
	+&dollar;cmd 00308 deny all from 224.0.0.0/3 to any in via &dollar;pif #Class D & E multicast

	-# Deny public pings
	-&dollar;cmd 00310 deny icmp from any to any in via &dollar;pif
	+# Deny public pings$
	+&dollar;cmd 00310 deny icmp from any to any in via &dollar;pif$
	+$
	+# Deny ident$
	+&dollar;cmd 00315 deny tcp from any to any 113 in via &dollar;pif$
	+$
	+# Deny all Netbios services.$
	+&dollar;cmd 00320 deny tcp from any to any 137 in via &dollar;pif$
	+&dollar;cmd 00321 deny tcp from any to any 138 in via &dollar;pif$
	+&dollar;cmd 00322 deny tcp from any to any 139 in via &dollar;pif$
	+&dollar;cmd 00323 deny tcp from any to any 81 in via &dollar;pif$

	-# Deny ident
	-&dollar;cmd 00315 deny tcp from any to any 113 in via &dollar;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
	-&dollar;cmd 00320 deny tcp from any to any 137 in via &dollar;pif
	-&dollar;cmd 00321 deny tcp from any to any 138 in via &dollar;pif
	-&dollar;cmd 00322 deny tcp from any to any 139 in via &dollar;pif
	-&dollar;cmd 00323 deny tcp from any to any 81 in via &dollar;pif
	-
	-# Deny any late arriving packets
	+# Deny fragments
	&dollar;cmd 00330 deny all from any to any frag in via &dollar;pif

	# Deny ACK packets that did not match the dynamic rule table
	&dollar;cmd 00332 deny tcp from any to any established in via &dollar;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.
	#&dollar;cmd 00360 allow udp from any to x.x.x.x 67 in via &dollar;pif keep-state

	-# Allow in standard www function because I have apache server
	+# Allow HTTP connections to internal web server
	&dollar;cmd 00400 allow tcp from any to me 80 in via &dollar;pif setup limit src-addr 2

	-# Allow in secure FTP, Telnet, and SCP from public Internet
	+# Allow inbound SSH connections
	&dollar;cmd 00410 allow tcp from any to me 22 in via &dollar;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.
	-&dollar;cmd 00420 allow tcp from any to me 23 in via &dollar;pif setup limit src-addr 2
	-
	-# Reject & Log all incoming connections from the outside
	-&dollar;cmd 00499 deny log all from any to any in via &dollar;pif
	+# Reject and log all other incoming connections
	+&dollar;cmd 00499 deny log all from any to any in via &dollar;pif</programlisting>

	-# Everything else is denied by default
	-# deny and log all packets that fell through to see what they are
	-&dollar;cmd 00999 deny log all from any to any
	-################ End of IPFW rules file ###############################</programlisting>
	- </sect3>
	+ <para>Die letzte Regel protokolliert alle Pakete, die mit
	+ keiner Regel im Regelsatz übereinstimmen:</para>

	- <sect3>
	- <title>Ein Beispiel für zustandshafte
	- <acronym>NAT</acronym>-Regeln</title>
	-
	- <indexterm>
	- <primary>NAT</primary>
	- <secondary>und IPFW</secondary>
	- </indexterm>
	-
	- <para>Es müssen einige zusätzliche
	- Konfigurationseinstellungen vorgenommen werden, um die
	- die <acronym>NAT</acronym>-Funktion von IPFW zu nutzen. Die
	- Kernelquellen müssen mit der Option
	- <literal>IPDIVERT</literal> (im IPFIREWALL-Abschnitt der
	- Kernelkonfigurationsdatei) neu gebaut werden, um den
	- benötigten angepassten Kernel zu erzeugen.</para>
	-
	- <para>Zusätzlich werden folgende Optionen in der
	- <filename>/etc/rc.conf</filename> benötigt:</para>
	-
	- <programlisting>natd_enable="YES" # Enable <acronym>NAT</acronym>D function
	-natd_interface="rl0" # interface name of public Internet NIC
	-natd_flags="-dynamic -m" # -m = preserve port numbers if possible</programlisting>
	-
	- <para>Zustandshafte Regeln bei aktiviertem
	- <literal>divert natd</literal> (<foreignphrase>Network
	- Address Translation</foreignphrase>) verkomplizieren die
	- Formulierung des Regelwerkes beträchtlich. Damit Ihre
	- Firewall funktioniert, kommt es insbesondere auf die Position
	- der Ausdrücke <literal>check-state</literal> sowie
	- <literal>divert natd</literal> 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 <literal>skipto</literal> benötigt. Dies
	- erfordert, dass jede Regel über eine eindeutige Nummer
	- verfügt, um so eindeutige Sprungziele zu erhalten.</para>
	-
	- <para>Im Folgenden wird anhand eines umkommentierten Beispiels
	- der Paketfluss durch das Regelwerk verdeutlicht.</para>
	-
	- <para>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
	- <literal>100, 101, 450, 500</literal> sowie
	- <literal>510</literal>. 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 <literal>skipto rule 500</literal>, damit
	- <acronym>NAT</acronym> verwendet werden kann.</para>
	-
	- <para>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
	- <literal>keep-state</literal> 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 <literal>skipto rule 500</literal>. Die
	- Regel 500 führt <acronym>NAT</acronym>s 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 <literal>check-state</literal>-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 <literal>check-state</literal>-Regel ein
	- nach außen gehender zugehöriger Eintrag in der
	- Zustandstabelle gefunden und die entsprechende Aktion (also
	- <literal>skipto 500</literal>) wird ausgeführt. Das
	- Paket springt zu Regel 500 und wird durch diese Regel für
	- das öffentliche Internet freigegeben.</para>
	-<!-- gecheckt bis hier - jkois - 2012-01-08 -->
	- <para>Innerhalb des durch die Firewall geschützten
	- Netzwerks werden alle eingehenden Pakete, die zu einer
	- existierenden Sitzung gehören, durch die Regel
	- <literal>check-state</literal> sowie entsprechend platzierte
	- <literal>divert natd</literal>-Regeln verarbeitet. Die
	- notwendige Arbeit beschränkt sich darauf, alle
	- <quote>schlechten</quote> 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
	- <literal>2</literal> begrenzt, um so DoS-Angriffe auf Dienste,
	- die auf diesem Port laufen, zu verhindern. Die Aktion dieser
	- Regel ist <literal>allow</literal>, daher wird das Paket
	- freigegeben und in das LAN weitergeleitet. Das als Antwort
	- generierte Paket wird durch die
	- <literal>check-state</literal>-Regel als zu einer Sitzung
	- gehörend erkannt. Damit wird es der Regel 500
	- zugeführt, <acronym>NAT</acronym> wird durchgeführt
	- und über die Schnittstelle zum öffentlichen Internet
	- nach außen geroutet.</para>
	+ <programlisting># Everything else is denied and logged
	+&dollar;cmd 00999 deny log all from any to any</programlisting>
	+ </sect2>

	- <para>Beispiel 1 für einen Regelsatz:</para>
	+ <sect2 xml:id="network-natd">
	+ <info>
	+ <title><acronym>NAT</acronym> Konfiguration</title>

	- <programlisting>#!/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"
	+ <authorgroup>
	+ <author>
	+ <personname>
	+ <firstname>Chern</firstname>
	+ <surname>Lee</surname>
	+ </personname>
	+ <contrib>Beigetragen von </contrib>
	+ </author>
	+ </authorgroup>
	+ </info>

	-ipfw -q -f flush
	+ <indexterm>
	+ <primary>NAT</primary>
	+ <secondary>und <application>IPFW</application></secondary>
	+ </indexterm>

	-&dollar;cmd 002 allow all from any to any via xl0 # exclude LAN traffic
	-&dollar;cmd 003 allow all from any to any via lo0 # exclude loopback traffic
	+ <para>&os;s integrierter <acronym>NAT</acronym>-Daemon,
	+ &man.natd.8;, arbeitet in Verbindung mit
	+ <application>IPFW</application>, um
	+ <foreignphrase>Network Address Translation</foreignphrase>
	+ bereitzustellen. <acronym>NAT</acronym> wird verwendet, um
	+ mehreren internen Rechnern, über eine einzige
	+ <acronym>IP</acronym>-Adresse, eine gemeinsame Verbindung zum
	+ Internet zu ermöglichen.</para>
	+
	+ <para>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 <link
	+ xlink:href="ftp://ftp.isi.edu./in-notes/rfc1918.txt">RFC
	+ 1918</link> konforme Adresse zugewiesen bekommen. Zudem
	+ muss das Standard-Gateway der Rechner auf die interne
	+ <acronym>IP</acronym>-Adresse des &man.natd.8;-Systems
	+ gesetzt werden.</para>
	+
	+ <para>Es ist noch ein wenig Konfiguration nötig, um die
	+ <acronym>NAT</acronym>-Funktion von
	+ <application>IPFW</application> zu aktivieren. Wenn das
	+ System einen angepassten Kernel hat, muss die
	+ Kernelkonfigurationsdatei die Zeile
	+ <literal>option IPDIVERT</literal> sowie weitere
	+ <literal>IPFIREWALL</literal>-Optionen, die in <xref
	+ linkend="firewalls-ipfw-enable"/> beschrieben sind,
	+ enthalten.</para>
	+
	+ <para>Um die <acronym>NAT</acronym>-Unterstützung beim Booten
	+ zu aktivieren, müssen folgende Einträge in
	+ <filename>/etc/rc.conf</filename> vorhanden sein:</para>
	+
	+ <programlisting>gateway_enable="YES" # enables the gateway
	+natd_enable="YES" # enables <acronym>NAT</acronym>
	+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;</programlisting>

	-&dollar;cmd 100 divert natd ip from any to any in via &dollar;pif
	-&dollar;cmd 101 check-state
	+ <note>
	+ <para>Es ist auch möglich eine Konfigurationsdatei zu
	+ verwenden, welche die Optionen enthält, die an
	+ &man.natd.8; übergeben werden:</para>

	-# Authorized outbound packets
	-&dollar;cmd 120 &dollar;skip udp from any to xx.168.240.2 53 out via &dollar;pif &dollar;ks
	-&dollar;cmd 121 &dollar;skip udp from any to xx.168.240.5 53 out via &dollar;pif &dollar;ks
	-&dollar;cmd 125 &dollar;skip tcp from any to any &dollar;good_tcpo out via &dollar;pif setup &dollar;ks
	-&dollar;cmd 130 &dollar;skip icmp from any to any out via &dollar;pif &dollar;ks
	-&dollar;cmd 135 &dollar;skip udp from any to any 123 out via &dollar;pif &dollar;ks
	+ <programlisting>natd_flags="-f /etc/natd.conf"</programlisting>

	+ <para>Die angegebene Datei muss die Konfigurationsoptionen
	+ enthalten, eine Option pro Zeile. Zum Beispiel:</para>

	-# Deny all inbound traffic from non-routable reserved address spaces
	-&dollar;cmd 300 deny all from 192.168.0.0/16 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 301 deny all from 172.16.0.0/12 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 302 deny all from 10.0.0.0/8 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 303 deny all from 127.0.0.0/8 to any in via &dollar;pif #loopback
	-&dollar;cmd 304 deny all from 0.0.0.0/8 to any in via &dollar;pif #loopback
	-&dollar;cmd 305 deny all from 169.254.0.0/16 to any in via &dollar;pif #DHCP auto-config
	-&dollar;cmd 306 deny all from 192.0.2.0/24 to any in via &dollar;pif #reserved for docs
	-&dollar;cmd 307 deny all from 204.152.64.0/23 to any in via &dollar;pif #Sun cluster
	-&dollar;cmd 308 deny all from 224.0.0.0/3 to any in via &dollar;pif #Class D & E multicast
	+ <programlisting>redirect_port tcp 192.168.0.2:6667 6667
	+redirect_port tcp 192.168.0.3:80 80</programlisting>

	-# Authorized inbound packets
	-&dollar;cmd 400 allow udp from xx.70.207.54 to any 68 in &dollar;ks
	-&dollar;cmd 420 allow tcp from any to me 80 in via &dollar;pif setup limit src-addr 1
	+ <para>Weitere Informationen zu dieser Konfigurationsdatei
	+ finden Sie in &man.natd.8;.</para>
	+ </note>

	+ <para>Als nächstes werden die <acronym>NAT</acronym>-Regeln
	+ hinzugefügt. Wenn die Regeln zustandsorientiert sind, ist die
	+ Platzierung der <acronym>NAT</acronym>-Regeln sehr wichtig und
	+ die <literal>skipto</literal>-Aktion wird verwendet. Dies
	+ erfordert, dass jede Regel über eine eindeutige Nummer
	+ verfügt, um eindeutige Sprungziele zu erhalten.</para>
	+
	+ <para>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
	+ <acronym>NAT</acronym> zu konfigurieren. Zunächst werden
	+ einige Variablen hinzugefügt, darunter Regelnummern, die
	+ <literal>keep-state</literal>-Option und eine Liste mit
	+ <acronym>TCP</acronym>-Ports um die Anzahl der Regeln zu
	+ reduzieren:</para>

	-&dollar;cmd 450 deny log ip from any to any
	+ <programlisting>#!/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"</programlisting>

	-# This is skipto location for outbound stateful rules
	-&dollar;cmd 500 divert natd ip from any to any out via &dollar;pif
	-&dollar;cmd 510 allow ip from any to any
	+ <para>Die <acronym>NAT</acronym>-Regel für eingehende Pakete
	+ wird <emphasis>nach</emphasis> den beiden Regeln, die das
	+ interne Netzwerk und die Loopback-Schnittstelle erlauben und
	+ <emphasis>vor</emphasis> der
	+ <literal>check-state</literal>-Regel eingefügt. Es ist
	+ wichtig, dass die Nummer der <acronym>NAT</acronym>-Regel
	+ (in diesem Beispiel <literal>100</literal>) höher ist, als
	+ die beiden vorherigen Regeln und niedriger, als die
	+ <literal>check-state</literal>-Regel:</para>
	+
	+ <programlisting>&dollar;cmd 005 allow all from any to any via xl0 # exclude LAN traffic
	+&dollar;cmd 010 allow all from any to any via lo0 # exclude loopback traffic
	+&dollar;cmd 100 divert natd ip from any to any in via &dollar;pif # NAT any inbound packets
	+# Allow the packet through if it has an existing entry in the dynamic rules table
	+&dollar;cmd 101 check-state</programlisting>
	+
	+ <para>Die Regeln für den ausgehenden Verkehr werden ebenfalls
	+ modifiziert, um Aktionen mit der
	+ <literal>&dollar;skipto</literal>-Variable zu erlauben und
	+ anzuzeigen, dass die Prüfung mit der Regel
	+ <literal>500</literal> fortgesetzt wird. Die sieben Regeln
	+ für <acronym>TCP</acronym> wurden durch die Regel
	+ <literal>125</literal> ersetzt, da die sieben erlaubten
	+ ausgehenden Ports in der Variable
	+ <literal>&dollar;good_tcp0</literal> enthalten sind.</para>
	+
	+ <programlisting># Authorized outbound packets
	+&dollar;cmd 120 &dollar;skip udp from any to x.x.x.x 53 out via &dollar;pif &dollar;ks
	+&dollar;cmd 121 &dollar;skip udp from any to x.x.x.x 67 out via &dollar;pif &dollar;ks
	+&dollar;cmd 125 &dollar;skip tcp from any to any &dollar;good_tcpo out via &dollar;pif setup &dollar;ks
	+&dollar;cmd 130 &dollar;skip icmp from any to any out via &dollar;pif &dollar;ks</programlisting>

	-######################## end of rules ##################</programlisting>
	+ <para>Die eingehenden Regeln bleiben unverändert, mit Ausnahme
	+ der letzten Regel, in der das
	+ <literal>via &dollar;pif</literal> entfert wird, um ein- und
	+ ausgehende Pakete prüfen zu können. Nach der letzten Regel
	+ für ausgehende Pakete muss die <acronym>NAT</acronym>-Regel
	+ folgen. Die Regel muss eine höhere Nummer als die letzte
	+ Regel haben und die Nummer muss über die
	+ <literal>skipto</literal>-Aktion referenziert werden. In
	+ diesem Regelsatz leitet die Regel mit der Nummer
	+ <literal>500</literal> alle ausgehenden Pakete zur
	+ Weiterverarbeitung an &man.natd.8; weiter. Die darauf
	+ folgende Regel lässt alle von <acronym>NAT</acronym>
	+ verarbeiteten Pakete passieren.</para>
	+
	+ <programlisting>&dollar;cmd 499 deny log all from any to any
	+&dollar;cmd 500 divert natd ip from any to any out via &dollar;pif # skipto location for outbound stateful rules
	+&dollar;cmd 510 allow ip from any to any</programlisting>
	+
	+ <para>In diesem Beispiel steuern die Regeln
	+ <literal>100</literal>, <literal>101</literal>,
	+ <literal>125</literal>, <literal>500</literal> und
	+ <literal>510</literal> die Adressübersetzung der ein- und
	+ ausgehende Pakete, so dass immer die private
	+ <acronym>LAN</acronym> <acronym>IP</acronym>-Adresse in der
	+ dynamische Zustandstabelle registriert werden.</para>
	+
	+ <para>Nehmen wir beispielsweise einen Web-Browser, der neue
	+ <acronym>HTTP</acronym>-Sitzungen über Port 80 aufbaut. Wenn
	+ nun das erste ausgehende Paket von der Firewall geprüft wird,
	+ trifft es nicht auf Regel <literal>100</literal> zu, da das
	+ Paket nach außen geleitet wird und nicht nach innen. Das
	+ Paket trifft auch nicht auf Regel <literal>101</literal> zu,
	+ da es das erste ist und somit noch nicht in der dynamischen
	+ Zustandstabelle enthalten ist. Das Paket entspricht
	+ schließlich Regel <literal>125</literal>, da es ausgehend auf
	+ einem erlaubten Port gesendet wird und von einer
	+ <acronym>IP</acronym>-Adresse aus dem internen
	+ <acronym>LAN</acronym> stammt. Für Pakete, die auf diese
	+ Regel zutreffen, werden zwei Aktionen ausgeführt. Zuerst
	+ wird durch die Aktion <literal>keep-state</literal> ein
	+ dynamischer Eintrag in der Statustabelle erstellt und die
	+ angegebene Aktion <literal>skipto 500</literal> ausgeführt.
	+ Als nächstes durchläuft das Paket <acronym>NAT</acronym> 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
	+ <literal>100</literal> auf das Paket zu und die Zieladresse
	+ wird auf die zugehörige (lokale)
	+ <acronym>LAN</acronym>-Adresse abgebildet. Danach wird das
	+ Paket von der Regel <literal>check-state</literal>
	+ verarbeitet. Die Zustandstabelle erkennt, dass eine
	+ zugehörige aktive Sitzung vorliegt und das Paket wird
	+ freigegeben und in das <acronym>LAN</acronym> geleitet.</para>
	+
	+ <para>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
	+ <acronym>LAN</acronym> freigegeben. Das Antwortpaket wird
	+ von der Regel <literal>check-state</literal> als Paket einer
	+ aktiven Sitzung erkannt. Das Paket wird dann von Regel
	+ <literal>500</literal> per <acronym>NAT</acronym>
	+ verarbeitet, bevor es über die externe Schnittstelle versendet
	+ wird.</para>

	- <para>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.</para>
	+ <sect3>
	+ <title>Weiterleitung von Ports</title>

	- <para>Beispiel 2 für einen Regelsatz:</para>
	+ <para>Der Nachteil von &man.natd.8; ist, dass die Rechner im
	+ <acronym>LAN</acronym> 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 <acronym>LAN</acronym> 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
	+ <acronym>LAN</acronym> weiterleiten.</para>
	+
	+ <para>Angenommen es gibt einen <acronym>IRC</acronym>-Server
	+ auf Rechner <systemitem>A</systemitem> und einen Webserver
	+ auf Rechner <systemitem>B</systemitem>. Damit dies
	+ funktioniert, müssen die Verbindungen auf den Ports 6667
	+ (<acronym>IRC</acronym>) und 80 (<acronym>HTTP</acronym>)
	+ an die jeweiligen Rechner weitergeleitet werden.</para>
	+
	+ <para>Die Syntax für <option>-redirect_port</option>
	+ lautet:</para>
	+
	+ <programlisting>-redirect_port proto targetIP:targetPORT[-targetPORT]
	+ [aliasIP:]aliasPORT[-aliasPORT]
	+ [remoteIP[:remotePORT[-remotePORT]]]</programlisting>
	+
	+ <para>Für das obige Beispiel sollten die Argumente wie folgt
	+ aussehen:</para>
	+
	+ <programlisting>-redirect_port tcp 192.168.0.2:6667 6667
	+ -redirect_port tcp 192.168.0.3:80 80</programlisting>
	+
	+ <para>Damit werden die entsprechenden
	+ <acronym>TCP</acronym>-Ports an die Rechner im
	+ <acronym>LAN</acronym> weitergeleitet.</para>
	+
	+ <para>Portbereiche können über <option>-redirect_port</option>
	+ festgelegt werden. Zum Beispiel würde
	+ <replaceable>tcp 192.168.0.2:2000-3000
	+ 2000-3000</replaceable> alle Verbindungen auf die Ports
	+ 2000 bis 3000 an die Ports 2000 bis 3000 an
	+ Rechner <systemitem>A</systemitem> weiterleiten.</para>
	+
	+ <para>Diese Optionen können über
	+ <literal>natd_flags=""</literal> in
	+ <filename>/etc/rc.conf</filename> direkt beim Start an
	+ &man.natd.8; übergeben werden. Alternativ können die
	+ Optionen in eine Konfigurationsdatei eingetragen
	+ werden.</para>

	- <programlisting>#!/bin/sh
	-################ Start of IPFW rules file ###############################
	-# Flush out the list before we begin.
	-ipfw -q -f flush
	+ <para>Weitere Konfigurationsmöglichkeiten sind in
	+ &man.natd.8; beschrieben.</para>
	+ </sect3>

	-# Set rules command prefix
	-cmd="ipfw -q add"
	-skip="skipto 800"
	-pif="rl0" # public interface name of NIC
	- # facing the public Internet
	+ <sect3>
	+ <title>Weiterleiten von Adressen</title>

	-#################################################################
	-# No restrictions on Inside LAN Interface for private network
	-# Change xl0 to your LAN NIC interface name
	-#################################################################
	-&dollar;cmd 005 allow all from any to any via xl0
	+ <para>Das Weiterleiten von Adressen ist nützlich, wenn
	+ mehr als eine <acronym>IP</acronym>-Adresse zur Verfügung
	+ steht. Jeder Rechner im <acronym>LAN</acronym> kann über
	+ &man.natd.8; seine eigene externe
	+ <acronym>IP</acronym>-Adresse zugewiesen bekommen.
	+ &man.natd.8; wird dann den ausgehenden Datenverkehr der
	+ Rechner aus dem <acronym>LAN</acronym> mit der
	+ entsprechenden externen <acronym>IP</acronym>-Adresse
	+ umschreiben. Auch der eingehenden Datenverkehr über die
	+ externe <acronym>IP</acronym>-Adresse wird an die
	+ entsprechenden Rechner im <acronym>LAN</acronym>
	+ weitergeleitet. Diese Methode ist auch als
	+ statisches <acronym>NAT</acronym> bekannt. Wenn Ihnen
	+ beispielsweise die <acronym>IP</acronym>-Adressen
	+ <systemitem class="ipaddress">128.1.1.1</systemitem>,
	+ <systemitem class="ipaddress">128.1.1.2</systemitem> und
	+ <systemitem class="ipaddress">128.1.1.3</systemitem> zur
	+ Verfügung stehen, kann <systemitem
	+ class="ipaddress">128.1.1.1</systemitem> als externe
	+ Adresse der &man.natd.8;-Maschine verwendet werden, während
	+ <systemitem class="ipaddress">128.1.1.2</systemitem> und
	+ <systemitem class="ipaddress">128.1.1.3</systemitem> an
	+ Rechner <systemitem>A</systemitem> und
	+ Rechner <systemitem>B</systemitem> im <acronym>LAN</acronym>
	+ weitergeleitet werden.</para>
	+
	+ <para>Die Syntax für <option>-redirect_address</option>
	+ lautet:</para>
	+
	+ <programlisting>-redirect_address localIP publicIP</programlisting>
	+
	+ <informaltable frame="none" pgwide="1">
	+ <tgroup cols="2">
	+ <tbody>
	+ <row>
	+ <entry>localIP</entry>
	+ <entry>Die interne <acronym>IP</acronym>-Adresse des
	+ Rechners im <acronym>LAN</acronym>.</entry>
	+ </row>
	+
	+ <row>
	+ <entry>publicIP</entry>
	+ <entry>Die externe <acronym>IP</acronym>-Adresse für
	+ den entsprechenden Rechner im
	+ <acronym>LAN</acronym>.</entry>
	+ </row>
	+ </tbody>
	+ </tgroup>
	+ </informaltable>
	+
	+ <para>Für das obige Beispiel sollten die Argumente wie
	+ folgt aussehen:</para>
	+
	+ <programlisting>-redirect_address 192.168.0.2 128.1.1.2
	+-redirect_address 192.168.0.3 128.1.1.3</programlisting>
	+
	+ <para>Genau wie bei <option>-redirect_port</option>, werden
	+ diese Argumente innerhalb der
	+ <filename>/etc/rc.conf</filename>-Option
	+ <literal>natd_flags=""</literal> angegeben, oder alternativ
	+ über eine Konfigurationsdatei. Allerdings müssen beim
	+ Weiterleiten von Adressen keine Ports umgeleitet werden, da
	+ der gesamte eingehende Datenverkehr einer bestimmte
	+ <acronym>IP</acronym>-Adresse weitergeleitet wird.</para>
	+
	+ <para>Die externe <acronym>IP</acronym>-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.</para>
	+ </sect3>
	+ </sect2>

	-#################################################################
	-# No restrictions on Loopback Interface
	-#################################################################
	-&dollar;cmd 010 allow all from any to any via lo0
	+ <sect2 xml:id="firewalls-ipfw-cmd">
	+ <title>Das <application>IPFW</application> Kommando</title>

	-#################################################################
	-# check if packet is inbound and nat address if it is
	-#################################################################
	-&dollar;cmd 014 divert natd ip from any to any in via &dollar;pif
	+ <indexterm>
	+ <primary><command>ipfw</command></primary>
	+ </indexterm>

	-#################################################################
	-# Allow the packet through if it has previous been added to the
	-# the "dynamic" rules table by a allow keep-state statement.
	-#################################################################
	-&dollar;cmd 015 check-state
	+ <para><command>ipfw</command> 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.</para>
	+
	+ <para><command>ipfw</command> ist auch hilfreich, um die
	+ geladenen Regeln der auf der Konsole auszugeben.
	+ <application>IPFW</application> 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.</para>

	-#################################################################
	-# 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.
	-#################################################################
	+ <para>Eine Auflistung aller geladenen Regeln erhalten Sie
	+ mit:</para>

	-# 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
	-&dollar;cmd 020 &dollar;skip tcp from any to x.x.x.x 53 out via &dollar;pif setup keep-state
	+ <screen>&prompt.root; <userinput>ipfw list</userinput></screen>

	+ <para>Eine Auflistung aller Regeln inklusive des letzten
	+ Treffers erhalten Sie mit:</para>

	-# Allow out access to my ISP's DHCP server for cable/DSL configurations.
	-&dollar;cmd 030 &dollar;skip udp from any to x.x.x.x 67 out via &dollar;pif keep-state
	+ <screen>&prompt.root; <userinput>ipfw -t list</userinput></screen>

	-# Allow out non-secure standard www function
	-&dollar;cmd 040 &dollar;skip tcp from any to any 80 out via &dollar;pif setup keep-state
	+ <para>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:</para>

	-# Allow out secure www function https over TLS SSL
	-&dollar;cmd 050 &dollar;skip tcp from any to any 443 out via &dollar;pif setup keep-state
	+ <screen>&prompt.root; <userinput>ipfw -a list</userinput></screen>

	-# Allow out send & get email function
	-&dollar;cmd 060 &dollar;skip tcp from any to any 25 out via &dollar;pif setup keep-state
	-&dollar;cmd 061 &dollar;skip tcp from any to any 110 out via &dollar;pif setup keep-state
	+ <para>Das folgende Kommando zeigt zusätzlich alle dynamischen
	+ Regeln an:</para>

	-# Allow out FreeBSD (make install & CVSUP) functions
	-# Basically give user root "GOD" privileges.
	-&dollar;cmd 070 &dollar;skip tcp from me to any out via &dollar;pif setup keep-state uid root
	+ <screen>&prompt.root; <userinput>ipfw -d list</userinput></screen>

	-# Allow out ping
	-&dollar;cmd 080 &dollar;skip icmp from any to any out via &dollar;pif keep-state
	+ <para>Um diese Auflistung um die <quote>abgelaufenen</quote>
	+ Regeln zu erweitern, geben Sie folgendes Kommando ein:</para>

	-# Allow out Time
	-&dollar;cmd 090 &dollar;skip tcp from any to any 37 out via &dollar;pif setup keep-state
	+ <screen>&prompt.root; <userinput>ipfw -d -e list</userinput></screen>

	-# Allow out nntp news (i.e. news groups)
	-&dollar;cmd 100 &dollar;skip tcp from any to any 119 out via &dollar;pif setup keep-state
	+ <para>Hiermit werden alle Zähler auf Null zurückgesetzt:</para>

	-# Allow out secure FTP, Telnet, and SCP
	-# This function is using SSH (secure shell)
	-&dollar;cmd 110 &dollar;skip tcp from any to any 22 out via &dollar;pif setup keep-state
	+ <screen>&prompt.root; <userinput>ipfw zero</userinput></screen>

	-# Allow out whois
	-&dollar;cmd 120 &dollar;skip tcp from any to any 43 out via &dollar;pif setup keep-state
	+ <para>Es ist auch möglich, einen spezifischen Zähler
	+ zurückzusetzen:</para>

	-# Allow ntp time server
	-&dollar;cmd 130 &dollar;skip udp from any to any 123 out via &dollar;pif keep-state
	+ <screen>&prompt.root; <userinput>ipfw zero NUM</userinput></screen>

	-#################################################################
	-# Interface facing Public Internet (Inbound Section)
	-# Check packets originating from the public Internet
	-# destined for this gateway server or the private network.
	-#################################################################
	+ <sect3>
	+ <title>Protokollierung von Firewall-Nachrichten</title>

	-# Deny all inbound traffic from non-routable reserved address spaces
	-&dollar;cmd 300 deny all from 192.168.0.0/16 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 301 deny all from 172.16.0.0/12 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 302 deny all from 10.0.0.0/8 to any in via &dollar;pif #RFC 1918 private IP
	-&dollar;cmd 303 deny all from 127.0.0.0/8 to any in via &dollar;pif #loopback
	-&dollar;cmd 304 deny all from 0.0.0.0/8 to any in via &dollar;pif #loopback
	-&dollar;cmd 305 deny all from 169.254.0.0/16 to any in via &dollar;pif #DHCP auto-config
	-&dollar;cmd 306 deny all from 192.0.2.0/24 to any in via &dollar;pif #reserved for docs
	-&dollar;cmd 307 deny all from 204.152.64.0/23 to any in via &dollar;pif #Sun cluster
	-&dollar;cmd 308 deny all from 224.0.0.0/3 to any in via &dollar;pif #Class D & E multicast
	+ <para>Auch bei aktivierter Protokollierung wird
	+ <application>IPFW</application> 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
	+ <literal>log</literal> hinzugefügt werden. Normalerweise
	+ werden nur geblockte Pakete protokolliert. Es ist üblich,
	+ die <quote>ipfw default deny everything</quote>-Regel am
	+ Ende des Regelwerks mit dem Schlüsselwort
	+ <literal>log</literal> zu duplizieren. Dadurch ist es
	+ möglich, alle Pakete zu sehen, auf die keine Regel
	+ zutraf.</para>

	-# Deny ident
	-&dollar;cmd 315 deny tcp from any to any 113 in via &dollar;pif
	+ <para>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.</para>

	-# Deny all Netbios service. 137=name, 138=datagram, 139=session
	-# Netbios is MS/Windows sharing services.
	-# Block MS/Windows hosts2 name server requests 81
	-&dollar;cmd 320 deny tcp from any to any 137 in via &dollar;pif
	-&dollar;cmd 321 deny tcp from any to any 138 in via &dollar;pif
	-&dollar;cmd 322 deny tcp from any to any 139 in via &dollar;pif
	-&dollar;cmd 323 deny tcp from any to any 81 in via &dollar;pif
	+ <para>Die Kerneloption
	+ <literal>IPFIREWALL_VERBOSE_LIMIT=5</literal> 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:</para>
	+
	+ <programlisting>Last message repeated 45 times</programlisting>
	+
	+ <para>Alle protokollierten Pakete werden in der Voreinstellung
	+ in <filename>/var/log/security</filename> gespeichert. Dies
	+ wird in <filename>/etc/syslog.conf</filename>
	+ definiert.</para>
	+ </sect3>

	-# Deny any late arriving packets
	-&dollar;cmd 330 deny all from any to any frag in via &dollar;pif
	+ <sect3 xml:id="firewalls-ipfw-rules-script">
	+ <title>Ein Firewall-Regelwerk erstellen</title>

	-# Deny ACK packets that did not match the dynamic rule table
	-&dollar;cmd 332 deny tcp from any to any established in via &dollar;pif
	+ <para>Die meisten fortgeschrittenen
	+ <application>IPFW</application>-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.</para>
	+
	+ <para>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 &dollar;
	+ (Dollarzeichen). Symbolische Felder haben das
	+ &dollar;-Präfix nicht. Der Wert, mit dem das symbolische
	+ Feld belegt wird, muss in doppelten Anführungszeichen
	+ ("") stehen.</para>

	-# 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.
	-&dollar;cmd 360 allow udp from x.x.x.x to any 68 in via &dollar;pif keep-state
	+ <para>Die Datei mit den Regeln könnte wie folgt aufgebaut
	+ sein:</para>

	-# Allow in standard www function because I have Apache server
	-&dollar;cmd 370 allow tcp from any to me 80 in via &dollar;pif setup limit src-addr 2
	+ <programlisting>############### 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
	+&dollar;cmd 00500 check-state
	+&dollar;cmd 00502 deny all from any to any frag
	+&dollar;cmd 00501 deny tcp from any to any established
	+&dollar;cmd 00600 allow tcp from any to any 80 out via &dollar;oif setup &dollar;ks
	+&dollar;cmd 00610 allow tcp from any to &dollar;odns 53 out via &dollar;oif setup &dollar;ks
	+&dollar;cmd 00611 allow udp from any to &dollar;odns 53 out via &dollar;oif &dollar;ks
	+################### End of example ipfw rules script ############</programlisting>

	-# Allow in secure FTP, Telnet, and SCP from public Internet
	-&dollar;cmd 380 allow tcp from any to me 22 in via &dollar;pif setup limit src-addr 2
	+ <para>Die Regeln in diesem Beispiel sind nicht wichtig.
	+ Wichtig ist es, zu zeigen, wie die symbolische Substitution
	+ innerhalb der Regeln verwendet wird.</para>
	+
	+ <para>Wenn dieses Beispiel in
	+ <filename>etc/ipfw.rules</filename> gespeichert wurde, so
	+ könnten alle Regeln durch die Ausführung des folgenden
	+ Kommandos neu geladen werden:</para>

	-# 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.
	-&dollar;cmd 390 allow tcp from any to me 23 in via &dollar;pif setup limit src-addr 2
	+ <screen>&prompt.root; <userinput>sh /etc/ipfw.rules</userinput></screen>

	-# Reject & Log all unauthorized incoming connections from the public Internet
	-&dollar;cmd 400 deny log all from any to any in via &dollar;pif
	+ <para>Anstelle von <filename>/etc/ipfw.rules</filename> kann
	+ ein beliebig anderer Name oder Speicherort verwendet
	+ werden.</para>

	-# Reject & Log all unauthorized out going connections to the public Internet
	-&dollar;cmd 450 deny log all from any to any out via &dollar;pif
	+ <para>Alternativ können die einzelnen Befehle dieses Skripts
	+ auch von Hand eingegeben werden:</para>

	-# This is skipto location for outbound stateful rules
	-&dollar;cmd 800 divert natd ip from any to any out via &dollar;pif
	-&dollar;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
	-&dollar;cmd 999 deny log all from any to any
	-################ End of IPFW rules file ###############################</programlisting>
	+ <screen>&prompt.root; <userinput>ipfw -q -f flush</userinput>
	+&prompt.root; <userinput>ipfw -q add check-state</userinput>
	+&prompt.root; <userinput>ipfw -q add deny all from any to any frag</userinput>
	+&prompt.root; <userinput>ipfw -q add deny tcp from any to any established</userinput>
	+&prompt.root; <userinput>ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state</userinput>
	+&prompt.root; <userinput>ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state</userinput>
	+&prompt.root; <userinput>ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state</userinput></screen>
	</sect3>
	</sect2>
	</sect1>
	-
	</chapter>

File Metadata

Mime Type: text/plain
Expires: Sun, Aug 23, 6:02 PM (3 h, 2 m)
Storage Engine: blob
Storage Format: Raw Data
Storage Handle: 37155619
Default Alt Text: D7084.diff (106 KB)

D7084.diffNo OneTemporaryActions

D7084.diffView Options

File Metadata

Event Timeline

D7084.diff
No OneTemporary
Actions

D7084.diff
View Options