From owner-svn-doc-head@freebsd.org Tue Jun 7 11:22:55 2016 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2311EB6D787; Tue, 7 Jun 2016 11:22:55 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C81931DF0; Tue, 7 Jun 2016 11:22:54 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u57BMsRh033803; Tue, 7 Jun 2016 11:22:54 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u57BMst3033802; Tue, 7 Jun 2016 11:22:54 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201606071122.u57BMst3033802@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Tue, 7 Jun 2016 11:22:54 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48900 - head/de_DE.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 11:22:55 -0000 Author: bhd Date: Tue Jun 7 11:22:53 2016 New Revision: 48900 URL: https://svnweb.freebsd.org/changeset/doc/48900 Log: Update of the firewall chapter part 2/4 -> PF Reviewed by: bcr Differential Revision: https://reviews.freebsd.org/D6738 Modified: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml Sun Jun 5 15:47:50 2016 (r48899) +++ head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Jun 7 11:22:53 2016 (r48900) @@ -293,306 +293,1384 @@ - Paket Filter (PF) von OpenBSD und - <acronym>ALTQ</acronym> + + PF + - JohnFerrellRevised and updated by + + + John + Ferrell + + Überarbeitet und aktualisiert von + - - firewall PF - Im Juli 2003 wurde PF, die - Standard-Firewall von OpenBSD, nach &os; portiert und in die - &os;-Ports-Sammlung aufgenommen. 2004 war PF in - &os; 5.3 Teil des Basissystems. Bei PF - handelt es sich um eine komplette, vollausgestattete Firewall, - die optional auch ALTQ (Alternatives - Queuing) unterstützt. ALTQ bietet Ihnen + In &os; 5.3 wurde PF von + OpenBSD in das Basissystem integriert. Bei + PF handelt es sich um eine komplette, + voll ausgestattete Firewall, die optional auch + ALTQ (Alternatives Queuing) + unterstützt. ALTQ stellt Quality of Service - (QoS)-Bandbreitenformung. + (QoS) zur Verfügung. - Das OpenBSD-Projekt leistet bereits hervorragende - Dokumentationsarbeit mit der PF FAQ. Aus diesem Grund - konzentriert sich dieser Handbuchabschnitt nur auf diejenigen - Besonderheiten von PF, die &os; betreffen, sowie ein - paar allgemeine Informationen hinsichtlich der Verwendung. Genauere - Informationen zum Einsatz erhalten Sie in der PF FAQ. - - Weitere Informationen zu PF für &os; finden - Sie unter http://pf4freebsd.love2party.net/. + Das OpenBSD-Projekt pflegt die maßgebliche Referenz von + PF in der PF FAQ. + Peter Hansteen betreut ein sehr ausführliches + PF-Tutorial unter + http://home.nuug.no/~peter/pf/. + + + Bedenken Sie beim Studium der PF FAQ, + dass &os; die PF-Version aus + OpenBSD 4.5 enthält. + + + Die &a.pf; ist ein guter Anlaufpunkt für Fragen zur + Konfiguration und dem Einsatz der + PF-Firewall. Überprüfen Sie + aber zunächst die Archive der Mailingliste, bevor Sie eine + Frage stellen. Vielleicht wurde die Frage dort schon + beantwortet. + + Weitere Informationen über die Portierung von + PF nach &os; finden Sie unter + http://pf4freebsd.love2party.net/. + + Dieser Abschnitt konzentriert sich auf + PF in &os;. Es wird beschrieben, wie + PF und + ALTQ aktiviert werden. Anschließend + wird demonstriert, wie Regelsätze auf einem &os;-System erstellt + werden. - Verwendung der PF-Kernelmodule + <application>PF</application> aktivieren + + Damit PF benutzt werden kann, + muss zunächst das Kernelmodul geladen werden. Dieser + Abschnitt beschreibt die Einträge für + /etc/rc.conf, die verwendet werden können + um PF zu aktivieren. - Um die PF Kernel Module zu laden, fügen Sie folgende - Zeile in ihre /etc/rc.conf ein: + Beginnen Sie mit folgender Zeile in + /etc/rc.conf: pf_enable="YES" - Danach starten Sie das Startup Script um die Module - zu laden: + &man.pfctl.8; beschreibt zusätzliche Optionen, die beim + Start an PF übergeben werden + können. Fügen Sie diesen Eintrag in + /etc/rc.conf hinzu und schreiben Sie die + benötigten Optionen zwischen die Anführungszeichen: + + pf_flags="" # additional flags for pfctl startup + + PF kann nicht gestartet werden, + wenn es seine Konfigurationsdatei nicht findet. In der + Voreinstellung existiert bereits ein Regelsatz namens + /etc/pf.conf. Wenn bereits ein Regelsatz + an anderer Stelle gespeichert wurde, fügen Sie in + /etc/rc.conf einen Eintrag mit dem + vollständigen Pfad zur Datei ein: - &prompt.root; /etc/rc.d/pf start + pf_rules="/path/to/pf.conf" - Das PF Modul wird nicht geladen, falls es die Ruleset - Konfigurationsdatei nicht findet. Standardmässig befindet - sich diese Datei in /etc/pf.conf. Falls das - PF Ruleset sich an einem anderen Platz befindet, können Sie das - durch Hinzufügen einer Zeile ähnlich der folgenden, in - ihrer /etc/rc.conf ändern: + Protokollierungsfunktionen für + PF werden von &man.pflog.4; zur + Verfügung gestellt. Fügen Sie folgende Zeile in + /etc/rc.conf ein, um diese Funktion zu + aktivieren: - pf_rules="/path/to/pf.conf" + pflog_enable="YES" + + Die folgenden Zeilen können ebenfalls hinzugefügt werden, + um den Speicherort der Protokolldatei zu bestimmen und weitere + Optionen beim Start an &man.pflog.4; zu übergeben: + + pflog_logfile="/var/log/pflog" # where pflogd should store the logfile +pflog_flags="" # additional flags for pflogd startup + + Falls ein LAN hinter der Firewall + existiert und die Pakete an die Rechner im + LAN weitergeleitet werden müssen, oder + wenn NAT benötigt wird, fügen Sie die + folgende Option hinzu: + + gateway_enable="YES" # Enable as LAN gateway + + Nachdem die Änderungen gespeichert wurden, kann + PF mit Unterstützung für + Protokollierung gestartet werden: + + &prompt.root; service pf start +&prompt.root; service pflog start + + - Das PF-Modul kann auch manuell über die - Kommandozeile geladen werden: + In der Voreinstellung liest PF + seine Konfiguration aus /etc/pf.conf und + modifiziert, verwirft oder akzeptiert Pakete anhand der + Definitionen in dieser Datei. &os; enthält mehrere + Beispieldateien unter + /usr/share/examples/pf/. Auch die + PF + FAQ enthält sehr ausführliche Beispiele für + PF-Regeln. + + Zur Steuerung von PF wird + pfctl verwendet. + fasst einige nützliche Optionen für diesen Befehl zusammen. + Eine Beschreibung aller verfügbaren Optionen finden Sie in + &man.pfctl.8;. - &prompt.root; kldload pf.ko + + Nützliche <command>pfctl</command> Optionen - Protokollierungsfunktionen für PF werden durch das Modul - pflog.ko zur Verfügung gestellt und - können durch folgenden Eintrag in der - /etc/rc.conf aktiviert werden: + + + + Kommando + Aufgabe + + - pflog_enable="YES" + + + pfctl -e + PF aktivieren + - Danach starten Sie das Startup Script, um das Modul - zu laden: + + pfctl -d + PF + deaktivieren + - &prompt.root; /etc/rc.d/pflog start + + pfctl -F all -f + /etc/pf.conf + Alle Filterregeln zurücksetzen + (NAT, Filter, Zustandstabelle) und + /etc/pf.conf erneut + einlesen. + - Falls Sie noch weitere Features für - PF benötigen, müssen Sie diese in den - Kernel einbauen. + + pfctl -s [ rules | nat | + states ] + Zusammenfassung der Filterregeln, + NAT-Regeln, oder der + Zustandstabelle. + + + + pfctl -vnf + /etc/pf.conf + Überprüft /etc/pf.conf auf + Fehler, lädt aber die Filterregeln nicht neu. + + + +
+ + + security/sudo ist nützlich um + Kommandos mit erhöhten Berechtigungen auszuführen, wie + beispielsweise pfctl. Das Programm kann + aus der Ports-Sammlung installiert werden. + + + Um den ein- und ausgehenden Verkehr im Auge zu behalten, + können Sie ein Werkzeug wie sysutils/pftop + benutzen. Sobald das Programm installiert ist, können Sie + pftop ausführen, um einen Snapshot + des Datenverkehrs zu sehen. Das Format der Ausgabe ist der + von &man.top.1; sehr ähnlich. - PF Kernel-Optionen + <application>ALTQ</application> aktivieren - - Kerneloptionen + Unter &os; kann ALTQ zusammen + mit PF benutzt werden, um Quality + of Service (QoS) bereitzustellen. Sobald + ALTQ aktiviert ist, können + Warteschlangen definiert werden, mit denen Sie die Priorität + für ausgehende Pakete festlegen können. + + Bevor Sie ALTQ aktivieren, + sollten Sie &man.altq.4; lesen und sicherstellen, das der + Treiber der Netzwerkkarte diese Funktion unterstützt. + + ALTQ steht nicht als ladbares + Kernelmodul zur Verfügung. Wenn die Netzwerkkarte des Systems + ALTQ unterstützt, erstellen Sie + nach den Anweisungen in einen + angepassten Kernel. Als erstes muss + ALTQ aktiviert werden. Zudem ist + mindestens eine weitere Option nötig, um den Algorithmus für + die Warteschlange zu bestimmen: - device pf - + options ALTQ +options ALTQ_CBQ # Class Based Queuing (CBQ) +options ALTQ_RED # Random Early Detection (RED) +options ALTQ_RIO # RED In/Out +options ALTQ_HFSC # Hierarchical Packet Schedule (HFSC) +options ALTQ_PRIQ # Priority Queuing (PRIQ) - - Kerneloptionen + Die folgenden Algorithmen stehen zur Verfügung: - device pflog - + + + CBQ + + Class Based Queuing (CBQ) erlaubt + es, die Bandbreite einer Verbindung in verschiedene + Klassen oder Warteschlangen zu unterteilen, um die + Priorität von Datenpaketen basierend auf Filterregeln zu + beeinflussen. + + - - Kerneloptionen + + RED + + Random Early Detection (RED) wird + eingesetzt, um eine Überlastung des Netzwerks zu + vermeiden. Dazu ermittelt RED 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 nach dem + Zufallsprinzip verworfen. + + - device pfsync - + + RIO + + Random Early Detection In and Out + (RIO). Dieser Modus verwaltet + mehrere Warteschlangen durchschnittlicher Größe mit + mehreren Schwellwerten, eine für jedes + QoS-Level. + + - Es ist nicht zwingend nötig, dass Sie - PF-Unterstützung in den &os;-Kernel - kompilieren. Sie werden dies tun müssen, um eine von PFs - fortgeschritteneren Eigenschaften nutzen zu können, die nicht als - Kernelmodul verfügbar ist. Genauer handelt es sich dabei um - &man.pfsync.4;, ein Pseudo-Gerät, welches bestimmte - Änderungen der PF-Zustandstabelle offenlegt. - Es kann mit &man.carp.4; kombiniert werden, um ausfallsichere - Firewalls mit PF zu realisieren. Weitere - Informationen zu CARP erhalten Sie in - des Handbuchs. - - Die Kernelkonfigurationsoptionen von PF befinden - sich in /usr/src/sys/conf/NOTES und sind im - Folgenden wiedergegeben: + + HFSC + + Hierachical Fair Service Curve Packet Scheduler + (HFSC) wird in + http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html + beschrieben. + + - device pf -device pflog -device pfsync + + PRIQ + + Priority Queuing (PRIQ) lässt den + Verkehr einer Warteschlange mit höherer Priorität zuerst + durch. + + + - Die Option device pf aktiviert die - Unterstützung für die Packet - Filter-Firewall (&man.pf.4;). + Weitere Informationen über diese Algorithmen und Beispiele + für Regelsätze finden Sie unter + http://www.openbsd.org/faq/pf/queueing.html. + - Die Option device pflog aktiviert das optionale - &man.pflog.4;-Pseudonetzwerkgerät, das zum Protokollieren - des Datenverkehrs über einen &man.bpf.4;-Deskriptor - dient. &man.pflogd.8; ist in der Lage, diese Protokolldateien - auf Ihre Platte zu speichern. + + + <application>PF</application> Regelsätze + + + + + Peter + Hansteen + N. M. + + Beigetragen von + + + + + Dieser Abschnitt beschreibt die Erstellung von angepassten + Regelsätzen. Es wird mit dem einfachsten Regelsatz begonnen + auf dem dann weitere aufgebaut werden, um die + Konzepte und Funktionen von PF an + einigen konkreten Beispielen zu verdeutlichen. + + Der einfachste Regelsatz gilt für einen Rechner, der + keine Dienste anbietet und Zugriff auf das Internet haben + soll. Für diesen minimalen Regelsatz wird + /etc/pf.conf wie folgt + konfiguriert: + + block in all +pass out all keep state + + Die erste Regel blockiert jeglichen eingehenden + Datenverkehr. Die zweite Regel erlaubt ausgehende + Verbindungen von diesem Rechner, während die + Zustandsinformationen dieser Verbindungen gespeichert werden. + Diese Zustandsinformationen machen es möglich, den + Antwortverkehr für diese Verbindungen zu erlauben. Der + Regelsatz wird mit dem folgenden Befehl geladen: + + &prompt.root; pfctl -e ; pfctl -f /etc/pf.conf + + Neben den Zustandsinformationen verfügt + PF über + Listen und + Makros. Diese können bei der + Erstellung der Regeln definiert werden. Makros können Listen + enthalten und sie müssen vor ihrer ersten Benutzung definiert + sein. Fügen Sie beispielsweise folgende Zeilen an den Anfang + des Regelsatzes: + + tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" +udp_services = "{ domain }" + + PF versteht sowohl Portnamen + als auch Portnummern, solange die Namen in + /etc/services aufgeführt sind. Dieses + Beispiel erstellt zwei Makros. Das erste ist eine Liste mit + sieben TCP-Portnamen, die zweite Liste + enthält einen UDP-Portnamen. Sobald ein + Makro definiert ist, kann es in den Regeln verwendet werden. + In diesem Beispiel wird der gesamte Datenverkehr geblockt, mit + Ausnahme der Verbindungen die von diesem Rechner initiiert + wurden und sich auf einen der angegebenen + TCP-Dienste oder den + UDP-Dienst beziehen: + + tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" +udp_services = "{ domain }" +block all +pass out proto tcp to any port $tcp_services keep state +pass proto udp to any port $udp_services keep state + + Obwohl UDP als zustandsloses Protokoll + betrachtet wird, ist PF in der Lage + einige Zustandsinformationen zu verfolgen. Wenn + beispielsweise eine UDP-Abfrage für einen + Nameserver das System verlässt, wird + PF nach der Antwort Ausschau halten + und das Antwortpaket durch lassen. + + Nachdem der Regelsatz verändert wurde, muss er neu geladen + werden: + + &prompt.root; pfctl -f /etc/pf.conf + + Wenn keine Syntaxfehler festgestellt werden, wird + pfctl keine Ausgabe erzeugen. Die Syntax + kann auch getestet werden, bevor der Regelsatz geladen + wird: + + &prompt.root; pfctl -nf /etc/pf.conf + + Die Option bewirkt, dass die Regeln + nur interpretiert, jedoch nicht geladen werden. Dies bietet + die Möglichkeit, alle Fehler zu korrigieren. Es wird immer + der letzte gültige Regelsatz geladen, bis + PF entweder deaktiviert, oder ein + neuer Regelsatz geladen wird. + + + Wenn Sie beim Laden oder Prüfen des Regelsatzes noch die + Option hinzufügen, wird + pfctl den komplett interpretierten + Regelsatz anzeigen. Dies ist äußerst nützlich, wenn Sie + versuchen Fehler im Regelsatz zu finden. + + + + Einfaches Gateway mit <acronym>NAT</acronym> + + Dieser Abschnitt zeigt wie ein &os;-System mit + PF als Gateway konfiguriert wird. + Das Gateway muss über mindestens zwei Netzwerkkarten + verfügen, die jeweils mit einem separaten Netzwerk verbunden + sind. In diesem Beispiel ist xl1 mit + dem Internet verbunden und xl0 ist mit + dem internen Netzwerk verbunden. + + Aktivieren Sie zunächst das Gateway, damit der Rechner + den Netzwerkverkehr von einer Schnittstelle zur nächsten + weiterleiten kann. Diese + sysctl-Einstellung sorgt dafür, + dass IPv4-Pakete weitergeleitet + werden: + + &prompt.root; sysctl net.inet.ip.forwarding=1 + + So leiten Sie IPv6-Datenverkehr + weiter: + + &prompt.root; sysctl net.inet6.ip6.forwarding=1 + + Um diese Einstellungen beim Systemstart zu aktivieren, + fügen Sie folgende Zeilen in + /etc/rc.conf ein: + + gateway_enable="YES" #für ipv4 +ipv6_gateway_enable="YES" #für ipv6 + + Prüfen Sie mit ifconfig, dass beide + Schnittstellen vorhanden und aktiv sind. + + Als nächstes erstellen Sie die nötigen + PF-Regeln, damit das Gateway den + Datenverkehr weiterleiten kann. Die folgende Regel erlaubt + den zustandsorientierten Verkehr aus dem Internet zu den + Rechnern im Netzwerk: + + pass in on xl1 from xl1:network to xl0:network port $ports keep state + + Diese Regel erlaubt lediglich den Datenverkehr über das + Gateway auf der internen Schnittstelle. Damit die Pakete + noch weiter gehen, wird eine passende Regel benötigt: + + pass out on xl0 from xl1:network to xl0:network port $ports keep state + + Obwohl diese beiden Regeln funktionieren, werden sie + in der Praxis so spezifisch selten benötigt. Ein lesbarer + Regelsatz ist oft ein sicherer Regelsatz. Der Rest dieses + Abschnitts zeigt, wie Sie die Regeln so einfach und lesbar + wie möglich halten. Zum Beispiel könnten die beiden Regeln + zu einer Regel zusammengefasst werden: + + pass from xl1:network to any port $ports keep state + + Die Notation interface:network kann + durch ein Makro ersetzt werden, um den Regelsatz besser + lesbar zu machen. Zum Beispiel könnte für das Netzwerk an + der internen Schnittstelle (xl0:network) + ein Makro namens $localnet definiert + werden. Alternativ könnte für die Definition von + $localnet auch eine + IP-Adresse/Netzmaske Notation verwendet + werden, um ein Netzwerk zu bezeichnen, beispielsweise + 192.168.100.1/24 für ein privates + Subnetz. + + Bei Bedarf kann für $localnet auch + eine Liste von Netzwerken definiert werden. Abhängig von + den Bedürfnissen kann $localnet auch für + eine typische Regel wie folgt verwendet werden: + + pass from $localnet to any port $ports keep state + + Der folgende Regelsatz erlaubt sämtlichen Verkehr, der + von den Rechnern im internen Netzwerk initiiert wird. + Zunächst werden zwei Makros definiert, die die externen und + internen 3COM-Schnittstellen repräsentieren. + + + Bei Einwählverbindungen wird tun0 + für die externe Schnittstelle verwendet. Bei + ADSL-Verbindungen, insbesondere denen + die PPP over Ethernet + (PPPoE) verwenden, ist die richtige + externe Schnittstelle tun0 und nicht + die physische Ethernet-Schnittstelle. + + + ext_if = "xl0" # macro for external interface - use tun0 for PPPoE +int_if = "xl1" # macro for internal interface +localnet = $int_if:network +# ext_if IP address could be dynamic, hence ($ext_if) +nat on $ext_if from $localnet to any -> ($ext_if) +block all +pass from { lo0, $localnet } to any keep state + + Dieser Regelsatz führt die NAT-Regel + ein, die verwendet wird, um die Übersetzung der + Netzwerkadressen von den nicht-routebaren Adressen im + internen Netzwerk auf die IP-Adresse der + externen Schnittstelle zu handhaben. Die Klammern im + letzten Teil der NAT-Regel + ($ext_if) werden angegeben, wenn die + IP-Adresse der externen Schnittstelle + dynamisch zugewiesen wird. Damit wird sichergestellt, dass + der Netzwerkverkehr ohne schwerwiegende Unterbrechungen + weiterläuft, auch wenn sich die externe + IP-Adresse ändert. + + Beachten Sie, dass dieser Regelsatz wahrscheinlich mehr + Verkehr aus dem Netzwerk zulässt, als eigentlich nötig ist. + Bei einem angemessenen Aufbau könnte folgendes Makro + erstellt werden: + + client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ + https, cvspserver, 2628, 5999, 8000, 8080 }" + + Dieses Makro wird dann in der Filterregel + benutzt: + + pass inet proto tcp from $localnet to any port $client_out \ + flags S/SA keep state + + Weitere pass Regeln werden + vielleicht noch benötigt. Diese Regel aktiviert + SSH auf der externen + Schnittstelle: + + pass in inet proto tcp to $ext_if port ssh + + Dieses Makrodefinition und Regel erlaubt + DNS und NTP für + interne Clients: + + udp_services = "{ domain, ntp }" +pass quick inet proto { tcp, udp } to any port $udp_services keep state + + Beachten Sie das Schlüsselwort quick + in dieser Regel. Da der Regelsatz aus mehreren Regeln + besteht, ist es wichtig, die Beziehungen zwischen den + einzelnen Regeln zu verstehen. Die Regeln werden von oben + nach unten ausgewertet, in der Reihenfolge wie sie + geschrieben sind. Für jedes Paket oder jede Verbindung, das + PF ausgewertet, wird die letzte + übereinstimmende Regel im Regelsatz angewendet. Wenn jedoch + ein Paket auf eine Regel passt, welche das Schlüsselwort + quick enthält, wird das Paket + entsprechend dieser Regel behandelt und die + Regelverarbeitung wird gestoppt. Diese Vorgehensweise ist + sehr nützlich, wenn eine Ausnahme von den allgemeinen Regeln + erforderlich ist. + - Die Option device pfsync aktiviert das optionale - &man.pfsync.4;-Pseudonetzwerkgerät für die - Überwachung von Statusänderungen. - + + Einen <acronym>FTP</acronym>-Proxy einrichten - - Verfügbare rc.conf-Optionen + Die Konfiguration einer funktionierenden Regel für + FTP kann aufgrund der Beschaffenheit des + FTP-Protokolls problematisch sein. + FTP ist sehr viel älter als Firewalls + und schon vom Design her unsicher. Die häufigsten Argumente + gegen eine Verwendung von FTP + sind: + + + + Passwörter werden im Klartext übertragen. + + + + Das Protokoll erfordert die Verwendung von + mindestens zwei TCP-Verbindungen + (Steuerung und Daten) auf separaten Ports. + + + + Wenn eine Sitzung aufgebaut wird, werden die Daten + auf zufällig ausgewählten Ports übermittelt. + + - Die folgenden &man.rc.conf.5;-Einträge konfigurieren - PF und &man.pflog.4; beim Systemstart: + All diese Punkte stellen Herausforderungen dar, noch + bevor die Client- oder Server-Software auf potenzielle + Sicherheitslücken überprüft wurde. Es existieren aber auch + sichere Alternativen für die Dateiübertragung, wie + &man.sftp.1; oder &man.scp.1;, wo die Authentifizierung und + die Datenübertragung über eine verschlüsselte Verbindung + erfolgt. + + Für Situationen, in denen FTP + erforderlich ist, kann PF den + FTP-Datenverkehr an ein kleines + Proxy-Programm namens &man.ftp-proxy.8; weiterleiten. + Dieses Programm ist im Basissystem von &os; enthalten. Die + Aufgabe des Proxies ist das dynamische Einfügen und + Entfernen von Regeln im Regelsatz. Dies wird durch den + Einsatz von Ankern erreicht, damit der + FTP-Verkehr korrekt verarbeitet werden + kann. + + Fügen Sie folgende Zeilen in + /etc/rc.conf ein, um den Proxy zu + aktivieren: + + ftpproxy_enable="YES" + + Danach kann der Proxy mit service ftp-proxy + start gestartet werden. + + Für die Grundkonfiguration müssen drei weitere Einträge + in /etc/pf.conf hinzugefügt werden. + Zunächst werden die Anker hinzugefügt, die der Proxy für die + FTP-Sitzungen verwendet: + + nat-anchor "ftp-proxy/*" +rdr-anchor "ftp-proxy/*" + + Dann wird eine pass-Regel benötigt, + damit der FTP-Datenverkehr durch den + Proxy geleitet werden kann. + + Die Regeln für Umleitung und NAT + müssen vor den eigentlichen Filterregeln definiert werden. + Fügen Sie diese rdr-Regel unmittelbar + nach der NAT-Regel ein: + + rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 + + Zum Schluss muss der umgeleitete Verkehr die Firewall + passieren dürfen: + + pass out proto tcp from $proxy to any port ftp + + $poxy enthält die Adresse, an dem der + Proxy-Daemon gebunden ist. + + Speichern Sie /etc/pf.conf und + laden Sie die Regeln neu. Prüfen Sie von einem Client, ob + die FTP-Verbindungen + funktionieren: + + &prompt.root; pfctl -f /etc/pf.conf + + Dieses Beispiel umfasst eine Grundkonfiguration, in der + die Rechner im lokalen Netzwerk Zugriff auf entfernte + FTP-Server benötigen. Diese + Konfiguration sollte mit den meisten + FTP-Clients und -Servern gut + funktionieren. Das Verhalten von &man.ftp-proxy.8; kann + durch diverse Optionen in ftpproxy_flags + beeinflusst werden. Einige Clients und Server haben + bestimmte Marotten, die bei der Konfiguration berücksichtigt + werden müssen. Es kann zum Beispiel notwendig sein, den + FTP-Datenverkehr für den Proxy einer + bestimmten Warteschlange zuzuweisen. + + Es besteht auch die Möglichkeit einen + FTP-Server mit + PF und &man.ftp-proxy.8; zu + schützen. Konfigurieren Sie einen separaten + ftp-proxy mit für den + Reverse-Modus auf einem separaten Port und einer eigenen + Umleitungsregel. + - pf_enable="YES" # PF aktivieren (Modul, wenn nötig, aktivieren) -pf_rules="/etc/pf.conf" # Datei mit Regeldefinitionen für pf -pf_flags="" # zusätzliche Parameter für den Start von pfctl -pflog_enable="YES" # starte pflogd(8) -pflog_logfile="/var/log/pflog" # wo soll pflogd die Protokolldatei speichern -pflog_flags="" # zusätzliche Parameter für den Start von pflogd + + <acronym>ICMP</acronym> verwalten - Wenn Sie ein lokales Netzwerk hinter dieser Firewall betreiben - und Pakete für dessen Rechner weiterleiten oder NAT verwenden - wollen, benötigen Sie zusätzlich die folgende Option: + Viele Werkzeuge zur Fehlerbehebung in + TCP/IP-Netzwerken verlassen sich auf das + Internet Control Message + Protocol (ICMP), das + speziell für diese Zwecke entwickelt wurde. + + Das ICMP-Protokoll sendet und + empfängt Kontrollnachrichten zwischen Rechnern und Gateways, + hauptsächlich um ungewöhnliche Bedingungen auf dem Weg zum + Zielrechner zu berichten. Router verwenden + ICMP um Paketgrößen und andere + Übertragungsparameter zu ermitteln. Dieser Prozess ist auch + als Path MTU + Discovery bekannt. + + Aus der Sicht einer Firewall sind einige + ICMP-Kontrollnachrichten anfällig für + bekannte Angriffsmethoden. Zwar ist die Fehlerbehebung + einfacher, wenn alle ICMP-Pakete + bedingungslos durch gelassen werden, aber dass macht es auch + für Angreifer leichter, Informationen über das Netzwerk zu + extrahieren. Aus diesen Gründen ist die folgende Regel nicht + optimal: + + pass inet proto icmp from any to any + + Eine Lösung besteht darin, nur den + ICMP-Verkehr aus dem lokalen Netz zu + akzeptieren, während ICMP-Pakete von + außerhalb des Netzwerks verworfen werden: + + pass inet proto icmp from $localnet to any keep state +pass inet proto icmp from any to $ext_if keep state + + Es stehen noch weitere Optionen zur Verfügung, die die + Flexibilität von PF + demonstrieren. Anstatt beispielsweise alle + ICMP-Nachrichten zu erlauben, kann man + die Nachrichten angeben, die von &man.ping.8; und + &man.traceroute.8; verwendet werden. Beginnen Sie damit, + ein Makro für diese Art von Nachrichten zu + definieren: + + icmp_types = "echoreq" + + Erstellen Sie dann eine Regel, die das eben erstellte + Makro benutzt: + + pass inet proto icmp all icmp-type $icmp_types keep state + + Wenn weitere Arten von + ICMP-Nachrichten benötigt werden, kann + die Liste icmp_types einfach erweitert + werden. Geben Sie more + /usr/src/contrib/pf/pfctl/pfctl_parser.c ein, um + eine Liste der von PF + unterstützten ICMP-Nachrichten zu sehen. + Die Webseite + http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml + enthält eine Erklärung für jeden Nachrichtentyp. + + Da &unix; traceroute in der + Voreinstellung UDP verwendet, wird eine + weitere Regel benötigt: + + # allow out the default range for traceroute(8): +pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state + + Da TRACERT.EXE unter + µsoft.windows;-Systemen ICMP Echo + Request Meldungen verwendet, ist nur die erste Regel + notwendig um Traces für solche Systeme zu ermöglichen. + &unix; traceroute kann aber auch andere + Protokolle verwenden, zum Beispiel ICMP + Echo Request, wenn der Schalter benutzt + wird. Details finden Sie in &man.traceroute.8;. + + + Path <acronym>MTU</acronym> Discovery + + Internet-Protokolle sind so ausgelegt, dass sie + geräteunabhängig sind. Eine Folge davon ist, dass die + optimale Paketgröße nicht immer zuverlässig vorhergesagt + werden kann. Das größte Hindernis ist hier die + Maximum Transmission Unit + (MTU), welche die Obergrenze für die + Paketgröße festlegt. Die MTU für die + Schnittstelle des Systems können Sie sich mit + ifconfig anzeigen lassen. + + TCP/IP benutzt ein Verfahren, das + als path MTU discovery + bekannt ist, um die korrekte Paketgröße für eine + Verbindung zu bestimmen. Dieses Verfahren sendet Pakete + unterschiedlicher Größe mit dem Flag do not + fragment und erwartet ein + ICMP-Antwortpaket vom Typ + type 3, code 4, wenn die Obergrenze + erreicht worden ist. Typ 3 bedeutet Ziel nicht + erreichbar und Code 4 ist die Abkürzung für + Fragmentierung nötig, aber Do-not-Fragment Flag ist + gesetzt. Um path MTU + discovery zu erlauben und damit + Verbindungen zu anderen MTUs zu + unterstützen, fügen Sie dem Makro + icmp_types den Typ destination + unreachable hinzu: + + icmp_types = "{ echoreq, unreach }" + + Da die pass-Regel bereits das Makro + verwendet, braucht es nicht geändert werden um den neuen + ICMP-Typ zu unterstützen: + + pass inet proto icmp all icmp-type $icmp_types keep state + + PF kann alle Variationen + von ICMP-Typen und Codes filtern. Eine + Liste der verfügbaren Typen und Codes ist in &man.icmp.4; + und &man.icmp6.4; dokumentiert. + + - gateway_enable="YES" # LAN Gateway aktivieren - + + Tabellen benutzen - - Filterregeln erstellen + Manchmal sind bestimmte Daten für die Filterung und + Weiterleitung interessant, jedoch wäre eine Definition einer + solchen Filterregel für einen Regelsatz viel zu lang. + PF unterstützt die Verwendung von + Tabellen. Dies sind definierte Listen, die verändert werden + können, ohne den gesamten Regelsatz neu laden zu müssen. + Zudem können diese Listen sehr schnell durchsucht werden. + Tabellennamen sind immer in < > + eingeschlossen und sehen wie folgt aus: + + table <clients> { 192.168.2.0/24, !192.168.2.5 } + + In diesem Beispiel ist das Netzwerk + 192.168.2.0/24 Teil der Tabelle. + 192.168.2.5 wurde im dem Operator + ! ausgeschlossen und ist somit nicht Teil + der Tabelle. Es ist auch möglich Tabellen aus Dateien zu + laden, wo jeder Eintrag in einer separaten Zeile steht. + Dieses Beispiel verwendet dazu die Datei + /etc/clients: + + 192.168.2.0/24 +!192.168.2.5 + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***