Index: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml (revision 49086) +++ head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml (revision 49087) @@ -1,4771 +1,4383 @@ Firewalls Joseph J.BarbishBeigetragen von BradDavisNach SGML konvertiert und aktualisiert von MichaelBunzelÜbersetzt von JohannKois BenjaminLukas firewall security firewalls Einführung Firewalls ermöglichen es, den ein- und ausgehenden Netzwerkverkehr eines Systems zu filtern. Dazu verwendet eine Firewall eine oder mehrere Gruppen von Regeln, um ankommende Netzwerkpakete zu untersuchen und entweder durchzulassen oder zu blockieren. Die Regeln einer Firewall untersuchen charakteristische Eigenschaften von Datenpaketen, darunter den Protokolltyp, die Quell- und Zieladresse sowie den Quell- und Zielport. Firewalls können die Sicherheit eines Rechners oder eines Netzwerks erhöhen, indem sie folgende Aufgaben übernehmen: Den Schutz der Anwendungen, Dienste und Rechner eines internen Netzwerks vor unerwünschtem Datenverkehr aus dem Internet. Die Beschränkung des Zugriffs von Rechnern des internen Netzwerks auf Rechner oder Dienste des öffentlichen Internets. Den Einsatz von Network Address Translation (NAT), welches es durch die Verwendung von privaten IP-Adressen ermöglicht, eine einzige gemeinsame Internetverbindung für mehrere Rechner zu nutzen. Dies geschieht entweder über eine einzige IP-Adresse oder über eine Gruppe von jeweils automatisch zugewiesenen öffentlichen Adressen. Das Basissystem von &os; enthält drei Firewalls: PF, IPFW und IPFILTER (auch als IPF bekannt). &os; enthält ebenfalls zwei Traffic-Shaper zur Kontrolle der Bandbreite: &man.altq.4; und &man.dummynet.4;. ALTQ ist traditionell eng an PF gebunden, während dummynet zusammen mit IPFW verwendet wird. Gemeinsam ist allen Firewalls, dass sie Regeln einsetzen, um den Transfer von ein- und ausgehenden Datenpaketen des Systems zu steuern. Unterschiedlich ist aber die Art und Weise, wie dies realisiert wird. Auch die für diese Regeln verwendete Syntax ist unterschiedlich. &os; besitzt mehrere Firewalls, um den unterschiedlichen Anforderungen und Vorlieben von Benutzern gerecht zu werden. Jeder Benutzer sollte selbst beurteilen, welche Firewall seinen Bedürfnissen am besten entspricht. Nachdem Sie dieses Kapitel gelesen haben, werden Sie wissen: Wie man Paketfilterregeln erstellt. Was die Unterschiede zwischen den in &os; eingebauten Firewalls sind. Wie die PF-Firewall konfiguriert und einsetzt wird. Wie die IPFW-Firewall konfiguriert und einsetzt wird. Wie die IPFILTER-Firewall konfiguriert und einsetzt wird. Bevor Sie dieses Kapitel lesen, sollten Sie: Die grundlegenden Konzepte von &os; und dem Internet verstehen. Da alle Firewalls auf der Inspektion ausgewählter Kontrollfelder in Datenpaketen basieren, muss für die Erstellung von Firewallregeln ein grundlegendes Verständnis von TCP/IP vorhanden sein. Eine gute Einführung finden Sie in Daryl's TCP/IP Primer. Firewallkonzepte firewall Regelsatz Ein Regelsatz besteht aus einer Gruppe von Regeln, die Pakete basierend auf ihren Inhalt entweder blockieren oder durchlassen. Der bidirektionale Austausch von Paketen zwischen zwei Rechnern wird als Sitzung (Session) bezeichnet. Der Regelsatz verarbeitet sowohl ankommende Pakete aus dem Internet, als auch die vom System erzeugten Antwortpakete. Jeder TCP/IP-Dienst hat ein festgelegtes Protokoll und einen vorgegebenen Port. Pakete für einen bestimmten Dienst stammen von einer Quelladresse und einem unprivilegierten Port und gehen an einen spezifischen Port auf der Zieladresse. Alle oben genannten Parameter können als Selektionskriterien verwendet werden, um einen Regelsatz zu erstellen, der den Zugriff auf bestimmte Dienste gewährt oder blockiert. Unbekannte Portnummern können Sie in /etc/services nachschlagen. Alternativ finden Sie die Portnummern und deren Verwendungszweck auf http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers. Die Seite http://www.sans.org/security-resources/idfaq/oddports.php enthält eine Liste der Portnummern, die auch von Trojanern benutzt werden. FTP hat zwei Modi: Aktiv und Passiv. Unterschied liegt in der Bestimmung des Datenkanals. Der Passiv-Modus ist sicherer, da der Datenkanal vom Client bestimmt wird. Eine ausführliche Erklärung von FTP und den verschiedenen Modi finden Sie unter http://www.slacksite.com/other.ftp.html. Ein Firewall-Regelsatz kann entweder einschließend (inclusive firewall) oder ausschließend (exclusive Firewall) sein. Eine ausschließende Firewall lässt jeden Datenverkehr durch, der nicht durch eine Regel ausgeschlossen wurde. Eine einschließende Firewall macht das genaue Gegenteil. Sie lässt Datenverkehr nur dann passieren, wenn dieser einer der definierten Regeln entspricht. Eine einschließende Firewall bietet eine wesentlich bessere Kontrolle des ausgehenden Verkehrs, was sie zur besseren Wahl für Systeme macht, welche Dienste für das Internet anbieten. Sie kontrolliert auch den Verkehr aus dem öffentlichen Internet zum privaten Netzwerk. Jeder Verkehr, der keiner Regel entspricht wird geblockt und protokolliert. Einschließende Firewalls sind generell sicherer als ausschließende Firewalls, da sie das Risiko, dass unerwünschter Verkehr hindurch geht, drastisch reduzieren. Wenn nicht anders vermerkt, verwenden alle Konfigurationen und Regelsätze in diesem Kapitel einschließende Firewalls. Die Sicherheit kann durch den Einsatz einer zustandsorientierten Firewall (stateful firewall) weiter erhöht werden. Dieser Typ Firewall überwacht alle offenen Verbindungen und erlaubt nur Datenverkehr von bereits bestehenden Verbindungen oder wenn eine neue Verbindung aufgebaut wird. Eine zustandsorientierte Firewall behandelt den Verkehr als einen bidirektionalen Austausch von Paketen während einer Session. Wenn ein Zustand für eine passende Regel angegeben wird, erstellt die Firewall dynamisch interne Regeln für jedes Paket, das während dieser Session ausgetauscht wird. Die Firewall hat ausreichend Möglichkeiten, um zu bestimmen, ob ein Paket zu einer Session gehört. Alle Pakete, die nicht zu dieser Session passen, werden automatisch abgelehnt. Sobald die Session beendet ist, wird sie aus der dynamischen Zustandstabelle entfernt. Eine zustandsorientierte Filterung erlaubt es, sich auf die Sperrung bzw. Freigabe von neuen Sessions zu konzentrieren. Wenn eine neue Session genehmigt wird, werden alle nachfolgenden Pakete dieser Session automatisch erlaubt und betrügerische Pakete werden automatisch abgelehnt. Wenn eine neue Session nicht genehmigt wird, werden alle nachfolgenden Pakete dieser Session abgelehnt. Die zustandsorientierte Filterung bietet fortgeschrittene Fähigkeiten zur Abwehr von verschiedensten Angriffsmethoden, die von Angreifern eingesetzt werden. NAT steht für Network Address Translation. Die NAT-Funktion ermöglicht es einem privaten LAN hinter einer Firewall, sich eine einzelne vom ISP zugewiesene IP-Adresse zu teilen, auch wenn die Adresse dynamisch zugewiesen wird. NAT ermöglicht den Internetzugriff für jeden Rechner im LAN, ohne dass der ISP für mehrere Internet-Konten bezahlt wird. NAT übersetzt automatisch die private IP-Adresse auf die öffentliche IP-Adresse, sobald ein Paket für das öffentliche Internet die Firewall passiert. Zusätzlich führt es auch die Übersetzung der Anwortpakete durch. Gemäß RFC 1918 sind die folgenden IP-Adressbereiche für private Netzwerke reserviert und werden nie ins öffentliche Internet weitergeleitet. Daher sind diese Bereiche für den Einsatz mit NAT geeignet: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Seien Sie äußerst vorsichtig wenn Sie mit Firewallregeln arbeiten. Durch eine falsche Konfiguration kann der Administrator den Zugriff auf den Server verlieren. Um auf der sicheren Seite zu sein, sollten Sie die anfängliche Konfiguration der Firewall von der lokalen Konsole durchführen, anstatt dass Sie dies aus der Ferne über ssh tun. PF John Ferrell Überarbeitet und aktualisiert von firewall PF 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) zur Verfügung. 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. <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. Beginnen Sie mit folgender Zeile in /etc/rc.conf: pf_enable="YES" &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: pf_rules="/path/to/pf.conf" 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: 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 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;. Nützliche <command>pfctl</command> Optionen Kommando Aufgabe pfctl -e PF aktivieren pfctl -d PF deaktivieren pfctl -F all -f /etc/pf.conf Alle Filterregeln zurücksetzen (NAT, Filter, Zustandstabelle) und /etc/pf.conf erneut einlesen. 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. <application>ALTQ</application> aktivieren 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: 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) Die folgenden Algorithmen stehen zur Verfügung: 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. 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. 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. HFSC Hierachical Fair Service Curve Packet Scheduler (HFSC) wird in http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html beschrieben. PRIQ Priority Queuing (PRIQ) lässt den Verkehr einer Warteschlange mit höherer Priorität zuerst durch. Weitere Informationen über diese Algorithmen und Beispiele für Regelsätze finden Sie unter http://www.openbsd.org/faq/pf/queueing.html. <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. Einen <acronym>FTP</acronym>-Proxy einrichten 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. 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. <acronym>ICMP</acronym> verwalten 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. Tabellen benutzen 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 Um sich auf diese Datei zu beziehen, definieren Sie die Tabelle wie folgt: table <clients> persist file "/etc/clients" Sobald die Tabelle definiert ist, kann eine Filterregel Bezug darauf nehmen: pass inet proto tcp from <clients> to any port $client_out flags S/SA keep state Die Inhalte einer Tabelle können mit pfctl direkt verändert werden. Dieses Beispiel fügt ein weiteres Netzwerk zur Tabelle hinzu: &prompt.root; pfctl -t clients -T add 192.168.1.0/16 Beachten Sie, dass auf diese Weise vorgenommene Änderungen direkt übernommen werden, jedoch bei einem Neustart des Systems oder bei einem Stromausfall verloren gehen. Um die Änderungen dauerhaft zu speichern, müssen sie in der Definition der Tabelle oder in der Datei, auf die sich die Tabelle bezieht, bearbeitet werden. Mit einem &man.cron.8; Job und einem Befehl wie pfctl -t clients -T show >/etc/clients können Sie auch eine Kopie der Tabelle auf Platte speichern und dann in regelmäßigen Abständen aktualisieren. Alternativ kann /etc/clients auch mit den Tabelleneinträgen, die sich aktuell im Speicher befinden, aktualisiert werden. &prompt.root; pfctl -t clients -T replace -f /etc/clients Verwendung von Tabellen zum Schutz von <acronym>SSH</acronym> Benutzer, die SSH auf einer externen Schnittstelle ausführen, haben wahrscheinlich schon einmal ähnliche Meldungen in den Protokolldateien gesehen: Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:35 skapet sshd[5279]: Received disconnect from 200.72.41.31: 11: Bye Bye Sep 26 03:12:44 skapet sshd[29635]: Invalid user admin from 200.72.41.31 Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2 Diese Meldungen deuten auf einen Brute-Force-Angriff hin, bei dem ein Angreifer oder ein Programm versucht, den Benutzernamen und das Passwort zu erraten, um Zugriff auf das System zu bekommen. Wenn der Zugriff über SSH für berechtigte Benutzer erforderlich ist, kann eine Änderung des Standard-Ports für SSH einen gewissen Schutz bieten. Allerdings bietet PF eine elegantere Lösung für dieses Problem. pass-Regeln können Einschränkungen für Dinge enthalten, die ein verbindender Rechner tun kann. Bei einem Verstoß gegen diese Einschränkungen kann dann dem betroffenen Rechner der Zugriff teilweise oder ganz entzogen werden. Es ist sogar möglich, alle bestehenden Verbindungen zu trennen, falls die Grenze überschritten wird. Um dies zu konfigurieren, erstellen Sie folgende Tabelle im Regelsatz: table <bruteforce> persist Fügen Sie dann ziemlich am Anfang der Filterregeln folgende Regeln hinzu, um die Brute-Force-Angriffe zu blocken und gleichzeitig berechtigte Verbindungen zu erlauben: block quick from <bruteforce> pass inet proto tcp from any to $localnet port $tcp_services \ flags S/SA keep state \ (max-src-conn 100, max-src-conn-rate 15/5, \ overload <bruteforce> flush global) Der Teil in Klammern definiert die Grenzwerte. Die Zahlen sollten an die lokalen Anforderungen angepasst werden. Die Zeilen können wie folgt interpretiert werden: max-src-conn definiert die maximal erlaubte Anzahl gleichzeitiger Verbindungen von einem Rechner. max-src-conn-rate definiert die maximal erlaubte Anzahl neuer Verbindungen eines einzelnen Rechners (15) pro Anzahl von Sekunden (5). overload <bruteforce> bedeutet, dass jeder Rechner, der diesen Grenzwert überschreitet, zur Tabelle bruteforce hinzugefügt wird. Diese Filterregel blockiert jeglichen Datenverkehr von Adressen aus der Tabelle bruteforce. flush global besagt, dass alle (global) Verbindungen dieses Rechners getrennt (flush) werden, wenn der Grenzwert erreicht wird. Diese Filterregeln helfen nicht bei langsamen Brute-Force-Angriffen, wie sie in http://home.nuug.no/~peter/hailmary2013/ beschrieben sind. Dieser Beispielregelsatz dient lediglich als Illustration. Wenn Sie allgemein eine große Anzahl an Verbindungen erlauben wollen, aber gleichzeitig bei SSH etwas restriktiver vorgehen möchten, können Sie die obige Regel ergänzen: pass quick proto { tcp, udp } from any to any port ssh \ flags S/SA keep state \ (max-src-conn 15, max-src-conn-rate 5/3, \ overload <bruteforce> flush global) Es ist möglicherweise nicht notwendig, alle aggressiven Rechner zu blockieren Es ist zu erwähnen, dass der overlaod-Mechanismus eine allgemeine Technik darstellt, die nicht auf SSH beschränkt ist. Außerdem ist es nicht immer optimal, Datenverkehr von aggressiven Rechnern zu blockieren. Eine overload-Regel kann beispielsweise benutzt werden, um einen Mail- oder Webserver zu schützen. Die overload-Tabelle könnte dann in einer Regel verwendet werden, um aggressive Rechner einer Warteschlange mit geringerer Bandbreite zuzuweisen, oder den Rechner auf eine bestimtme Webseite umzuleiten. Im Laufe der Zeit werden die Tabellen durch die overload-Regeln immer größer und belegen immer mehr Speicher. Manchmal wird eine geblockte IP-Adresse einem Rechner dynamisch zugewiesen, der eigentlich berechtigt ist, mit den Rechnern im lokalen Netzwerk zu kommunizieren. Für solche Situationen bietet pfctl die Möglichkeit, Tabelleneinträge auslaufen zu lassen. Dieses Kommando würde beispielsweise Einträge aus der Tabelle <bruteforce> löschen, die seit 86400 Sekunden nicht mehr referenziert wurden: &prompt.root; pfctl -t bruteforce -T expire 86400 Eine ähnliche Funktionalität bietet security/expiretable, welches Einträge entfernt, die für einen bestimmten Zeitraum nicht referenziert wurden. Nach der Installation kann expiretable benutzt werden, um Einträge aus der Tabelle <bruteforce> nach einer bestimmten Zeit zu entfernen. Dieses Beispiel entfernt alle Einträge, die älter sind als 24 Stunden: /usr/local/sbin/expiretable -v -d -t 24h bruteforce Schutzt vor <acronym>SPAM</acronym> Im Gegensatz zum spamd-Daemon von spamassassin, kann mail/spamd zusammen mit PF den SPAM direkt an der Firewall abwehren. Dieser spamd wird in PF über einen Satz von Umleitungen konfiguriert. Spammer neigen dazu, eine große Anzahl von Nachrichten zu versenden. Dabei nutzten Sie SPAM-freundliche Netzwerke und gekaperte Rechner, welche dann ziemlich schnell bei sogenannten Blacklists gemeldet werden. Wenn eine SMTP-Verbindung von einer Adresse in der Blacklist empfangen wird, präsentiert spamd einen Banner und schaltet sofort in einen Modus, in dem die Antworten auf den SMTP-Verkehr jeweils ein Byte groß sind. Diese Technik, die möglichst viel Zeit des Spammers verschwenden soll, wird Tarpitting genannt. Die spezifische Implementierung, welche ein Byte SMTP-Antworten verwendet, wird als Stuttering bezeichnet. Dieses Beispiel zeigt das grundlegende Verfahren zur Konfiguration von spamd mit automatisch aktualisierten Blacklists. Für weitere Informationen lesen die Manualpages, die zusammen mit mail/spamd installiert werden. Konfiguration von <application>spamd</application> Installieren Sie das Paket oder den Port mail/spamd. Um spamd's Greylisting-Funktion zu nutzen, muss &man.fdescfs.5; in /dev/fd eingehängt werden. Fügen Sie folgende Zeile in /etc/fstab ein: fdescfs /dev/fd fdescfs rw 0 0 Danach hängen Sie das Dateisystem ein: &prompt.root; mount fdescfs Fügen Sie folgende Zeilen in den PF-Regelsatz ein: table <spamd> persist table <spamd-white> persist rdr pass on $ext_if inet proto tcp from <spamd> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 rdr pass on $ext_if inet proto tcp from !<spamd-white> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 Die beiden Tabellen <spamd> und <spam-white> sind von großer Bedeutung. SMTP-Verkehr von einer Adresse, die in <spamd> aber nicht in <spamd-white> ist, wird an den spamd-Daemon auf Port 8025 umgeleitet. Im nächsten Schritt wird spamd in /usr/local/etc/spamd.conf konfiguriert und einige Parameter werden in /etc/rc.conf hinzugefügt. Die Installation von mail/spamd enthält eine Beispielkonfiguration (/usr/local/etc/spamd.conf.sample) und eine Manualpage für spamd.conf. Beziehen Sie sich für zusätzliche Konfigurationsoptionen auf diese Dokumentation. Die Konfigurationsdatei enthält einen Block, in dem die all-Liste definiert ist, die wiederum weitere Listen spezifiziert: all:\ :traplist:whitelist: Dieser Eintrag fügt die gewünschten Blacklists, getrennt durch einen Doppelpunkt (:), hinzu. Um auch eine Whitelist zu verwenden, fügen Sie den Namen unmittelbar hinter dem Namen der Blacklist ein. Zum Beispiel: :Blacklist:Whitelist:. Danach folgt die Definition der verwendeten Blacklist: traplist:\ :black:\ :msg="SPAM. Your address %A has sent spam within the last 24 hours":\ :method=http:\ :file=www.openbsd.org/spamd/traplist.gz In der ersten Zeile steht der Name der Blacklist und die zweite Zeile gibt den Typ an. Das Feld msg enthält die Nachricht, die dem Absender während des SMTP-Dialogs angezeigt wird. Das Feld mehtod legt fest, wie spamd-setup die Listen bezieht; unterstützte Methoden sind http, ftp, file und ein externes Programm via exec. Im letzten Feld gibt file den Namen der Datei an, die spamd erwartet. Die Definition der Whitelist ist ähnlich. Das Feld msg wird jedoch nicht definiert, da eine Meldung hier nicht erforderlich ist: whitelist:\ :white:\ :method=file:\ :file=/var/mail/whitelist.txt Wählen Sie die Datenquellen mit Sorgfalt: Bei der Verwendung von sämtlichen Blacklists aus der Beispieldatei spamd.conf würden große Teile des Internets geblockt. Der Administrator muss diese Datei bearbeiten, um eine optimale Konfiguration zu erzielen. Dazu gehört auch die Auswahl von geeigneten Blacklists und, wenn nötig, die Erstellung von benutzerdefinierten Listen. Als nächstes fügen Sie folgenden Eintrag in /etc/rc.conf hinzu. Zusätzliche Optionen sind in der Manualpage beschrieben: spamd_flags="-v" # use "" and see spamd-setup(8) for flags Wenn Sie fertig sind, starten Sie spamd durch die Eingabe von service obspamd start. Führen Sie die weitere Konfiguration mit spamd-setup durch. Erstellen Sie zum Schluss einen &man.cron.8;-Job, der spamd-setup in regelmäßigen Abständen aufruft, um die Listen zu aktualisieren. Auf einem typischen Gateway vor dem Mailserver, werden Rechner innerhalb von wenigen Minuten geblockt. PF unterstützt auch Greylisting, das Nachrichten von unbekannten Rechnern vorübergehend mit 45n-Codes ablehnt. Nachrichten von diesen Rechnern werden bei einem erneuten Versuch nach einer angemessenen Zeit durchgelassen. Nachrichten von Rechnern, die nach RFC 1123 und RFC 2821 konfiguriert sind, werden sofort durchgelassen. Weitere Informationen über Greylisting finden Sie unter greylisting.org. Das Erstaunlichste an Greylisting ist, neben der einfachen Benutzung, dass es immer noch funktioniert. Spammer und Malware-Autoren gelingt es bislang nur schwer, diese Technik zu umgehen. Die grundsätzliche Vorgehensweise zur Konfiguration von Greylisting ist wie folgt: Konfiguration von Greylisting Stellen Sie sicher, dass &man.fdescfs.5; eingehängt ist. Dies wird in Schritt 1 der vorherigen Prozedur beschrieben. Um spamd im Greylisting-Modus auszuführen, fügen Sie folgende Zeilen in /etc/rc.conf ein: spamd_grey="YES" # use spamd greylisting if YES Lesen Sie die Manualpage von spamd für Beschreibungen von zusätzlichen Parametern. Starten Sie die Dienste, um die Konfiguration von Greylisting abzuschließen: &prompt.root; service obspamd restart &prompt.root; service spamlogd start Hinter den Kulissen führen die spamdb-Datenbank und spamlogd wesentliche Aufgaben der Greylisting-Funktion aus. spamdb ist die Schnittstelle für den Administrator, der über den Inhalt der Datenbank /var/db/spamdb Blaklists, Whitelists und Greylists verwaltet. Netzwerk-Hygiene Dieser Abschnitt beschreibt die Verwendung von block-policy, scrub und antispoof, mit denen das Verhalten des Regelsatzes weiter optimiert werden kann. Die Option block-policy kann im Teil options des Regelwerks konfiguriert werden, vor den Umleitungen und den eigentlichen Filterregeln. Diese Option legt fest, welche Rückmeldung PF an einen geblockten Rechner sendet. Es existieren zwei mögliche Werte: drop verwirft das Paket ohne Rückmeldung und return gibt eine Statusmeldung, wie etwa Connection refused zurück. Die Voreinstellung ist drop. Geben Sie den gewünschten Wert ein, um die block-policy-Richtlinie zu ändern: set block-policy return scrub ist ein Schlüsselwort in PF, das die Paket-Normalisierung aktiviert. Dieser Prozess fügt fragmentierte Pakete wieder zusammen und blockt TCP-Pakete mit ungültigen Flag-Kombinationen. Ein aktiviertes scrub bietet einen gewissen Schutz gegen Angriffe, die auf die falsche Handhabung von fragmentierten Paketen aufbauen. Es stehen viele Optionen zur Verfügung, jedoch sollte die einfachste Form für die meisten Konfigurationen ausreichend sein: scrub in all Einige Dienste, wie beispielsweise NFS, erfordern eine bestimmte Handhabung von fragmentierten Paketen. Weitere Informationen finden Sie unter http://www.openbsd.org/faq/pf/scrub.html. Dieses Beispiel fügt fragmentierte Pakete wieder zusammen, löscht das do not fragment-Bit und setzt die maximale Segmentgröße auf 1440 Bytes: scrub in all fragment reassemble no-df max-mss 1440 Der antispoof-Mechanismus bietet einen Schutz gegen gefälschte IP-Adressen. Dabei werden hauptsächlich Pakete verworfen, die auf der falschen Schnittstellen ankommen. Folgende Regeln verwerfen gefälschte Adressen, wenn sie aus dem Internet oder dem lokalen Netzwerk stammen: antispoof for $ext_if antispoof for $int_if Handhabung von nicht-routebaren Adressen Sogar bei einem richtig konfigurierten NAT-Gateway müssen Sie vielleicht die Fehlkonfiguration anderer Personen ausgleichen. Ein typischer Fehler besteht darin, nicht-routebare Adressen ins Internet zu lassen. Da der Verkehr von nicht-routebaren Adressen Teil eines DoS-Angriffs sein kann, sollten Sie in Betracht ziehen, diesen Verkehr explizit an der externen Schnittstelle des Netzwerks zu blockieren. In diesem Beispiel wird ein Makro erstellt, das die nicht-routebaren Adressen enthält. Datenverkehr von und zu diesen Adressen wird dann an der externen Schnittstelle des Gateways verworfen. martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \ 0.0.0.0/8, 240.0.0.0/4 }" block drop in quick on $ext_if from $martians to any block drop out quick on $ext_if from any to $martians Die IPFILTER-Firewall (IPF) firewall IPFILTER Geschrieben wurde IPFILTER von Darren Reed. IPFILTER ist vom Betriebssystem unabhängig: Es ist eine Open Source Anwendung, die auf die Betriebssysteme &os;, NetBSD, OpenBSD, &sunos;, HP/UX und &solaris; portiert wurde. IPFILTER wird aktiv betreut und gepflegt. Es werden regelmäßig neue Versionen herausgegeben. IPFILTER basiert auf einer kernelseitigen Firewall und einem NAT Mechanismus, der durch Anwenderprogramme betreut und gesteuert werden kann. Die Regeln der Firewall werden mit dem Programm &man.ipf.8; gesetzt oder gelöscht. Für die Manipulation der NAT Regeln verwendet man &man.ipnat.8;. Mit &man.ipfstat.8; werden Laufzeitstatistiken der kernelseitigen Anteile von IPFILTER aufgelistet. Und mit dem Programm &man.ipmon.8; kann man die Aktionen von IPFILTER in die Protokolldateien des Systems speichern. IPF funktionierte ursprünglich mit einer Regel-Prozess-Logik à la die letzte Regel, die passt, entscheidet und verwendete ausschließlich Regeln ohne feste Zustände. Inzwischen wurde die Regel-Prozess-Logik drastisch modernisiert: Es gibt eine und eine zustandsorientierte Option. Die offizielle Dokumentation beinhaltet leider nur die veralteten Parameter zur Regelerstellung - die neuen Funktionen werden nur als Zusatzoptionen aufgelistet, was ihre Vorteile beim Erstellen einer weit überlegenen und viel sichereren Firewall völlig untergräbt. Die Anweisungen in diesem Kapitel basieren darauf, Regeln mit den Optionen und zu erstellen. Mit diesem Grundwissen wird man einen kompletten einschließenden Regelsatz erstellen können. Für eine ausführliche Erläuterung der alten Methode zur Regelverarbeitung schauen Sie bitte auf http://www.munk.me.uk/ipf/ipf-howto.html oder http://coombs.anu.edu.au/~avalon/ip-filter.html. Antworten auf häufige Fragen finden Sie unter http://www.phildev.net/ipf/index.html. Und ein durchsuchbares Archiv der Mailingliste zu IPFILTER gibt es unter http://marc.theaimsgroup.com/?l=ipfilter. Aktivieren von IPF IPFILTER enabling &os; enthält IPF in der Standardversion als ladbares Kernelmodul. Dieses Modul wird vom System automatisch geladen, wenn in der rc.conf der Eintrag ipfilter_enable="YES" angelegt wird. In dieser ursprünglichen Konfiguration ist die Protokollierung aktiv und die Option default pass all ("Pakete passieren lassen") als Standard gesetzt. Um die block all ("alles Blockieren") Option zu setzen, muss man nicht gleich einen neuen Kernel bauen - es reicht, block all als letzte Position des Regelsatzes aufzulisten. Kernel-Optionen Kerneloptionen IPFILTER Kerneloptionen IPFILTER_LOG Kerneloptionen IPFILTER_DEFAULT_BLOCK IPFILTER Kerneloptionen Es ist nicht unbedingt notwendig, IPF durch die folgenden Optionen direkt in der Kernel einzubinden. Diese Möglichkeit der Verwendung von IPF wird hier mehr als Hintergrundwissen angeboten. Man sollte nur wissen, dass dadurch nicht mehr das Kernelmodul geladen wird - und dementsprechend auch nicht mehr entladen werden kann. Die Beschreibung der einzelnen Optionen von IPF für die Verwendung in der Kernelkonfiguration finden Sie auch in der Datei /usr/src/sys/conf/NOTES. options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK options IPFILTER aktiviert die Verwendung der IPFILTER Firewall. options IPFILTER_LOG aktiviert den Logging-Mechanismus. Das bedeutet, dass jedes Paket geloggt wird, auf das eine Regel passt, die das Schlüsselwort log enthält. Dazu wird der Pseudo—Device ipl verwendet. options IPFILTER_DEFAULT_BLOCK ändert das Verhalten der Firewall dahingehend, dass jedes Paket, dass nicht explizit von einer pass Regel Zugang erhält, abgewiesen, bzw. geblockt, wird. Diese Einstellungen werden erst aktiv, wenn der Kernel, in den sie eingebunden wurden, kompiliert, installiert und gebootet wurde. Optionen in rc.conf Um IPF während des Bootvorgangs einzubinden, braucht man lediglich die folgenden Zeilen der Datei /etc/rc.conf anzufügen: ipfilter_enable="YES" # Startet IPF ipfilter_rules="/etc/ipf.rules" # liest den Regelsatz aus einer Datei ipmon_enable="YES" # Startet das IP-Monitor Log ipmon_flags="-Ds" # D = Als Da:mon starten # s = Protokollierung via syslog # v = Protokollierung von tcp window, ack, seq # n = Namen statt IP & port ausgeben Falls sich hinter der Firewall ein lokales Netzwerk befindet, das den reservierten privaten Adressbereich verwendet, müssen die folgenden Zeilen zur Aktivierung von NAT ebenfalls in /etc/rc.conf eingetragen werden: gateway_enable="YES" # Aktivierung des LAN-Gateways ipnat_enable="YES" # Startet die ipnat Funktion ipnat_rules="/etc/ipnat.rules" # Liest die ipnat-Regeldefinitionen aus einer Datei Der Befehl ipf ipf Mit dem Befehl &man.ipf.8; liest man die Datei, die den Regelsatz enthält ein. Mit dem folgenden Befehl können Sie Ihre eigenen, für Ihr System maßgeschneiderten Regeln einlesen und so in einem Schritt alle Regeln der laufenden Firewall ersetzen: &prompt.root; ipf -Fa -f /etc/ipf.rules bedeutet, dass alle intern gespeicherten Tabellen mit Regeln gelöscht werden. gibt die Datei an, aus der die neuen Regeln gelesen werden sollen. Mit diesen beiden Optionen erhalten Sie die Möglichkeit, Änderungen an der Datei mit Ihrem Regelsatz vorzunehmen und gleich die Firewall mit den neuen Regeln zu bestücken, ohne den Rechner neu starten zu müssen. Da dieser Vorgang beliebig wiederholt werden kann, ist es ein sehr bequemer Weg, neue Regeln einzuarbeiten und zu testen. Um mehr über diese und weitere Optionen von &man.ipf.8; zu erfahren, konsultieren Sie bitte die Manpage. &man.ipf.8; erwartet, dass es sich bei der Datei mit dem Regelsatz um eine Standard-Textdatei handelt. Eine Datei, die ein Skript oder Variablen enthält, wird nicht verarbeitet. Es gibt allerdings doch einen Weg, IPF Regeln mit Hilfe von Skripten und Variablen zu erstellen. Weitere Informationen dazu finden Sie unter . IPFSTAT ipfstat IPFILTER statistics Das normale Verhalten von &man.ipfstat.8; ist, die Zusammenfassung der angefallenen Statistiken, die als Resultat der Anwendung von nutzerspezifischen Regeln auf ein- und ausgehende Pakete seit dem letzten Start der Firewall oder seit dem letzten Zurücksetzen der Zähler auf Null durch das Kommando ipf -Z angesammelt wurden, abzurufen und anzuzeigen. Für weiterführende Informationen schauen Sie bitte auf die Manpage von &man.ipfstat.8;! Die Ausgabe von &man.ipfstat.8;, wenn keine Parameter übergeben wurden, sieht etwa so aus: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) Wenn die Option für eingehend oder für ausgehend übergeben wird, liefert das Kommando eine entsprechende Liste von Filter-Regeln, die gerade installiert sind und vom Kernel verwendet werden. ipfstat -in zeigt alle aktive Regeln für eingehende Verbindungen zusammen mit ihren Nummern. ipfstat -on erledigt dasselbe für die ausgehenden Verbindungen. Die Ausgabe sieht in etwa folgendermaßen aus: @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state ipfstat -ih zeigt die Tabelle der aktiven Regeln für eingehende Verbindungen zusammen mit der Anzahl, wie oft jeder einzelnen Regel entsprochen wurde. ipfstat -oh zeigt das Gleiche für die ausgehenden Verbindungen. Hier wird die Ausgabe so oder so ähnlich aussehen: 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state Einer der wichtigsten Funktionen von ipfstat wird über die Option bereitgestellt. Mit ihr wird eine Statustabelle vergleichbar der Prozess-Tabelle von &man.top.1; ausgegeben. Mit dieser Funktion erhalten Sie im Falle eines Angriffs die Möglichkeit, die angreifenden Pakete zu identifizieren, abzufangen und auszuwerten. Weitere Unteroptionen eröffnen, die IP-Adresse, den Port oder das Protokoll, geteilt nach Herkunft und Ziel, auszuwählen und dann in Echtzeit zu beobachten. Lesen Sie dazu bitte auch die Manpage von &man.ipfstat.8;. IPMON ipmon IPFILTER logging Damit der Befehl ipmon korrekt arbeiten kann, muss die Option IPFILTER_LOG in die Kernelkonfiguration eingearbeitet werden. Das Kommando selbst arbeitet in zwei verschiedenen Modi. Für den nativen Modus startet man ipmon auf der Kommandozeile ohne die Option . Der Hintergrundmodus (daemon mode) dient der Erstellung eines stetigen Systemprotokolls, so dass Einträge vergangener Ereignisse inspiziert werden können. So sollen &os; und IPFILTER entsprechend ihrer Konfiguration zusammen arbeiten. &os; kann mit einem eingebauten Mechanismus Systemprotokolle turnusmäßig abspeichern. Aus diesem Grund sollte man besser &man.syslogd.8; verwenden anstatt die Protokollinformationen in eine Datei zu schreiben, wie es als Standard vorgesehen ist. In der Standard-rc.conf-Datei (im Ordner /etc/defaults/) wird dem Eintrag ipmon_flags die Option übergeben: ipmon_flags="-Ds" # D = Als Da:mon starten # s = Protokollierung via syslog # v = Protokollierung von tcp window, ack, seq # n = Namen statt IP & port ausgeben Die Vorteile des Protokollierens liegen auf der Hand: Sie versetzen den Administrator in die Lage, nach einem Vorfall Informationen abzurufen, etwa welche Pakete aussortiert wurden, welche Adressen diese Pakete gesendet haben oder wohin sie gesendet werden sollten. Alles in allem erhält er ein sehr gutes Werkzeug zum Aufspüren von Angreifern. Jedoch, auch wenn die Protokollierung aktiviert ist, wird IPF keine einzige Regel zum Protokollieren von alleine entwerfen und umsetzen. Der Administrator der Firewall entscheidet, welche Regeln in seinem Regelsatz mitgeschrieben werden sollen und er muss dementsprechend das Schlüsselword log in dieser Regel angeben. Normalerweise werden nur Treffer auf abweisende Regeln protokolliert. Es ist üblich, als letzte Regel eine alles blockierende Regel mit dem Schlüsselwort log in den Regelsatz einzutragen. Dadurch erkennt man alle Pakete, die keiner Regel im Regelsatz entsprachen. IPMON Logging Syslogd verwendet seine eigene Methode zum Sortieren der gesammtelten Protokolldaten - spezielle Gruppierungen namens facility und level. IPMON verwendet im daemon-Modus als facility den Wert security. Die folgenden level können für eine genauere Trennung der Protokolldaten verwendet werden: LOG_INFO - Alle zu protokollierenden Pakete LOG_NOTICE - Protokollierte Pakete, die passieren durften LOG_WARNING - Protokollierte Pakete, die blockiert wurden LOG_ERR - Protokollierte Pakete, deren Headerdaten nicht komplett vorlagen Damit IPFILTER angewiesen werden kann, alle Protokolldaten in die Datei /var/log/ipfilter.log zu schreiben, muss diese erst erstellt werden. Folgendes Kommando übernimmt diese Aufgabe: &prompt.root; touch /var/log/ipfilter.log Die Funktionen von &man.syslogd.8; werden durch Definition in der Datei /etc/syslog.conf gesteuert. In dieser Datei kann sehr weitläfig eingestellt werden, wie syslog mit den Systemnachrichten umgehen soll, die ihm von Anwendungen wie IPF übergeben werden. Fügen Sie folgende Definition in die Datei /etc/syslog.conf ein, um die Protokollierung für IPF via syslog zu aktivieren: security.* /var/log/ipfilter.log security.* bedeutet, dass alle Nachrichten der Klasse security.* am angegebenen Ort (hier eine Datei) geschrieben werden sollen. Um Änderungen an der Datei /etc/syslog.conf zu aktivieren müssen Sie den Rechner neu starten, oder den Befehl &prompt.root; /etc/rc.d/syslogd reload ausführen. Vergessen Sie nicht, /etc/newsyslog.conf anzupassen, damit die neuen Protokolldateien, die eben konfiguriert wurden, auch in den Rotationsturnus eingefügt werden! Die Formatierung der Logdatei Nachrichten, die durch ipmon erzeugt werden, bestehen aus durch Leerstellen getrennten Datenfeldern. Folgende Felder sind in allen Nachrichten enthalten: Das Datum der Paketerstellung. Die Uhrzeit der Paketerstellung in der Form HH:MM:SS.F, mit Stunden, Minuten, Sekunden und Sekundenbruchteilen, wobei letztere mehrere Stellen lang sein können. Der Name der Schnittstelle, die das Paket verarbeitet hat, bspw. dc0. Die Gruppe und die Nummer der angewandten Regel, bspw. @0:17. Die ausgeführte Aktion: p für passed (zugelassen), b für blockiert, S für short packet (unvollständiger Header), n für no match (gar keine Regel wurde berührt) und L für Log-Regel. Die Reihe, in der die Flags angezeigt werden ist: S, p, b, n, L. Ein groß geschriebenes P oder B bedeutet, dass das Paket aufgrund einer globalen Einstellung protokolliert wurde und nicht wegen einer einzelnen Regel. Die Adressen. Diese bestehen aus drei Feldern: Der Quelladresse mit Port (getrennt durch ein Komma), dem Symbol -> und der Zieladresse. Also bspw. 209.53.15.22,80 -> 198.64.221.18,1722. PR gefolgt vom Namen eines Netzwerk-Protokolls oder dessen Nummer. Bspw. PR tcp. len gefolgt von der Länge des Headers und der Gesamtlänge des Paketes, beispielsweise len 20 40. Wenn es sich um ein TCP-Paket handelt, wird ein weiteres Feld, beginnend mit einem Querstrich und gefolgt von Buchstaben, die den gesetzten Flags entsprechen, angezeigt. Lesen Sie bitte die Manpage &man.ipmon.8; für eine Liste der Buchstaben und deren Bedeutungen. Falls das Paket ein ICMP-Paket ist, werden zwei Felder am Ende hinzugefügt - das erstere ist immer ICMP, das zweite enthält die ICMP-Nachricht und den Nachrichtentyp, getrennt durch einen Schrägstrich. ICMP 3/3 steht beispielsweise für Port nicht erreichbar. Die Erstellung eines Regelsatzes mit Variablen Erfahrenere IPF Anwender erstellen sich eine Datei, die die Regeln enthält und gestalten diese als ein Skript, in dem Variablen verwendet werden. Der wichtigste Vorteil besteht darin, dass man lediglich den Wert der Variablen anpassen muss und diese, sobald das Skript gestartet wird, durch die entsprechenden Werte ersetzt und die Regeln entsprechend formuliert werden. In Skripten kann man so häufig verwendete Werte einfach als Variable in mehreren Regeln zuweisen. Am folgenden Beispiel soll das verdeutlicht werden. Die Syntax dieses Skriptes ist kompatibel mit den Shells &man.sh.1;, &man.csh.1; und &man.tcsh.1;. Variablen beginnen mit einem Dollar-Zeichen: $Variablenname. Im Beispiel unten steht $oif für die Variable, in der der Name der Schnittstelle abgelegt wird, über die der Verkehr nach außen erfolgt. In Variablenzuweisungen fehlt das beginnende $-Zeichen. Alleine der Name der Variable wird angegeben, gefolgt von einem Gleichheitszeichen, und dem Wert, der der Variablen zugewiesen werden soll. Dieser muss in doppelten Anführungszeichen ("") stehen. Also folgt eine Zuweisung dem Schema Variablenname = "Wert". ############# Start of IPF rules script ######################## oif="dc0" # Name der Internet-Schnittstelle odns="192.0.2.11" # IP des DNS-Servers unseres ISPs myip="192.0.2.7" # die statische IP, die uns der ISP zugeteilt hat ks="keep state" fks="flags S keep state" # Sie haben die Wahl, aus diesem Skript eine eigene # /etc/ipf.rules erstellen zu lassen oder es einfach # direkt als Skript laufen zu lassen. # # Entfernen Sie dazu das eine Kommentarzeichen # und kommentieren Sie die andere Zeile aus! # # 1) Diese Zeile verwenden Sie zur Erstellung von /etc/ipf.rules #cat > /etc/ipf.rules << EOF # # 2) Diese Zeile, wenn Sie direkt mit dem Skript arbeiten wollen /sbin/ipf -Fa -f - << EOF # Erlaubnis ausgehenden Verkehrs an den Nameserver des ISPs pass out quick on $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $ks # Erlaubnis ausgehenden unsicheren www-Verkehrs pass out quick on $oif proto tcp from $myip to any port = 80 $fks # Erlaubnis ausgehenden sicheren www-Verkehrs https via TLS SSL pass out quick on $oif proto tcp from $myip to any port = 443 $fks EOF ################## End of IPF rules script ######################## Das ist schon alles. Die Regeln selbst sind im Beispiel nicht so wichtig - achten Sie auf die Anwendung der Variablenzuweisung am Anfang und die Verwendung der Variablen im Skript. Falls das obige Beispiel in einer Datei namens /etc/ipf.rules.script gespeichert wurde, können die Regeln mit folgenden Kommando neu geladen werden: &prompt.root; sh /etc/ipf.rules.script Es gibt ein Problem mit Regelsatz-Dateien, die Variablen verwenden: IPF kann mit Variablen nichts anfangen - und kann derartige Skripte nicht direkt einlesen. Unser kleines Skript kann daher nur auf eine der beiden folgenden Weisen verwendet werden: Entfernen Sie das Kommentarzeichen der Zeile, die mit cat beginnt. Kommentieren Sie die Zeile aus, die mit /sbin/ipf beginnt. Schreiben Sie die Zeile ipfilter_enable="YES" in die Datei /etc/rc.conf und rufen Sie dann das Skript auf, um /etc/ipf.rules zu erstellen oder zu erneuern. Deaktivieren Sie IPFILTER in den Systemstart-Skripten, indem Sie die Zeile ipfilter_enable="NO" in die Datei /etc/rc.conf eintragen (was auch der Standard-Einstellung entspricht). Fügen Sie ein Skript ähnlich dem folgenden in Ihr Verzeichnis /usr/local/etc/rc.d/. Es sinnvoll, dem Skript einen offensichtlichen Namen zu geben, wie etwa ipf.loadrules.sh. Die Endung .sh ist dabei verbindlich. #!/bin/sh sh /etc/ipf.rules.script Die Zugriffsrechte für die Datei, die das Skript enthält, müssen für den Eigentümer root auf Lesen, Schreiben und Ausführen gesetzt werden. &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh Wenn nun Ihr System startet, werden Ihre IPF-Regeln geladen. IPF Regelsätze Ein Regelsatz ist eine Gruppe von IPF-Regeln, die anhand der Werte eines Netzwerkpaketes entscheiden, ob dieses Paket durchgelassen oder blockiert wird. Der Austausch von Paketen erfolgt immer zweiseitig in Form einer sogenannten Session. Der Regelsatz der Firewall verarbeitet sowohl die eingehenden Pakete aus dem öffentlichen Internet als auch die Pakete, die vom System als Antwort auf die Ersteren gesendet werden. Jeder Dienst, der via TCP/IP arbeitet, zum Beispiel telnet, www oder mail, ist vordefiniert durch sein Protokoll und seinen privilegierten Port, an dem er auf Anfragen wartet und reagieren kann. Pakete, die gezielt einen Dienst ansprechen sollen, werden von einem unprivilegierten Port des Senders an einen konkreten privilegierten Port des Zielsystems geschickt. Alle genannten Parameter (Ports, Adressen usw.) können als Auswahlkriterien zum erstellen von Regeln eingesetzt werden, die Dienste erlauben oder blockieren. IPFILTER rule processing order IPF wurde ursprünglich mit einer Regel-Prozess-Logik geschrieben, die ausschließlich statusfreie Regeln zuließ und nach dem Prinzip die letzte Regel, die passt, entscheidet arbeitete. Mit der Zeit erhielt IPF eine Option sowie Option für die Anwendung von zustandsorientierten Regeln, was die Regel-Prozess-Logik signifikant modernisierte. Die Anweisungen in diesem Kapitel basieren auf der Verwendung von Regeln, die diese beiden neuen Optionen verarbeiten. Dies ist das Framework zur Entwicklung eines Firewallregelsatzes. Wenn Sie mit einer Firewall arbeiten, seien Sie sehr vorsichtig. Durch wenige Einstellungen können Sie sich aus Ihrem System aussperren. Wenn Sie auf der sicheren Seite sein wollen, führen Sie die Firewall-Konfiguration direkt am entsprechenden Gerät aus und nicht über eine Netzwerkverbindung wie bspw. ssh. IPF Regel-Syntax IPFILTER rule syntax Die Syntax zur Erstellung der Regeln, die hier vorgestellt wird, ist dahingehend vereinfacht worden, dass sie ausschliesslich auf den modernen Regelkontext, mit statusbehafteten Regeln und einer die erste Regel, die passt, gewinnt-Logik, zurückgreift. Um alles über die veraltete Syntax zu erfahren, lesen Sie bitte die Man-Page von &man.ipf.8;. Ein #-Zeichen markiert den Beginn eines Kommentars. Es darf nach nach einer Regel stehen oder als erstes Zeichen einer Zeile. Leere Zeilen werden von der Regel-Prozess-Logik ignoriert. Regeln enthalten Schlüsselwörter. Diese Schlüsselwörter müssen in einer bestimmten Reihenfolge von links nach rechts in einer Zeile erscheinen. Als solche identifizierte Schlüsselwörter werden fett wiedergegeben. Einige Schlüsselwörter haben Unteroptionen, die wiederum selbst Schlüsselwörter sein und ebenfalls weiter Unteroptionen einschließen können. ACTION IN-OUT OPTIONS SELECTION STATEFUL PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG STATEFUL ACTION = block | pass IN-OUT = in | out OPTIONS = log | quick | on interface-name SELECTION = proto value | source/destination IP | port = number | flags flag-value PROTO = tcp/udp | udp | tcp | icmp SRC_ADD,DST_ADDR = all | from object to object OBJECT = IP address | any PORT_NUM = port number TCP_FLAG = S STATEFUL = keep state ACTION Die ACTION bestimmt, was mit dem Paket passieren soll, wenn der Rest der Regel zutrifft. Dieser Teil muss für jede Regel angegeben werden. Das Schlüsselwort block gibt an, dass das Paket verfallen soll, wenn die Auswahlparameter zutreffen. Das Schlüsselwort pass gibt an, dass das Paket durch die Firewall durchgelassen werden soll, wenn die Auswahlparameter zutreffen. IN-OUT Ebenfalls verbindlich ist die Angabe, welchen Teil der Verbindung, Ein- oder Ausgang, die Regel beeinflussen soll. Das nächste Schlüsselwort muss daher entweder in, für eingehend, oder out, für ausgehend, lauten - oder die Regel wird aufgrund eines Syntaxfehlers nicht umgesetzt. in bedeutet, dass diese Regel auf eingehende Pakete angewendet wird, die gerade an der dem öffentlichen Internet zugewandten Schnittstelle empfangen wurden. out bedeutet, das diese Regel auf ausgehende Pakete angewendet wird, also Pakete die gerade gesendet werden und deren Zieladresse im öffentlichen Internet liegt. OPTIONS Die Optionen müssen in der hier aufgeführten Reihenfolge verwendet werden. log bestimmt, dass die Kopfdaten des Paketes an die Systemschnittstelle &man.ipl.4; geschrieben werden sollen. Genaueres dazu weiter unten im Abschnitt LOGGING. quick bestimmt, dass, wenn die Auswahlkriterien der Regel auf das Paket zutreffen, keine weiteren Regeln ausgewertet werden. So vermeidet man das Abarbeiten des gesamten Regelsatzes. Diese Option ist eine verbindliche Vorraussetzung der modernen Regel-Prozess-Logik. on bestimmt den Namen der Schnittstelle, der als Auswahlkriterium hinzugefügt werden soll. Die Namen aller verfügbaren Schnittstellen werden durch den Befehl &man.ifconfig.8; angezeigt. wenn man diese Option verwendet, passt die Regeln nur auf Pakete, die durch diese Schnittstelle empfangen (in) oder gesendet (out) wurden. Für die modernisierte Regel-Prozess-Logik ist die Verwendung dieser Option verbindlich. Wenn ein Paket protokolliert wird, werden die Kopfdaten in die Pseudo-Schnittstelle &man.ipl.4; geschrieben. Folgende Parameter können zusätzlich übergeben werden, müssen dazu aber direkt nach dem Schlüsselwort log und in gleicher Reihenfolge stehen: body bestimmt, dass die ersten 128 Bytes des Paketinhaltes zusätzlich zu den Kopfdaten protokolliert werden. first trifft nur zu, wenn das Schlüsselwort log zusammen mit keep-state verwendet wird. Es bestimmt, dass nur das auslösende Paket protokolliert wird und nicht jedes weitere Paket, dass von der gespeicherten Status-Regel betroffen ist. SELECTION Die Schlüsselwörter, die in diesem Abschnitt vorgestellt werden, dienen zur Beschreibung von Attributen, anhand derer geprüft und entschieden wird, ob eine Regel zutrifft oder nicht. Es gibt ein Schlüsselwort, und das hat mehrere Optionen, von denen eine ausgewählt werden muss. Die folgenden allgemeinen Attribute können beliebig zum Erstellen einer Regel verwendet werden, allerdings nur in der vorgestellten Reihenfolge: PROTO proto ist das Schlüsselwort für das im Paket angewendete Protokoll. Als Option ein Protokoll aus Auswahlkriterium übergeben. Diese Option ist verbindlich, wenn man die moderne Regel-Prozess-Logik verwendet. tcp/udp | udp | tcp | icmp oder irgendein Protokollname, der in der Datei /etc/protocols zu finden ist, kann übergeben werden. Außerdem kann das Schlüsselwort tcp/udp verwendet werden, wenn sowohl TCP als auch UDP von der Regel betroffen sein sollen. Dieses Schlüsselwort wurde eingeführt, um Duplikate sonst identischer Regeln zu vermeiden. SRC_ADDR/DST_ADDR Das Schlüsselwort all ist ein Synonym für from any to any ohne weitere Auswahlkriterien. from src to dst: Die Schlüsselwörter from und to dienen zur Angabe von Quelle und Ziel in Form von IP-Adressen oder -Bereichen. Innerhalb einer Regel muss immer beides angegeben werden. Statt einer Adresse kann auch das Schlüsselwort any übergeben werden, das für jede beliebige IP-Adresse steht. Zum Beispiel: from any to any oder from 0.0.0.0/0 to any oder from any to 0.0.0.0/0 oder from 0.0.0.0 to any oder from any to 0.0.0.0 bedeuten alle das Gleiche. IP-Bereiche können nur in der CIDR-Notation angegeben werden. Der Port net-mgmt/ipcalc hilft Ihnen bei der Berechnung der richtigen Angaben. Weiterführende Informationen zu CIDR finden Sie auf der Webseite von ipcalc. PORT Wenn ein Port als Auswahlkriterium übergeben wurde, bei Quelle und/oder Ziel, wird er nur bei TCP und UDP Paketen verwendet. Angegeben werden kann entweder die Portnummer oder der Dienstname aus /etc/services. Die Verwendung der Portoption mit dem to-Objekt ist verbindlich für die Verwendung der modernisierten Regel-Prozess-Logik. Ein Beispiel für die Filterung Paketen von allen Quell-IPs mit beliebiger Portnummer auf beliebige Ziel-IPs mit der Portnummer 80 (dem www-Port): from any to any port = 80. Einfache Portvergleiche können auf verschiedenen Wegen erfolgen. Mehrere Vergleichsoperatoren stehen dafür zur Verfügung. Genauso können Bereiche angegeben werden. port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge". Um einen Bereich anzugeben: port "<>" | "><" Genau wie die Trefferspezifikation für Quelle und Ziel sind auch die beiden folgenden Parameter obligatorisch bei der Verwendung der modernen Regel-Prozess-Logik. <acronym>TCP</acronym>_FLAG Flags spielen nur beim Filtern von TCP eine Rolle. Die Buchstaben entsprechen jeweils einem möglichen Flag, dass in den Kopfdaten der TCP-Pakete geprueft werden soll. Die moderne Regel-Prozess-Logik verwendet den Parameter flags S um eine Anfrage zum Start einer TCP-Session zu identifizieren. STATEFUL keep state zeigt bei einer Passage-Regel an, dass für alle Pakete, die die Selektion erfolgreich durchlaufen, Stateful Filtering eingerichtet werden soll. Diese Option ist obligatorisch für die Verwendung der modernen Prozess-Regel-Logik. Stateful Filtering IPFILTER stateful filtering Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session conversation. When activated, keep-state dynamically generates internal rules for each anticipated packet being exchanged during the bi-directional session conversation. It has sufficient matching capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors. Keep state will also allow ICMP packets related to a TCP or UDP session through. So if you get ICMP type 3 code 4 in response to some web surfing allowed out by a keep state rule, they will be automatically allowed in. Any packet that IPF can be certain is part of an active session, even if it is a different protocol, will be let in. What happens is: Packets destined to go out through the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not belong to an already active session, are simply checked against the outbound ruleset. Packets coming in from the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not belong to an already active session, are simply checked against the inbound ruleset. When the conversation completes it is removed from the dynamic state table. Stateful filtering allows you to focus on blocking/passing new sessions. If the new session is passed, all its subsequent packets will be allowed through automatically and any impostors automatically rejected. If a new session is blocked, none of its subsequent packets will be allowed through. Stateful filtering has technically advanced matching abilities capable of defending against the flood of different attack methods currently employed by attackers. Inclusive Ruleset Example The following ruleset is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only allows services matching pass rules through, and blocks all others by default. Firewalls intended to protect other machines, also called network firewalls, should have at least two interfaces, which are generally configured to trust one side (the LAN) and not the other (the public Internet). Alternatively, a firewall might be configured to protect only the system it is running on—this is called a host based firewall, and is particularly appropriate for servers on an untrusted network. All &unix; flavored systems including &os; are designed to use interface lo0 and IP address 127.0.0.1 for internal communication within the operating system. The firewall rules must contain rules to allow free unmolested movement of these special internally used packets. The interface which faces the public Internet is the one to place the rules that authorize and control access of the outbound and inbound connections. This can be your user PPP tun0 interface or your NIC that is connected to your DSL or cable modem. In cases where one or more NICs are cabled to private network segments, those interfaces may require rules to allow packets originating from those LAN interfaces transit to each other and/or to the outside (Internet). The rules should be organized into three major sections: first trusted interfaces, then the public interface outbound, and last the public untrusted interface inbound. The rules in each of the public interface sections should have the most frequently matched rules placed before less commonly matched rules, with the last rule in the section blocking and logging all packets on that interface and direction. The Outbound section in the following ruleset only contains pass rules which contain selection values that uniquely identify the service that is authorized for public Internet access. All the rules have the quick, on, proto, port, and keep state options set. The proto tcp rules have the flag option included to identify the session start request as the triggering packet to activate the stateful facility. The Inbound section has all the blocking of undesirable packets first, for two different reasons. The first is that malicious packets may be partial matches for legitimate traffic. These packets have to be discarded rather than allowed in, based on their partial matches against allow rules. The second reason is that known and uninteresting rejects may be blocked silently, rather than being caught and logged by the last rules in the section. The final rule in each section, blocks and logs all packets and can be used to create the legal evidence needed to prosecute the people who are attacking your system. Another thing that should be taken care of, is to ensure there is no response returned for any of the undesirable traffic. Invalid packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. The less the attackers can learn about your system, the more time they must invest before actually doing something bad. Rules that include a log first option, will only log the event the first time they are triggered. This option is included in the sample nmap OS fingerprint rule. The security/nmap utility is commonly used by attackers who attempt to identify the operating system of your server. Any time there are logged messages on a rule with the log first option, an ipfstat -hio command should be executed to evaluate how many times the rule has actually matched. Large number of matches usually indicate that the system is being flooded (i.e.: under attack). The /etc/services file may be used to lookup unknown port numbers. Alternatively, visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers and do a port number lookup to find the purpose of a particular port number. Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. The following ruleset creates a complete and very secure inclusive type of firewall ruleset that has been tested on production systems. It can be easily modified for your own system. Just comment out any pass rules for services that should not be authorized. To avoid logging unwanted messages, just add a block rule in the inbound section. The dc0 interface name has to be changed in every rule to the real interface name of the NIC card that connects your system to the public Internet. For user PPP it would be tun0. Add the following statements to /etc/ipf.rules: ################################################################# # No restrictions on Inside LAN Interface for private network # Not needed unless you have LAN ################################################################# #pass out quick on xl0 all #pass in quick on xl0 all ################################################################# # No restrictions on Loopback Interface ################################################################# pass in quick on lo0 all pass out quick on lo0 all ################################################################# # Interface facing Public Internet (Outbound Section) # Match session start requests originating from behind the # firewall on the private network # or from this gateway server destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. # xxx 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 pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # Allow out access to my ISP's DHCP server for cable or DSL networks. # This rule is not needed for 'user ppp' type 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 pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Allow out non-secure standard www function pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state # Allow out secure www function https over TLS SSL pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Allow out send & get email function pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Allow out Time pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Allow out nntp news pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # Allow out gateway & LAN users' non-secure FTP ( both passive & active modes) # This function uses the IPNAT built in FTP proxy function coded in # the nat rules file to make this single rule function correctly. # If you want to use the pkg_add command to install application packages # on your gateway system you need this rule. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements) # This function is using SSH (secure shell) pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Allow out insecure Telnet pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state # Allow out FreeBSD CVSup pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Allow out ping to public Internet pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Allow out whois from LAN to public Internet pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Block and log only the first occurrence of everything # else that's trying to get out. # This rule implements the default block block out log first quick on dc0 all ################################################################# # Interface facing Public Internet (Inbound Section) # Match packets originating from the public Internet # destined for this gateway server or the private network. ################################################################# # Block all inbound traffic from non-routable or reserved address spaces block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP block in quick on dc0 from 127.0.0.0/8 to any #loopback block in quick on dc0 from 0.0.0.0/8 to any #loopback block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast ##### Block a bunch of different nasty things. ############ # That I do not want to see in the log # Block frags block in quick on dc0 all with frags # Block short tcp packets block in quick on dc0 proto tcp all with short # block source routed packets block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Block nmap OS fingerprint attempts # Log first occurrence of these so I can get their IP address block in log first quick on dc0 proto tcp from any to any flags FUP # Block anything with special options block in quick on dc0 all with ipopts # Block public pings block in quick on dc0 proto icmp all icmp-type 8 # Block ident block in quick on dc0 proto tcp from any to any port = 113 # Block all Netbios service. 137=name, 138=datagram, 139=session # Netbios is MS/Windows sharing services. # Block MS/Windows hosts2 name server requests 81 block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 # Allow traffic in from ISP's DHCP server. This rule must contain # the IP address of your ISP's DHCP server as it is 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. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Allow in standard www function because I have apache server pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # Allow in non-secure Telnet session from public Internet # labeled non-secure because ID/PW passed over public Internet as clear text. # Delete this sample group if you do not have telnet server enabled. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state # Allow in secure FTP, Telnet, and SCP from public Internet # This function is using SSH (secure shell) pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state # Block and log only first occurrence of all remaining traffic # coming into the firewall. The logging of only the first # occurrence avoids filling up disk with Denial of Service logs. # This rule implements the default block. block in log first quick on dc0 all ################### End of rules file ##################################### <acronym>NAT</acronym> NAT IP masquerading NAT network address translation NAT NAT stands for Network Address Translation. To those familiar with &linux;, this concept is called IP Masquerading; NAT and IP Masquerading are the same thing. One of the many things the IPF NAT function enables is the ability to have a private Local Area Network (LAN) behind the firewall sharing a single ISP assigned IP address on the public Internet. You may ask why would someone want to do this. ISPs normally assign a dynamic IP address to their non-commercial users. Dynamic means that the IP address can be different each time you dial in and log on to your ISP, or for cable and DSL modem users, when the modem is power cycled. This dynamic IP address is used to identify your system to the public Internet. Now lets say you have five PCs at home and each one needs Internet access. You would have to pay your ISP for an individual Internet account for each PC and have five phone lines. With NAT only a single account is needed with your ISP. The other four PCs may then be cabled to a switch and the switch to the NIC in your &os; system which is going to service your LAN as a gateway. NAT will automatically translate the private LAN IP address for each separate PC on the LAN to the single public IP address as it exits the firewall bound for the public Internet. It also does the reverse translation for returning packets. There is a special range of IP addresses reserved for NATed private LANs. According to RFC 1918, the following IP ranges may be used for private nets which will never be routed directly to the public Internet: Start IP 10.0.0.0 - Ending IP 10.255.255.255 Start IP 172.16.0.0 - Ending IP 172.31.255.255 Start IP 192.168.0.0 - Ending IP 192.168.255.255 IP<acronym>NAT</acronym> NAT and IPFILTER ipnat NAT rules are loaded by using the ipnat command. Typically the NAT rules are stored in /etc/ipnat.rules. See &man.ipnat.8; for details. When changing the NAT rules after NAT has been started, make your changes to the file containing the NAT rules, then run the ipnat command with the flags to delete the internal in use NAT rules and flush the contents of the translation table of all active entries. To reload the NAT rules issue a command like this: &prompt.root; ipnat -CF -f /etc/ipnat.rules To display some statistics about your NAT, use this command: &prompt.root; ipnat -s To list the NAT table's current mappings, use this command: &prompt.root; ipnat -l To turn verbose mode on, and display information relating to rule processing and active rules/table entries: &prompt.root; ipnat -v IP<acronym>NAT</acronym> Rules NAT rules are very flexible and can accomplish many different things to fit the needs of commercial and home users. The rule syntax presented here has been simplified to what is most commonly used in a non-commercial environment. For a complete rule syntax description see the &man.ipnat.5; manual page. The syntax for a NAT rule looks something like this: map IF LAN_IP_RANGE -> PUBLIC_ADDRESS The keyword map starts the rule. Replace IF with the external interface. The LAN_IP_RANGE is what your internal clients use for IP Addressing, usually this is something like 192.168.1.0/24. The PUBLIC_ADDRESS can either be the external IP address or the special keyword 0/32, which means to use the IP address assigned to IF. How <acronym>NAT</acronym> works A packet arrives at the firewall from the LAN with a public destination. It passes through the outbound filter rules, NAT gets its turn at the packet and applies its rules top down, first matching rule wins. NAT tests each of its rules against the packet's interface name and source IP address. When a packet's interface name matches a NAT rule then the source IP address (i.e.: private LAN IP address) of the packet is checked to see if it falls within the IP address range specified to the left of the arrow symbol on the NAT rule. On a match the packet has its source IP address rewritten with the public IP address obtained by the 0/32 keyword. NAT posts an entry in its internal NAT table so when the packet returns from the public Internet it can be mapped back to its original private IP address and then passed to the filter rules for processing. Enabling IP<acronym>NAT</acronym> To enable IPNAT add these statements to /etc/rc.conf. To enable your machine to route traffic between interfaces: gateway_enable="YES" To start IPNAT automatically each time: ipnat_enable="YES" To specify where to load the IPNAT rules from: ipnat_rules="/etc/ipnat.rules" <acronym>NAT</acronym> for a very large LAN For networks that have large numbers of PC's on the LAN or networks with more than a single LAN, the process of funneling all those private IP addresses into a single public IP address becomes a resource problem that may cause problems with the same port numbers being used many times across many NATed LAN PC's, causing collisions. There are two ways to relieve this resource problem. Assigning Ports to Use A normal NAT rule would look like: map dc0 192.168.1.0/24 -> 0/32 In the above rule the packet's source port is unchanged as the packet passes through IPNAT. By adding the portmap keyword, IPNAT can be directed to only use source ports in the specified range. For example the following rule will tell IPNAT to modify the source port to be within the range shown: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 Additionally we can make things even easier by using the auto keyword to tell IPNAT to determine by itself which ports are available to use: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto Using a Pool of Public Addresses In very large LANs there comes a point where there are just too many LAN addresses to fit into a single public address. If a block of public IP addresses is available, these addresses can be used as a pool, and IPNAT may pick one of the public IP addresses as packet-addresses are mapped on their way out. For example, instead of mapping all packets through a single public IP address, as in: map dc0 192.168.1.0/24 -> 204.134.75.1 A range of public IP addresses can be specified either with a netmask: map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 or using CIDR notation: map dc0 192.168.1.0/24 -> 204.134.75.0/24 Port Redirection A very common practice is to have a web server, email server, database server and DNS server each segregated to a different PC on the LAN. In this case the traffic from these servers still have to be NATed, but there has to be some way to direct the inbound traffic to the correct LAN PCs. IPNAT has the redirection facilities of NAT to solve this problem. For example, assuming a web server operating on LAN address 10.0.10.25 and using a single public IP address of 20.20.20.5 the rule would be coded as follows: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 or: rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 or for a LAN DNS Server on LAN address of 10.0.10.33 that needs to receive public DNS requests: rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp FTP and <acronym>NAT</acronym> FTP is a dinosaur left over from the time before the Internet as it is known today, when research universities were leased lined together and FTP was used to share files among research Scientists. This was a time when data security was not a consideration. Over the years the FTP protocol became buried into the backbone of the emerging Internet and its username and password being sent in clear text was never changed to address new security concerns. FTP has two flavors, it can run in active mode or passive mode. The difference is in how the data channel is acquired. Passive mode is more secure as the data channel is acquired by the ordinal ftp session requester. For a real good explanation of FTP and the different modes see http://www.slacksite.com/other/ftp.html. IP<acronym>NAT</acronym> Rules IPNAT has a special built in FTP proxy option which can be specified on the NAT map rule. It can monitor all outbound packet traffic for FTP active or passive start session requests and dynamically create temporary filter rules containing only the port number really in use for the data channel. This eliminates the security risk FTP normally exposes the firewall to from having large ranges of high order port numbers open. This rule will handle all the traffic for the internal LAN: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp This rule handles the FTP traffic from the gateway: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp This rule handles all non-FTP traffic from the internal LAN: map dc0 10.0.10.0/29 -> 0/32 The FTP map rule goes before our regular map rule. All packets are tested against the first rule from the top. Matches on interface name, then private LAN source IP address, and then is it a FTP packet. If all that matches then the special FTP proxy creates temp filter rules to let the FTP session packets pass in and out, in addition to also NATing the FTP packets. All LAN packets that are not FTP do not match the first rule and fall through to the third rule and are tested, matching on interface and source IP, then are NATed. IP<acronym>NAT</acronym> FTP Filter Rules Only one filter rule is needed for FTP if the NAT FTP proxy is used. Without the FTP Proxy, the following three rules will be needed: # Allow out LAN PC client FTP to public Internet # Active and passive modes pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Allow out passive mode data channel high order port numbers pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Active mode let data channel in from FTP server pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state IPFW - firewall + Firewall IPFW - Die IPFIREWALL - (IPFW) ist eine vom &os; Project - gesponserte Software-Firewall. Sie wurde und wird - freiwillig von Mitgliedern des &os; Projects geschrieben und - gewartet. Mit zustandslosen Regeln und einer Grammatik für - Regeln implementiert sie eine sogenannte Einfache - Zustandsgesteuerte Logik. + IPFW ist eine + Stateful-Firewall + für &os;, die sowohl IPv4 als auch + IPv6 unterstützt. Die Firewall setzt sich + aus mehreren Komponenten zusammen: dem Kernel Firewall + Filter-Prozessor mit integriertem Paket-Accounting, + Protokollfunktionen, NAT, dem + &man.dummynet.4; Traffic-Shaper, + sowie Weiterleitungs-, Bridge- und ipstealth-Funktionen. - Die Standardinstallation von IPFW enthält - einen beispielhaften Regelsatz - (/etc/rc.firewall und - /etc/rc.firewall6). Dieser ist eher - einfach gehalten; es ist nicht zu erwarten, dass dieser - ohne Modifikationen angewandt werden kann. Dieses Beispiel - nutzt keine zustandsorientierte Filterung, von der allerdings - die meisten Installationen profitieren sollten. Deshalb wird sich - dieser Abschnitt auch nicht auf diese Beispiele stützen. + &os; enthält mit /etc/rc.firewall ein + Beispielregelwerk, welches mehrere Firewall-Typen für + gebräuchliche Szenarien definiert und unerfahrene Anwender + dabei unterstützen soll, ein geeignetes Regelwerk zu erstellen. + IPFW besitzt eine leistungsstarke + Syntax, mit der erfahrene Benutzer ihre eigenen Regeln + anfertigen können, um den Sicherheitsanforderungen der + jeweiligen Umgebung gerecht zu werden. - 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. + Diser Abschnitt beschreibt, wie + IPFW aktiviert wird und bietet einen + Überblick über die Regelsyntax. Zudem werden mehrere Regelsätze + für gebräuchliche Konfigurationsszenarien vorgestellt. - IPFW besteht aus sieben Komponenten: Hauptbestandteil ist der - Kernel Firewall Filter, ein Regel-Prozessor mit integrierter - Paket-Buchführung. Außerdem enthalten - ist eine Komponente zur Protokollierung der Aktivitäten der - Firewall (also ein Logfunktion). Weiters besteht die IPFW aus einer - Regel zum Umleiten des Datenverkehrs (divert), die - auch Network Address Translation (NAT) - unterstützt. Die restlichen Bestandteile dienen verschiedenen - fortgeschrittenen Zwecken. Der - Traffic Shaper &man.dummynet.4; - gestattet es beispielsweise, den Datenverkehr zu lenken, während - die fwd-Regel zum Weiterleiten von Datenpaketen - dient. Komplettiert wird IPFW durch Funktionen zum - Überbrücken von Netzwerkgrenzen - (Bridge-Funktion) sowie - ipstealth, das es gestattet, - bridging-Funktionen durchzuführen, ohne dabei das TTL-Feld im - IP-Paket zu erhöhen. IPFW unterstützt IPv4 und IPv6. - - IPFW aktivieren + <application>IPFW</application> aktivieren - IPFW - + IPFW aktivieren - IPFW ist in der &os;-Installation standardmäßig - als ein zur Laufzeit ladbares Kernelmodul enthalten, das - vom System automatisch geladen wird, wenn in der Datei - rc.conf die Option - firewall_enable="YES" gesetzt wird. Es ist - daher nicht notwendig, IPFW statisch in den Kernel zu - kompilieren. + Das &os; Basissystem enthält für + IPFW ein ladbares Kernelmodul, was + bedeutet, dass kein angepasster Kernel benötigt wird, um + IPFW zu benutzen. - Während des Systemstart wird bei gesetzter Option - firewall_enable="YES" (in der Datei - rc.conf) folgende Nachricht ausgegeben: - - ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled - - Das Kernelmodul hat eine Protokollierungsfunktion. Um - diese zu aktivieren und einen Schwellwert für die - Protokollierung zu definieren, ist es erforderlich, folgende - Ausdrücke der /etc/sysctl.conf - hinzuzufügen: - - net.inet.ip.fw.verbose=1 -net.inet.ip.fw.verbose_limit=5 - - - - Kerneloptionen - Kerneloptionen - IPFIREWALL Kerneloptionen - IPFIREWALL_VERBOSE Kerneloptionen - IPFIREWALL_VERBOSE_LIMIT - IPFW - + IPFW Kerneloptionen - Es ist für die Aktivierung von IPFW nicht zwingend - erforderlich, die folgenden Optionen in den Kernel zu - kompilieren. Es wird hier lediglich als - Hintergrundinformation aufgeführt. + Wenn Sie eine statische Unterstützung für + IPFW in den Kernel kompilieren + wollen, lesen Sie . Folgende + Optionen können in der Kernelkonfigurationsdatei verwendet + werden: - options IPFIREWALL + 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 - Diese Option aktiviert IPFW als Bestandteil des - Kernels. + Um IPFW beim Systemstart zu + aktivieren, fügen Sie folgende Zeile in + /etc/rc.conf ein: - options IPFIREWALL_VERBOSE - - Diese Option aktiviert die Funktion, alle Pakete, die durch - IPFW verarbeitet werden und bei denen das Schlüsselwort - log gesetzt ist, zu protokollieren. - - options IPFIREWALL_VERBOSE_LIMIT=5 - - Diese Option limitiert die Anzahl der durch &man.syslogd.8; - protokollierten Pakete auf das angegebene Maximum. Sie wird - in feindlichen Umgebungen verwandt, in denen die - Protokollierung der Firewall-Aktivität erwünscht - ist. Dadurch wird ein möglicher Denial-of-Service-Angriff - durch Überflutung von &man.syslogd.8; verhindert. - - - Kerneloptionen - - IPFIREWALL_DEFAULT_TO_ACCEPT - - - options IPFIREWALL_DEFAULT_TO_ACCEPT - - Diese Option erlaubt allen Paketen, die Firewall zu passieren. - Diese Einstellung kann beispielsweise bei der ersten Konfiguration - der Firewall hilfreich sein. - - - Kerneloptionen - - IPDIVERT - - - options IPDIVERT - - Dies aktiviert die Nutzung der - NAT-Funktionalität. - - - Die Firewall wird alle eingehenden oder ausgehenden - Pakete blockieren, wenn entweder die Kernel-Option - IPFIREWALL_DEFAULT_TO_ACCEPT fehlt oder - aber keine Regel, die die betreffenden Verbindungen explizit - gestattet, existiert. Dies enstpricht im Wesentlichen der - Einstellung default to deny - - - - - Optionen in <filename>/etc/rc.conf</filename> - - Der Eintrag - firewall_enable="YES" - aktiviert die Firewall während des Systemstarts. + 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: - Die Auswahl einer für &os; verfügbaren Firewall - erfolgt durch einen entsprechenden Eintrag in der Datei - /etc/rc.firewall, durch den der Firewalltyp - festgelegt wird. - firewall_type="open" - Konkret sind folgende Einträge erlaubt: + Folgende Profile stehen zur Verfügung: - open — gestattet jeglichen - Datenverkehr + open: gestattet jeglichen + Datenverkehr. - client — schützt nur die - jeweilige Maschine (Client/Mandant) + client: schützt lediglich diesen + Rechner. - simple — schützt das - gesamte Netzwerk + simple: schützt das gesamte + Netzwerk. - closed — unterbindet - jeglichen IP-Datenverkehr mit Ausnahme des Verkehrs - über die Loopback-Schnittstelle. + closed: blockiert den gesamten + IP-Datenverkehr, mit Ausnahme des + Verkehrs über die Loopback-Schnittstelle. - UNKNOWN — deaktiviert das - Laden von Firewallregeln + workstation: schützt lediglich + diesen Rechner und verwendet zustandsorientierte + Regeln. - filename - — absoluter Pfad zu einer Datei, in der die - Firewallregeln definiert sind + UNKNOWN: deaktiviert das Laden von + Firewallregeln. + + + filename: + absoluter Pfad zu einer Datei, in der die Firewallregeln + definiert sind. + - Angepasste Regeln für &man.ipfw.8; können auf zwei - verschiedene Arten geladen werden. Einerseits kann man durch die - Variable firewall_type den absoluten Pfad - der Datei angeben, welche die Firewallregeln - (ohne weitere Optionen) für &man.ipfw.8; enthält. Ein - einfaches Beispiel für einen Regelsatz, der jeglichen - eingehenden und ausgehenden Datenverkehr blockiert, könnte - beispielsweise so aussehen: + Wenn Sie firewall_type auf + client oder simple + setzen, müssen Sie die voreingestellten Regeln in + /etc/rc.firewall anpassen, damit sie + der Konfiguration des Systems entsprechen. - add deny in add deny out + Beachten Sie, dass das Profil filename + verwendet wird, um ein benutzerdefiniertes Regelwerk zu + laden. - Andererseits ist es möglich, den Wert der - firewall_type-Variable mit dem absoluten - Pfad einer Datei zu belegen, die (als ausführbares Skript) - die &man.ipfw.8;-Kommandos enthält, die beim Booten - ausgeführt werden sollen. Ein gültiges Skript (das die - gleiche Funktion hat wie die Zeile im letzten Beispiel) könnte - beispielsweise so aussehen: + Eine alternative Möglichkeit, um ein benutzerdefiniertes + Regelwerk zu laden, bietet die Variable + firewall_script. Setzen Sie die Variable + auf den absoluten Pfad eines + ausführbaren Skripts, welches die Befehle + für IPFW enthält. Die Beispiele in + diesem Abschnitt gehen davon aus, dass + firewall_script auf + /etc/ipfw.rules gesetzt ist. - #!/bin/sh + firewall_script="/etc/ipfw.rules" -ipfw -q flush + Die Protokollierung wird mit diesem Eintrag + aktiviert: -ipfw add deny in -ipfw add deny out - - - Wenn die Variable firewall_type - entweder auf client oder - simple gesetzt ist, sollten die - Standardregeln in der Datei - /etc/rc.firewall geprüft und an die - Konfiguration der gegebenen Maschine angepasst werden. Beachten - Sie dabei bitte, dass die Beispiele dieses Kapitels davon - ausgehen, dass das firewall_script auf - /etc/ipfw.rules gesetzt ist. - - - Das Logging wird durch folgenden Eintrag aktiviert: - firewall_logging="YES" - - Die Variable firewall_logging definiert - lediglich die sysctl-Variable als - net.inet.ip.fw.verbose = 1 (lesen Sie dazu - bitte auch den Abschnitt - des Handbuchs). Es gibt keine - rc.conf-Variable, mit der man - Protokollierungsschwellen setzen könnte. Dies kann - lediglich über &man.sysctl.8; geschehen, wobei Sie in - der Datei /etc/sysctl.conf nur - Werte > 1 angeben sollten: + Es existiert keine Variable für + /etc/rc.conf, um die Protokollierung zu + begrenzen. Um die Anzahl der Protokoll-Nachrichten pro + Verbindungsversuch zu begrenzen, legen Sie die Anzahl der + Einträge in /etc/sysctl.conf fest: - net.inet.ip.fw.verbose_limit=5 - + net.inet.ip.fw.verbose_limit=5 - Sollte Ihre Maschinen als Gateway fungieren (also mittels - &man.natd.8; Network Address - Translation (NAT) - durchführen), finden Sie weitere Optionen in - /etc/rc.conf. - + Nachdem Sie die Änderungen gespeichert haben, können Sie + die Firewall starten. Um auch die Anzahl der + Protokoll-Nachrichten zu konfigurieren, setzen Sie mit + sysctl den gewünschten Wert: - - Der Befehl IPFW - - ipfw - - Mit &man.ipfw.8; ist es möglich, im laufenden Betrieb - einzelne Regeln hinzuzufügen oder zu entfernen. Problematisch - ist allerdings, dass diese Änderungen verloren gehen, wenn - das System neu gestartet wird. Daher ist es empfehlenswert, - eigene Regeln in einer Datei zu definieren und diese zu laden, um - die Regeln der Firewall im laufenden Betrieb anzupassen. - - &man.ipfw.8; ist jedoch hilfreich, um die Regeln der laufenden - Firewall in der Konsole auszugeben. IPFW erzeugt dynamisch einen - Zähler, der jedes Paket, auf das eine Regel zutrifft, - zählt. Dadurch wird es möglich, die Funktion einer - Regel zu überprüfen. - - Eine sequentielle Liste aller Regeln erhalten Sie mit: - - &prompt.root; ipfw list - - Eine Liste aller Regeln inklusive des letzten Treffers - erhalten Sie durch den folgenden Befehl: - - &prompt.root; ipfw -t list - - Um eine Liste aller Regeln inklusive der Anzahl der Pakete, die - von einer Regel gefiltert wurden, zu erhalten, geben Sie - den folgenden Befehl ein: - - &prompt.root; ipfw -a list - - Eine Liste, die zusätzlich allen dynamischen Regeln - enthält, erhalten Sie mit: - - &prompt.root; ipfw -d list - - Um diese Liste um alle abgelaufenen Regeln zu - erweitern, ädern Sie diesen Befehl wie folgt ab: - - &prompt.root; ipfw -d -e list - - Alle Zähler auf Null zurücksetzen: - - &prompt.root; ipfw zero - - Es ist auch möglich, einen spezifischen Zähler - auszuwählen und zurückzusetzen: - - &prompt.root; ipfw zero NUM + &prompt.root; service firewall start +&prompt.root; sysctl net.inet.ip.fw.verbose_limit=5 - IPFW-Regeln + <application>IPFW</application> Regel-Syntax - Ein Regelwerk ist eine Menge von IPFW-Regeln, die in - Abhängigkeit von bestimmten Paketeigenschaften Pakete - entweder passieren lassen oder abweisen. Der - zustandshafte bidirektionale Transfer von Paketen zwischen - Rechnern wird als Sitzung bezeichnet. Das Regelwerk der Firewall - verarbeitet sowohl ankommende Pakete (aus dem öffentlichen - Internet) als auch Pakete, deren Ursprung in einer Antwort des - Systems auf empfangene Pakete liegt. Jeder - TCP/IP-Dienst (wie telnet, www, mail) ist - durch sein Protokoll und durch den priveligierten - (eingehenden) Port definiert. An einen spezifischen Dienst - adressierte Pakete kommen von einer Quelladresse und einem - unprivilegierten (high order) Port. Sie adressieren den - spezifischen Port des Dienstes an der Zieladresse. Alle weiter - oben aufgeführten Parameter (also Ports und Adressen) - können als Selektionskriterium zur Erzeugung von Regeln - genutzt werden, die ein Passieren der Firewall für oder - ein Blockieren von Diensten bewirken. - - - IPFW - - rule processing order - - - - Wenn ein Paket die Firewall betritt, also von der Firewall geprüft und verarbeitet wird, wird die erste Regel des Regelwerkes auf das Paket angewandt. Auf diese Weise wird in aufsteigender Reihenfolge der Regelnummer mit allen weiteren Regeln verfahren. Falls die Selektionsparameter einer Regel auf ein Paket zutreffen, wird das Aktionsfeld der Regel ausgeführt und die Prüfung des Pakets beendet, nachfolgende Regeln werden also nicht mehr geprüft. Diese Suchmethode wird als erster - Treffer gewinnt bezeichnet. Falls keine Regel auf + Treffer gewinnt bezeichnet. Falls keine Regel auf das betreffende Paket zutrifft, wird die obligatorische - IPFW-Rückfallregel (also Regel 65535) angewendet und das - Paket wird ohne Rückantwort verworfen. + IPFW-Rückfallregel mit der Nummer + 65535 angewendet und das Paket wird ohne Rückantwort + verworfen. Wenn das Paket jedoch einer Regel mit dem + Schlüsselwort count, + skipto oder tee + entspricht, wird die Prüfung des Pakets weiter + fortgeführt. Weitere Details darüber, wie diese + Schlüsselwörter die Regelverarbeitung beeinflussen, finden Sie + in &man.ipfw.8;. - - Die Prüfung der Regeln wird nach Treffern von mit - count, skipto und - tee parametrisierten Regeln ungeachtet - des erster Treffer gewinnt-Prinzips weiter - fortgeführt. - + + IPFW + Regel-Syntax + - Die Anweisungen basieren auf der Nutzung von Regeln - mit den zustandsgesteuerten Optionen keep, - state, limit, - in und out. Diese - bilden die Basis für die Spezifikation von - Firewallregeln. + Bei der Erstellung der + IPFW-Regeln müssen die + Schlüsselwörter in der folgenden Reihenfolge geschrieben + werden. Einige Schlüsselwörter müssen zwingend angegeben + werden, während andere optional sind. Die Wörter in + Großbuchstaben repräsentieren Variablen und die Wörter in + Kleinbuchstaben müssen den Variablen vorangestellt + werden. Das Zeichen # wird benutzt, um + einen Kommentar einzuleiten und kann am Ende einer Regel oder + in einer eigenen Zeile stehen. Leerzeilen werden + ignoriert. - - Bei der Arbeit mit Firewallregeln ist Vorsicht geboten. - Es ist sehr einfach, sich selbst auszuschließen. - + CMD RULE_NUMBER set SET_NUMBER ACTION log + LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT + OPTIONS - - Syntax der Firewallregeln + Dieser Abschnitt bietet einen Überblick über diese + Schlüsselwörter und deren Optionen. Es ist keine vollständige + Liste aller verfügbaren Optionen. Eine vollständige + Beschreibung der Regel-Syntax, die Sie verwenden können um + IPFW-Regeln zu erstellen, finden + Sie in &man.ipfw.8;. - - IPFW + + + CMD + + Jede Regel muss mit ipfw add + beginnen. + + - rule syntax - + + RULE_NUMBER + + Jede Regel gehört zu einer Nummer zwischen + 1 und 65534. Die + Nummer wird verwendet, um die Reihenfolge der + Regelverarbeitung zu kennzeichnen. Es ist möglich, dass + mehrere Regeln dieselbe Nummer haben. In diesem Fall + werden sie entsprechend der Reihenfolge angewendet, in + der sie aufgenommen wurden. + + - Mit der in diesem Abschnitt dargestellten Syntax der - Regeln kann ein Standardregelsatz für eine - einschließende Firewall erstellt - werden. Für eine vollständige Beschreibung der - Regelsyntax lesen Sie bitte die Manualpage &man.ipfw.8; + + SET_NUMBER + + Jede Regel ist einer Set-Nummer + zwischen 0 und 31 + zugeordnet. Sets können einzeln aktiviert oder + deaktiviert werden. Dies macht es möglich, eine Reihe + von Regeln schnell hinzuzufügen oder zu löschen. Wenn + SET_NUMBER nicht angegeben ist, wird + die Regel zu Set 0 + hinzugefügt. + + - Regelausdrücke werden von links nach - rechts ausgewertet. Schlüsselwörter - werden in fetter Schrift dargestellt. Manche - Schlüsselworte beinhalten Unteroptionen, die wiederum - selbst aus Schlüsselworten samt Optionen bestehen - können. + + ACTION + + Eine Regel kann mit einer der folgenden Aktionen + verknüpft werden. Die festgelegte Aktion wird + ausgeführt, wenn das Paket den Selektionskriterien der + Regel entspricht. - Kommentare sind mit einen führenden Doppelkreuz - (#) ausgezeichnet. Sie können am - Ende einer Regel oder in einzelnen, separaten Zeilen stehen. - Leerzeilen werden ignoriert. + allow | accept | pass | + permit: All diese Aktionen sind + gleichbedeutend und erlauben Pakete, die mit der Regel + übereinstimmen. - CMD RULE_NUMBER ACTION LOGGING SELECTION - STATEFUL + check-state: Diese Aktion + überprüft die Regel in der dynamischen Zustandstabelle. + Bei einer Übereinstimmung wird die mit der dynamischen + Regel verknüpfte Aktion ausgeführt, andernfalls wird mit + der Prüfung gegen die nächste Regel fortgefahren. Die + Regel check-state hat selbst kein + Selektionskriterium. Sollte keine + check-state-Regel im Regelwerk + vorhanden sein, wird die dynamische Zustandstabelle beim + ersten Vorkommen einer keep-state- + oder limit-Regel überprüft. - - CMD + count: Aktualisiert die + Zähler für alle Pakete, die mit dieser Regel + übereinstimmen. Die Prüfung wird mit der nächsten Regel + fortgesetzt. - Jede neue Regel benötigt das Präfix - add, um die Regel der internen - Tabelle hinzuzfügen. - + deny | drop: Diese Aktionen + sind gleichbedeutend und verwerfen Pakete, die mit + dieser Regel übereinstimmen. - - RULE_NUMBER + Es stehen noch weitere Aktionen zur Verfügung. + Einzelheiten finden Sie in &man.ipfw.8;. + + - Zu jeder Regel gehört eine Regelnummer zwischen 1 - und 65535. - + + LOG_AMOUNT + + Erfüllt ein Paket die Selektionskriterien mit dem + Schlüsselwort log, wird dies von + &man.syslogd.8; mit der Annotation + SECURITY protokolliert. Dies erfolgt + allerdings nur, wenn die Anzahl der protokollierten + Pakete der betreffenden Regel die definierte + LOG_AMOUNT-Grenze nicht übersteigt. + Wenn LOG_AMOUNT nicht definiert ist, + wird die Grenze aus dem Wert von + net.inet.ip.fw.verbose_limit + benutzt. Ein Wert von 0 bedeutet + eine unbegrenzte Protokollierung. Wird eine definierte + Grenze erreicht, wird die Protokollierung für diese + Regel deaktiviert. Um die Protokollierung zu + reaktivieren, können Sie den Protokoll- oder Paketzähler + mit ipfw resetlog + zurücksetzen. - - ACTION + + 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. + + + - Eine Regel kann mit einer der vier folgenden Aktionen - verbunden sein, die ausgeführt werden, wenn ein Paket - den Selektionskriterien der Regel entspricht. + + PROTO + + Dieser optionale Wert wird verwendet, um einen + beliebigen Protokollnamen oder -nummer aus + /etc/protocols gegen das Paket zu + prüfen. + + - allow | accept | pass | permit + + SRC + + Nach dem Schlüsslwortfrom muss + die Quelladresse stehen, oder ein Schlüsselwort, das die + Quelladresse darstellt. Eine Adresse wird dargestellt + duch any, me (jede + Adresse dieses Systems), me6 (jede + IPv6-Adresse dieses Systems), oder + table gefolgt von der Nummer der + Tabelle, welche die Adressen enthält. + IP-Adressen können in + CIDR-Notation geschrieben werden. + Beispielsweise 1.2.3.4/25 oder + 1.2.3.4:255.255.255.128. + + - 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. + + SRC_PORT + + Optional kann ein Quellport über eine Nummer oder + einen Namen aus /etc/services + spezifiziert werden. + + - check-state + + DST + + Nach dem Schlüsselwort to muss + die Zieladresse stehen, oder ein Schlüsselwort, das die + Zieladresse darstellt. Es können die gleichen + Schlüsselwörter und Adressen benutzt werden, die bereits + im SRC-Abschnitt beschrieben wurden. + + - Diese Aktion prüft das Paket gegen die Regeln aus - den dynamischen Regeltabellen. Trifft ein - Selektionskriterium zu, wird die zur dynamischen Regel - gehörende Aktion ausgeführt. Anderenfalls wird - gegen die nächste Regel geprüft. Die - check-state-Regel selbst hat kein - Selektionskriterium. Sollte eine - check-state-Regel im Regelwerk fehlen, - wird gegen die erste keep-state- oder - limit-Regel in den dynamischen Regeln - geprüft. + + DST_PORT + + Optional kann ein Zielport über eine Nummer oder + einen Namen aus /etc/services + spezifiziert werden. + + - deny | drop + + OPTIONS + + Nach der Quell- und Zieladresse können noch weitere + Optionen angegeben werden. Wie der Name bereits sagt, + sind OPTIONS optional. Häufig + verwendete Optionen sind in oder + out, mit denen die Richtug des + Pakets bestimmt wird, icmptypes + gefolgt vom Typ der ICMP-Nachricht, + sowie keep-state. - Beide Schlüsselworte bewirken dieselbe Aktion: - Ein Paket, dass die Selektionskriterien der Regel - erfüllt, wird verworfen und die Regelprüfung - wird beendet. - + Wenn ein Paket auf eine + keep-state-Regel zutrifft, wird + die Firewall eine dynamische Regel erstellen, die dem + bidirektionalen Datenverkehr zwischen den gleichen + Quell- und Zieladressen mit dem gleichen Protokoll + entspricht. - - Protokollierung + Dynamische Regeln sind für einen sogenannten + SYN-flood-Angriff + anfällig, bei dem eine riesige Anzahl an dynamischen + Regeln erzeugt wird. Verwenden Sie die Option + limit, um einen solchen Angriff + entgegenzuwirken. Diese Option begrenzt die Anzahl + der gleichzeitig möglichen Sitzungen. Es handelt sich + dabei um einen Zähler, der die Anzahl von dynamischen + Regeln in Kombination mit der Quelladresse verfolgt. + Übersteigt der Zähler den durch limit + definierten Wert, wird das Paket verworfen. - log oder - logamount + Es stehen noch viele weitere Optionen zur Verfügung. + &man.ipfw.8; enthält eine Beschreibung der einzelnen + Optionen. + + + + - Erfüllt ein Paket die Selektionskriterien mit dem - Schlüsselwort log, wird dies von - &man.syslogd.8; mit der Annotation SECURITY protokolliert. - Dies erfolgt allerdings nur, wenn die Anzahl der - protokollierten Pakete der betreffenden Regel die im - logamount-Parameter definierte - Schwelle nicht übersteigt. Ist der Parameter - logamount nicht definiert, wird diese - Grenze aus der sysctl-Variable - net.inet.ip.fw.verbose_limit ermittelt. - Ist einer dieser beiden Werte auf Null - gesetzt, wird unbegrenzt protokolliert. Wurde hingegen - ein definierter Schwellenwert erreicht, wird die - Protokollierung deaktiviert. Um sie zu reaktivieren, - können Sie entweder den Protokoll- oder den - Paketzähler rücksetzen (und zwar über den - Befehl ipfw reset log). + + Beispiel für einen Regelsatz - - Die Protokollierung findet statt, nachdem alle - Paketselektionskriterien geprüft und bevor die - daraus folgende, endgültige Aktion - (accept oder deny) - auf das Paket ausgeführt wird. Die Entscheidung, - welche Regel protokolliert werden soll, bleibt Ihnen - überlassen. - - + Dieser Abschnitt die Erstellung eines Firewall-Skripts + namens /etc/ipfw.rules mit + zustandsorientierten (stateful + Regeln. Alle Regeln in diesem Beispiel verwenden die Optionen + in und out, um die + Richtung des Pakets zu verdeutlichen. Zusätzlich wird + via + interface-name benutzt, um die + Schnittstelle für das Paket zu prüfen. - - Selektion + + Bei den anfänglichen Tests mit dem Firewall-Regelsatz + sollten Sie vielleicht folgende Einstellung + vornehmen: - 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. + net.inet.ip.fw.default_to_accept="1" - udp | tcp | icmp + Dies legt die Standardregel von &man.ipfw.8; etwas + großzügiger fest, als das voreingestellte + default deny ip from any to any. Dadurch + sinkt die Gefahr, sich nach einem Neustart des Systems + auszusperren. + - Weitere in /etc/protocols - angegebene Protokolle werden ebenfalls erkannt und - können daher verwendet werden, um das Protokoll zu - definieren, gegen das Pakete geprüft werden. Die - Angabe des Protokolls ist verpflichtend. + Das Firewall-Skript beginnt mit einem Hinweis, dass es + sich um ein Bourne Shell-Skript handelt. Danach werden alle + vorhandenen Filterregeln gelöscht. Anschließend wird die + Variable cmd erstellt, sodass + ipfw add nicht jedes mal von Hand + eingegeben werden muss. Die Variable pif + repräsentiert die mit dem Internet verbundene + Schnittstelle. - from src to dst + #!/bin/sh +# Flush out the list before we begin. +ipfw -q -f flush - Die Schlüsselwörter from - und to beziehen sich auf IP-Adressen und - definieren sowohl Ursprungs- als auch Zieladresse einer - Datenverbindung. Firewallregeln müssen Parameter - für den Ursprung und das Ziel - enthalten. Das Schlüsselwort any - steht für beliebige IP-Adressen. Bei - me handelt es sich um ein spezielles - Schlüsselwort, das alle IP-Adressen beschreibt, die - einer bestimmten Netzwerkschnittstelle Ihres Systems - (auf dem die Firewall läuft) zugeordnet sind. - Beispiele hierfür sind - from me to any, - from any to me, - from 0.0.0.0/0 to any , - from any to 0.0.0.0/0, - from 0.0.0.0 to any, - from any to 0.0.0.0 oder - from me to 0.0.0.0. IP-Adressen werden - entweder in CIDR-Notation - oder durch Punkte getrennt mit Suffixen - (192.168.2.101/24) für - die Netzmaske oder als einzelne numerische, durch Punkte - getrennte Adressen - (192.168.2.101) angegeben. - Die dafür notwendigen Berechnungen erleichtert der - Port net-mgmt/ipcalc. - Weiterführende Informationen finden sich auf - http://jodies.de/ipcalc. +# Set rules command prefix +cmd="ipfw -q add" +pif="dc0" # interface name of NIC attached to Internet - port number + Jetzt folgen die eigentlichen Filterregeln. Diese ersten + beiden Regeln erlauben den Datenverkehr aus dem internen + Netzwerk und über die Loopback-Schnittstelle: - Bei der Verarbeitung von Protokollen wie - TCP oder UDP, die - Portnummern verwenden, muss die Portnummer des - betreffenden Dienstes angegeben werden. Anstelle der - Portnummer kann auch der in der Datei - /etc/services definierte Name des - Dienstes angegeben werden. + # Change xl0 to LAN NIC interface name +$cmd 00005 allow all from any to any via xl0 - in | out +# No restrictions on Loopback Interface +$cmd 00010 allow all from any to any via lo0 - Diese Schlüsselwörter beziehen sich auf die - Richtung des Datenverkehrs. Jede Regel - muss eines dieser beiden - Schlüsselwörter enthalten. + Die nächste Regel erlaubt Pakete, für die ein Eintrag + in der dynamischen Zustandstabelle existiert: - via IF + $cmd 00101 check-state - Eine Regel mit dem Schlüsselwort - via IF betrifft nur Pakete, die über - die angegebene Schnittstellte geroutet werden (ersetzen Sie - IF durch den Namen Ihrer - Netzwerkschnittstelle). Die Angabe des - Schlüsselwortes via bewirkt, dass - die Netzwerkschnittstelle in die Regelprüfung - aufgenommen wird. + Die nächsten Regeln definieren, welche internen Rechner + Verbindungen zu anderen Rechnern im Internet aufbauen dürfen. + Hier werden wieder zustandsorientierte Regeln + verwendet: - setup + # Allow access to public DNS +# Replace x.x.x.x with the IP address of a public DNS server +# and repeat for each DNS server in /etc/resolv.conf +$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state +$cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state - Dieses obligatorische Schlüsselwort bezeichnet - die Anforderung des Sitzungsstarts für - TCP-Pakete. +# Allow access to ISP's DHCP server for cable/DSL configurations. +# Use the first rule and check log for IP address. +# Then, uncomment the second rule, input the IP address, and delete the first rule +$cmd 00120 allow log udp from any to any 67 out via $pif keep-state +#$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state - keep-state +# Allow outbound HTTP and HTTPS connections +$cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state +$cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state - Dieses obligatorische Schlüsselwort bewirkt, - dass die Firewall eine dynamische Regel erzeugt, die - bidirektionalen Datenverkehr zwischen Ursprungs- und - Zieladresse sowie Ursprungs- und Zielport prüft, - der das gleiche Protokoll verwendet. +# Allow outbound email connections +$cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state +$cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state - limit {src-addr | src-port | dst-addr | - dst-port} +# Allow outbound ping +$cmd 00250 allow icmp from any to any out via $pif keep-state - Wird das Schlüsselwort limit - verwendet, sind nur N durch diese - Regel definierte Verbindungen erlaubt. Es können - dabei ein oder mehrere Ursprungs- und Zieladressen sowie - ein oder mehrere Ports angegeben werden. Die - Schlüsselwörter limit - und keep-state können nicht in - derselben Regel verwendet werden. Die Option - limit bewirkt dieselbe Zustandsteuerung - wie die Option keep-state, erweitert - diese jedoch um eigene Regeln. - - +# Allow outbound NTP +$cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state - - Optionen für zustandsgesteuerte Regeln +# Allow outbound SSH +$cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state - - IPFW +# deny and log all other outbound connections +$cmd 00299 deny log all from any to any out via $pif - stateful filtering - + Die folgenden Regeln steuern die Verbindungen von + Rechern aus dem Internet ins interne Netzwerk. Zuerst werden + Pakete verworfen, die typischerweise im Zusammenhang mit + Angriffen stehen. Danach werden bestimmte Arten von + Verbindungen erlaubt. Alle Dienste aus dem öffentlichen + Internet beinhalten die Option limit, um + Flooding zu unterbinden. - + # Deny all inbound traffic from non-routable reserved address spaces +$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP +$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP +$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP +$cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #loopback +$cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback +$cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config +$cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs +$cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect +$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast - Eine zustandsgesteuerte Filterung behandelt Datenverkehr - als einen bidirektionalen Austausch von Datenpaketen (die eine - sogenannte Konversation innerhalb einer Sitzung darstellen). - Sie ist in der Lage, zu bestimmen, ob die Konversation von - originärem Sender und Empfänger gültigen - Prozeduren des bidirektionalen Pakettausches entspricht. - Pakete, die dem Muster von Konversationen in Sitzungen nicht - folgen, werden automatisch als Betrüger - abgelehnt. +# Deny public pings$ +$cmd 00310 deny icmp from any to any in via $pif$ +$ +# Deny ident$ +$cmd 00315 deny tcp from any to any 113 in via $pif$ +$ +# Deny all Netbios services.$ +$cmd 00320 deny tcp from any to any 137 in via $pif$ +$cmd 00321 deny tcp from any to any 138 in via $pif$ +$cmd 00322 deny tcp from any to any 139 in via $pif$ +$cmd 00323 deny tcp from any to any 81 in via $pif$ - Die check-state-Option wird verwendet, - wo genau innerhalb des IPFW-Regelwerks die Prüfung - dynamischer Regeln stattfinden soll. Erfüllt ein - Datenpaket die Selektionskriterien der Regel, verlässt - das Paket die Firewall. Gleichzeitig wird eine neue - dynamische Regel erzeugt, die für das nächste Paket - der bidirektionalen Konversation in der Sitzung vorgesehen - ist. Falls ein Paket die (dyanmische) Regel nicht erfüllt, - wird es gegen die nächste Regel im Regelwerk - geprüft. +# Deny fragments +$cmd 00330 deny all from any to any frag in via $pif - Dynamische Regeln sind für einem sogenannten - SYN-flood-Angriff anfällig, - bei dem eine riesige Anzahl schwebender - dynamischer Regelprüfungungsinstanzen erzeugt wird. Um - einem solchen Angriff zu begegnen, wurde in &os; die neue - Option limit geschaffen. Diese Option - begrenzt die Anzahl der gleichzeitig möglichen - Sitzungen und/oder Konversationen. Es handelt sich dabei um - einen Zähler, der die Anzahl von Instanzen dynamischer - Regelprüfungen in Abhängigkeit von einer eindeutigen - Urspungs- und Quelladresskombination zählt. - Übersteigt der Zähler den durch - limit definierten Schwellenwert, wird - das Paket verworfen. - +# Deny ACK packets that did not match the dynamic rule table +$cmd 00332 deny tcp from any to any established in via $pif - - Protokollierung von Firewall-Nachrichten +# Allow traffic from ISP's DHCP server. +# Replace x.x.x.x with the same IP address used in rule 00120. +#$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state - - IPFW +# Allow HTTP connections to internal web server +$cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 - logging - +# Allow inbound SSH connections +$cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 - 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. +# Reject and log all other incoming connections +$cmd 00499 deny log all from any to any in via $pif - IPFW protokolliert nur jene Regeln, für die ein - Administrator dies explizit aktiviert. Ein Aktivieren - der Protolllfunktion führt also nicht dazu, dass - automatisch alle Regeln protokolliert werden. Vielmehr - entscheidet der Administrator der Firewall, welche Regeln - protokolliert werden sollen. Dazu wird die Option - log für diese Regeln aktiviert. Im - Regelfall werden nur deny-Regeln - protokolliert, beispielsweise die deny-Regel - für eintreffende ICMP-Nachrichten. - Üblicherweise wird die ipfw default deny - everything-Regel doppelt angelegt. Einmal mit und - einmal ohne aktivierte Option log. Dadurch - erhält man eine Auflistung aller Pakete, auf die keine - Regel zutraf. + Die letzte Regel protokolliert alle Pakete, die mit + keiner Regel im Regelsatz übereinstimmen: - Protokollierung ist allerdings ein zweischneidiges - Schwert, bei mangelnder Vorsicht wird man mit einer enormen - Flut von Protokollierungsdaten förmlich - überschwemmt und belastet - zusätzlich die Festplatte des Systems durch rasch - wachsende Protokolldateien. DoS-Angriffe, die auf diese - Art und Weise Festplatten an die Kapazitätsgrenze treiben, - gehören zu den ältesten Angriffen überhaupt. - Außerdem werden Protokollnachrichten nicht nur an - &man.syslogd.8; geschickt, sondern auch auf einem - root-Terminal angezeigt. + # Everything else is denied and logged +$cmd 00999 deny log all from any to any + - Die Kerneloption - IPFIREWALL_VERBOSE_LIMIT=5 begrenzt die - Anzahl gleicher Nachrichten an &man.syslogd.8; für - eine gegebene Regel auf fünf Nachrichten. Ist diese - Option im Kernel aktiviert, wird nach Erreichen der - festgelegten Anzahl die Protokollierung einer (sich - unmittelbar hintereinander wiederholenden) Nachricht auf den - angegebenen Schwellenwert begrenzt, da beispielsweise die - Speicherung von 200 gleichen Protokollnachrichten durch - &man.syslogd.8; sinnlos ist. Daher werden durch diesen - nur füf derartige Nachrichten protokolliert. Alle - weiteren derartigen Nachrichten werden nur gezählt und - deren Gesamtzahl wird schließlich von &man.syslogd.8; - durch folgenden Ausdruck ausgegeben: + + + <acronym>NAT</acronym> Konfiguration - last message repeated 45 times + + + + Chern + Lee + + Beigetragen von + + + - Alle protokollierten Nachrichten für Datenpakete - werden in der Voreinstellung in die Datei - /var/log/security (die in der Datei - /etc/syslog.conf definiert wird), - geschrieben. - + + NAT + und IPFW + - - Skripte zur Regeldefinition erstellen + &os;s integrierter NAT-Daemon, + &man.natd.8;, arbeitet in Verbindung mit + IPFW, um + Network Address Translation + bereitzustellen. NAT wird verwendet, um + mehreren internen Rechnern, über eine einzige + IP-Adresse, eine gemeinsame Verbindung zum + Internet zu ermöglichen. - 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. + Um dies zu tun, muss der mit dem Internet verbundene + &os;-Rechner als Gateway eingerichtet sein. Das System muss + über zwei Netzwerkschnittstellen verfügen, wobei eine + Schnittstelle mit dem Internet verbunden ist und die andere + mit dem internen Netzwerk. Jeder Rechner im internen Netzwerk + sollte eine RFC + 1918 konforme Adresse zugewiesen bekommen. Zudem + muss das Standard-Gateway der Rechner auf die interne + IP-Adresse des &man.natd.8;-Systems + gesetzt werden. - Die Syntax des folgenden Skripts entspricht der Syntax von - &man.sh.1;, &man.csh.1; sowie &man.tcsh.1;. Felder, die - symbolisch substituiert werden, haben das Präfix - $ (das Dollarzeichen). Symbolische Felder haben dieses - $-Praefix nicht. Der Wert, mit dem das symbolische - Feld belegt wird, muss in - doppelten Anführungszeichen - eingeschlossen sein. + Es ist noch ein wenig Konfiguration nötig, um die + NAT-Funktion von + IPFW zu aktivieren. Wenn das + System einen angepassten Kernel hat, muss die + Kernelkonfigurationsdatei die Zeile + option IPDIVERT sowie weitere + IPFIREWALL-Optionen, die in beschrieben sind, + enthalten. - Beginnen Sie Ihre Regeldatei wie folgt: + Um die NAT-Unterstützung beim Booten + zu aktivieren, müssen folgende Einträge in + /etc/rc.conf vorhanden sein: - ############### start of example ipfw rules script ############# -# -ipfw -q -f flush # Delete all rules -# Set defaults -oif="tun0" # out interface -odns="192.0.2.11" # ISP's DNS server IP address -cmd="ipfw -q add " # build rule prefix -ks="keep-state" # just too lazy to key this each time -$cmd 00500 check-state -$cmd 00502 deny all from any to any frag -$cmd 00501 deny tcp from any to any established -$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks -$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks -$cmd 00611 allow udp from any to $odns 53 out via $oif $ks -################### End of example ipfw rules script ############ + gateway_enable="YES" # enables the gateway +natd_enable="YES" # enables NAT +natd_interface="rl0" # specify interface name of NIC attached to Internet +natd_flags="-dynamic -m" # -m = preserve port numbers; additional options are listed in &man.natd.8; - Die Regeln in diesem Beispiel sind nicht wichtig. Wichtig - ist es, zu zeigen, wie die symbolische Substitution innerhalb - der Regeln verwendet wird. + + Es ist auch möglich eine Konfigurationsdatei zu + verwenden, welche die Optionen enthält, die an + &man.natd.8; übergeben werden: - Wurde dieses Beispiel in der Datei - /etc/ipfw.rules gespeichert, so können - alle Regeln durch die Ausführung des folgenden Befehls - neu geladen werden: + natd_flags="-f /etc/natd.conf" - &prompt.root; sh /etc/ipfw.rules + Die angegebene Datei muss die Konfigurationsoptionen + enthalten, eine Option pro Zeile. Zum Beispiel: - Statt /etc/ipfw.rules können Sie - auch einen beliebigen anderen Namen und/oder Speicherort - verwenden. + redirect_port tcp 192.168.0.2:6667 6667 +redirect_port tcp 192.168.0.3:80 80 - Alternativ könnten Sie die einzelnen Befehle dieses - Skripts auch manuell starten: + Weitere Informationen zu dieser Konfigurationsdatei + finden Sie in &man.natd.8;. + - &prompt.root; ipfw -q -f flush -&prompt.root; ipfw -q add check-state -&prompt.root; ipfw -q add deny all from any to any frag -&prompt.root; ipfw -q add deny tcp from any to any established -&prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state -&prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state -&prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state - + Als nächstes werden die NAT-Regeln + hinzugefügt. Wenn die Regeln zustandsorientiert sind, ist die + Platzierung der NAT-Regeln sehr wichtig und + die skipto-Aktion wird verwendet. Dies + erfordert, dass jede Regel über eine eindeutige Nummer + verfügt, um eindeutige Sprungziele zu erhalten. - - Zustandsgesteuertes Regelwerk + Das folgende Beispiel baut auf dem im vorherigen Abschnitt + gezeigten Firewall-Relgelsatz auf. Es werden einige neue + Einträge hinzugefügt und bestehende Regeln modifiziert, um + NAT zu konfigurieren. Zunächst werden + einige Variablen hinzugefügt, darunter Regelnummern, die + keep-state-Option und eine Liste mit + TCP-Ports um die Anzahl der Regeln zu + reduzieren: - Das folgende Regelwerk (ohne - NAT-Funktionalität) ist ein Beispiel - dafür, wie man eine sehr sichere - einschließende Firewall aufsetzen kann. - Eine einschließende Firewall erlaubt es nur Diensten, - für die explizite Regeln existieren, die Firewall zu - passieren. Alle anderen Dienste und Pakete werden hingegen - blockiert. Firewalls, die ganze Netzwerksegmente schützen - sollen, benötigen mindestens zwei Netzwerkschnittstellen, - für die jeweils eigene Regeln definiert werden müssen, - damit die Firewall ordnungsgemäß funktioniert. - - Alle unixoiden Betriebssysteme (aber auch solche, die - Konzepte aus &unix; implementieren), darunter auch &os;, - verwenden die Schnittstelle lo0 mit - der IP-Adresse 127.0.0.1 zur - internen Kommunikation mit dem Betriebssystem. Die Firewall - muss so eingestellt sein, dass sie den Datenverkehr dieser - speziellen (und nur intern genutzten) Pakete ungehindert - durchlässt. - - Die Regeln, die den Zugriff auf eingehene und ausgehende - Verbindungen regeln, autorisieren und kontrollieren, - müssen mit der für die Verbindung zum - öffentlichen Internet verantwortlichen Schnittstelle - assoziiert werden. Bei dieser Schnittstelle kann es sich - beispielsweise um - PPP/tun0 oder - die Netzwerkkarte handelt, über, die mit Ihrem - DSL- oder Kabelmodem verbunden - ist. - - Falls mehr als eine Netzwerkkarte mit einem privaten - Netzwerk (hinter der Firewall) verbunden sind, müssen - die Firewallregeln für alle diese Schnittstellen - entstammenden Datenpakete freien und ungehinderten - Datenverkehr erlauben. - - Es ist sinnvoll, die Regeln in drei Abschnitte - aufzuteilen. Der erste Abschnitt enthält die freien, - von der Firewall nicht zu überwachenden - Netzwerkschnittstellen. Danach folgen die öffentlichen, - für den ausgehenden Verkehr verantwortlichen - Schnittstellen. Zuletzt kommen dann die Schnittstellen, - die für den eingehenden Datenverkehr verantwortlich - sind. - - Innerhalb der einzelnen Abschnitte ist es sinnvoll, die - am häufigsten verwendeten Regeln vor den seltener - verwendeten Regel zu platzieren. Jeder Abschnitt sollte - mit einer letzten Regel (die alle Pakete, auf die keine - Regel zutraf, verwirft) abgeschlossen werden. - - Der Abschnitt für den ausgehenden Datenverkehr des - folgenden Beispiels enthät nur - allow)-Regeln, in denen der Dienst, dem - der Zugriff auf das öffentliche Internet gewährt - wird, eindeutig definiert ist. Alle Regeln verwenden die - Optionen proto, port, - in/out, via sowie - keep state kodiert. Die - Regeln mit proto tcp verwenden - zusätzlich die Option setup, damit - die initiale, eine Sitzung beginnende Anfrage identifiziert - werden kann, damit die die Zustandsttabelle gefüllt - werden kann. - - Der Abschnitt für den eingehenden Datenverkehr - beginnt mit allen Regeln, die zur Blockierung - unerwünschten Datenverkehrs benötigt werden. - Für diese Vorgehensweise gibt es zwei Gründe: - Zum einen könnten bösartige Pakete legtitimen - Datenverker so sehr ähneln, dass sie die - Bedingungen von allow-Regeln erfüllen - und daher die Firewall passieren dürfen. Daher sollten - derartige Pakete direkt verworden werden. Zum anderen - sollten unerwünschte Pakete mit bekannten (und somit - uninteressanten Mustern) sofort ohne Rückmeldung blockiert - werden, anstatt erst von der letzten, generischen Regel - blockiert (und, was noch wichtiger ist, auch noch - protokolliert). Die letzte Regel jedes Abschnittes blockiert - und protokolliert; sie kann daher dazu verwendet werden, - vor Gericht haltbare Beweise zu erhalten, damit sie gegen - Personen vorgehen können, die versuchen, Ihre Systeme - anzugreifen. - - Achten Sie darauf, dass Sie keine Netwerkantworten für - geblockte Pakete senden. Diese müssen ohne - Rückmeldung verworfen werden, damit ein Angreifer keine - Informationen darüber erhält, ob seine Datenpakete - Ihr System erreicht hat. Je weniger Information ein Angreifer - über Ihr System erhält, desto sicherer ist Ihr - System. Datenpakete an Ports, die nicht bekannten Diensten - zugeordnet werden können, können über die Datei - /etc/services identifiziert werden. - Alternativ kann eine Anfrage an http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers - Klarheit über die Aufgabe/Funktion einer bestimmten Portnummer - bringen. Auf der Seite http://www.sans.org/security-resources/idfaq/oddports.php - kann man Information über bekannte Trojaner und von - diesen verwendete Portnummern erhalten. - - - - Ein Beispiel für einschließende - Regeln - - Das folgende Regelwerk (ohne - NAT-Funktionalität) beschreibt ein - vollständiges, einschließendes Regelwerk. Dieses - Regelwerk kann direkt auf Ihren eigenen Systemen eingesetzt - werden, wenn alle pass-Regeln - für von Ihnen nicht benötigten Dienste - auskommentiert werden. Falls Sie keine Protokollierung - benötigen, können Sie diese im Abschnitt für - den eingehenden Datenverkehr durch eine - deny deaktivieren. Die im Beispiel - verwendete Netzwerkschnittstelle dc0 - müssen Sie durch die auf Ihrem System für - ausgehenden Datenverkehr vorgesehenen Netzwerkschnittstelle - ersetzen. Im Falle von benutzergesteuertem - PPPs wäre dies - beispielsweise tun0. - - Alle Regeln folgen einem bestimmten Muster. - - - - Alle Ausdrücke, die eine Anfrage zum Beginn - einer zustandsgesteuerten darstellen, beinhalten den - Ausdruck keep-state. - - - - Alle Dienste aus dem öffentlichen Internet - beinhalten die Option limit, um - gegebenenfalls - flooding zu - unterbinden. - - - - Alle Regeln bezeichnen die Richtung durch der - Ausdrücke in oder - out. - - - - Alle Regeln legen die verwendete - Netzwerkschnittstelle die Ausdrücke - via und - interface-name fest. - - - - Die folgenden Regeln werden in der Datei - /etc/ipfw.rules definiert. - - ################ Start of IPFW rules file ############################### -# Flush out the list before we begin. + #!/bin/sh ipfw -q -f flush - -# Set rules command prefix cmd="ipfw -q add" -pif="dc0" # public interface name of NIC - # facing the public Internet +skip="skipto 500" +pif=dc0 +ks="keep-state" +good_tcpo="22,25,37,53,80,443,110" -################################################################# -# No restrictions on Inside LAN Interface for private network -# Not needed unless you have LAN. -# Change xl0 to your LAN NIC interface name -################################################################# -#$cmd 00005 allow all from any to any via xl0 + Die NAT-Regel für eingehende Pakete + wird nach den beiden Regeln, die das + interne Netzwerk und die Loopback-Schnittstelle erlauben und + vor der + check-state-Regel eingefügt. Es ist + wichtig, dass die Nummer der NAT-Regel + (in diesem Beispiel 100) höher ist, als + die beiden vorherigen Regeln und niedriger, als die + check-state-Regel: -################################################################# -# No restrictions on Loopback Interface -################################################################# -$cmd 00010 allow all from any to any via lo0 + $cmd 005 allow all from any to any via xl0 # exclude LAN traffic +$cmd 010 allow all from any to any via lo0 # exclude loopback traffic +$cmd 100 divert natd ip from any to any in via $pif # NAT any inbound packets +# Allow the packet through if it has an existing entry in the dynamic rules table +$cmd 101 check-state -################################################################# -# Allow the packet through if it has previous been added to the -# the "dynamic" rules table by a allow keep-state statement. -################################################################# -$cmd 00015 check-state + Die Regeln für den ausgehenden Verkehr werden ebenfalls + modifiziert, um Aktionen mit der + $skipto-Variable zu erlauben und + anzuzeigen, dass die Prüfung mit der Regel + 500 fortgesetzt wird. Die sieben Regeln + für TCP wurden durch die Regel + 125 ersetzt, da die sieben erlaubten + ausgehenden Ports in der Variable + $good_tcp0 enthalten sind. -################################################################# -# 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. -################################################################# + # Authorized outbound packets +$cmd 120 $skip udp from any to x.x.x.x 53 out via $pif $ks +$cmd 121 $skip udp from any to x.x.x.x 67 out via $pif $ks +$cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks +$cmd 130 $skip icmp from any to any out via $pif $ks -# Allow out access to my ISP's Domain name server. -# x.x.x.x must be the IP address of your ISP.s DNS -# Dup these lines if your ISP has more than one DNS server -# Get the IP addresses from /etc/resolv.conf file -$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state -$cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state + Die eingehenden Regeln bleiben unverändert, mit Ausnahme + der letzten Regel, in der das + via $pif entfert wird, um ein- und + ausgehende Pakete prüfen zu können. Nach der letzten Regel + für ausgehende Pakete muss die NAT-Regel + folgen. Die Regel muss eine höhere Nummer als die letzte + Regel haben und die Nummer muss über die + skipto-Aktion referenziert werden. In + diesem Regelsatz leitet die Regel mit der Nummer + 500 alle ausgehenden Pakete zur + Weiterverarbeitung an &man.natd.8; weiter. Die darauf + folgende Regel lässt alle von NAT + verarbeiteten Pakete passieren. -# 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 -$cmd 00120 allow log udp from any to any 67 out via $pif keep-state -#$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state + $cmd 499 deny log all from any to any +$cmd 500 divert natd ip from any to any out via $pif # skipto location for outbound stateful rules +$cmd 510 allow ip from any to any -# Allow out non-secure standard www function -$cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state + In diesem Beispiel steuern die Regeln + 100, 101, + 125, 500 und + 510 die Adressübersetzung der ein- und + ausgehende Pakete, so dass immer die private + LAN IP-Adresse in der + dynamische Zustandstabelle registriert werden. -# Allow out secure www function https over TLS SSL -$cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state + Nehmen wir beispielsweise einen Web-Browser, der neue + HTTP-Sitzungen über Port 80 aufbaut. Wenn + nun das erste ausgehende Paket von der Firewall geprüft wird, + trifft es nicht auf Regel 100 zu, da das + Paket nach außen geleitet wird und nicht nach innen. Das + Paket trifft auch nicht auf Regel 101 zu, + da es das erste ist und somit noch nicht in der dynamischen + Zustandstabelle enthalten ist. Das Paket entspricht + schließlich Regel 125, da es ausgehend auf + einem erlaubten Port gesendet wird und von einer + IP-Adresse aus dem internen + LAN stammt. Für Pakete, die auf diese + Regel zutreffen, werden zwei Aktionen ausgeführt. Zuerst + wird durch die Aktion keep-state ein + dynamischer Eintrag in der Statustabelle erstellt und die + angegebene Aktion skipto 500 ausgeführt. + Als nächstes durchläuft das Paket NAT und + wird dann an das Internet gesendet. Nachdem dieses Paket am + Webserver angekommen ist, wird dort eine Antwort erzeugt und + zurückgeschickt. Dieses Paket wird wieder von oben nach unten + durch das Regelwerk geprüft. Dieses Mal trifft Regel + 100 auf das Paket zu und die Zieladresse + wird auf die zugehörige (lokale) + LAN-Adresse abgebildet. Danach wird das + Paket von der Regel check-state + verarbeitet. Die Zustandstabelle erkennt, dass eine + zugehörige aktive Sitzung vorliegt und das Paket wird + freigegeben und in das LAN geleitet. -# Allow out send & get email function -$cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state -$cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state + Für den eingehenden Datenverkehr muss der Regelsatz + unerwünschte Pakete blockieren und Pakete für autorisierte + Dienste durchlassen. Ein Paket, das mit einer Regel für den + eingehenden Datenverkehr übereinstimmt, wird in der + dynamischen Zustandstabelle eingetragen und dann an das + LAN freigegeben. Das Antwortpaket wird + von der Regel check-state als Paket einer + aktiven Sitzung erkannt. Das Paket wird dann von Regel + 500 per NAT + verarbeitet, bevor es über die externe Schnittstelle versendet + wird. -# Allow out FBSD (make install & CVSUP) functions -# Basically give user root "GOD" privileges. -$cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root + + Weiterleitung von Ports -# Allow out ping -$cmd 00250 allow icmp from any to any out via $pif keep-state + Der Nachteil von &man.natd.8; ist, dass die Rechner im + LAN nicht aus dem Internet zugänglich + sind. Diese Rechner können zwar ausgehende Verbindungen + zur Außenwelt aufbauen, jedoch keine eingehenden + Verbindungen empfangen. Dies stellt ein Problem dar, wenn + Sie auf einem Rechner im LAN Dienste + anbieten möchten, die aus dem Internet erreichbar sein + sollen. In diesem Fall können Sie die Ports, welche über + das Internet erreichbar sein sollen, über die + &man.natd.8;-Maschine an den Rechner im + LAN weiterleiten. -# Allow out Time -$cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state + Angenommen es gibt einen IRC-Server + auf Rechner A und einen Webserver + auf Rechner B. Damit dies + funktioniert, müssen die Verbindungen auf den Ports 6667 + (IRC) und 80 (HTTP) + an die jeweiligen Rechner weitergeleitet werden. -# Allow out nntp news (i.e. news groups) -$cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state + Die Syntax für + lautet: -# Allow out secure FTP, Telnet, and SCP -# This function is using SSH (secure shell) -$cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state + -redirect_port proto targetIP:targetPORT[-targetPORT] + [aliasIP:]aliasPORT[-aliasPORT] + [remoteIP[:remotePORT[-remotePORT]]] -# Allow out whois -$cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state + Für das obige Beispiel sollten die Argumente wie folgt + aussehen: -# deny and log everything else that.s trying to get out. -# This rule enforces the block all by default logic. -$cmd 00299 deny log all from any to any out via $pif + -redirect_port tcp 192.168.0.2:6667 6667 + -redirect_port tcp 192.168.0.3:80 80 -################################################################# -# Interface facing Public Internet (Inbound Section) -# Check packets originating from the public Internet -# destined for this gateway server or the private network. -################################################################# + Damit werden die entsprechenden + TCP-Ports an die Rechner im + LAN weitergeleitet. -# Deny all inbound traffic from non-routable reserved address spaces -$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP -$cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP -$cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP -$cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #loopback -$cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback -$cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config -$cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs -$cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect -$cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast + Portbereiche können über + festgelegt werden. Zum Beispiel würde + tcp 192.168.0.2:2000-3000 + 2000-3000 alle Verbindungen auf die Ports + 2000 bis 3000 an die Ports 2000 bis 3000 an + Rechner A weiterleiten. -# Deny public pings -$cmd 00310 deny icmp from any to any in via $pif + Diese Optionen können über + natd_flags="" in + /etc/rc.conf direkt beim Start an + &man.natd.8; übergeben werden. Alternativ können die + Optionen in eine Konfigurationsdatei eingetragen + werden. -# Deny ident -$cmd 00315 deny tcp from any to any 113 in via $pif - -# Deny all Netbios service. 137=name, 138=datagram, 139=session -# Netbios is MS/Windows sharing services. -# Block MS/Windows hosts2 name server requests 81 -$cmd 00320 deny tcp from any to any 137 in via $pif -$cmd 00321 deny tcp from any to any 138 in via $pif -$cmd 00322 deny tcp from any to any 139 in via $pif -$cmd 00323 deny tcp from any to any 81 in via $pif - -# Deny any late arriving packets -$cmd 00330 deny all from any to any frag in via $pif - -# Deny ACK packets that did not match the dynamic rule table -$cmd 00332 deny tcp from any to any established in via $pif - -# Allow traffic in from ISP's DHCP server. This rule must contain -# the IP address of your ISP.s DHCP server as it.s the only -# authorized source to send this packet type. -# Only necessary for cable or DSL configurations. -# This rule is not needed for .user ppp. type connection to -# the public Internet. This is the same IP address you captured -# and used in the outbound section. -#$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state - -# Allow in standard www function because I have apache server -$cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 - -# Allow in secure FTP, Telnet, and SCP from public Internet -$cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 - -# Allow in non-secure Telnet session from public Internet -# labeled non-secure because ID & PW are passed over public -# Internet as clear text. -# Delete this sample group if you do not have telnet server enabled. -$cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 - -# Reject & Log all incoming connections from the outside -$cmd 00499 deny log all from any to any in via $pif - -# Everything else is denied by default -# deny and log all packets that fell through to see what they are -$cmd 00999 deny log all from any to any -################ End of IPFW rules file ############################### + Weitere Konfigurationsmöglichkeiten sind in + &man.natd.8; beschrieben. - Ein Beispiel für zustandshafte - <acronym>NAT</acronym>-Regeln + Weiterleiten von Adressen - - NAT - und IPFW - + Das Weiterleiten von Adressen ist nützlich, wenn + mehr als eine IP-Adresse zur Verfügung + steht. Jeder Rechner im LAN kann über + &man.natd.8; seine eigene externe + IP-Adresse zugewiesen bekommen. + &man.natd.8; wird dann den ausgehenden Datenverkehr der + Rechner aus dem LAN mit der + entsprechenden externen IP-Adresse + umschreiben. Auch der eingehenden Datenverkehr über die + externe IP-Adresse wird an die + entsprechenden Rechner im LAN + weitergeleitet. Diese Methode ist auch als + statisches NAT bekannt. Wenn Ihnen + beispielsweise die IP-Adressen + 128.1.1.1, + 128.1.1.2 und + 128.1.1.3 zur + Verfügung stehen, kann 128.1.1.1 als externe + Adresse der &man.natd.8;-Maschine verwendet werden, während + 128.1.1.2 und + 128.1.1.3 an + Rechner A und + Rechner B im LAN + weitergeleitet werden. - Es müssen einige zusätzliche - Konfigurationseinstellungen vorgenommen werden, um die - die NAT-Funktion von IPFW zu nutzen. Die - Kernelquellen müssen mit der Option - IPDIVERT (im IPFIREWALL-Abschnitt der - Kernelkonfigurationsdatei) neu gebaut werden, um den - benötigten angepassten Kernel zu erzeugen. + Die Syntax für + lautet: - Zusätzlich werden folgende Optionen in der - /etc/rc.conf benötigt: + -redirect_address localIP publicIP - natd_enable="YES" # Enable NATD function -natd_interface="rl0" # interface name of public Internet NIC -natd_flags="-dynamic -m" # -m = preserve port numbers if possible + + + + + localIP + Die interne IP-Adresse des + Rechners im LAN. + - Zustandshafte Regeln bei aktiviertem - divert natd (Network - Address Translation) verkomplizieren die - Formulierung des Regelwerkes beträchtlich. Damit Ihre - Firewall funktioniert, kommt es insbesondere auf die Position - der Ausdrücke check-state sowie - divert natd an. Sie können nicht - länger einen einfachen, kaskadierenden Ablauf verwenden - (also einen Regelsatz, bei dem einfach auf eine Regel nach der - anderen geprüft wird. Vielmehr wird der neue - Aktionstyp skipto benötigt. Dies - erfordert, dass jede Regel über eine eindeutige Nummer - verfügt, um so eindeutige Sprungziele zu erhalten. + + publicIP + Die externe IP-Adresse für + den entsprechenden Rechner im + LAN. + + + + - Im Folgenden wird anhand eines umkommentierten Beispiels - der Paketfluss durch das Regelwerk verdeutlicht. + Für das obige Beispiel sollten die Argumente wie + folgt aussehen: - Die Verarbeitung beginnt mit der ersten Regel (also am - Anfang der Regeldatei. Sie setzt sich Regel für Regel - weiter fort, bis das Ende der Datei erreicht ist oder eine - Regel für das Paket einen Treffer erzielt und das Paket - so die Firewall verlassen kann. Achten Sie besonders auf die - Position der Regeln mit den Nummern - 100, 101, 450, 500 sowie - 510. Diese Regeln steuern die - Adressumsetzung ausgehender und eingehender Pakete, so dass - deren entsprechende Einträge in der Zustandstabelle immer - die private LAN-Adressen abbilden. Zusätzlich werden in - allen Regeln die Richtung des Pakets (eingehend oder - ausgehend) so die vom Paket zu verwendende Netzwerkschnittstelle - definiert. Ausgehende Anfragen, die eine Sitzung starten, rufen - immer skipto rule 500, damit - NAT verwendet werden kann. + -redirect_address 192.168.0.2 128.1.1.2 +-redirect_address 192.168.0.3 128.1.1.3 - Nehmen wir nun an, dass ein Nutzer einen Webbrowser - verwendet, um eine Internetseite aufzurufen. Derartige - Anfragen werden in der Regel über Port 80 geleitet. Die - zugehörigen Pakete werden durch die Firewall verarbeitet. - Regel 100 trifft nicht zu, denn das Paket geht nach außen, - nicht nach innen. Regel 101 trifft ebenfalls nicht zu, denn es - handelt sich um das erste Paket. Folglich wird die Sitzung - erst initiiert und kann somit noch nicht in der - Zustandstabelle enthalten sein kann. Die erste Regel, die - zutrifft, ist Regel 125. Das Paket will das lokale Netzwerk - über die Schnittstelle zum öffentlichen Internet (das - heißt nach außen) verlassen, es hat aber noch die - Quelladresse des privaten lokalen Netzwerks. Da Regel 125 - zutrifft, werden zwei Aktionen ausgeführt: Die Option - keep-state bewirkt, dass das Paket in der - internen Tabelle für zustandshafte, dynamische Regeln - registriert wird. Danach wird der Aktionsteil der Regel - ausgeführt. Dieser ist Bestandteil der Informationen, die - in die in der Tabelle für dynamische Regeln aufgenommen - wird und lautet skipto rule 500. Die - Regel 500 führt NATs auf die - IP-Adresse des Paketes durch. Danach verlässt das Paket - das LAN nach außen in Richtung des öffentlichen - Internets. Dieser letzte Teil ist für funktionierendes - NAT von entscheidender Bedeutung. Nachdem dieses Paket - am Bestimmungsort angekommen ist, wird dort eine Antwort - generiert und zurückgeschickt. Dieses Paket wird auf die - gleiche Art und Weise durch das gegebene Regelwerk - verarbeitet. Dieses Mal trifft Regel 100 auf das Paket zu, - damit wird die Bestimmungsadresse auf die zugehörige - (lokale) LAN-Adresse (rück-)abgebildet. Danach wird es - von der check-state-Regel verarbeitet, - die Zustandstabelle erkennt, dass eine zugehörige - aktive Sitzung vorliegt und das Paket wird freigegeben - und in das LAN geleitet. Es wird innerhalb des LANs von dem PC, - der die zugehörige Sitzung hält, empfangen, der - ein neues Paket absendet und ein weiteres Datensegment vom - entfernten Server anfordert. Dieses Mal wird bei der - Prüfung der check-state-Regel ein - nach außen gehender zugehöriger Eintrag in der - Zustandstabelle gefunden und die entsprechende Aktion (also - skipto 500) wird ausgeführt. Das - Paket springt zu Regel 500 und wird durch diese Regel für - das öffentliche Internet freigegeben. - - Innerhalb des durch die Firewall geschützten - Netzwerks werden alle eingehenden Pakete, die zu einer - existierenden Sitzung gehören, durch die Regel - check-state sowie entsprechend platzierte - divert natd-Regeln verarbeitet. Die - notwendige Arbeit beschränkt sich darauf, alle - schlechten Pakete zu blockieren und nur - authorisierten Diensten zugehörige Pakete - durchzulassen. In Umkehrung des bisherigen Beispiels nehmen - wir nun, dass auf dem Rechner, auf dem die Firewall läuft, - auch ein Apache Webserver läuft, auf den von außen, - also aus dem öffentlichen Internet, zugegriffen werden - kann. Das erste von außen eintreffende Paket (das auch - eine neue Sitzung startet) erfüllt Regel 100. Die - Zieladresse des Paketes wird daher auf die LAN-Adresse des - Firewallrechners abgebildet. Das Paket wird dann weiter auf - alle in der Firewall definierten Regeln geprüft und trifft - schließlich auf Regel 425. Durch diese Regel werden - zwei Aktionen ausgelösst: Erstens wird aus dem Paket - eine dynamische Regel generiert und in die Zustandstabelle - geschrieben. Zusätzlich wird jedoch die Anzahl neuer - Sitzungsanfragen (von der gleichen Quell-IP-Adresse) auf - 2 begrenzt, um so DoS-Angriffe auf Dienste, - die auf diesem Port laufen, zu verhindern. Die Aktion dieser - Regel ist allow, daher wird das Paket - freigegeben und in das LAN weitergeleitet. Das als Antwort - generierte Paket wird durch die - check-state-Regel als zu einer Sitzung - gehörend erkannt. Damit wird es der Regel 500 - zugeführt, NAT wird durchgeführt - und über die Schnittstelle zum öffentlichen Internet - nach außen geroutet. + Genau wie bei , werden + diese Argumente innerhalb der + /etc/rc.conf-Option + natd_flags="" angegeben, oder alternativ + über eine Konfigurationsdatei. Allerdings müssen beim + Weiterleiten von Adressen keine Ports umgeleitet werden, da + der gesamte eingehende Datenverkehr einer bestimmte + IP-Adresse weitergeleitet wird. - Beispiel 1 für einen Regelsatz: + Die externe IP-Adresse der + &man.natd.8;-Maschine muss auf der externen Schnittstelle + aktiv und mit einem Alias versehen sein. Weitere + Einzelheiten sind in &man.natd.8; beschrieben. + + - #!/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" + + Das <application>IPFW</application> Kommando -ipfw -q -f flush + + ipfw + -$cmd 002 allow all from any to any via xl0 # exclude LAN traffic -$cmd 003 allow all from any to any via lo0 # exclude loopback traffic + ipfw kann benutzt werden, um einzelne + Regeln im laufenden Betrieb hinzuzufügen oder zu entfernen. + Problematisch ist jedoch, dass diese Änderungen bei einem + Neustart des Systems verloren gehen. Daher ist es + empfehlenswert, eigene Regeln in einer Datei zu definieren + und diese zu laden, um die Regeln der Firewall im laufenden + Betrieb anzupassen. -$cmd 100 divert natd ip from any to any in via $pif -$cmd 101 check-state + ipfw ist auch hilfreich, um die + geladenen Regeln der auf der Konsole auszugeben. + IPFW erzeugt dynamisch einen + Zähler, der jedes Paket, auf das eine Regel zutrifft, zählt. + Dadurch ist es möglich, die Funktion einer Regel zu + überprüfen. -# Authorized outbound packets -$cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks -$cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks -$cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks -$cmd 130 $skip icmp from any to any out via $pif $ks -$cmd 135 $skip udp from any to any 123 out via $pif $ks + Eine Auflistung aller geladenen Regeln erhalten Sie + mit: + &prompt.root; ipfw list -# Deny all inbound traffic from non-routable reserved address spaces -$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP -$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP -$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP -$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback -$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback -$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config -$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs -$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster -$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast + Eine Auflistung aller Regeln inklusive des letzten + Treffers erhalten Sie mit: -# Authorized inbound packets -$cmd 400 allow udp from xx.70.207.54 to any 68 in $ks -$cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 + &prompt.root; ipfw -t list + 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: -$cmd 450 deny log ip from any to any + &prompt.root; ipfw -a list -# This is skipto location for outbound stateful rules -$cmd 500 divert natd ip from any to any out via $pif -$cmd 510 allow ip from any to any + Das folgende Kommando zeigt zusätzlich alle dynamischen + Regeln an: -######################## end of rules ################## + &prompt.root; ipfw -d list - 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. + Um diese Auflistung um die abgelaufenen + Regeln zu erweitern, geben Sie folgendes Kommando ein: - Beispiel 2 für einen Regelsatz: + &prompt.root; ipfw -d -e list - #!/bin/sh -################ Start of IPFW rules file ############################### -# Flush out the list before we begin. -ipfw -q -f flush + Hiermit werden alle Zähler auf Null zurückgesetzt: -# Set rules command prefix -cmd="ipfw -q add" -skip="skipto 800" -pif="rl0" # public interface name of NIC - # facing the public Internet + &prompt.root; ipfw zero -################################################################# -# No restrictions on Inside LAN Interface for private network -# Change xl0 to your LAN NIC interface name -################################################################# -$cmd 005 allow all from any to any via xl0 + Es ist auch möglich, einen spezifischen Zähler + zurückzusetzen: -################################################################# -# No restrictions on Loopback Interface -################################################################# -$cmd 010 allow all from any to any via lo0 + &prompt.root; ipfw zero NUM -################################################################# -# check if packet is inbound and nat address if it is -################################################################# -$cmd 014 divert natd ip from any to any in via $pif + + Protokollierung von Firewall-Nachrichten -################################################################# -# Allow the packet through if it has previous been added to the -# the "dynamic" rules table by a allow keep-state statement. -################################################################# -$cmd 015 check-state + Auch bei aktivierter Protokollierung wird + IPFW von selbst keine Regeln + protokollieren. Der Administrator muss entscheiden, welche + Regeln aus dem Regelwerk protokolliert werden sollen. In + diesen Regeln muss dann das Schlüsselwort + log hinzugefügt werden. Normalerweise + werden nur geblockte Pakete protokolliert. Es ist üblich, + die ipfw default deny everything-Regel am + Ende des Regelwerks mit dem Schlüsselwort + log zu duplizieren. Dadurch ist es + möglich, alle Pakete zu sehen, auf die keine Regel + zutraf. -################################################################# -# 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. -################################################################# + 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. -# Allow out access to my ISP's Domain name server. -# x.x.x.x must be the IP address of your ISP's DNS -# Dup these lines if your ISP has more than one DNS server -# Get the IP addresses from /etc/resolv.conf file -$cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state + Die Kerneloption + IPFIREWALL_VERBOSE_LIMIT=5 begrenzt die + Anzahl identischer Nachrichten an &man.syslogd.8; für eine + gegebene Regel auf fünf Nachrichten. Ist diese Option im + Kernel aktiviert, wird nach Erreichen den festgelegten + Anzahl die Protokollierung von aufeinanderfolgenden + Nachrichten auf den festgelegten Wert begrenzt, da + beispielsweise die Speicherung von 200 gleichen + Protokoll-Nachrichten sinnlos ist. Daher werden durch + diese Option nur fünf gleichartige Nachrichten + protokolliert. Alle weiteren Nachrichten werden nur gezählt + und deren Gesamtzahl wird schließlich von &man.syslogd.8; + wie folgt ausgegeben: + Last message repeated 45 times -# Allow out access to my ISP's DHCP server for cable/DSL configurations. -$cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state + Alle protokollierten Pakete werden in der Voreinstellung + in /var/log/security gespeichert. Dies + wird in /etc/syslog.conf + definiert. + -# Allow out non-secure standard www function -$cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state + + Ein Firewall-Regelwerk erstellen -# Allow out secure www function https over TLS SSL -$cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state + Die meisten fortgeschrittenen + IPFW-Benutzer erzeugen eine + Datei, welche die Regeln für die Firewall enthält, um diese + als Skript ausführen zu können. Der Vorteil einer + derartigen Konfiguration besteht darin, dass dadurch mehrere + Regeln gleichzeitig geändert und aktiviert werden können, + ohne dass dazu das System neu gestartet werden muss. Dies + ist zudem beim Testen von Regeländerungen sehr hilfreich. + Weil es sich bei der Datei um ein Skript handelt, ist es + auch möglich, häufig verwendete Befehle durch Aliase zu + ersetzen und diese dann in mehreren Regeln zu nutzen. -# Allow out send & get email function -$cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state -$cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state + Die Syntax des folgenden Skripts entspricht der Syntax + von &man.sh.1;, &man.csh.1; sowie &man.tcsh.1;. Felder, die + symbolisch substituiert werden, haben das Präfix $ + (Dollarzeichen). Symbolische Felder haben das + $-Präfix nicht. Der Wert, mit dem das symbolische + Feld belegt wird, muss in doppelten Anführungszeichen + ("") stehen. -# Allow out FreeBSD (make install & CVSUP) functions -# Basically give user root "GOD" privileges. -$cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root + Die Datei mit den Regeln könnte wie folgt aufgebaut + sein: -# Allow out ping -$cmd 080 $skip icmp from any to any out via $pif keep-state + ############### start of example ipfw rules script ############# +# +ipfw -q -f flush # Delete all rules +# Set defaults +oif="tun0" # out interface +odns="192.0.2.11" # ISP's DNS server IP address +cmd="ipfw -q add " # build rule prefix +ks="keep-state" # just too lazy to key this each time +$cmd 00500 check-state +$cmd 00502 deny all from any to any frag +$cmd 00501 deny tcp from any to any established +$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks +$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks +$cmd 00611 allow udp from any to $odns 53 out via $oif $ks +################### End of example ipfw rules script ############ -# Allow out Time -$cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state + Die Regeln in diesem Beispiel sind nicht wichtig. + Wichtig ist es, zu zeigen, wie die symbolische Substitution + innerhalb der Regeln verwendet wird. -# Allow out nntp news (i.e. news groups) -$cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state + Wenn dieses Beispiel in + etc/ipfw.rules gespeichert wurde, so + könnten alle Regeln durch die Ausführung des folgenden + Kommandos neu geladen werden: -# Allow out secure FTP, Telnet, and SCP -# This function is using SSH (secure shell) -$cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state + &prompt.root; sh /etc/ipfw.rules -# Allow out whois -$cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state + Anstelle von /etc/ipfw.rules kann + ein beliebig anderer Name oder Speicherort verwendet + werden. -# Allow ntp time server -$cmd 130 $skip udp from any to any 123 out via $pif keep-state + Alternativ können die einzelnen Befehle dieses Skripts + auch von Hand eingegeben werden: -################################################################# -# Interface facing Public Internet (Inbound Section) -# Check packets originating from the public Internet -# destined for this gateway server or the private network. -################################################################# - -# Deny all inbound traffic from non-routable reserved address spaces -$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP -$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP -$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP -$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback -$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback -$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config -$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs -$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster -$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast - -# Deny ident -$cmd 315 deny tcp from any to any 113 in via $pif - -# Deny all Netbios service. 137=name, 138=datagram, 139=session -# Netbios is MS/Windows sharing services. -# Block MS/Windows hosts2 name server requests 81 -$cmd 320 deny tcp from any to any 137 in via $pif -$cmd 321 deny tcp from any to any 138 in via $pif -$cmd 322 deny tcp from any to any 139 in via $pif -$cmd 323 deny tcp from any to any 81 in via $pif - -# Deny any late arriving packets -$cmd 330 deny all from any to any frag in via $pif - -# Deny ACK packets that did not match the dynamic rule table -$cmd 332 deny tcp from any to any established in via $pif - -# Allow traffic in from ISP's DHCP server. This rule must contain -# the IP address of your ISP's DHCP server as it's the only -# authorized source to send this packet type. -# Only necessary for cable or DSL configurations. -# This rule is not needed for 'user ppp' type connection to -# the public Internet. This is the same IP address you captured -# and used in the outbound section. -$cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state - -# Allow in standard www function because I have Apache server -$cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 - -# Allow in secure FTP, Telnet, and SCP from public Internet -$cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 - -# Allow in non-secure Telnet session from public Internet -# labeled non-secure because ID & PW are passed over public -# Internet as clear text. -# Delete this sample group if you do not have telnet server enabled. -$cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 - -# Reject & Log all unauthorized incoming connections from the public Internet -$cmd 400 deny log all from any to any in via $pif - -# Reject & Log all unauthorized out going connections to the public Internet -$cmd 450 deny log all from any to any out via $pif - -# This is skipto location for outbound stateful rules -$cmd 800 divert natd ip from any to any out via $pif -$cmd 801 allow ip from any to any - -# Everything else is denied by default -# deny and log all packets that fell through to see what they are -$cmd 999 deny log all from any to any -################ End of IPFW rules file ############################### + &prompt.root; ipfw -q -f flush +&prompt.root; ipfw -q add check-state +&prompt.root; ipfw -q add deny all from any to any frag +&prompt.root; ipfw -q add deny tcp from any to any established +&prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state +&prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state +&prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state -