Firewall: Unterschied zwischen den Versionen
Gehrke (Diskussion | Beiträge) K (→Paketfilter: Rechtschreibunk) |
Gehrke (Diskussion | Beiträge) K (→pfSense) |
||
(15 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 65: | Zeile 65: | ||
Um wieder das Beispiel der Schulklasse zu nötigen: Stellen wir uns vor, der Lehrer hat eine Frage gestellt, auf die er eine Note vergeben will. Derjenige, der die richtige Antwort gibt, bekommt eine 1. Der Schüler Ben weiß die Antwort nicht. Die Schülerin Nicole mag den Schüler Ben aber sehr und möchte ihm deshalb eine gute Note verschaffen. Dafür verstellt sie ihre Stimme und gibt die richtige Antwort. | Um wieder das Beispiel der Schulklasse zu nötigen: Stellen wir uns vor, der Lehrer hat eine Frage gestellt, auf die er eine Note vergeben will. Derjenige, der die richtige Antwort gibt, bekommt eine 1. Der Schüler Ben weiß die Antwort nicht. Die Schülerin Nicole mag den Schüler Ben aber sehr und möchte ihm deshalb eine gute Note verschaffen. Dafür verstellt sie ihre Stimme und gibt die richtige Antwort. | ||
− | Der Aufpasser beherrscht aber Antispoofing und weiß | + | Der Aufpasser beherrscht aber Antispoofing und weiß, dass der Schüler Ben vorne rechts in der Klasse sieht. Die Anwort kam aber von hinten links (da sitzt Nicole). Deshalb verwirft er die Antwort und die Note kann nicht gefälscht werden. (Aber keine Sorge: Nicole und Bens Geschichte hatte ein glückliches Ende mit einer Hochzeit in Weiß und einem berauschenden Fest.) |
== Hochverfügbarkeit (Stateful Failover) == | == Hochverfügbarkeit (Stateful Failover) == | ||
Unter Stateful Failover versteht man die Fähigkeit, zwei Firewalls zu koppeln, so dass keine Verbindung unterbrochen wird, auch nicht, wenn eine der beiden Firewalls ausfällt. Die Firewall wird also hochverfügbar. | Unter Stateful Failover versteht man die Fähigkeit, zwei Firewalls zu koppeln, so dass keine Verbindung unterbrochen wird, auch nicht, wenn eine der beiden Firewalls ausfällt. Die Firewall wird also hochverfügbar. | ||
− | Um wieder im Beispiel zu bleiben: Man stelle sich vor, der Aufpasser in der Klasse hat einen | + | Um wieder im Beispiel zu bleiben: Man stelle sich vor, der Aufpasser in der Klasse hat einen dringenden Arzttermin und muss weg (wer möchte kann sich auch vorstellen das der Aufpasser einen Herzinfarkt hat und tot umfällt, aber das war dem Autor ein wenig zu blutig, deshalb der Arzttermin). Da der Aufpasser nicht mehr da ist und alle Verbindung von Lehrer zu Schüler über ihn laufen, können Lehrer und Schüler nicht mehr miteinander sprechen. |
Deshalb hat der Administrator einen zweiten Aufpasser in die Klasse gesetzt. Sobald der erste ausfällt, übernimmt der zweite und es kann weiter gehen. Somit hätte man ein Failover realisiert, allerdings noch kein Stateful Failover. Im Moment schreibt sich nämlich nur der aktive Aufpasser die Fragen des Lehrers auf. Somit kann nur er erkennen, ob ein Datenpakt von einem Schüler eine Antwort darstellt. Fällt er aus, weiß der zweite Aufpasser nicht, welche Fragen schon gestellt wurden, da er sich die Fragen nicht mitgeschrieben hat. Der Lehrer müsste also alle Fragen neu stellen, damit die Antworten durch kommen. | Deshalb hat der Administrator einen zweiten Aufpasser in die Klasse gesetzt. Sobald der erste ausfällt, übernimmt der zweite und es kann weiter gehen. Somit hätte man ein Failover realisiert, allerdings noch kein Stateful Failover. Im Moment schreibt sich nämlich nur der aktive Aufpasser die Fragen des Lehrers auf. Somit kann nur er erkennen, ob ein Datenpakt von einem Schüler eine Antwort darstellt. Fällt er aus, weiß der zweite Aufpasser nicht, welche Fragen schon gestellt wurden, da er sich die Fragen nicht mitgeschrieben hat. Der Lehrer müsste also alle Fragen neu stellen, damit die Antworten durch kommen. | ||
− | Ein Stateful Failover-Aufpasser (oder -Firewall) schreibt sich also die Fragen mit auch wenn er gerade nicht aktiv ist. Fällt der aktive Aufpasser/Firewall aus, braucht der Lehrer die Fragen nicht nochmal neu zu stellen. Die Verbindungen werden also nicht unterbrochen. | + | Ein Stateful Failover-Aufpasser (oder -Firewall) schreibt sich also die Fragen mit, auch wenn er gerade nicht aktiv ist. Fällt der aktive Aufpasser/Firewall aus, braucht der Lehrer die Fragen nicht nochmal neu zu stellen. Die Verbindungen werden also nicht unterbrochen. |
= Open Source Firewalls = | = Open Source Firewalls = | ||
Zeile 84: | Zeile 84: | ||
=== netfilter/iptables === | === netfilter/iptables === | ||
− | Der Linux-Kernel hat eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über die Befehl "iptables" (Layer 3/4 für IPv4), "ip6tables" (Layer 3/4 für IPv6), "arptables" (Layer 2) und "ebtables" (Layer 2 in Verbindung mit Bridge) konfiguriert werden. Oftmals wird auch einfach von [[iptables]] gesprochen wenn man Netfilter meint. | + | Der Linux-Kernel hat eine Firewall mit eingebaut. Diese nennt sich "'''Netfilter'''" und kann über die Befehl "iptables" (Layer 3/4 für IPv4), "ip6tables" (Layer 3/4 für IPv6), "arptables" (Layer 2) und "ebtables" (Layer 2 in Verbindung mit Bridge) konfiguriert werden. Oftmals wird auch einfach von [[iptables]] gesprochen, wenn man Netfilter meint. |
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da es durch iptables vollkommen ersetzt ist. | Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da es durch iptables vollkommen ersetzt ist. | ||
− | netfilter beherrscht das Stateful Inspection, kann also Verbindungen anhand | + | netfilter beherrscht das [[#Stateful_Inspection|Stateful Inspection]], kann also Verbindungen anhand ihres Zustands zulassen oder verbieten. Darüber hinaus setzt man netfilter auch zur Manipulation von Datenpaketen wie z.B [http://de.wikipedia.org/wiki/Network_Address_Translation NAT] ein. |
− | Es wird auch schon an Hochverfügbarkeit, also an Stateful Failover-Funktionalität gearbeitet. Das entsprechende Modul, welches hierfür benötigt wird, nennt sich ct_sync (siehe Ende der Seite). Es ist allerdings noch nicht standardmäßig im Linux-Kernel integriert. | + | Es wird auch schon an Hochverfügbarkeit, also an [[#Hochverfügbarkeit (Stateful Failover)|Stateful Failover-Funktionalität]] gearbeitet. Das entsprechende Modul, welches hierfür benötigt wird, nennt sich ct_sync (siehe [[#Quellen & Weiterführendes|Quellen & Weiterführendes]] am Ende der Seite). Es ist allerdings noch nicht standardmäßig im Linux-Kernel integriert. |
=== TuxGuardian === | === TuxGuardian === | ||
Zeile 95: | Zeile 95: | ||
Für Linux gibt es auch eine Desktopfirewall namens [http://tuxguardian.sourceforge.net/ TuxGuardian]. TuxGuardian ermöglicht es, für jedes Programm individuell zu bestimmen, ob es ins Internet darf oder nicht. Hierfür öffnet sich ein kleines Fenster, welches den Benutzer fragt, ob er/sie den Zugriff zulassen möchte oder nicht. Alternativ kann man auch über eine Konfigurationsdatei bestimmen, welches Programm Verbindungen öffnen darf und welches nicht. | Für Linux gibt es auch eine Desktopfirewall namens [http://tuxguardian.sourceforge.net/ TuxGuardian]. TuxGuardian ermöglicht es, für jedes Programm individuell zu bestimmen, ob es ins Internet darf oder nicht. Hierfür öffnet sich ein kleines Fenster, welches den Benutzer fragt, ob er/sie den Zugriff zulassen möchte oder nicht. Alternativ kann man auch über eine Konfigurationsdatei bestimmen, welches Programm Verbindungen öffnen darf und welches nicht. | ||
− | Tuxguardian ist bisher nicht Teil der gängigen Distributionen wie Ubuntu oder OpenSUSE, weshalb man es manuell nachinstallieren muss. | + | Tuxguardian ist bisher nicht Teil der gängigen Distributionen wie [[Ubuntu]] oder [[OpenSUSE]], weshalb man es manuell nachinstallieren muss. |
=== pf === | === pf === | ||
− | ''pf'' steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. [[pf]] beherrscht Stateful Inspection und kann mit Hilfe von pf_sync sogar hochverfügbar gemacht werden. (Ein Howto hierzu findet sich am Ende der Seite.) | + | ''pf'' steht für Paket Filter und ist der Name der Firewallsoftware von [[OpenBSD]]. [[pf]] beherrscht [[#Stateful Inspection|Stateful Inspection]] und kann mit Hilfe von pf_sync sogar [[#Hochverfügbarkeit (Stateful Failover)|hochverfügbar]] gemacht werden. (Ein Howto hierzu findet sich am Ende der Seite.) |
=== wipfw === | === wipfw === | ||
− | ''[http://wipfw.sourceforge.net/ wipfw]'' ist eine Portierung der FreeBSD Firewall ipfw auf Windows. Sie bietet zwar nicht alle Funktionen wie das Original ipfw, die wichtigsten Funktionen sind jedoch bereits integriert. Damit wäre es also theoretisch | + | ''[http://wipfw.sourceforge.net/ wipfw]'' ist eine Portierung der FreeBSD Firewall ipfw auf Windows. Sie bietet zwar nicht alle Funktionen wie das Original ipfw, die wichtigsten Funktionen sind jedoch bereits integriert. Damit wäre es also theoretisch möglich, MS Windows als echte Netzwerkfirewall einzusetzen. (Aber wer will das schon.) |
== Administrationsoberflächen == | == Administrationsoberflächen == | ||
Zeile 111: | Zeile 111: | ||
=== Firewall Builder === | === Firewall Builder === | ||
− | Neben distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Software zur Konfiguration von Netfilter, wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist ein GUI, in welchem man sich das Regelwerk für eine Firewall zusammenklicken kann. Man kann Regelwerke für iptables, ipfilter, OpenBSD pf und sogar (mit einem kostenpflichtigen Zusatzmodul) für Cisco PIX Firewalls erstellen. | + | Neben distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Software zur Konfiguration von Netfilter, wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist ein GUI, in welchem man sich das Regelwerk für eine Firewall zusammenklicken kann. Man kann Regelwerke für [[iptables]], ipfilter, OpenBSD [[pf]] und sogar (mit einem kostenpflichtigen Zusatzmodul) für Cisco PIX Firewalls erstellen. |
=== Easy Firewall Generator for IPTables === | === Easy Firewall Generator for IPTables === | ||
Der [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist eine Webseite, über die man sich ein Shellscript für iptables erstellen lassen kann. Man folgt einfach den Fragen auf der Seite und kopiert am Ende die Ausgabe in eine Datei. Diese lässt man über ein [[Runlevel scripte - Scripts selbst erstellen|Runlevelscript]] bei jedem Start ausführen. | Der [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist eine Webseite, über die man sich ein Shellscript für iptables erstellen lassen kann. Man folgt einfach den Fragen auf der Seite und kopiert am Ende die Ausgabe in eine Datei. Diese lässt man über ein [[Runlevel scripte - Scripts selbst erstellen|Runlevelscript]] bei jedem Start ausführen. | ||
+ | |||
+ | ==Firewall-Distributionen== | ||
+ | Es gibt komplette Distributionen, die sich auf die Funktionalität einer Firewall spezialisiert haben. | ||
+ | ===pfSense=== | ||
+ | pfSense ist eine Firewall-Distribution auf Basis des Betriebssystems [[FreeBSD]] und des Paketfilters [[pf]]. Diese ist insbesondere auf 'Embedded Devices' und fertigen 'Appliances ' populär. | ||
+ | *[http://pfsense.org pfsense.org] | ||
+ | *[http://de.wikipedia.org/wiki/Pfsense pfSense (Wikipedia)] | ||
+ | Zusätzlich zur klassischen Firewall-Funktionalität wird insbesondere auch ein [[VPN]]-Server auf Basis der folgenden Protokolle implementiert: IPsec, L2TP, [[OpenVPN]], PPTP. | ||
= Wichtige Sicherheitshinweise zu Firewalls = | = Wichtige Sicherheitshinweise zu Firewalls = | ||
Zeile 121: | Zeile 129: | ||
== Die Firewall als Allheilmittel? == | == Die Firewall als Allheilmittel? == | ||
− | Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt, öffnet man ja die Firewall und | + | Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt, öffnet man ja die Firewall und setzt die dahinter liegenden Systeme potentiellen Angriffen aus. Man muss also noch zusätzliche Sicherheitsmaßen ergreifen, um die Dienste, welche die Firewall erlauben soll, abzusichern. Eine Firewall kann somit nur Teil eines Sicherheitskonzeptes sein, nicht jedoch das Konzept alleine darstellen. |
− | Darüber hinaus muss man sicherstellen, dass die Firewall "im Weg" steht, d.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre als ob man eine Vordertür mit Sicherheitsschlössern, Fingerabdrucksensor und Stahlpanzerung hat, die Rückseite des Hauses aber ein Loch in der Mauer hat. | + | Darüber hinaus muss man sicherstellen, dass die Firewall "im Weg" steht, d.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre, als ob man eine Vordertür mit Sicherheitsschlössern, Fingerabdrucksensor und Stahlpanzerung hat, die Rückseite des Hauses aber ein Loch in der Mauer hat. |
Auch kann man eine Firewall relativ leicht durchtunneln, wenn man ein System innen und außen unter Kontrolle hat. PCs im eigenen Netzwerk mit einem Trojaner machen also selbst die beste Firewall u.U. löchrig. | Auch kann man eine Firewall relativ leicht durchtunneln, wenn man ein System innen und außen unter Kontrolle hat. PCs im eigenen Netzwerk mit einem Trojaner machen also selbst die beste Firewall u.U. löchrig. | ||
Zeile 131: | Zeile 139: | ||
== Grundsätze zur Gestaltung des Regelwerkes == | == Grundsätze zur Gestaltung des Regelwerkes == | ||
− | Wie man eine Firewall und deren Regelwerk aufbaut, hängt natürlich von den Anforderungen ab. Allerdings lassen sich einige ganz | + | Wie man eine Firewall und deren Regelwerk aufbaut, hängt natürlich von den Anforderungen ab. Allerdings lassen sich einige ganz nützliche Grundregeln festhalten, welche nachfolgend aufgeführt werden. Die Regeln sind nicht für eine spezifische Firewallsoftware, sondern können im Prinzip für alle Firewalls gelten. |
− | In diesem Beispiel wird davon ausgegangen, dass die Firewall die erste Regel benutzt, die sie findet. Wird also ein Paket von einer Regel ganz vorne zugelassen und von einer Regel ganz hinten verworfen, so würde die hier verwendete Beispiel Firewall das Paket zulassen, da die entsprechende Regel zuerst im Regelwerk gefunden wurde. Dies ist die normale Verhaltensweise von netfilter und der meisten anderen Firewalls (wenn auch nicht alle; pf wendet z.B. die letzte | + | In diesem Beispiel wird davon ausgegangen, dass die Firewall die erste Regel benutzt, die sie findet. Wird also ein Paket von einer Regel ganz vorne zugelassen und von einer Regel ganz hinten verworfen, so würde die hier verwendete Beispiel Firewall das Paket zulassen, da die entsprechende Regel '''zuerst''' im Regelwerk gefunden wurde. Dies ist die normale Verhaltensweise von [[iptables|netfilter]] und der meisten anderen Firewalls (wenn auch nicht alle; [[pf]] wendet z.B. die '''letzte''' gefundene Regel an). |
'''Broadcast Regel''' | '''Broadcast Regel''' | ||
Zeile 139: | Zeile 147: | ||
* Quelle: Alle | * Quelle: Alle | ||
* Ziel: Broadcast IP Adresse der Netzwerksegmente | * Ziel: Broadcast IP Adresse der Netzwerksegmente | ||
− | * Service: ''unterschiedlich, meist MS-RPC, RIP, NBT, eben alles, was als Broadcast geschickt wird und was das eigene | + | * Service: ''unterschiedlich, meist MS-RPC, RIP, NBT, eben alles, was als Broadcast geschickt wird und was das eigene Netzwerksegment nicht verlassen soll.'' |
+ | ** Anmerkung: Broadcast-Pakete werden generell nicht geroutet und überschreiten somit nie ein Netzwerksegment, weshalb diese Regel unnötig erscheint. | ||
+ | ** Anmerkung zur Anmerkung: Es geht hierbei nicht um die Unterbindung dieses Traffics, sondern darum die Firewall zu entlasten, wenn das Broadcast-Paket gleich am Anfang des Regelwerks verworfen wird, muss die Firewall nicht für jedes dieser Pakete das ganze Regelwerk abarbeiten, das verringert die Systemlast deutlich.) | ||
* Aktion: Paket verwerfen | * Aktion: Paket verwerfen | ||
* Ins Log schreiben? Nein | * Ins Log schreiben? Nein | ||
− | Die Broadcastregel filtert unnötiges Rauschen im Netzwerk. Viele Dienste wie SMB schicken regelmäßig Daten mit Statusinformationen an die Broadcastadresse des Netzwerkes. Diese Daten sind in aller Regel nur für das jeweilige Netzwerksegment eines Rechners notwendig und müssen nicht in andere Netzwerke weitergeleitet werden. | + | Die Broadcastregel filtert '''unnötiges Rauschen''' im Netzwerk. Viele Dienste wie [[SMB]] schicken regelmäßig Daten mit Statusinformationen an die Broadcastadresse des Netzwerkes. Diese Daten sind in aller Regel nur für das jeweilige Netzwerksegment eines Rechners notwendig und müssen nicht in andere Netzwerke weitergeleitet werden. |
Da solche Pakete relativ häufig auftauchen, steht die Regel ganz vorne im Regelwerk. Dadurch muss die Firewall nicht das ganze Regelwerk abarbeiten, was die Last der Maschine verringert. Aus dem gleichen Grund wird ein Greifen dieser Regel auch nicht ins Log geschrieben. Es würde das Log nur unnötig vollschreiben und die Suche nach interessanten Daten erschweren. | Da solche Pakete relativ häufig auftauchen, steht die Regel ganz vorne im Regelwerk. Dadurch muss die Firewall nicht das ganze Regelwerk abarbeiten, was die Last der Maschine verringert. Aus dem gleichen Grund wird ein Greifen dieser Regel auch nicht ins Log geschrieben. Es würde das Log nur unnötig vollschreiben und die Suche nach interessanten Daten erschweren. | ||
Zeile 151: | Zeile 161: | ||
* Quelle: IP-Adresse des Administrator PCs | * Quelle: IP-Adresse des Administrator PCs | ||
* Ziel: IP-Adresse der Firewall | * Ziel: IP-Adresse der Firewall | ||
− | * Service: ssh (bzw. was zur Administration der Firewall benötigt wird) | + | * Service: [[ssh]] (bzw. was zur Administration der Firewall benötigt wird) |
* Aktion: Zulassen | * Aktion: Zulassen | ||
* Ins Log schreiben? Ja | * Ins Log schreiben? Ja | ||
− | Die Administrationsregel erlaubt den Zugriff auf die Firewall durch den Administrator. Diese Regel muss schon beim ersten Aktivieren des Regelwerkes vorhanden sein. Sonst sägt man sich den eigenen Ast ab und kann nach Aktivierung der Firewall diese nicht mehr kontrollieren. (Trifft nur für Netzwerk zu - bei Administration über Tastatur, Serial oder ähnlichen Methoden kann man auch zwischendurch mal ein nicht funktionales Regelwerk haben ohne sich auszuschließen.) | + | Die Administrationsregel erlaubt den '''Zugriff auf die Firewall''' durch den Administrator. Diese Regel muss schon beim ersten Aktivieren des Regelwerkes vorhanden sein. Sonst sägt man sich den eigenen Ast ab und kann nach Aktivierung der Firewall diese nicht mehr kontrollieren. (Trifft nur für Netzwerk zu - bei Administration über Tastatur, Serial oder ähnlichen Methoden kann man auch zwischendurch mal ein nicht funktionales Regelwerk haben ohne sich auszuschließen.) |
'''Stealth Regel''' | '''Stealth Regel''' | ||
Zeile 165: | Zeile 175: | ||
* Ins Log schreiben? Ja | * Ins Log schreiben? Ja | ||
− | Die sogenannte | + | Die sogenannte Stealth-Regel sorgt dafür, dass die Firewall auf keinerlei Anfragen, welche direkt an sie gerichtet wurde, reagiert. Sie taucht also in [[traceroute]]s oder ähnlichem nicht mehr auf und ist dadurch quasi '''unsichtbar'''. Der Vorteil ist, dass ein Angreifer nicht mehr ohne weiteres erkennen kann, welche Firewall-Software eingesetzt wurde. Dadurch wird es schwieriger evtl. vorhandene Lücken und Bugs in der Firewall-Software auszunutzen. Allerdings ist auch dies kein Allheilmittel. Dadurch, dass die Firewall nicht reagiert, weiß der Angreifer schon mal, dass höchstwahrscheinlich eine Firewall eingesetzt wird. Keine Antwort ist somit auch eine Antwort. |
''' DROP Regel''' | ''' DROP Regel''' | ||
Zeile 175: | Zeile 185: | ||
* Ins Log schreiben? Ja | * Ins Log schreiben? Ja | ||
− | Dies ist die letzte Regel im Regelwerk. Jedes Paket für das keine andere Regel gefunden wurde wird verworfen. Diese Regel realisiert dadurch eine "Deny All" Regelwerk, d.h. alles was nicht erlaubt ist, ist verboten. Ein solches Vorgehen wird häufig für Firewalls eingesetzt welche ein Firmennetzwerk mit dem Internet verbinden. | + | Dies ist die letzte Regel im Regelwerk. Jedes Paket, für das keine andere Regel gefunden wurde, wird verworfen. Diese Regel realisiert dadurch eine "Deny All" Regelwerk, d.h. '''alles was nicht erlaubt ist, ist verboten'''. Ein solches Vorgehen wird häufig für Firewalls eingesetzt, welche ein Firmennetzwerk mit dem Internet verbinden. |
= Quellen & Weiterführendes = | = Quellen & Weiterführendes = | ||
− | |||
* [http://iptables-tutorial.frozentux.net/iptables-tutorial.html Sehr gute Einführung in iptables] | * [http://iptables-tutorial.frozentux.net/iptables-tutorial.html Sehr gute Einführung in iptables] | ||
* [http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke Eine Firewall als Netzwerkbrücke] | * [http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke Eine Firewall als Netzwerkbrücke] | ||
Zeile 185: | Zeile 194: | ||
* [http://gnumonks.org/~laforge/weblog/linux/netfilter/ct_sync/index.html Statefull Failover für netfilter (ct_sync)] | * [http://gnumonks.org/~laforge/weblog/linux/netfilter/ct_sync/index.html Statefull Failover für netfilter (ct_sync)] | ||
* [http://tuxguardian.sourceforge.net/documentation.php Dokumentation von TuxGuadian] | * [http://tuxguardian.sourceforge.net/documentation.php Dokumentation von TuxGuadian] | ||
+ | * [[IP-Tables Skripte fuer Single Host, SMB-Server und Router]] | ||
---- | ---- | ||
[[Security|zurück zur Security]] | [[Security|zurück zur Security]] | ||
− | [[Category:Security]] | + | [[Category:Security]] [[Category:Netzwerk]] |
Aktuelle Version vom 11. Januar 2015, 14:59 Uhr
Dieser Artikel beschäftigt sich mit Firewalls im Allgemeinen. Es geht nicht um die Konfiguration einer speziellen Firewall. Anleitungen und Artikel darüber finden sich, am Ende der Seite, in den Quellen.
Eine Firewall (auch der Firewall) ist eine Netzwerkkomponente, die der Netzwerksicherheit dient. Sie soll zwei oder mehr Netzwerksegmente kontrollierbar miteinander verbinden. Das bedeutet, dass die einzelnen Rechner in den verschiedenen Netzwerksegmenten bestimmte Verbindungen untereinander aufbauen sollen, jedoch nicht jede beliebige Kommunikation durchführen können.
Inhaltsverzeichnis
Firewalltypen
Netzwerkfirewall
Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen, deren Verbindungen kontrolliert werden sollen. Die Firewall ist somit Teil beider Netzwerke und hat somit (mit Ausnahmen) auch zwei IP-Adressen; jeweils eine aus dem entsprechenden Netz. Damit Daten von einem Netzwerk in das andere Netzwerk gesendet werden können, muss die Firewall auch als Router dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.
Tatsächlich kann man eine Netzwerkfirewall auch als Layer-3/4 Firewall bezeichnen, denn sie arbeitet meistens in den Schichten 3 und 4 des ISO/OSI Modells. Eine Firewall, die keinerlei Verbindungen blockiert, verhält sich somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.
Neben diesen Layer-3/4 Firewalls kann eine Firewall auch im Layer 2, also bereits im Data Link Layer, aktiv sein. Eine solche Firewall filtert dann nicht mehr anhand von IP-Adressen, sondern nach MAC-Adressen. Solche Bridge-Firewalls werden in aller Regel für die Kontrolle des eigenen internen LANs eingesetzt. Im Außeneinsatz, also zur Trennung zwischen eigenem LAN und Internet machen solche Firewalls keinen Sinn, da MAC-Adressen bereits nach dem ersten Router verloren gehen und so ein feinkörnige Trennung der Zugriffe nicht mehr möglich ist.
Desktop- oder Hostfirewall
Neben der Firewall als Netzwerkkomponente, gibt es auch noch Firewalls, die auf einem Rechner mit nur einer Netzwerkkarte laufen, also keine verschiedenen Netzwerksegemente miteinander verbinden können. Solche Firewalls werden als Host- oder auch Desktopfirewall bezeichnet. Ihre Aufgaben bestehen darin,
- den Rechner vor Angriffen von außen zu schützen, sowie
- zu verhindern das vom eigenen Rechner aus Verbindungen ins Netzwerk aufgebaut werden.
Der Sinn einer Desktopfirewall ist umstritten, da man auch ohne Firewall den Rechner vor Zugriffen von außen schützen kann, indem man einfach keine Dienste wie SSH oder VNC an der physikalischen Netzwerkkarte lauschen lässt. Dadurch reagiert der eigene Rechner überhaupt nicht auf Anfragen und diese müssen nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte, dass bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert man dann nicht einfach das Programm, welches diese Daten sendet?
Application-Layer-Firewalls
Unter dem Begriff Application-Layer-Firewall (oder auch Web-Application-Firewall) versteht man Firewalls, welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes, beeinflussen. Eine Application-Layer-Firewall kann also erkennen, ob das, was ein Rechner sendet, wirklich eine Webanfrage ist, oder ob der Anfragende Rechner versucht, unerlaubt Daten durch die Firewall zu schicken, indem er so tut, als wäre es eine Webanfrage. So kann eine Application-Layer-Firewall z.B. Webseiten ausfiltern, welche versuchen, eine bekannte Browserlücke auszunutzen, oder verhindern, dass ein Benutzer einen Virus herunterlädt. Auch können auf diesem Wege Sicherheitslücken in Server-Anwendungen unschädlich gemacht werden, ohne die Anwendungen selbst anpassen zu müssen.
Oftmals werden Application-Layer-Firewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.
Firewalltechnologien
Paketfilter
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls, d.h. sie analysieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien, ob diese Pakete weitergeleitet oder verworfen wird.
Wenn z.B. ein Webbrowser Daten von einem Webserver abruft, so packt der Webserver die Daten in Pakete zusammen und schickt diese an den Browser. Bevor diese Pakete den Browser erreichen, müssen sie durch die Firewall durch, da diese "auf dem Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (Quelladresse), wohin die Daten sollen (Zieladresse), sowie welcher Port verwendet wird (z.B. http oder ssh). Diese Daten vergleicht sie mit ihrem Regelwerk.
Wenn es eine Regel gibt, welche diese Verbindung explizit erlaubt, wird das Datenpaket weitergeleitet. Gibt es eine Regel, welche diese Verbindung verbietet, wird das Paket verworfen. Gibt es keine Regel, handelt die Firewall nach ihrer Default Policy. Dies ist eine Regel, die angewendet wird, wenn keine andere Regel zu finden ist.
Stateful Inspection
Eine Firewall, die Stateful Inspection beherrscht, handelt erstmal wie ein reiner Paketfilter, kann jedoch zusätzlich den Status einer Verbindung berücksichtigen, d.h. wenn Rechner A eine Verbindung zu Rechner B aufbaut, indem er ein Datenpaket schickt, lässt die Firewall automatisch die Antwort von Rechner B zu, sofern dies vom Administrator entsprechend eingestellt wurde.
Versucht der Rechner B allerdings Daten an Rechner A zu schicken, ohne das vorher Rechner A ein Paket geschickt hat, würde die Firewall die Verbindung blockieren.
Man kann sich das wie bei einer Schulklasse vorstellen, bei der zwischen Schülern und Lehreren noch ein Aufpasser sitzt. Dieser Aufpasser ist die Firewall. Der Aufpasser hat vom Administrator die Regel bekommen, dass Daten vom Lehrer zu den Schülern immer durchgelassen werden dürfen. Der Lehrer kann somit zu den Schülern sprechen.
Wenn die Schüler auch Daten an den Lehrer schicken können sollen, braucht der Aufpasser auch eine entsprechende Regel. Wenn der Aufpasser nun kein Stateful Inspection kann, so muss der Administrator eine Regel einbauen, welche es den Schülern immer erlaubt, Daten an den Lehrer zu schicken. Das würde bedeuten, dass die Schüler dem Lehrer ständig ins Wort fallen könnten.
Kann der Aufpasser aber Stateful Inspection, so kann der Administrator dem Aufpasser sagen, dass dieser nur Daten von den Schülern zum Lehrer durchlassen soll, wenn der Lehrer vorher eine entsprechende Verbindung aufgebaut hat. Die Schüler könnten also nur Daten schicken, wenn der Lehrer vorher eine Frage gestellt hat und auf eine Antwort wartet. Wenn der Lehrer nur am Erklären ist und keine Antwort möchte, würde der Aufpasser jeden Zwischenruf von den Schülern zum Lehrer verhindern.
Proxy
Viele Firewalls haben inzwischen Proxies integriert, oder bieten zumindest teilweise solche Fähigkeiten an.
Proxies setzen der Stateful Inspection noch etwas oben drauf. Eine Stateful Inspection Firewall kann zwar erkennen, ob ein eingehendes Datenpaket eine Antwort zu einem vorherigen Datenpaket war, jedoch nicht, ob die Antwort auch Sinn macht.
Eine Firewall mit Proxyfunktionalität kann genau das. eine Proxyfirewall "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern, dass z.B. ein Browser eine Verbindung zu einem Webserver aufbaut und dieser eine mit einem Trojaner gespickte Seite zurückliefert.
Um beim Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland?" und ein Schüler könnte antworten, "der Lehrer ist doof", den Lehrer somit trauig machen und ihn an seinen Fähigkeiten zweifeln lassen, so dass er irgendwann eine Neurose bekommt und krank wird. Ein Aufpasser mit Proxyfähigkeiten könnte dies verhindern und nur Antworten wie "Karlsruhe", "Frankfurt", oder eben auch "Berlin" durchlassen. Damit ist der Lehrer geschützt, allerdings leuchtet es ein, dass der Aufpasser hierfür Ahnung von Geograhpie haben muss.
Entsprechendes gilt auch für echte Firewalls. Sie müssen "wissen", was eine gültige Antwort darstellt, was relativ aufwendig ist und dementsprechend nicht immer zuverlässig funktioniert(?).
Antispoofing
Unter Antispoofing versteht man die Fähigkeit einer Firewall, Pakete aufgrund ihrer physikalischen Herkunft zu kontrollieren, d.h. die Firewall würde eine Verbindung kontrollieren, wenn sie nicht über die "richtige" Netzwerkkarte reinkommt. Die Idee dahinter ist, zu verhindern, dass ein Angreifer seine Quelladresse fälscht und somit Daten über die Firewall schicken könnte.
Um wieder das Beispiel der Schulklasse zu nötigen: Stellen wir uns vor, der Lehrer hat eine Frage gestellt, auf die er eine Note vergeben will. Derjenige, der die richtige Antwort gibt, bekommt eine 1. Der Schüler Ben weiß die Antwort nicht. Die Schülerin Nicole mag den Schüler Ben aber sehr und möchte ihm deshalb eine gute Note verschaffen. Dafür verstellt sie ihre Stimme und gibt die richtige Antwort.
Der Aufpasser beherrscht aber Antispoofing und weiß, dass der Schüler Ben vorne rechts in der Klasse sieht. Die Anwort kam aber von hinten links (da sitzt Nicole). Deshalb verwirft er die Antwort und die Note kann nicht gefälscht werden. (Aber keine Sorge: Nicole und Bens Geschichte hatte ein glückliches Ende mit einer Hochzeit in Weiß und einem berauschenden Fest.)
Hochverfügbarkeit (Stateful Failover)
Unter Stateful Failover versteht man die Fähigkeit, zwei Firewalls zu koppeln, so dass keine Verbindung unterbrochen wird, auch nicht, wenn eine der beiden Firewalls ausfällt. Die Firewall wird also hochverfügbar.
Um wieder im Beispiel zu bleiben: Man stelle sich vor, der Aufpasser in der Klasse hat einen dringenden Arzttermin und muss weg (wer möchte kann sich auch vorstellen das der Aufpasser einen Herzinfarkt hat und tot umfällt, aber das war dem Autor ein wenig zu blutig, deshalb der Arzttermin). Da der Aufpasser nicht mehr da ist und alle Verbindung von Lehrer zu Schüler über ihn laufen, können Lehrer und Schüler nicht mehr miteinander sprechen.
Deshalb hat der Administrator einen zweiten Aufpasser in die Klasse gesetzt. Sobald der erste ausfällt, übernimmt der zweite und es kann weiter gehen. Somit hätte man ein Failover realisiert, allerdings noch kein Stateful Failover. Im Moment schreibt sich nämlich nur der aktive Aufpasser die Fragen des Lehrers auf. Somit kann nur er erkennen, ob ein Datenpakt von einem Schüler eine Antwort darstellt. Fällt er aus, weiß der zweite Aufpasser nicht, welche Fragen schon gestellt wurden, da er sich die Fragen nicht mitgeschrieben hat. Der Lehrer müsste also alle Fragen neu stellen, damit die Antworten durch kommen.
Ein Stateful Failover-Aufpasser (oder -Firewall) schreibt sich also die Fragen mit, auch wenn er gerade nicht aktiv ist. Fällt der aktive Aufpasser/Firewall aus, braucht der Lehrer die Fragen nicht nochmal neu zu stellen. Die Verbindungen werden also nicht unterbrochen.
Open Source Firewalls
Echte Firewallsysteme
Nachfolgend einige Open Source Firewalls. Eine solche Liste kann natürlich nicht vollständig sein, deshalb werden nur einige herausragende Vertreter aufgeführt.
netfilter/iptables
Der Linux-Kernel hat eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über die Befehl "iptables" (Layer 3/4 für IPv4), "ip6tables" (Layer 3/4 für IPv6), "arptables" (Layer 2) und "ebtables" (Layer 2 in Verbindung mit Bridge) konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen, wenn man Netfilter meint. Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da es durch iptables vollkommen ersetzt ist.
netfilter beherrscht das Stateful Inspection, kann also Verbindungen anhand ihres Zustands zulassen oder verbieten. Darüber hinaus setzt man netfilter auch zur Manipulation von Datenpaketen wie z.B NAT ein.
Es wird auch schon an Hochverfügbarkeit, also an Stateful Failover-Funktionalität gearbeitet. Das entsprechende Modul, welches hierfür benötigt wird, nennt sich ct_sync (siehe Quellen & Weiterführendes am Ende der Seite). Es ist allerdings noch nicht standardmäßig im Linux-Kernel integriert.
TuxGuardian
Für Linux gibt es auch eine Desktopfirewall namens TuxGuardian. TuxGuardian ermöglicht es, für jedes Programm individuell zu bestimmen, ob es ins Internet darf oder nicht. Hierfür öffnet sich ein kleines Fenster, welches den Benutzer fragt, ob er/sie den Zugriff zulassen möchte oder nicht. Alternativ kann man auch über eine Konfigurationsdatei bestimmen, welches Programm Verbindungen öffnen darf und welches nicht.
Tuxguardian ist bisher nicht Teil der gängigen Distributionen wie Ubuntu oder OpenSUSE, weshalb man es manuell nachinstallieren muss.
pf
pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Stateful Inspection und kann mit Hilfe von pf_sync sogar hochverfügbar gemacht werden. (Ein Howto hierzu findet sich am Ende der Seite.)
wipfw
wipfw ist eine Portierung der FreeBSD Firewall ipfw auf Windows. Sie bietet zwar nicht alle Funktionen wie das Original ipfw, die wichtigsten Funktionen sind jedoch bereits integriert. Damit wäre es also theoretisch möglich, MS Windows als echte Netzwerkfirewall einzusetzen. (Aber wer will das schon.)
Administrationsoberflächen
SuSE-Firewall
Die SuSE-Firewall ist keine neue Firewall, sondern nur eine Oberfläche für iptables. Somit kann die SuSE-Firewall nur das, was auch netfilter kann. Die Administration dieser "Firewall" lässt sich über YaST erledigen. Zur Fehlersuche kann man sich die Datei /etc/sysconfig/SuSEfirewall2
in einem Texteditor ansehen. Darin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.
Firewall Builder
Neben distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Software zur Konfiguration von Netfilter, wie z.B. Firewall Builder. Der Firewall Builder ist ein GUI, in welchem man sich das Regelwerk für eine Firewall zusammenklicken kann. Man kann Regelwerke für iptables, ipfilter, OpenBSD pf und sogar (mit einem kostenpflichtigen Zusatzmodul) für Cisco PIX Firewalls erstellen.
Easy Firewall Generator for IPTables
Der Easy Firewall Generator for IPTables ist eine Webseite, über die man sich ein Shellscript für iptables erstellen lassen kann. Man folgt einfach den Fragen auf der Seite und kopiert am Ende die Ausgabe in eine Datei. Diese lässt man über ein Runlevelscript bei jedem Start ausführen.
Firewall-Distributionen
Es gibt komplette Distributionen, die sich auf die Funktionalität einer Firewall spezialisiert haben.
pfSense
pfSense ist eine Firewall-Distribution auf Basis des Betriebssystems FreeBSD und des Paketfilters pf. Diese ist insbesondere auf 'Embedded Devices' und fertigen 'Appliances ' populär.
Zusätzlich zur klassischen Firewall-Funktionalität wird insbesondere auch ein VPN-Server auf Basis der folgenden Protokolle implementiert: IPsec, L2TP, OpenVPN, PPTP.
Wichtige Sicherheitshinweise zu Firewalls
Die Firewall als Allheilmittel?
Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt, öffnet man ja die Firewall und setzt die dahinter liegenden Systeme potentiellen Angriffen aus. Man muss also noch zusätzliche Sicherheitsmaßen ergreifen, um die Dienste, welche die Firewall erlauben soll, abzusichern. Eine Firewall kann somit nur Teil eines Sicherheitskonzeptes sein, nicht jedoch das Konzept alleine darstellen.
Darüber hinaus muss man sicherstellen, dass die Firewall "im Weg" steht, d.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre, als ob man eine Vordertür mit Sicherheitsschlössern, Fingerabdrucksensor und Stahlpanzerung hat, die Rückseite des Hauses aber ein Loch in der Mauer hat.
Auch kann man eine Firewall relativ leicht durchtunneln, wenn man ein System innen und außen unter Kontrolle hat. PCs im eigenen Netzwerk mit einem Trojaner machen also selbst die beste Firewall u.U. löchrig.
Natürlich kann auch die Firewall selbst einen Bug haben, wodurch wiederum Verbindungen zugelassen werden oder die Firewall u.U. komplett umgangen werden. Auch dies muss man berücksichtigen.
Grundsätze zur Gestaltung des Regelwerkes
Wie man eine Firewall und deren Regelwerk aufbaut, hängt natürlich von den Anforderungen ab. Allerdings lassen sich einige ganz nützliche Grundregeln festhalten, welche nachfolgend aufgeführt werden. Die Regeln sind nicht für eine spezifische Firewallsoftware, sondern können im Prinzip für alle Firewalls gelten.
In diesem Beispiel wird davon ausgegangen, dass die Firewall die erste Regel benutzt, die sie findet. Wird also ein Paket von einer Regel ganz vorne zugelassen und von einer Regel ganz hinten verworfen, so würde die hier verwendete Beispiel Firewall das Paket zulassen, da die entsprechende Regel zuerst im Regelwerk gefunden wurde. Dies ist die normale Verhaltensweise von netfilter und der meisten anderen Firewalls (wenn auch nicht alle; pf wendet z.B. die letzte gefundene Regel an).
Broadcast Regel
- Position im Regelwerk: Ganz vorne
- Quelle: Alle
- Ziel: Broadcast IP Adresse der Netzwerksegmente
- Service: unterschiedlich, meist MS-RPC, RIP, NBT, eben alles, was als Broadcast geschickt wird und was das eigene Netzwerksegment nicht verlassen soll.
- Anmerkung: Broadcast-Pakete werden generell nicht geroutet und überschreiten somit nie ein Netzwerksegment, weshalb diese Regel unnötig erscheint.
- Anmerkung zur Anmerkung: Es geht hierbei nicht um die Unterbindung dieses Traffics, sondern darum die Firewall zu entlasten, wenn das Broadcast-Paket gleich am Anfang des Regelwerks verworfen wird, muss die Firewall nicht für jedes dieser Pakete das ganze Regelwerk abarbeiten, das verringert die Systemlast deutlich.)
- Aktion: Paket verwerfen
- Ins Log schreiben? Nein
Die Broadcastregel filtert unnötiges Rauschen im Netzwerk. Viele Dienste wie SMB schicken regelmäßig Daten mit Statusinformationen an die Broadcastadresse des Netzwerkes. Diese Daten sind in aller Regel nur für das jeweilige Netzwerksegment eines Rechners notwendig und müssen nicht in andere Netzwerke weitergeleitet werden.
Da solche Pakete relativ häufig auftauchen, steht die Regel ganz vorne im Regelwerk. Dadurch muss die Firewall nicht das ganze Regelwerk abarbeiten, was die Last der Maschine verringert. Aus dem gleichen Grund wird ein Greifen dieser Regel auch nicht ins Log geschrieben. Es würde das Log nur unnötig vollschreiben und die Suche nach interessanten Daten erschweren.
Administrations-Regel
- Position im Regelwerk: Vor der Stealth Rule
- Quelle: IP-Adresse des Administrator PCs
- Ziel: IP-Adresse der Firewall
- Service: ssh (bzw. was zur Administration der Firewall benötigt wird)
- Aktion: Zulassen
- Ins Log schreiben? Ja
Die Administrationsregel erlaubt den Zugriff auf die Firewall durch den Administrator. Diese Regel muss schon beim ersten Aktivieren des Regelwerkes vorhanden sein. Sonst sägt man sich den eigenen Ast ab und kann nach Aktivierung der Firewall diese nicht mehr kontrollieren. (Trifft nur für Netzwerk zu - bei Administration über Tastatur, Serial oder ähnlichen Methoden kann man auch zwischendurch mal ein nicht funktionales Regelwerk haben ohne sich auszuschließen.)
Stealth Regel
- Position im Regelwerk: Vorne
- Quelle: Alle
- Ziel: IP-Adresse der Firewall
- Service: Alle
- Aktion: Paket verwerfen
- Ins Log schreiben? Ja
Die sogenannte Stealth-Regel sorgt dafür, dass die Firewall auf keinerlei Anfragen, welche direkt an sie gerichtet wurde, reagiert. Sie taucht also in traceroutes oder ähnlichem nicht mehr auf und ist dadurch quasi unsichtbar. Der Vorteil ist, dass ein Angreifer nicht mehr ohne weiteres erkennen kann, welche Firewall-Software eingesetzt wurde. Dadurch wird es schwieriger evtl. vorhandene Lücken und Bugs in der Firewall-Software auszunutzen. Allerdings ist auch dies kein Allheilmittel. Dadurch, dass die Firewall nicht reagiert, weiß der Angreifer schon mal, dass höchstwahrscheinlich eine Firewall eingesetzt wird. Keine Antwort ist somit auch eine Antwort.
DROP Regel
- Position im Regelwerk: Letzte Regel
- Quelle: Alle
- Ziel: Alle
- Service: Alle
- Aktion: Paket verwerfen
- Ins Log schreiben? Ja
Dies ist die letzte Regel im Regelwerk. Jedes Paket, für das keine andere Regel gefunden wurde, wird verworfen. Diese Regel realisiert dadurch eine "Deny All" Regelwerk, d.h. alles was nicht erlaubt ist, ist verboten. Ein solches Vorgehen wird häufig für Firewalls eingesetzt, welche ein Firmennetzwerk mit dem Internet verbinden.
Quellen & Weiterführendes
- Sehr gute Einführung in iptables
- Eine Firewall als Netzwerkbrücke
- Firewallcluster mit OpenBSD, pf und pf_sync
- Deutscher Wikipediaartikel zum Thema Firewall
- Statefull Failover für netfilter (ct_sync)
- Dokumentation von TuxGuadian
- IP-Tables Skripte fuer Single Host, SMB-Server und Router