Firewall - Versionsgeschichte

Gehrke: /* pfSense */

2015-01-11T14:59:34Z

‎pfSense

Gehrke: /* pfSense */ VPN-Funktionalität

2015-01-11T14:40:20Z

‎pfSense: VPN-Funktionalität

Gehrke: /* Grundsätze zur Gestaltung des Regelwerkes */ Formatierung

2013-11-24T14:52:35Z

‎Grundsätze zur Gestaltung des Regelwerkes: Formatierung

Gehrke: /* Grundsätze zur Gestaltung des Regelwerkes */ Rechtschreibung, interne Links und Formatierung - nichts inhaltliches

2013-11-23T22:29:27Z

‎Grundsätze zur Gestaltung des Regelwerkes: Rechtschreibung, interne Links und Formatierung - nichts inhaltliches

Gehrke: /* Die Firewall als Allheilmittel? */ Rechtschreibunk

2013-11-23T22:13:13Z

‎Die Firewall als Allheilmittel?: Rechtschreibunk

Gehrke: /* Firewall Builder */ interne Verlinkung

2013-11-23T21:42:41Z

‎Firewall Builder: interne Verlinkung

Gehrke: /* Open Source Firewalls */ Inhaltliche Erweiterung 'Firewall-Distributionen' / 'pfSense' - bitte um Review !

2013-11-23T21:41:11Z

‎Open Source Firewalls: Inhaltliche Erweiterung 'Firewall-Distributionen' / 'pfSense' - bitte um Review !

Gehrke: /* wipfw */

2013-11-23T21:26:31Z

‎wipfw

Gehrke: /* pf */

2013-11-23T21:25:41Z

‎pf

Gehrke: /* TuxGuardian */ interne Links

2013-11-23T21:21:43Z

‎TuxGuardian: interne Links

@@ Zeile 123: / Zeile 123: @@
 *[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:
+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 =

@@ Zeile 123: / Zeile 123: @@
 *[http://pfsense.org pfsense.org]
 *[http://de.wikipedia.org/wiki/Pfsense pfSense (Wikipedia)]
 = Wichtige Sicherheitshinweise zu Firewalls =

@@ Zeile 184: / Zeile 184: @@
 * 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. a'''lles 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 =

@@ Zeile 138: / Zeile 138: @@
 == 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ützlich 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.
+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 gefunde Regel an).
+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'''
@@ Zeile 146: / Zeile 146: @@
 * 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 Netzwerksegement nicht verlassen soll.'' (Anm.: 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 Broadcastpaket 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.)
+* Service: ''unterschiedlich, meist MS-RPC, RIP, NBT, eben alles, was als Broadcast geschickt wird und was das eigene Netzwerksegment nicht verlassen soll.''
 * 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.
+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.
@@ Zeile 158: / Zeile 160: @@
 * Quelle: IP-Adresse des Administrator PCs
 * 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
 * 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'''
@@ Zeile 172: / Zeile 174: @@
 * Ins Log schreiben? Ja
-Die sogenannte Stealthregel 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 Firewallsoftware eingesetzt wurde. Dadurch wird es schwieriger evtl. vorhandene Lücken und Bugs in der Firewallsoftware auszunutzen. Allerdings ist auch dies kein Allheilmittel. Dadurch, dass die Firewall nicht reagiert, weiß der Angreifer schonmal, dass höchstwahrscheinlich eine Firewall eingesetzt wird. Keine Antwort ist somit auch eine Antwort.
+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'''
@@ Zeile 182: / Zeile 184: @@
 * 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. a'''lles 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 =

@@ Zeile 128: / Zeile 128: @@
 == Die Firewall als Allheilmittel? ==
-Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt, öffnet man ja die Firewall und stetzt die dahinterliegenden 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.
+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.

@@ Zeile 111: / Zeile 111: @@
 === 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 ===

← Nächstältere Version		Version vom 23. November 2013, 21:41 Uhr
Zeile 116:		Zeile 116:

	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)]

	= Wichtige Sicherheitshinweise zu Firewalls =		= Wichtige Sicherheitshinweise zu Firewalls =

@@ Zeile 102: / Zeile 102: @@
 === 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 Möglich, MS Windows als echte Netzwerkfirewall einzusetzen. (Aber wer will das schon.)
+''[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 ==

@@ Zeile 99: / Zeile 99: @@
 === 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 ===

@@ 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.
-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 ===