cvs commit: de-docproj/books/handbook/firewalls chapter.sgml

From: Johann Kois <jkois(at)doc.bsdgroup.de>
Date: Sun, 8 Jan 2012 18:42:35 GMT

jkois 2012-01-08 18:42:35 UTC

FreeBSD German Documentation Repository

Modified files:
    books/handbook/firewalls chapter.sgml
  Log:
  So. Fertig gecheckt.

  Wenns keine Probleme gibt und der Bau nicht abkackt, fliegt dieses Kapitel demnächst über den großen Teich ... ;-)

  Zusätzlich: MFen 1.95 -> 1.97

  Noch offen: ca. 600 Zeilen im Abschnitt IPF. Keine Ahnung, warum die (da in Englisch) überhaupt im deutschen Handbuch drin sind).

  Revision Changes Path
  1.51 +363 -419 de-docproj/books/handbook/firewalls/chapter.sgml

  Index: chapter.sgml
  ===================================================================
  RCS file: /home/cvs/de-docproj/books/handbook/firewalls/chapter.sgml,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -I$FreeBSDde.*$ -r1.50 -r1.51
  --- chapter.sgml 8 Jan 2012 17:10:04 -0000 1.50
  +++ chapter.sgml 8 Jan 2012 18:42:35 -0000 1.51
  @@ -3,8 +3,8 @@
        The FreeBSD German Documentation Project

        $FreeBSD$
  - $FreeBSDde: de-docproj/books/handbook/firewalls/chapter.sgml,v 1.50 2012/01/08 17:10:04 jkois Exp $
  - basiert auf: 1.95
  + $FreeBSDde: de-docproj/books/handbook/firewalls/chapter.sgml,v 1.51 2012/01/08 18:42:35 jkois Exp $
  + basiert auf: 1.97
   -->

   <chapter id="firewalls">
  @@ -414,9 +414,13 @@
           <para>Beim Lesen der <ulink
             url="http://www.openbsd.org/faq/pf/">PF FAQ</ulink> wollten Sie
             darauf achten, dass verschiedene Versionen von &os; auch
  - unterschiedliche Versionen von PF enthalten. Aktuelle
  - &os;-Versionen benutzen die selbe Version von
  - <acronym>PF</acronym> wie OpenBSD 4.1.</para>
  + unterschiedliche Versionen von PF enthalten.
  + &os; 8.<replaceable>X</replaceable> (und älter)
  + &os;-Versionen benutzen dieselbe Version von
  + <acronym>PF</acronym> wie OpenBSD 4.1.
  + &os; 9.<replaceable>X</replaceable> (und neuer) benutzen
  + hingegen die dieselbe Version von <acronym>PF</acronym> wie
  + OpenBSD 4.5.</para></para>
         </warning>

         <para>Die &a.pf; ist eine erste Anlaufstelle für
  @@ -2163,7 +2167,7 @@
         </sect3>
       </sect2>
     </sect1>
  -
  +
     <sect1 id="firewalls-ipfw">
       <title>IPFW</title>

  @@ -2992,7 +2996,7 @@
         <sect3>
           <title>Zustandsgesteuertes Regelwerk</title>

  - <para>Des folgende Regelwerk (ohne
  + <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.
  @@ -3023,321 +3027,282 @@
             die Netzwerkkarte handelt, über, die mit Ihrem
             <acronym>DSL</acronym>- oder Kabelmodem verbunden
             ist.</para>
  -
  - <para>In Fällen, in denen mehr als
  - ein <acronym>NIC</acronym> mit einem
  - privaten <acronym>LAN</acronym> hinter der Firewall
  - verbunden sind, müssen die Firewallregeln für
  - alle dieser interfaces entstammenden Datenpakete freien,
  - ungehinderten Datenverkehr erlauben.</para>
  -
  - <para>Es ist angebracht, die Regeln in drei Abschnitte zu
  - strukturieren. Der erste Abschnitt enthält die freien,
  - von der Firewall nicht zu berührenden
  - Netzwerkschnittstellen. Dem folgen die öffentlichen
  - Schnittstellen auswärts, danach einwärts.</para>
  -
  - <para>Innerhalb dieser Abschnitte sollten die am
  - häufigsten zu nutzenden Regeln vor seltener genutzten
  - stehen. Die Abschnitte selbst sollten mit einer letzten
  - Regel, die alle Pakete blockiert und protokolliert,
  - terminiert werden.</para>
  -
  - <para>Im folgenden Beispiel enthält der Abschnitt mit
  - Regeln für ausgehenden Datenverkehr
  - (<literal>allow</literal>) nur Regeln, für deren
  - Selektionskriterien der Dienst, dem öffentlicher
  - Internetzugang gewährt wird, eindeuting indentifiziert
  - ist. In allen diesen Regeln sind Optionen für
  - <literal>proto</literal>, <literal>port</literal>,
  - <literal>in/out</literal>, <literal>via</literal> und
  - <literal>keep state</literal> kodiert. Die
  - Regeln <literal>proto tcp</literal> beinhalten die Option
  - <literal>setup</literal>, um damit die initiale, eine
  - Sitzung beginnende Anfrage identifizieren zu können und
  - daraus die ZustandstTabelle befüllen zu
  - können.</para>

  - <para>Der Abschnitt mit Regeln für eingehenden
  - Datenverkehr beginnt mit allen Regeln, die
  - unerwünschten Datenverkehr blockieren. Dies geschieht
  - aus zwei Gründen: Zum einen könnten bösartige
  - Pakete legtitimen Datenverker sosehr ähneln, dass
  - sie Treffer bei <literal>allow</literal> Regeln für
  - legitimen Datenverkehr erzielen und so die firwall passieren
  - können. Stattdessen sollten diese Pakete verworfen
  - werden. Zum anderen sollten unerwünschte Pakete mit
  - bekannten und somit uninteressanten Mustern geräuschlos
  - blockiert werden, anstatt von der letzten, generischen Regel
  - blockiert und, wichtiger, zudem protokolliert zu werden Die
  - letzte Regel jedes Abschnittes blockiert und protokolliert;
  - sie kann so genutzt werden, um justiziable Beweise
  - sicherzustellen, um damit die Personen, die Angriffe gegen
  - Ihre Systeme fahren, zu verfolgen.</para>
  -
  - <para>Desweiteren sollte gewährleistet werden, dass
  - keine Netzwerkantworten auf geblockte Pakete ergehen.
  - Stattdessen sollte unerwünschter Verkehr
  - geräuschlos verworfen werden. So wird der Angreifer
  - keine Information erhalten, ob seine Pakete Ihr System
  - erreicht haben. Je weniger Information ein Angreifer
  - über Ihr System erhält, desto sicherer ist es.
  - Pakete an Ports, die nicht bekannten Diensten zugeordnet
  - werden können, können
  - mit <filename>/etc/services</filename> identifiziert werden.
  - Alternativ kann eine Anfrage an
  - <ulink url="http://www.securitystats.com/tools/portsearch.php"></ulink>
  - Klarheit über den Zweck einer bestimmten Portnummer
  - bringen. Auf der Seite
  - <ulink url="http://www.simovits.com/trojans/trojans.html"></ulink>
  + <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 <ulink
  + url="http://www.securitystats.com/tools/portsearch.php"></ulink>
  + Klarheit über die Aufgabe/Funktion einer bestimmten Portnummer
  + bringen. Auf der Seite <ulink
  + url="http://www.simovits.com/trojans/trojans.html"></ulink>
             kann man Information über bekannte Trojaner und von
             diesen verwendete Portnummern erhalten.</para>
         </sect3>

         <sect3>
           <title>Ein Beispiel für einschließende
  - Regeln</title>

----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Sun 08 Jan 2012 - 19:42:55 CET