Index: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml (revision 48899) +++ head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml (revision 48900) @@ -1,3693 +1,4771 @@ 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. - Paket Filter (PF) von OpenBSD und - <acronym>ALTQ</acronym> + + PF + - JohnFerrellRevised and updated by + + + John + Ferrell + + Überarbeitet und aktualisiert von + - - firewall PF - Im Juli 2003 wurde PF, die - Standard-Firewall von OpenBSD, nach &os; portiert und in die - &os;-Ports-Sammlung aufgenommen. 2004 war PF in - &os; 5.3 Teil des Basissystems. Bei PF - handelt es sich um eine komplette, vollausgestattete Firewall, - die optional auch ALTQ (Alternatives - Queuing) unterstützt. ALTQ bietet Ihnen + In &os; 5.3 wurde PF von + OpenBSD in das Basissystem integriert. Bei + PF handelt es sich um eine komplette, + voll ausgestattete Firewall, die optional auch + ALTQ (Alternatives Queuing) + unterstützt. ALTQ stellt Quality of Service - (QoS)-Bandbreitenformung. + (QoS) zur Verfügung. - Das OpenBSD-Projekt leistet bereits hervorragende - Dokumentationsarbeit mit der PF FAQ. Aus diesem Grund - konzentriert sich dieser Handbuchabschnitt nur auf diejenigen - Besonderheiten von PF, die &os; betreffen, sowie ein - paar allgemeine Informationen hinsichtlich der Verwendung. Genauere - Informationen zum Einsatz erhalten Sie in der PF FAQ. + 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/. - Weitere Informationen zu PF für &os; finden - Sie unter http://pf4freebsd.love2party.net/. + + Bedenken Sie beim Studium der PF FAQ, + dass &os; die PF-Version aus + OpenBSD 4.5 enthält. + - - Verwendung der PF-Kernelmodule + 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. - Um die PF Kernel Module zu laden, fügen Sie folgende - Zeile in ihre /etc/rc.conf ein: + Weitere Informationen über die Portierung von + PF nach &os; finden Sie unter + http://pf4freebsd.love2party.net/. - pf_enable="YES" + 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. - Danach starten Sie das Startup Script um die Module - zu laden: + + <application>PF</application> aktivieren - &prompt.root; /etc/rc.d/pf start + 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. - Das PF Modul wird nicht geladen, falls es die Ruleset - Konfigurationsdatei nicht findet. Standardmässig befindet - sich diese Datei in /etc/pf.conf. Falls das - PF Ruleset sich an einem anderen Platz befindet, können Sie das - durch Hinzufügen einer Zeile ähnlich der folgenden, in - ihrer /etc/rc.conf ändern: + Beginnen Sie mit folgender Zeile in + /etc/rc.conf: - pf_rules="/path/to/pf.conf" + pf_enable="YES" - - Ein Beispiel für die Datei pf.conf - finden Sie im Verzeichnis /usr/share/examples/pf/. - + &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: - Das PF-Modul kann auch manuell über die - Kommandozeile geladen werden: + pf_flags="" # additional flags for pfctl startup - &prompt.root; kldload pf.ko + 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: - Protokollierungsfunktionen für PF werden durch das Modul - pflog.ko zur Verfügung gestellt und - können durch folgenden Eintrag in der - /etc/rc.conf aktiviert werden: + 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" - Danach starten Sie das Startup Script, um das Modul - zu laden: + 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: - &prompt.root; /etc/rc.d/pflog start + pflog_logfile="/var/log/pflog" # where pflogd should store the logfile +pflog_flags="" # additional flags for pflogd startup - Falls Sie noch weitere Features für - PF benötigen, müssen Sie diese in den - Kernel einbauen. - + 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: - - PF Kernel-Optionen + gateway_enable="YES" # Enable as LAN gateway - - Kerneloptionen + Nachdem die Änderungen gespeichert wurden, kann + PF mit Unterstützung für + Protokollierung gestartet werden: - device pf + &prompt.root; service pf start +&prompt.root; service pflog start + + - Die folgenden &man.rc.conf.5;-Einträge konfigurieren - PF und &man.pflog.4; beim Systemstart: + 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. - pf_enable="YES" # PF aktivieren (Modul, wenn nötig, aktivieren) -pf_rules="/etc/pf.conf" # Datei mit Regeldefinitionen für pf -pf_flags="" # zusätzliche Parameter für den Start von pfctl -pflog_enable="YES" # starte pflogd(8) -pflog_logfile="/var/log/pflog" # wo soll pflogd die Protokolldatei speichern -pflog_flags="" # zusätzliche Parameter für den Start von pflogd + 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;. - Wenn Sie ein lokales Netzwerk hinter dieser Firewall betreiben - und Pakete für dessen Rechner weiterleiten oder NAT verwenden - wollen, benötigen Sie zusätzlich die folgende Option: + + Nützliche <command>pfctl</command> Optionen - gateway_enable="YES" # LAN Gateway aktivieren - + + + + Kommando + Aufgabe + + - - Filterregeln erstellen + + + pfctl -e + PF aktivieren + - PF liest seine konfigurierten Regeln aus - &man.pf.conf.5; (standardmässig /etc/pf.conf) - und modifiziert, verwirft oder lässt Pakete passieren anhand der - Regeln oder Definitionen, die in dieser Datei gespeichert sind. &os; - enthält dazu nach der Installation mehrere Beispieldateien, die - in /usr/share/examples/pf/ abgelegt sind. - Für eine ausführliche Behandlung des - PF-Regelwerks lesen Sie bitte die PF FAQ. + + pfctl -d + PF + deaktivieren + - - Beim Lesen der PF FAQ wollten Sie - darauf achten, dass verschiedene Versionen von &os; auch - unterschiedliche Versionen von PF enthalten. - &os; 8.X (und älter) - &os;-Versionen benutzen PF aus OpenBSD 4.1. - &os; 9.X (und neuer) benutzen - hingegen PF aus OpenBSD 4.5. - + + pfctl -F all -f + /etc/pf.conf + Alle Filterregeln zurücksetzen + (NAT, Filter, Zustandstabelle) und + /etc/pf.conf erneut + einlesen. + - Die &a.pf; ist eine erste Anlaufstelle für - Fragen zur Konfiguration und dem Einsatz der PF - Firewall. Vergessen Sie nicht, vorher die Mailinglistenarchive zu - durchsuchen, bevor Sie dort eine Frage stellen! + + 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. - Arbeiten mit PF + <application>ALTQ</application> aktivieren - Benutzen Sie &man.pfctl.8;, um PF zu steuern. - Unten finden Sie ein paar nützliche Befehle (lesen Sie auch die - Manualpage zu &man.pfctl.8;, um alle verfügbaren Optionen - nachzuschlagen): + 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. - - - - - Befehl - Zweck - - + Bevor Sie ALTQ aktivieren, + sollten Sie &man.altq.4; lesen und sicherstellen, das der + Treiber der Netzwerkkarte diese Funktion unterstützt. - - - pfctl -e - PF aktivieren - + 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: - - pfctl -d - PF deaktivieren - + 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) - - pfctl -F all -f /etc/pf.conf - Alle Filterregeln zurücksetzen (NAT, Filter, Zustand, - Tabelle, etc.) und erneut aus der Datei - /etc/pf.conf auslesen - + Die folgenden Algorithmen stehen zur Verfügung: - - pfctl -s [ rules | nat | - states ] - Bericht über die Filterregeln, NAT-Regeln, oder - Zustandstabellen - + + + 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. + + - - pfctl -vnf /etc/pf.conf - überprüft /etc/pf.conf auf - Fehler, lädt aber das Regelwerk nicht neu - - - - + + 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. - - <acronym>ALTQ</acronym> aktivieren + + + <application>PF</application> Regelsätze - ALTQ muss vor der Verwendung in den - &os;-Kernel kompiliert werden. Beachten Sie, dass - ALTQ nicht von allen verfügbaren - Netzwerkkartentreibern unterstützt wird. Sehen Sie daher - zuerst in &man.altq.4; nach, ob Ihre Netzwerkkarte diese - Funktion unter Ihrer &os;-Version unterstützt. + + + + Peter + Hansteen + N. M. + + Beigetragen von + + + - Die folgenden Kerneloptionen aktivieren ALTQ - sowie alle Zusatzfunktionen: + 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. - options ALTQ -options ALTQ_CBQ # Class Bases Queuing (CBQ) -options ALTQ_RED # Random Early Detection (RED) -options ALTQ_RIO # RED In/Out -options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) -options ALTQ_PRIQ # Priority Queuing (PRIQ) -options ALTQ_NOPCC # Wird von SMP benötigt + 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: - options ALTQ aktiviert das - ALTQ-Framework. + block in all +pass out all keep state - options ALTQ_CBQ aktiviert das - Class Based Queuing (CBQ). - CBQ erlaubt es, die Bandbreite einer Verbindung in - verschiedene Klassen oder Warteschlangen zu unterteilen, um die - Priorität von Datenpaketen basierend auf Filterregeln zu - ändern. + 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: - options ALTQ_RED aktiviert - Random Early Detection - (RED). RED wird - zur Vermeidung einer Netzwerkverstopfung verwendet. 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 verworfen. Getreu seinem Namen - verwirft RED Pakete unterschiedlicher - Verbindungen nach dem Zufallsprinzip. + &prompt.root; pfctl -e ; pfctl -f /etc/pf.conf - options ALTQ_RIO aktiviert - Random Early Detection In and Out. + 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: - options ALTQ_HFSC aktiviert den - Hierarchical Fair Service Curve-Paketplaner. - Weitere Informationen zu HFSC finden Sie - unter http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html. + tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s }" +udp_services = "{ domain }" - options ALTQ_PRIQ aktiviert - Priority Queuing (PRIQ). - PRIQ lässt Verkehr einer Warteschlange mit - höherer Priorität zuerst durch. + 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: - options ALTQ_NOPCC aktiviert die - SMP Unterstützung von - ALTQ. Diese Option ist nur auf - SMP-System erforderlich. + 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 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. 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. 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. 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 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. 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 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. options IPFIREWALL Diese Option aktiviert IPFW als Bestandteil des Kernels. 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. 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: open — gestattet jeglichen Datenverkehr client — schützt nur die jeweilige Maschine (Client/Mandant) simple — schützt das gesamte Netzwerk closed — unterbindet jeglichen IP-Datenverkehr mit Ausnahme des Verkehrs über die Loopback-Schnittstelle. 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: add deny in add deny out 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: #!/bin/sh ipfw -q flush 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: 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. 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 IPFW-Regeln 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 das betreffende Paket zutrifft, wird die obligatorische IPFW-Rückfallregel (also Regel 65535) angewendet und das Paket wird ohne Rückantwort verworfen. 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. 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 Arbeit mit Firewallregeln ist Vorsicht geboten. Es ist sehr einfach, sich selbst auszuschließen. Syntax der Firewallregeln IPFW rule syntax 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; 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. Kommentare sind mit einen führenden Doppelkreuz (#) ausgezeichnet. Sie können am Ende einer Regel oder in einzelnen, separaten Zeilen stehen. Leerzeilen werden ignoriert. CMD RULE_NUMBER ACTION LOGGING SELECTION STATEFUL CMD Jede neue Regel benötigt das Präfix add, um die Regel der internen Tabelle hinzuzfügen. RULE_NUMBER Zu jeder Regel gehört eine Regelnummer zwischen 1 und 65535. ACTION Eine Regel kann mit einer der vier folgenden Aktionen verbunden sein, die ausgeführt werden, wenn ein Paket den Selektionskriterien der Regel entspricht. allow | accept | pass | permit 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. check-state 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. deny | drop Beide Schlüsselworte bewirken dieselbe Aktion: Ein Paket, dass die Selektionskriterien der Regel erfüllt, wird verworfen und die Regelprüfung wird beendet. Protokollierung log oder logamount 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). 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. Selektion 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. udp | tcp | icmp 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. from src to dst 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. port number 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. in | out Diese Schlüsselwörter beziehen sich auf die Richtung des Datenverkehrs. Jede Regel muss eines dieser beiden Schlüsselwörter enthalten. via IF 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. setup Dieses obligatorische Schlüsselwort bezeichnet die Anforderung des Sitzungsstarts für TCP-Pakete. 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. limit {src-addr | src-port | dst-addr | dst-port} 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. Optionen für zustandsgesteuerte Regeln IPFW stateful filtering 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. 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. 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. Protokollierung von Firewall-Nachrichten IPFW logging 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. 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. 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. 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: last message repeated 45 times 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. Skripte zur Regeldefinition erstellen 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. 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. Beginnen Sie Ihre Regeldatei wie folgt: ############### 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 ############ Die Regeln in diesem Beispiel sind nicht wichtig. Wichtig ist es, zu zeigen, wie die symbolische Substitution innerhalb der Regeln verwendet wird. 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: &prompt.root; sh /etc/ipfw.rules Statt /etc/ipfw.rules können Sie auch einen beliebigen anderen Namen und/oder Speicherort verwenden. Alternativ könnten Sie die einzelnen Befehle dieses Skripts auch manuell starten: &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 Zustandsgesteuertes Regelwerk 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. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" pif="dc0" # public interface name of NIC # facing the public Internet ################################################################# # 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 ################################################################# # No restrictions on Loopback Interface ################################################################# $cmd 00010 allow all from any to any via lo0 ################################################################# # 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 ################################################################# # 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. ################################################################# # 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 # 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 # Allow out non-secure standard www function $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Allow out secure www function https over TLS SSL $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # 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 # 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 # Allow out ping $cmd 00250 allow icmp from any to any out via $pif keep-state # Allow out Time $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Allow out nntp news (i.e. news groups) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # 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 # Allow out whois $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # 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 ################################################################# # 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 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 # 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 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 ############################### Ein Beispiel für zustandshafte <acronym>NAT</acronym>-Regeln NAT und IPFW 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. Zusätzlich werden folgende Optionen in der /etc/rc.conf benötigt: 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 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. Im Folgenden wird anhand eines umkommentierten Beispiels der Paketfluss durch das Regelwerk verdeutlicht. 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. 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. Beispiel 1 für einen Regelsatz: #!/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" ipfw -q -f flush $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 $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # 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 # 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 # 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 $cmd 450 deny log ip from any to any # 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 ######################## end of rules ################## 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. Beispiel 2 für einen Regelsatz: #!/bin/sh ################ Start of IPFW rules file ############################### # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" skip="skipto 800" pif="rl0" # public interface name of NIC # facing the public Internet ################################################################# # 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 ################################################################# # No restrictions on Loopback Interface ################################################################# $cmd 010 allow all from any to any via lo0 ################################################################# # check if packet is inbound and nat address if it is ################################################################# $cmd 014 divert natd ip from any to any in via $pif ################################################################# # 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 ################################################################# # 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. ################################################################# # 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 # 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 # Allow out non-secure standard www function $cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state # Allow out secure www function https over TLS SSL $cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state # 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 # 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 # Allow out ping $cmd 080 $skip icmp from any to any out via $pif keep-state # Allow out Time $cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state # Allow out nntp news (i.e. news groups) $cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state # 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 # Allow out whois $cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state # Allow ntp time server $cmd 130 $skip udp from any to any 123 out via $pif keep-state ################################################################# # 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 ###############################