Index: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml (revision 48857) +++ head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml (revision 48858) @@ -1,3607 +1,3693 @@ 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 Ihres Systems zu filtern. Dazu verwendet eine + 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 Ihres + 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 Netzwerk auf Rechner oder Dienste des externen + internen Netzwerks auf Rechner oder Dienste des öffentlichen Internets. Den Einsatz von Network Address Translation - (NAT), die es Ihnen durch die Verwendung + (NAT), welches es durch die Verwendung von privaten IP-Adressen ermöglicht, eine einzige gemeinsame Internetverbindung für mehrere - Rechner zu nutzen (entweder über eine einzige Adresse - oder über eine Gruppe von jeweils automatisch - zugewiesenen öffentlichen - IP-Adressen). + Rechner zu nutzen. Dies geschieht entweder über eine + einzige IP-Adresse oder über eine Gruppe + von jeweils automatisch zugewiesenen öffentlichen + Adressen. - Nachdem Sie dieses Kapitel gelesen haben, werden Sie: + 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: + - Wissen, wie man korrekte Paketfilterregeln erstellt. + Wie man Paketfilterregeln erstellt. - Die Unterschiede zwischen den in &os; eingebauten Firewalls - kennen. + Was die Unterschiede zwischen den in &os; eingebauten + Firewalls sind. - Wissen, wie man die PF-Firewall - von OpenBSD konfiguriert und einsetzt. + Wie die PF-Firewall + konfiguriert und einsetzt wird. - IPFILTER konfigurieren und - einsetzen können. + Wie die IPFW-Firewall + konfiguriert und einsetzt wird. - Wissen, wie man IPFW konfiguriert - und einsetzt. + 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 - - rulesets + Regelsatz - Es gibt zwei grundlegende Arten, Regelgruppen für - Firewalls zu erstellen: einschließend - (inclusive firewall) sowie - auschließend (exclusive - Firewall). Eine auschließ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 - durch, wenn er einer der definierten Regeln entspricht. + 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. - Eine inclusive Firewall bietet eine wesentlich bessere Kontrolle - des ausgehenden Verkehrs, macht sie zur besseren Wahl für Systeme, - die Services für das Internet anbieten. Sie kontrolliert - auch den Verkehr vom Internet zu ihrem privaten Netzwerk. Jeder Verkehr, - der keiner Regel entspricht wird geblockt und geloggt. Inclusive - Firewalls sind generell sicherer als exclusive Firewalls, da sie das - Risiko, dass unerwünschter Verkehr hindurch geht, drastisch - reduzieren. + 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 Beispielregelsets dieses Kapitels inclusive Firewalls. + und Regelsätze in diesem Kapitel einschließende + Firewalls. - Die Sicherheit einer Firewall kann durch den Einsatz einer - zustandsabhängigen Firewall + Die Sicherheit kann durch den Einsatz einer + zustandsorientierten Firewall (stateful firewall) weiter - erhöht werden. Dieser Typ einer Firewall - überwacht alle durch die Firewall gehenden offenen - Verbindungen und erlaubt nur schon bestehenden Verkehr oder - Datenverkehr, der eine neue Verbindung öffnet. Der Nachteil - einer zustandsabhängigen Firewall ist allerdings, dass sie - anfällig für Denial of Service (DoS) - -Attacken ist, wenn sehr schnell sehr viele neue Verbindungen - erstellt werden. Bei den meisten Firewalls können Sie eine - Kombination aus zustandsabhängigem und nicht - zustandsabhängigem Verhalten verwenden, um eine für Ihre - Bedürfnisse optimale Firewall einzurichten. - + 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. - - Firewallpakete + 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. - Das Basissystem von &os; enthält bereits drei - Firewallpakete: IPFILTER (auch als - IPF bekannt), IPFIREWALL - (auch als IPFW bezeichnet) sowie das von OpenBSD - übernommene PacketFilter (das auch als - PF bezeichnet wird). Zusätzlich - verfügt &os; über zwei eingebaute Pakete für das - sogenannte traffic shaping (dabei - handelt es sich die Steuerung des Bandbreitenverbrauchs): - &man.altq.4; sowie &man.dummynet.4;. Dummynet steht traditionell - in enger Verbindung mit IPFW, während - ALTQ gemeinsam mit PF - eingesetzt wird. Traffic Shaping für IPFILTER ist derzeit - mit IPFILTER für NAT sowie Filterung und - mit IPFW und &man.dummynet.4; - oder durch die Kombination von - PF mit ALTQ möglich. - Gemeinsam ist allen Firewallpaketen (IPF, IPFW sowie PF), dass sie - Regeln einsetzen, um den Transfer von Datenpaketen auf und von - Ihrem System zu regeln. Unterschiedlich sind aber die Art und - Weise, wie dies realisiert wird. Auch die für diese Regeln - verwendete Syntax ist unterschiedlich. + Sobald die Session beendet ist, wird sie aus der + dynamischen Zustandstabelle entfernt. - &os; überlässt es dem Anwender, das Firewallsystem - zu wählen, dass seinen Anforderungen und Vorlieben am Besten - entspricht. Keines der im Basissystem enthaltenen Firewallpakete - wird dabei als das beste angesehen. + 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. - IPFILTER hat etwa den Vorteil, dass dessen - zustandsabhängige Regeln relativ einfach in einer - NAT-Umgebung implementiert werden können. - Außerdem verfügt es über einen eigenen FTP-Proxy, - der die Erstellung von sicheren Regeln für ausgehende - FTP-Verbindungen vereinfacht. + 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. - Da alle Firewalls auf der Untersuchung der Werte - ausgewählter Kontrollfelder von Datenpaketen basieren, ist es - für die Erstellung von Firewallregeln notwendig, die - Funktionsweise von TCP/IP zu verstehen. - Außerdem muss man dazu wissen, was die Werte der einzelnen - Kontrollfelder bedeuten und wie diese während einer - Verbindung eingesetzt werden. Eine gute Erklärung dieser - Thematik finden Sie unter http://www.ipprimer.com/overview.cfm. + 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> JohnFerrellRevised and updated by 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 Quality of Service (QoS)-Bandbreitenformung. Das OpenBSD-Projekt leistet bereits hervorragende Dokumentationsarbeit mit der PF FAQ. Aus diesem Grund konzentriert sich dieser Handbuchabschnitt nur auf diejenigen Besonderheiten von PF, die &os; betreffen, sowie ein paar allgemeine Informationen hinsichtlich der Verwendung. Genauere Informationen zum Einsatz erhalten Sie in der PF FAQ. Weitere Informationen zu PF für &os; finden Sie unter http://pf4freebsd.love2party.net/. Verwendung der PF-Kernelmodule Um die PF Kernel Module zu laden, fügen Sie folgende Zeile in ihre /etc/rc.conf ein: pf_enable="YES" Danach starten Sie das Startup Script um die Module zu laden: &prompt.root; /etc/rc.d/pf start 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: pf_rules="/path/to/pf.conf" Ein Beispiel für die Datei pf.conf finden Sie im Verzeichnis /usr/share/examples/pf/. Das PF-Modul kann auch manuell über die Kommandozeile geladen werden: &prompt.root; kldload pf.ko 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: pflog_enable="YES" Danach starten Sie das Startup Script, um das Modul zu laden: &prompt.root; /etc/rc.d/pflog start Falls Sie noch weitere Features für PF benötigen, müssen Sie diese in den Kernel einbauen. PF Kernel-Optionen Kerneloptionen device pf Kerneloptionen device pflog Kerneloptionen device pfsync Es ist nicht zwingend nötig, dass Sie PF-Unterstützung in den &os;-Kernel kompilieren. Sie werden dies tun müssen, um eine von PFs fortgeschritteneren Eigenschaften nutzen zu können, die nicht als Kernelmodul verfügbar ist. Genauer handelt es sich dabei um &man.pfsync.4;, ein Pseudo-Gerät, welches bestimmte Änderungen der PF-Zustandstabelle offenlegt. Es kann mit &man.carp.4; kombiniert werden, um ausfallsichere Firewalls mit PF zu realisieren. Weitere Informationen zu CARP erhalten Sie in des Handbuchs. Die Kernelkonfigurationsoptionen von PF befinden sich in /usr/src/sys/conf/NOTES und sind im Folgenden wiedergegeben: device pf device pflog device pfsync Die Option device pf aktiviert die Unterstützung für die Packet Filter-Firewall (&man.pf.4;). Die Option device pflog aktiviert das optionale &man.pflog.4;-Pseudonetzwerkgerät, das zum Protokollieren des Datenverkehrs über einen &man.bpf.4;-Deskriptor dient. &man.pflogd.8; ist in der Lage, diese Protokolldateien auf Ihre Platte zu speichern. Die Option device pfsync aktiviert das optionale &man.pfsync.4;-Pseudonetzwerkgerät für die Überwachung von Statusänderungen. Verfügbare rc.conf-Optionen Die folgenden &man.rc.conf.5;-Einträge konfigurieren PF und &man.pflog.4; beim Systemstart: 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 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: gateway_enable="YES" # LAN Gateway aktivieren Filterregeln erstellen 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. 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. 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! Arbeiten mit PF 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): Befehl Zweck pfctl -e PF aktivieren pfctl -d PF deaktivieren 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 pfctl -s [ rules | nat | states ] Bericht über die Filterregeln, NAT-Regeln, oder Zustandstabellen pfctl -vnf /etc/pf.conf überprüft /etc/pf.conf auf Fehler, lädt aber das Regelwerk nicht neu <acronym>ALTQ</acronym> aktivieren 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. Die folgenden Kerneloptionen aktivieren ALTQ sowie alle Zusatzfunktionen: 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 options ALTQ aktiviert das ALTQ-Framework. 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. 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. options ALTQ_RIO aktiviert Random Early Detection In and Out. 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. options ALTQ_PRIQ aktiviert Priority Queuing (PRIQ). PRIQ lässt Verkehr einer Warteschlange mit höherer Priorität zuerst durch. options ALTQ_NOPCC aktiviert die SMP Unterstützung von ALTQ. Diese Option ist nur auf SMP-System erforderlich. 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.1;. Mit &man.ipfstat.8; werden Laufzeitstatistiken der + &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.obfuscation.org/ipf/ipf-howto.html#TOC_1 - oder http://coombs.anu.edu.au/~avalon/ip-filter.html. + 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's the only +# 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.1; for + /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 ###############################