fboerner 2010-02-17 19:12:00 UTC
FreeBSD German Documentation Repository
Modified files:
books/handbook/firewalls chapter.sgml
Log:
MFen 1.86 -> 1.87
Diese Revision auf die bereits uebersetzen Teile dieses Textes angewendet. Die restlichen Korrekturen kommen dann mit der Uebersetzung des restlichen Textes.
Approved by: bcr (mentor)
Revision Changes Path
1.19 +36 -27 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.18
retrieving revision 1.19
diff -u -I$FreeBSDde.*$ -r1.18 -r1.19
--- chapter.sgml 17 Feb 2010 18:51:45 -0000 1.18
+++ chapter.sgml 17 Feb 2010 19:12:00 -0000 1.19
@@ -3,8 +3,8 @@
The FreeBSD German Documentation Project
$FreeBSD: doc/de_DE.ISO8859-1/books/handbook/firewalls/chapter.sgml,v 1.13 2009/10/07 10:19:10 bcr Exp $
- $FreeBSDde: de-docproj/books/handbook/firewalls/chapter.sgml,v 1.18 2010/02/17 18:51:45 fboerner Exp $
- basiert auf: 1.86
+ $FreeBSDde: de-docproj/books/handbook/firewalls/chapter.sgml,v 1.19 2010/02/17 19:12:00 fboerner Exp $
+ basiert auf: 1.87
-->
<chapter id="firewalls">
@@ -141,15 +141,24 @@
das genaue Gegenteil. Sie lässt Datenverkehr nur dann
durch, wenn er einer der definierten Regeln entspricht.</para>
- <para>Einschließende Firewalls sind tendentiell sicherer als
- ausschließende Firewalls, da sie das Risiko, dass
- unerwünschter Datenverkehr die Firewall passiert, signifikant
+ <para>Eine inclusive Firewall bietet eine wesentlich bessere Kontrolle
+ des ausgehenden Verkehrs, macht sie zur besseren Wahl für Systeme,
+ die Services für das Internet anbieten. Sie kontrolliert
+ auch den Verkehr vom Internet zu ihrem privaten Netzwerk. Jeder Verkehr,
+ der keiner Regel entspricht wird geblockt und geloggt. Inclusive
+ Firewalls sind generell sicherer als exclusive Firewalls, da sie das
+ Risiko, dass unerwünschter Verkehr hindurch geht, drastisch
reduzieren.</para>
+
+ <note>
+ <para>Wenn nicht anders vermerkt, verwenden alle Konfigurationen
+ und Beispielregelsets dieses Kapitels inclusive Firewalls.</para>
+ </note>
<para>Die Sicherheit einer Firewall kann durch den Einsatz einer
<quote>zustandsabhängigen Firewall</quote>
(<foreignphrase>stateful firewall</foreignphrase>) weiter
- erhöht werden. Eine zustandsabhängige Firewall
+ erhöht werden. Dieser Typ einer Firewall
überwacht alle durch die Firewall gehenden offenen
Verbindungen und erlaubt nur schon bestehenden Verkehr oder
Datenverkehr, der eine neue Verbindung öffnet. Der Nachteil
@@ -159,7 +168,7 @@
erstellt werden. Bei den meisten Firewalls können Sie eine
Kombination aus zustandsabhängigem und nicht
zustandsabhängigem Verhalten verwenden, um eine für Ihre
- Bedürfnisse optimale Fireall einzurichten.</para>
+ Bedürfnisse optimale Firewall einzurichten.</para>
</sect1>
<sect1 id="firewalls-apps">
@@ -178,8 +187,8 @@
in enger Verbindung mit <acronym>IPFW</acronym>, während
<acronym>ALTQ</acronym> gemeinsam mit
<acronym>PF</acronym> eingesetzt wird.
- Traffic Shaping für <acronym>IPFILTER</acronym> ist derzeit
- mit <acronym>IPFILTER</acronym> für NAT sowie Filterung und
+ Traffic Shaping für IPFILTER ist derzeit
+ mit IPFILTER für NAT sowie Filterung und
mit <acronym>IPFW</acronym> und &man.dummynet.4;
<emphasis>oder</emphasis> durch die Kombination von
<acronym>PF</acronym> mit <acronym>ALTQ</acronym> möglich.
@@ -204,7 +213,7 @@
<para>Da alle Firewalls auf der Untersuchung der Werte
ausgewählter Kontrollfelder von Datenpaketen basieren, ist es
für die Erstellung von Firewallregeln notwendig, die
- Funktionsweise von <acronym>TCP</acronym>/IP zu verstehen.
+ Funktionsweise von <acronym>TCP/IP</acronym> zu verstehen.
Außerdem muss man dazu wissen, was die Werte der einzelnen
Kontrollfelder bedeuten und wie diese während einer
Verbindung eingesetzt werden. Eine gute Erklärung dieser
@@ -320,8 +329,8 @@
Änderungen der <acronym>PF</acronym>-Zustandstabelle offenlegt.
Es kann mit &man.carp.4; kombiniert werden, um ausfallsichere
Firewalls mit <acronym>PF</acronym> zu realisieren. Weitere
- Informationen zu <acronym>CARP</acronym> erhalten Sie in <link
- linkend="carp">Kapitel 29</link> des Handbuchs.</para>
+ Informationen zu <acronym>CARP</acronym> erhalten Sie in
+ <xref linkend="carp"> des Handbuchs.</para>
<para>Die Kernelkonfigurationsoptionen von <acronym>PF</acronym> befinden
sich in <filename>/usr/src/sys/conf/NOTES</filename> und sind im
@@ -414,7 +423,7 @@
<title>Arbeiten mit PF</title>
<para>Benutzen Sie &man.pfctl.8;, um <acronym>PF</acronym> zu steuern.
- Unten finden sie ein paar nützliche Befehle (lesen Sie auch die
+ Unten finden Sie ein paar nützliche Befehle (lesen Sie auch die
Manualpage zu &man.pfctl.8;, um alle verfügbaren Optionen
nachzuschlagen):</para>
@@ -487,36 +496,36 @@
<acronym>ALTQ</acronym>-Framework.</para>
<para><literal>options ALTQ_CBQ</literal> aktiviert das
- <foreignphrase>Class Based Queuing</foreignphrase>
+ <emphasis>Class Based Queuing</emphasis>
(<acronym>CBQ</acronym>). <acronym>CBQ</acronym> erlaubt es, die
Bandbreite einer Verbindung in verschiedene Klassen oder
Warteschlangen zu unterteilen, um die Priorität von
Datenpaketen basierend auf Filterregeln zu ändern.</para>
- <para><literal>options ALTQ_RED</literal> aktiviert
- <foreignphrase>Random Early Detection</foreignphrase>
- (<acronym>RED</acronym>). <acronym>RED</acronym> wird
- zur Vermeidung einer Netzwerkverstopfung verwendet. Dazu
- ermittelt <acronym>RED</acronym> die Größe der
- Warteschlange und vergleicht diesen Wert mit den minimalen
- und maximalen Grenzwerten der Warteschlange. Ist die
- Warteschlange größer als das erlaubte Maximum,
- werden alle neuen Pakete verworfen. Getreu seinem Namen
- verwirft <acronym>RED</acronym> Pakete unterschiedlicher
+ <para><literal>options ALTQ_RED</literal> aktiviert
+ <emphasis>Random Early Detection</emphasis>
+ (<acronym>RED</acronym>). <acronym>RED</acronym> wird
+ zur Vermeidung einer Netzwerkverstopfung verwendet. Dazu
+ ermittelt <acronym>RED</acronym> die Größe der
+ Warteschlange und vergleicht diesen Wert mit den minimalen
+ und maximalen Grenzwerten der Warteschlange. Ist die
+ Warteschlange größer als das erlaubte Maximum,
+ werden alle neuen Pakete verworfen. Getreu seinem Namen
+ verwirft <acronym>RED</acronym> Pakete unterschiedlicher
Verbindungen nach dem Zufallsprinzip.</para>
<para><literal>options ALTQ_RIO</literal> aktiviert
- <foreignphrase>Random Early Detection In and
- Out</foreignphrase>.</para>
+ <emphasis>Random Early Detection In and
+ Out</emphasis>.</para>
<para><literal>options ALTQ_HFSC</literal> aktiviert den
- <foreignphrase>Hierarchical Fair Service Curve</foreignphrase>
+ <emphasis>Hierarchical Fair Service Curve</emphasis>
-Paketplaner. Weitere Informationen zu <acronym>HFSC</acronym>
finden Sie unter <ulink
url="http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html"></ulink>.</para>
<para><literal>options ALTQ_PRIQ</literal> aktiviert
- <foreignphrase>Priority Queuing</foreignphrase>
+ <emphasis>Priority Queuing</emphasis>
(<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym>
lässt Verkehr einer Warteschlange mit höherer
Priorität zuerst durch.</para>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Wed 17 Feb 2010 - 20:12:19 CET