Linupedia.org - Benutzerbeiträge [de]

Firewall

2008-11-24T09:40:59Z

Nbkr: /* Grundsätze zur Gestaltung des Regelwerkes */

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 [http://de.wikipedia.org/wiki/Netzwerksegment 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.

= 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 [http://de.wikipedia.org/wiki/Router 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 [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht 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 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.

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 anaylsieren 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 (Quelladdresse), wohin die Daten sollen (Zieladdresse), 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 expliziert 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ß das 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 drigenden Arztermin 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 ihrem Zustand 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.

=== TuxGuardian ===

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.

=== 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 ===
''[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 ==

=== 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 <code>/etc/sysconfig/SuSEfirewall2</code> 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. [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 ===

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.

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

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ü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.

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

'''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 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.)
* 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 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.

''' 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 =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

----
[[Security|zurück zur Security]]
[[Category:Security]]

Loginchecker

2008-03-28T23:53:42Z

Nbkr: Die Seite wurde neu angelegt: Das folgende kleine Script ermittelt wie lange ein Benutzer am heutigen Tag angemeldet war. Es überprüft dabei die vergangen Logins sowie die aktuelle Uptime für ein...

Das folgende kleine Script ermittelt wie lange ein Benutzer am heutigen Tag angemeldet war. Es überprüft dabei die vergangen Logins sowie die aktuelle Uptime für einen bestimmten
Benutzer. Das Script erwartet als Parameter zuerst den zu prüfenden Benutzernamen, dann die Loginkonsole. Bei einem System ist das üblicherweise tty7. Um zu testen wie lange der Benutzer
"nbkr" heute angemeldet war, gibt man einfach ein:

./loginchecker.sh nbkr tty7

Das Script gibt dann die Loginzeit in Minuten aus.
Hier das Script:

#! /bin/bash

#Setting some variables
MYUSER=$1
TTY=$2

######################################## DO NOT CHANGE ANYTHING BELOW ##################################################################
# Getting the login values of the user of this month
OVERALLTIME=0
for i in `last | grep -v still | grep ^$MYUSER | grep $TTY | sed 's/ //g' | grep "\`LANG=en_US date '+%b %d'\`" | cut -d ' ' -f 7 | sed 's/.*(//g' | grep -v - | sed 's/)//g'`; do

#Getting the minutes and transforming them to decimal values
MINUTES=${i#???}
MINUTES=`echo $MINUTES | sed 's/^0//g' `

#Getting the hours and transforming the to decimal values
TMP=${i#??}
HOURS=${i%$TMP}
HOURS=`echo $HOURS | sed 's/^0//g' `

let "TMPTIME=$HOURS*60 + $MINUTES"

let "OVERALLTIME=$OVERALLTIME + $TMPTIME"

done

# Calculating the current uptime
UPTIME=`last | grep still | grep ^$MYUSER | grep $TTY | sed 's/ //g' | cut -d ' ' -f 7 | sed 's/.*(//g' | grep -v - | sed 's/)//g'`

UMINUTES=${UPTIME#???}
UMINUTES=`echo $UMINUTES | sed 's/^0//g' `
TMP=${UPTIME#??}
UHOURS=${UPTIME%$TMP}
UHOURS=`echo $UHOURS | sed 's/^0//g' `

let "UPHOURS=` date +%H` - $UHOURS"

# Now we have to check if uphours is negative.
# This happens when a user logs in before midnight and is still
# online after midnight. If so we have to add the (negative) value
# to 24 * 60 to get the correct time.
if [[ $UPHOURS -lt 0 ]]; then
let "UPHOURS=24 * 60 + $UPHOURS"
fi

TMP=`date +%M`
TMP2=`echo $TMP | sed 's/^0//g'`
let "UPMINUTES=$UMINUTES - $TMP2"
let "TODAYTIME=$UPHOURS*60 - $UPMINUTES"

echo $(($OVERALLTIME + $TODAYTIME));

Konsole

2008-03-28T23:50:50Z

Nbkr:

== Linux-Club Wikibook ==

* [[Shell]] - Linux-Club Wikibook zur Shell. Hier lernt man den Umgang mit der Shell und erfährt viele Hintergründe.

==Allgemein==
* [[KDE Konsole]] - Bookmarks missbrauchen/Wie man 1001 Befehle sich sinnvoll als Bookmark-Liste anlegen kann. Diese Konsole läuft auch unter Gnome.
* [[ETerm]] - Transparente Konsole
* [[ATerm]] - Transparente Konsole
* [[ Software Installieren/Deinstallieren mit rpm ]] - Wie installiere oder entferne ich Software mit dem RedHat/Fedora/SuSE-Paketmanager '''rpm'''?
* [[ Software Installieren/Deinstallieren mit dpkg ]] - Wie installiere oder entferne ich Software mit dem Debian-Paketmanager '''dpkg'''?
* [[ Software Installieren/Deinstallieren mit rug ]] - Wie Installiere oder entferne ich Software mit '''rug''', dem Kommandozeilen-Frontend des ZENworks Daemon?
* [[Zypper]] - Wie Installiere oder entferne ich Software mit '''zypper''', dem Kommandozeilen-Frontend von YaST (Paketmanager)?
* [[ Software aus dem Quelltext Installieren/Deinstallieren ]]- Wie installiere ich Software aus dem '''Quelltext'''? Wie entferne ich selbst kompilierte Software wieder?
* [[automatische Vervollstaendigung in bash erweitern]]
* [[FAQ Linux/Unix Konsolen Befehle]]
* [[Systemueberwachung mit sysstat]]
* [[Ausgaben waehrend des Logins anpassen]]
* [[: Kopie der root Partition]]
* [[Imageerstellung mit dd und ddrescue]] - Festplattenimageerstellung und simple Datensicherung mit dd
* [[Virtuelles (CD) Laufwerk unter Linux]] - Noch ein Weg "virtuelle CD/DVD Laufwerke" zu erstellen und zu nutzen
* [[Linux mit hdparm beschleunigen]]
* [[root - Passwort vergessen]]
* [[Farbe in der Konsole]]
* [[Rechte auf Dateien und Ordner getrennt vergeben]]
* [[CheckInstall]]
* [[Fehlermeldung]]
* [[loginchecker]] - Ein Script um zu überprüfen wie lange ein Benutzer heute angemeldet war.

==Shells==
* [[Shells - Allgemeines|Allgemeines zu Shells]]
* [[Bash]]
* [[Bashprogrammierung]]
* [[ssh innerhalb einer while-Schleife]]
* [[Csh]]
* [[Csh-Programmierung]]
* [[Ksh]]
* [[Ksh-Programmierung|Die Programmierung der Ksh]]
* [[Shell]]

==Unixwerkzeuge==
* [[Awk]]
* [[emacs]]
* [[Grep]]
* [[Make]]
* [[Reguläre Ausdrücke]]
* [[Sed]]
* [[Vi]]

== Suse Linux mit OS X ==

* [[Von Suse Linux per Konsole auf OS X]]
* [[Unsichtbare Dateien auf einer USBplatte löschen]]

== Scripte ==

* [[ Shellscripte]] - kleinere Shellscripte für die Konsolennutzung
* [[Perlscripte]] - kleinere Perlscripte u.a. für die Konsole
* [[Benutzerverwaltung per Script]]

== Konsolen "Erweiterungen" ==
* [[quadkonsole]] - mehrere Konsolen in einem Fenster
* [[screen]] - "Terminal Multiplexer", das Tool schlechthin, vor allem für ssh Nutzer
* [[yakuake]] - "Terminal Emulator", Konsole auf Tastendruck zum schnellen Öffnen und Schließen

== Weiterführende Links ==

* [http://www.bin-bash.de/index.php /bin/bash - Treffpunkt für Linux-Shelluser -] Gute Seite für den Konsolen-Einstieg
* [http://www.bash-hackers.org/ Bash-Hackers] - Einsteigsseite für ein Bash Programmierer Wiki und Bash Programmierer Forum
[[Category:Konsole]]
[[Kategorie:Übersicht]]

Webseiten beschleunigen mit mod cache

2008-02-25T08:51:31Z

Nbkr: Die Seite wurde neu angelegt: Der Apache lässt sich bekanntermaßen durch viele Module erweitern. Eines davon ist "mod_cache". Damit lassen sich dynamisch generiete Inhalte, wie sie z.B. Content Ma...

Der Apache lässt sich bekanntermaßen durch viele Module erweitern. Eines davon ist "mod_cache". Damit lassen sich dynamisch generiete Inhalte, wie sie z.B. Content Management Systeme generieren, zwischenspeichern. Dies sorgt für eine deutliche Verzögerung der Auslieferungszeiten. Im nachfolgenden Artikel zeigen wir Ihnen wie man dem Apache das Caching beibringt.

Seit Apacheversion 2.2.x gilt mod_cache offiziell als stabil und seine Verwendung im produktiven Umfeld wird empfohlen. Die meisten Linuxdistributionen liefern mod_cache schon seit einiger Zeit mit. Die Installation wird in diesem Artikel anhand von Ubuntu Linux 7.10 erklärt. Prinzipiell ist die Anleitung aber auch auf andere Distributionen anwendbar.

Zwar liefert Ubuntu 7.10 mod_cache zusammen mit dem Apache 2.2 bereits mit, allerdings ist es zunächst noch deaktiviert. Zur Aktivierung erstellt man einfach passende Symlinks im Verzeichnis /etc/apache2/mods-enabled/.
sudo ln -s /etc/apache2/mods-available/cache.load /etc/apache2/mods-enabled
sudo ln -s /etc/apache2/mods-available/disk_cache.* /etc/apache2/mods-enabled

Startet man den Apache nun mittels sudo /etc/init.d/apache2 restart, verfügt der Apache über Cachingfähigkeiten.

Jetzt muss man noch konfigurieren was der Apache cachen soll und wohin die Daten gespeichert werden soll.

Hierzu sucht man sich den passenden <Virtualhost> Abschnitt der Apacheconfiguration heraus und fügt folgends hinzu:
CacheEnable disk /
CacheRoot /var/cache/apache2/vhostX/

CacheRoot gibt dabei an wohin der Apache die gecachten Daten speichern soll. Diese Verzeichniss muss natürlich für den Apache beschreibbar sein. Damit der Apache die Festplatte des Servers nicht mit Daten überfrachtet sollte man dafür sorgen das der Cache regelmäßig zurückgestutzt wird. Hierfür kommt das Programm htcacheclean zum Einsatz. Diese kann man z.B. über einen Cronjob regelmäßig ausführen lassen. Es reduziert die Größe des Caches auf den angegeben Wert. Folgender Aufruf würde z.B. den Cache unter /var/cache/apache2/vhostX/ auf 100 MB geschränken.
htcacheclean -p /var/cache/apche2/vhostX/ -l 100M

Nach einem erneuten Neuladen des Apache fängt dieser Automatisch an die Daten zu cachen. Allerdings wird er bisher nur reine HTML Seiten und Grafiken cachen. Das bringt keinen wirklichen Performancegewinn. PHP Seiten wirden bisher noch nicht gecacht, da der Apache nicht ermitteln kann wann eine entsprechende Seite zuletzt bearbeitet wurde.

Diese Information geht nämlich nach dem Durchlauf der PHP Datei durch den PHP Compiler / Interpreter verloren. Um trotzdem ein Caching zu erreichen muss man diese Information manuell ausgeben. Dies ist der Punkt an dem es knifflig wird. Zwar ist es recht einfach einen "Last Modified" Header per PHP zu senden (siehe weiter im Artikel), allerdings ist es gar nicht so einfach zu ermitteln wann eine PHP Seite sich geändert hat.

Bei einer PHP Seite die hauptsächlich statischen Content enthält und nur Teile des Layout, wie z.B. das Menü, per include nachlädt ist das noch recht einfach. Man nimmt einfach das Änderungsdatum der Datei. In PHP kann man das mit fileatime ermitteln.

Bei einer PHP Seite die Daten aus einer Datenbank lädt, wie z.B. das Script das für das Anzeigen dieses Artikels verantwortlich ist, wird das schon nicht mehr so einfach. Der Content ändert sich zwar mit jedem neuen Datensatz in der Datenbank, die eigentliche Datei aber nicht. In diesem Fall ist es angebracht z.B. das Datum des Artikels als Änderungsdatum zu nehmen.

Hat man schlussendlich herausgefunden, wie man das Änderungsdatum definiert kann man es nun dem Apache mitteilen:
<?php
header('Last-Modified: '.gmdate('D, d M Y H:i:s', $last_mod) . ' GMT');
?>

Hierbei ist $last_mod das Änderungsdatum im Unixtimestamp-Format.

Darüber hinaus ist es natürlich auch noch sinnvoll dem Apache mitzuteilen wie alt seine Kopie der Seite maximal sein darf bevor er eine aktuelle Version anfordern muss. Dies funktioniert über den Max-Age Header
<?php header('Cache-Control: public,max-age=' . (3600 * 168)); ?>

Die Angabe (3600 * 168) bedeutet in diesem Fall eine maximales Alter von einer Woche.

Sobald dies in den PHP Dateien enthalten ist, cacht der Apache auch PHP Dateien. Je nachdem wie komplex eine PHP Datei ist, kann man mit dieser Methode die Auslieferungszeit um ca. 30% erhöhen.

== Quelle ==
* http://www.pgk-dienstleistungen.de/de/blog/e/Webseiten__beschleunigen__mit__mod_cache

LAMP

2008-02-25T08:49:13Z

Nbkr: /* Allgemein */

== Allgemein ==

* [[Apache]]
* [[Apache mit LDAP]] - Einrichtung einer Authentifizierung von Benutzern am Apache über eine zentrale Benutzerverwaltung mit LDAP
* [[XAMPP]]
* [[iCalendar mit WebDAV]] - Den Sunbird/Lightning-Kalender auf mehreren Rechnern nutzen
* [[Virtual Host mit Yast konfigurieren]]
* [[Das Apache-Modul mod_rewrite]] - Hier gibt es etliche Links zu dem Thema - Ist allerdings sehr Joomlalastig, da es auch [[Joomla/Links]] eingebunden ist.
* [[Webseiten beschleunigen mit mod_cache]]

== Musterkonfigurationen ==

* [[Apache Musterkonfigurationen]]
* [[VirtualHosts Musterkonfigurationen]]
* [[Errordocument Musterkonfigurationen]]
* [[htaccess SEO URL Musterkonfigurationen]]
Auf Joomla bezogen, da es in [[Joomla/Links]] integriert ist.
* [[htaccess Zugangsregelung]]

[[Category:LAMP]][[Kategorie:Übersicht]]

Firewall

2007-05-22T17:48:45Z

Nbkr:

{{Wettbewerb}}

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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet, die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= 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 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet _meistens_ im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht 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-4 Firewalls kann eine Firewall auch im Layer 2, also bereits im Data Link Layer aktiv sein. Eine solche Firewall filtert dann nicht mehr an Hand von IP Adressen, sondern an Hand von MAC Adressen. Solche Bridgefirewalls 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 wäre.

== 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, in dem 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 das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert man dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall 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 Applicationlayerfirewall 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, in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurde (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung expliziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird, wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall, die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindungen anhand ihrem Zustand zu zulassen oder zu 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin 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. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

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 wie wenn 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. PC 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 das 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ü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.

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB, eben alles was als Broadcast geschickt wird und was das eigene Netzwerksegement 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* 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.

''' 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

----
[[Security|zurück zur Security]]
[[Category:Security]]

Policy Based Routing

2007-05-22T17:33:51Z

Nbkr:

{{Wettbewerb}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten also keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheidet sich stark von den bisher eingesetzten Routingmöglichkeiten, bei welchen ein Router nur an Hand des Zieles, eines Datenpaketes entscheidet, an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtigt und dann entscheidet was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welches zuverlässig, aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden, ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden, ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamisches Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgend sowohl die Begriffe Router und Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist dies für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen: Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden, ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traf der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei eine klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert dieses Konzept nun folgendermaßen: Statt einer Routingtabelle gibt es gleich Mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann, was der Next Hop für ein bestimmtes Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen, in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen, wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutrifft, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zum nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "nummerischen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

==== Wie man Regeln und Routen anlegt ====

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts, wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu:

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0

Das a.b.c.d soll das Ziel darstellen, welches man in der Realität natürlich durch eine echte IP Adresse ersetzen muss. "via 192.168.1.1" stellt natürlich den Next Hop da und dev ra0 bezeichnet die Netzwerkkarte. Mit "table 2" bestimmt man das die Route der Tabelle 2 hinzugefügt werden soll.

Nun kann man sich die Routingtabelle auch ansehen:

ip route list table 2
a.b.c.d via 192.168.1.1 dev ra0

Übrigens sollte man sich beim Anlegen einer Route vertippt haben sollen, kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:

ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0

Auch ein ändern einer bestehenden Regel wäre möglich:

ip route change a.b.c.d table 2 via 192.168.1.1 dev ra0 via 192.168.1.2

Damit wäre nicht 192.168.1.1 der Next Hop sondern 192.168.1.2.

==== Beispielhafte Konfiguration - Unterschiedliches Routing für verschiedene Dienste ====

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man, dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Balast darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0 (tun0 ist das VPN Interface).

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports anhand unterschiedlicher Routingtabellen geroutet. Das war es was _im Prinzip_ wir erreichen wollten. Einige Hinweise noch: Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

Nun muss man noch die Routingtabellen 2 und 3 anlegen bzw. füllen. Dies geht so:

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0
ip route add a.b.c.d table 3 via 10.0.0.10 dev tun0

Die erste Zeile fügt der Tabelle 2 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d an 192.168.1.1 über das Interface ra0 geschickt werden.

Die zweite Zeile fügt der Tabelle 3 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d. an 10.0.0.10 über das Interface tun0 geschickt werden.

Das war es was erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.

== Abschlussbemerkung ==

Ich hoffe die Grundlagen von Policy Based Routing mit Linux konnte ich in diesem Artikel erläutern. Natürlich sind nicht alle Möglichkeiten von PBR ausgeschöpft. Allein ip und iptables bieten schier unendlich viele Möglichkeiten, deren komplette Auflistung den Rahmen dieses Artikels bei weitem sprengen würden. Falls noch Fragen zum Thema offen sind stehe ich gerne für Antworten bereit. Meine Kontaktdaten finden sich auf meiner Homepage: http://www.benjaminfleckenstein.de

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

----

[[Netzwerk|zurück zum Netzwerk]][[Category:Netzwerkgrundlagen]]

Policy Based Routing

2007-05-22T09:30:51Z

Nbkr:

{{Wettbewerb}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamisches Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

==== Wie man Regeln und Routen anlegt ====

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu.

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0

Das a.b.c.d soll das Ziel darstellen, welches man in der Realität natürlich durch eine echte IP Adresse ersetzen muss. "via 192.168.1.1" stellt natürlich den Next Hop da und dev ra0 bezeichnet die Netzwerkkarte. Mit "table 2" bestimmt man das die Route der Tabelle 2 hinzugefügt werden soll.

Nun kann man sich die Routingtabelle auch ansehen:

ip route list table 2
a.b.c.d via 192.168.1.1 dev ra0

Übrigens sollte man sich beim Anlegen einer Router vertippt haben sollen kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:

ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0

Auch ein ändern einer bestehenden Regel wäre möglich:

ip route change a.b.c.d table 2 via 192.168.1.1 dev ra0 via 192.168.1.2

Damit wäre nicht 192.168.1.1 der Next Hop sondern 192.168.1.2.

==== Beispielhafte Konfiguration - Unterschiedliches Routing für verschiedene Dienste ====

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Balast darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0 (tun0 ist das VPN Interface).

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports anhand unterschiedlicher Routingtabellen geroutet. Das war es was _im Prinzip_ wir erreichen wollten. Einige Hinweise noch: Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

Nun muss man noch die Routingtabellen 2 und 3 anlegen bzw. füllen. Dies geht so:

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0
ip route add a.b.c.d table 3 via 10.0.0.10 dev tun0

Die erste Zeile fügt der Tabelle 2 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d an 192.168.1.1 über das Interface ra0 geschickt werden.

Die zweite Zeile fügt der Tabelle 3 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d. an 10.0.0.10 über das Interface tun0 geschickt werden.

Das war es war erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.

== Abschlussbemerkung ==

Ich hoffe die Grundlagen von Policy Based Routing mit Linux konnte ich in diesem Artikel erläutern. Natürlich sind nicht alle Möglichkeiten von PBR ausgeschöpft. Allein ip und iptables bieten schier unendlich viele Möglichkeiten, deren komplette Auflistung den Rahmen dieses Artikels bei weitem sprengen würden. Falls noch Fragen zum Thema offen sind stehe ich gerne für Antworten bereit. Meine Kontaktdaten finden sich auf meiner Homepage: http://www.benjaminfleckenstein.de

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

----

[[Netzwerk|zurück zum Netzwerk]][[Category:Netzwerkgrundlagen]]

Firewall

2007-05-22T09:30:30Z

Nbkr:

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet, die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= 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 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet _meistens_ im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht 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-4 Firewalls kann eine Firewall auch im Layer 2, also bereits im Data Link Layer aktiv sein. Eine solche Firewall filtert dann nicht mehr an Hand von IP Adressen, sondern an Hand von MAC Adressen. Solche Bridgefirewalls 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 wäre.

== 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, in dem 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 das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall 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 Applicationlayerfirewall 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, in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 das 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ü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.

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB, eben alles was als Broadcast geschickt wird und was das eigene Netzwerksegement 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

----
[[Security|zurück zur Security]]
[[Category:Security]]

Policy Based Routing

2007-05-22T05:57:50Z

Nbkr:

{{Wettbewerb}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamisches Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

==== Wie man Regeln und Routen anlegt ====

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu.

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0

Das a.b.c.d soll das Ziel darstellen, welches man in der Realität natürlich durch eine echte IP Adresse ersetzen muss. "via 192.168.1.1" stellt natürlich den Next Hop da und dev ra0 bezeichnet die Netzwerkkarte. Mit "table 2" bestimmt man das die Route der Tabelle 2 hinzugefügt werden soll.

Nun kann man sich die Routingtabelle auch ansehen:

ip route list table 2
a.b.c.d via 192.168.1.1 dev ra0

Übrigens sollte man sich beim Anlegen einer Router vertippt haben sollen kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:

ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0

Auch ein ändern einer bestehenden Regel wäre möglich:

ip route change a.b.c.d table 2 via 192.168.1.1 dev ra0 via 192.168.1.2

Damit wäre nicht 192.168.1.1 der Next Hop sondern 192.168.1.2.

==== Beispielhafte Konfiguration - Unterschiedliches Routing für verschiedene Dienste ====

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Balast darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0 (tun0 ist das VPN Interface).

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports anhand unterschiedlicher Routingtabellen geroutet. Das war es was _im Prinzip_ wir erreichen wollten. Einige Hinweise noch: Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

Nun muss man noch die Routingtabellen 2 und 3 anlegen bzw. füllen. Dies geht so:

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0
ip route add a.b.c.d table 3 via 10.0.0.10 dev tun0

Die erste Zeile fügt der Tabelle 2 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d an 192.168.1.1 über das Interface ra0 geschickt werden.

Die zweite Zeile fügt der Tabelle 3 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d. an 10.0.0.10 über das Interface tun0 geschickt werden.

Das war es war erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.

== Abschlussbemerkung ==

Ich hoffe die Grundlagen von Policy Based Routing mit Linux konnte ich in diesem Artikel erläutern. Natürlich sind nicht alle Möglichkeiten von PBR ausgeschöpft. Allein ip und iptables bieten schier unendlich viele Möglichkeiten, deren komplette Auflistung den Rahmen dieses Artikels bei weitem sprengen würden. Falls noch Fragen zum Thema offen sind stehe ich gerne für Antworten bereit. Meine Kontaktdaten finden sich auf meiner Homepage: http://www.benjaminfleckenstein.de

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

[[Netzwerk|zurück zum Netzwerk]][[Category:Netzwerkgrundlagen]]

Diskussion:Policy Based Routing

2007-05-22T05:55:56Z

Nbkr:

Es wäre sinnvoll den Artikel nach "Policy Based Routing" zu verschieben, da mit Linux im Linux Wiki wohl überflüssig ist. --[[Benutzer:Yehudi|Yehudi]] 19:40, 20. Mai 2007 (CEST)

----
Andereseits macht das "mit Linux" deutlich dass es auch um die Konfiguration von PBR unter Linux geht und es sich nicht nur um einen allgemeinen Artikel zum Thema PBR handelt. Findest Du nicht?

--[[Benutzer:Nbkr|Nbkr]] 07:55, 22. Mai 2007 (CEST)

Benutzer:Nbkr

2007-05-22T05:54:37Z

Nbkr: /* Wikilinks für mich */

== Wer ich bin? ==
http://www.benjaminfleckenstein.de

== Wikilinks für mich ==

* [[Firewall]]
* [[Policy Based Routing mit Linux]]

Diskussion:Firewall

2007-05-22T05:54:07Z

Nbkr:

Hallo nbkr,

schön, dass Du beim Wettbewerb teilnimmst. füge doch bitte unten am Fuß noch die Kategorie ein:

<nowiki>----

[[Security|zurück zur Security]]
[[Category:Security]]</nowiki>

Ich wünsche Dir noch viel Erfolg.

--[[Benutzer:Yehudi|Yehudi]] 18:18, 16. Mai 2007 (CEST)

----
Danke! Die Links sind drin.
--[[Benutzer:Nbkr|Nbkr]] 07:54, 22. Mai 2007 (CEST)

Diskussion:Firewall

2007-05-22T05:53:42Z

Nbkr:

Firewall

2007-05-22T05:53:10Z

Nbkr:

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet, die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= 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 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet _meistens_ im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht 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-4 Firewalls kann eine Firewall auch im Layer 2, also bereits im Data Link Layer aktiv sein. Eine solche Firewall filtert dann nicht mehr an Hand von IP Adressen, sondern an Hand von MAC Adressen. Solche Bridgefirewalls 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 wäre.

== 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, in dem 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 das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall 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 Applicationlayerfirewall 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, in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 das 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ü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.

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB, eben alles was als Broadcast geschickt wird und was das eigene Netzwerksegement 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

[[Security|zurück zur Security]]
[[Category:Security]]

Firewall

2007-05-21T12:06:25Z

Nbkr: Typos

Firewall

2007-05-21T12:00:35Z

Nbkr: /* Netzwerkfirewall */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet _meistens_ im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO/OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

Neben diesen Layer-4 Firewalls kann eine Firewall auch im Layer 2, also bereits im Data Link Layer aktiv sein. Eine solche Firewall filtert dann nicht mehr an Hand von IP Adressen sondern an Hand von MAC Adressen. Solche Bridgefirewalls werden in aller Regel nicht 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 wäre.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 das 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ü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.

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB, eben alles was als Broadcast geschickt wird und was das eigene Netzwerksegement 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-21T11:50:53Z

Nbkr: /* Netzwerkfirewall */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO/OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 das 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ü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.

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB, eben alles was als Broadcast geschickt wird und was das eigene Netzwerksegement 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Policy Based Routing

2007-05-20T17:30:59Z

Nbkr: /* Die Praxis */

{{Wettbewerb}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamisches Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

==== Wie man Regeln und Routen anlegt ====

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu.

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0

Das a.b.c.d soll das Ziel darstellen, welches man in der Realität natürlich durch eine echte IP Adresse ersetzen muss. "via 192.168.1.1" stellt natürlich den Next Hop da und dev ra0 bezeichnet die Netzwerkkarte. Mit "table 2" bestimmt man das die Route der Tabelle 2 hinzugefügt werden soll.

Nun kann man sich die Routingtabelle auch ansehen:

ip route list table 2
a.b.c.d via 192.168.1.1 dev ra0

Übrigens sollte man sich beim Anlegen einer Router vertippt haben sollen kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:

ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0

Auch ein ändern einer bestehenden Regel wäre möglich:

ip route change a.b.c.d table 2 via 192.168.1.1 dev ra0 via 192.168.1.2

Damit wäre nicht 192.168.1.1 der Next Hop sondern 192.168.1.2.

==== Beispielhafte Konfiguration - Unterschiedliches Routing für verschiedene Dienste ====

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Balast darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0 (tun0 ist das VPN Interface).

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports anhand unterschiedlicher Routingtabellen geroutet. Das war es was _im Prinzip_ wir erreichen wollten. Einige Hinweise noch: Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

Nun muss man noch die Routingtabellen 2 und 3 anlegen bzw. füllen. Dies geht so:

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0
ip route add a.b.c.d table 3 via 10.0.0.10 dev tun0

Die erste Zeile fügt der Tabelle 2 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d an 192.168.1.1 über das Interface ra0 geschickt werden.

Die zweite Zeile fügt der Tabelle 3 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d. an 10.0.0.10 über das Interface tun0 geschickt werden.

Das war es war erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.

== Abschlussbemerkung ==

Ich hoffe die Grundlagen von Policy Based Routing mit Linux konnte ich in diesem Artikel erläutern. Natürlich sind nicht alle Möglichkeiten von PBR ausgeschöpft. Allein ip und iptables bieten schier unendlich viele Möglichkeiten, deren komplette Auflistung den Rahmen dieses Artikels bei weitem sprengen würden. Falls noch Fragen zum Thema offen sind stehe ich gerne für Antworten bereit. Meine Kontaktdaten finden sich auf meiner Homepage: http://www.benjaminfleckenstein.de

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

Policy Based Routing

2007-05-20T17:29:41Z

Nbkr:

{{Wettbewerb}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamisches Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

==== Wie man Regeln anlegt ====

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu.

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0

Das a.b.c.d soll das Ziel darstellen, welches man in der Realität natürlich durch eine echte IP Adresse ersetzen muss. "via 192.168.1.1" stellt natürlich den Next Hop da und dev ra0 bezeichnet die Netzwerkkarte. Mit "table 2" bestimmt man das die Route der Tabelle 2 hinzugefügt werden soll.

Nun kann man sich die Routingtabelle auch ansehen:

ip route list table 2
a.b.c.d via 192.168.1.1 dev ra0

Übrigens sollte man sich beim Anlegen einer Router vertippt haben sollen kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:

ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0

Auch ein ändern einer bestehenden Regel wäre möglich:

ip route change a.b.c.d table 2 via 192.168.1.1 dev ra0 via 192.168.1.2

Damit wäre nicht 192.168.1.1 der Next Hop sondern 192.168.1.2.

==== Beispielhafte Konfiguration 1 - Unterschiedliches Routing für verschiedene Dienste ====

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Overhead darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0.

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports anhand unterschiedlicher Routingtabellen geroutet. Das war es was _im Prinzip_ wir erreichen wollten. Einige Hinweise noch: Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

Nun muss man noch die Routingtabellen 2 und 3 anlegen bzw. füllen. Dies geht so:

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0
ip route add a.b.c.d table 3 via 10.0.0.10 dev tun0

Die erste Zeile fügt der Tabelle 2 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d an 192.168.1.1 über das Interface ra0 geschickt werden.

Die zweite Zeile fügt der Tabelle 3 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d. an 10.0.0.10 über das Interface tun0 geschickt werden.

Das war es war erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.

== Abschlussbemerkung ==

Ich hoffe die Grundlagen von Policy Based Routing mit Linux konnte ich in diesem Artikel erläutern. Natürlich sind nicht alle Möglichkeiten von PBR ausgeschöpft. Allein ip und iptables bieten schier unendlich viele Möglichkeiten, deren komplette Auflistung den Rahmen dieses Artikels bei weitem sprengen würden. Falls noch Fragen zum Thema offen sind stehe ich gerne für Antworten bereit. Meine Kontaktdaten finden sich auf meiner Homepage: http://www.benjaminfleckenstein.de

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

Policy Based Routing

2007-05-20T17:26:32Z

Nbkr: /* Die Praxis */

{{Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamisches Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

==== Wie man Regeln anlegt ====

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Folgendermaßen fügt man eine Route einer Tabelle zu.

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0

Das a.b.c.d soll das Ziel darstellen, welches man in der Realität natürlich durch eine echte IP Adresse ersetzen muss. "via 192.168.1.1" stellt natürlich den Next Hop da und dev ra0 bezeichnet die Netzwerkkarte. Mit "table 2" bestimmt man das die Route der Tabelle 2 hinzugefügt werden soll.

Nun kann man sich die Routingtabelle auch ansehen:

ip route list table 2
a.b.c.d via 192.168.1.1 dev ra0

Übrigens sollte man sich beim Anlegen einer Router vertippt haben sollen kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:

ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0

Auch ein ändern einer bestehenden Regel wäre möglich:

ip route change a.b.c.d table 2 via 192.168.1.1 dev ra0 via 192.168.1.2

Damit wäre nicht 192.168.1.1 der Next Hop sondern 192.168.1.2.

==== Beispielhafte Konfiguration 1 - Unterschiedliches Routing für verschiedene Dienste ====

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Overhead darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0.

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports anhand unterschiedlicher Routingtabellen geroutet. Das war es was _im Prinzip_ wir erreichen wollten. Einige Hinweise noch: Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

Nun muss man noch die Routingtabellen 2 und 3 anlegen bzw. füllen. Dies geht so:

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0
ip route add a.b.c.d table 3 via 10.0.0.10 dev tun0

Die erste Zeile fügt der Tabelle 2 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d an 192.168.1.1 über das Interface ra0 geschickt werden.

Die zweite Zeile fügt der Tabelle 3 ein Eintrag hinzu, wodurch alle Daten für das Ziel a.b.c.d. an 10.0.0.10 über das Interface tun0 geschickt werden.

Das war es war erreicht werden soll. Dank iptables und ip werden Pakete mit dem gleichen Ziel, aber unterschiedlichen Protokollen auch unterschiedlich geroutet. SMTP wird über die sichere VPN Verbindung geschickt, HTTPS über das normale Internet. Das alles ohne das die Clients im Netzwerk davon etwas mitbekommen.

== Abschlussbemerkung ==

Ich hoffe die Grundlagen von Policy Based Routing mit Linux konnte ich in diesem Artikel erläutern. Natürlich sind nicht alle Möglichkeiten von PBR ausgeschöpft. Allein ip und iptables bieten schier unendlich viele Möglichkeiten, deren komplette Auflistung den Rahmen dieses Artikels bei weitem sprengen würden. Falls noch Fragen zum Thema offen sind stehe ich gerne für Antworten bereit. Meine Kontaktdaten finden sich auf meiner Homepage: http://www.benjaminfleckenstein.de

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

Policy Based Routing

2007-05-20T17:16:09Z

Nbkr:

{{Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamisches Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Overhead darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0.

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports anhand unterschiedlicher Routingtabellen geroutet. Das war es was _im Prinzip_ wir erreichen wollten. Einige Hinweise noch: Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

Nun kann man also Regeln setzten wie man möchte. Allerdings wurde noch mit keinem Wort erwähnt mit man nun die Routingtabellen wirklich füllt. Keine Sorge das folgt jetzt:

Die Regelliste ist logischerweise nur die halbe Miete, denn damit kann man zwar sagen welche Routingtabelle genutzt werden soll, allerdings nützt einem dies gar nichts wenn die ganzen Routingtabellen leer sind. Diese muss man auch noch erstellen und füllen. Dies funktioniert auch mit "ip". Bleiben wir im Beispiel mit dem fwmark, welches als letztes erwähnt wurde. Hier kommen zwei Routingtabellen zum Einsatz, Nr. 2 und Nr. 3. Bisher gibt es diese Tabellen noch gar nicht, ergo würde das Routing noch nicht wirklich funktionieren. Wir müssen die beiden Tabellen erstellen.
Fangen wir mit Nr. 2 an. Diese soll wie gesagt die Daten über das Internet routen. Für das Ziel a.b.c.d. ist in diesem Fall der Next Hop der Router mit der IP 192.168.1.1 welcher sich über das Interface ra0 erreichen lässt.
Um dieses zu realisieren muss man folgendes eingeben.

ip route add a.b.c.d table 2 via 192.168.1.1 dev ra0

Das via 192.168.1.1 stellt natürlich den Next Hop da und dev ra0 bezeichnet die Netzwerkkarte.
Nun noch die Tabelle Nr. füllen. Dies soll für das gleiche Ziel (a.b.c.d) den Next Hop 10.0.0.10 nehmen welcher sich über das Interface tun0 erreichen lässt:

ip route add a.b.c.d table 3 via 10.0.0.10 dev tun0

Nun noch schnell anzeigen lassen ob das ganze geklappt hat:

ip route list table 2
a.b.c.d via 192.168.1.1 dev ra0

ip route list table 3
a.b.c.d via 10.0.0.10 dev tun0

Prima, hat geklappt. Das Policy Based Routing für unser kleines Beispiel sollte jetzt funktionieren. Mails werden über die VPN Verbindung verschickt, https Verkehr läuft über das Internet. Das alles ohne das die Clients im Netzwerk etwas merken!

Übrigens sollte man sich beim Anlegen einer Router vertippt haben sollen kann man die Route natürlich auch wieder löschen. So würde man die erste Route löschen:

ip route del a.b.c.d table 2 via 192.168.1.1 dev ra0

Auch ein ändern einer bestehenden Regel wäre möglich:

ip route change a.b.c.d table 2 via 192.168.1.1 dev ra0 via 192.168.1.2

Damit wäre nicht 192.168.1.1 der Next Hop sondern 192.168.1.2.

== Abschlussbemerkung ==

Ich hoffe die Grundlagen von Policy Based Routing mit Linux konnte ich in diesem Artikel erläutern. Natürlich sind nicht alle Möglichkeiten von PBR ausgeschöpft. Allein ip und iptables bieten schier unendlich viele Möglichkeiten, deren komplette Auflistung den Rahmen dieses Artikels bei weitem sprengen würden. Falls noch Fragen zum Thema offen sind stehe ich gerne für Antworten bereit. Meine Kontaktdaten finden sich auf meiner Homepage: http://www.benjaminfleckenstein.de

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

Policy Based Routing

2007-05-20T16:54:18Z

Nbkr:

{{Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamische Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wenn man sich nun die Liste wieder ansieht erhält man dies:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Unsere Regel steht zweimal drin. Das war eigentlich nicht beabsichtigt, ist aber kein Problem, man kann Regeln natürlich wieder löschen, und zwar so:

ip rule del from 192.168.1.17 prio 32765 table 17

Nun sollte die Regelliste wieder so aussehen:

0: from all lookup local
2: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serviceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Overhead darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0.

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports unterschiedlich geroutet. Das war es was wir erreichen wollten. Einige Hinweise noch zum Schluss. Es macht keinen Sinn die Markierung erst in der POSTROUTING-Kette zu setzen. Wie der Name schon sagt wurde die Routingentscheidung ja schon getroffen bevor die POSTROUTING-Kette durchlaufen wird. ip würde von der gesetzten Marke also längst nichts mehr mitbekommen.

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

Policy Based Routing

2007-05-20T16:46:42Z

Nbkr:

{{Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamische Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==
=== Voraussetzungen ===
Damit PBR unter Linux funktioniert, muss der Kernel dies unterstützen. Die Kernel der größeren Distributionen sind heute standardmäßig mit den notwendigen Optionen übersetzt worden, so dass man sich nicht selbst darum kümmern muss. Wer seinen Kernel selbst kompiliert sollte darauf achten, dass CONFIG_IP_ADVANCED_ROUTER und CONFIG_IP_MULTIPLE_TABLES auf "y" gesetzt sind.

Des Weiteren benötigt man das Programm "ip" welches sich, je nach Distribution, im Paket "iproute" bzw. "iproute2" befindet. Dieses Programm wird heute meist automatisch bei der Installation mitgeliefert, so dass man es in den seltensten Fällt nachinstallieren muss.

=== Prinzip (oder: Erklär mir wie es funktioniert, ohne mir die Sourcecodekommentare zu zeigen) ===
Wie muss man sich das Policy Based Routing technisch vorstellen?

Vorweg eine kurze Anmerkung. Ich verwende nachfolgende sowohl Router als Firewall gleichwertig. Zwar kann eine Firewall mehr als ein Router, allerdings ist diese mehr für das Policy Based Routing vorerst nicht von Interesse.

Das klassische Destination-Based Routing arbeitet folgendermaßen. Ein Datenpaket erreicht den Router/Firewall und durchläuft erstmal die PreRouting-Tabelle des Firewallsystems (vergleiche: http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png). Unter Umständen kann das Paket hier verändert werden. Dies erläutere ich später noch genauer. Nach der PreRouting-Tabelle steht die Routing Entscheidung an. D.h. der Router muss nun entscheiden ob und wohin das Paket weitergeleitet werden muss. Diese Entscheidung traff der Router bisher anhand einer Tabelle, der sogenannten Routing Tabelle. In dieser Tabelle stand nur drin, was der Next Hop, also der nächste Weiterleitungspunkt für ein Paket mit einem bestimmten Ziel ist. Anbei ein klassische Routingtabelle:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0
192.168.181.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
172.16.143.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 ra0

Das Policy Based Routing erweitert diese Konzept nun folgendermaßen. Statt einer Routingtabelle gibt es gleich mehrere. root kann sogar eigene Tabellen anlegen. Jede Tabelle hat eigene Einträge wie bei sie auch die klassiche Routingtabelle hat. Der Router hat nun also mehrere Tabellen in denen er nachschauen kann was der Next Hop für ein bestimmtest Ziel hat. Soweit, sogut, jedoch muss der Router nun noch wissen in welcher der vielen neuen Tabellen er jetzt tatsächlich nachschauen muss.

Hier kommt ein Rule List (= Regel Liste) ins Spiel. Innerhalb dieser Liste steht in welcher Routingtabelle der Router nachschauen soll. Als Kriterium kommen bestimmte Eigenschaften des Datenpaketes in Frage, wie Quell-IP, Type of Service, Firewall Remark oder auch das Netzwerkinterface über welches das Paket reinkam.

Auf gut Deutsch kann in der Liste also drin stehen:

Wenn ein Paket von 192.168.2.17 kommt, dann siehe in Routing Tabelle 5 nach.

Natürlich steht das nicht wirklich so drin. Eine echte Rulelist sieht so aus:

0: from all lookup local
2000: from all lookup 2
3000: from all lookup 3
3500: from all tos 04 lookup 32
4000: from 192.168.0.14 lookup 4
4000: from 192.168.0.3 lookup 4
4000: from 192.168.0.121 lookup 4
4000: from 192.168.0.30 lookup 4
32000: from all lookup 32
32766: from all lookup main
32767: from all lookup default

(Quelle siehe: Quellen am Ende der Seite, Quelle Nr. 5)

Die Zahlen vor den Anweisungen stellen die Priorität dar. Das heißt das System geht die Liste in der Reihenfolge der Zahlen durch. Wenn das Kriterum, in diesem Fall die "from ..." Anweisungen auf das Paket passen wird die Regel ausgeführt. In diesem Fall die verschieden "lookup"s. Das bedeutet wenn eine Regel greift wird in der zugehörigen Routingtabelle nachgeschaut. Findet sich in der Routingtabelle ein Eintrag der auf das Paket zutriff, wird also das Ziel des Paketes in der Tabelle erwähnt, so ist die Abarbeitung abgeschlossen. Der Router hat sich also entschieden. Findet der Router in der Tabelle keinen Routingeintrag, so geht er zur nächsten Eintrag der _Regelliste_ über und prüft diese. Dieses passiert solange bis eine Route gefunden wurde, oder die Regelliste komplett durchlaufen ist.

Übrigens die Zahlen hinter den Lookups sind natürlich die verschiedenen Routingtabellen. Diese "numersichen" Tabellen sind von root manuell angelegt worden. Die Routing Tabellen "local", "main" und "default" sind standardmäßig enthalten. local enthält alle Regeln die sich aus der Konfiguration der Netzwerkkarten ergeben. Dementsprechend kann diese Routingtabelle (als einzige) nicht von root verändert werden. "main" enthält die Routingtabelle wie man sie vom normalen Destinationbased-Routing kennt. Man kann sich diese Tabelle mit dem Befehl "route" ansehen. "default" wird normalerweise als letzte ausgeführt und dient dem Aufräumen. Alles was bisher zu keinem Ergebniss geführt hat sollte hier abgehandelt werden. Standardmäßig ist diese Tabelle allerdings leer.

=== Die Praxis ===
Genug der Theorie, nun ein wenig Praxis. Nachfolgend die Erklärung wie man eigene Regeln der Rulelist hinzufügt.
Hierzu braucht man das Programm "ip". ip ist ein echtes Schwergewicht in Sachen IP-Konfiguration. Es bietet unzählige Möglichkeiten und eine entsprechend lange Manpage. Darüber hinaus hat ip sogar noch eine eigenbaute Hilfefunktion, die man mit "ip help" aufrufen kann.

Nun endlich genug der Worte. Wir wollen nun eine Regel anlegen, die auf Deutsch aussagt:

Wenn die Quelle des Paketes gleich 192.168.1.17 ist, dann schaue in Routingtabelle 17 nach.

Das geht so. Einfach als root folgendes eintippen:

ip rule add from 192.168.1.17 table 17

Anschließend kann man sich das Ergebnis, also die veränderte Rulelist so ansehen:

ip rule list

oder wer es gerne kurz mag kann auch

ip ru ls

verwenden. Das ganze sollte jetzt so aussehen:

0: from all lookup local
32765: from 192.168.1.17 lookup 17
32766: from all lookup main
32767: from all lookup default

Wie man sehen kann wurde die Regel als erste der letzten eingefügt, also also die höchste noch frei Priorität bekommen. Man dies beeinflusse in dem man die Priorität selbst festlegt. Das geht so:

ip rule add from 192.168.1.17 prio 2 table 17

Wie gesagt kann man noch mehr als nur die Quelle als Selektionskriterum verwenden. Z.B. das [http://de.wikipedia.org/wiki/IP-Paket#TOS_.28Type_of_Service.29 TOS] Feld:

ip rule add from all tos 04 table 18

Zu deutsch würde diese Regel bedeuten:

Wenn ein Paket, egal welche QuellIP, beim TOS Feld den Wert 04 hat, dann siehe in Tabelle 18 nach.

Das ist alles schon recht nett, richtig spannend wird es aber erst, wenn man das ganze mit iptables kombiniert. Dann entfalltet PBR erst seine ganze Herrlichkeit. Netfilter/iptables ist in der Lage ein Paket abhängig von bestimmten Werten (wie z.B. den Serivceport) zu markieren. Diese Markierung kann ip wiederum erkennen und als Kritierum verwenden. Ein kleines Realweltbeispiel:

Angenommen man hat einen Server im Internet mit der IP Adresse a.b.c.d. Diese IP Adresse erreicht man über das Internet oder über eine spearate VPN Verbindung vom eigenen PBR-fähigen Router. Nun möchte man dass die Benutzer im eigenen Netzwerk Mails über die verschlüsselte VPN Verbindung senden. Normale https Verbindungen sollen aber nicht über die VPN Verbindung laufen, da eine zusätzliche Verschlüssung hier nur unnötigen Overhead darstellt.

Der Router hat nun also zwei Routingtabellen (Nr. 2 und Nr. 3). Nr. 2 ist die Verbindung über das Internet. D.h. der Next Hop für das Ziel a.b.c.d ist 192.168.1.1 über das Netzwerkinterface ra0. Tabelle Nr. 3 stellt die Tabelle für die VPN Verbindung dar. In dieser Tabelle ist der Next Hop für Ziel a.b.c.d die IP 10.0.0.10 über das Interface tun0.

Da ip rule add keine Möglichkeit bietet das TCP Destination Port Feld als Kriterium auszuwählen kann man keine direkte Regel erzeugen. Statt dessen muss man mit IPtables die Pakete markieren und anhand dieser Markierung filtern. Das geht nun so. Zuerst markieren wir das Paket:

iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 443 -j MARK --set-mark 2
iptables -A PREROUTING -t mangle -p tcp -d a.b.c.d --dport 25 -j MARK --set-mark 3

Zu gut Deutsch:

Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 443, dann gebe dem Paket die Markierung 2
Füge zur PREROUTING-Kette folgendes hinzu: Wenn das Ziel a.b.c.d ist und der Zielport 25, dann gebe dem Paket die Markierung 3

Alle https Pakete tragen nun also die Markierung 2, alle SMTP Pakete die Markierung 3.

Nun muss man noch die entsprechende Regeln setzen:

ip rule add fwmark 2 table 2
ip rule add fwmark 3 table 3

Somit werden Pakete mit gleichem Ziel, aber unterschiedlichen tcp Ports unterschiedlich geroutet. Das war es was wir erreichen wollten. Einige Hinweise noch zum Schluss. Man kann die Markierung nur dem

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]
# [http://linux-net.osdl.org/index.php/Iproute2 Homepage von iproute2]
# [http://gentoo-wiki.com/TIP_Dual-Homed_Gentoo_Server Gentoo Seite welchen den Kernelsupport erläutert]
# [http://www.compendium.com.ar/policy-routing.txt Policy based routing MICRO-HOWTO]
# [http://www.linuxfaq.de/f/cache/1266.html#tth_sEc3 Wie man mit iptables Pakete markiert]

Policy Based Routing

2007-05-20T15:54:32Z

Nbkr:

Policy Based Routing

2007-05-20T15:29:08Z

Nbkr:

Policy Based Routing

2007-05-15T10:41:32Z

Nbkr: /* Quellen */

Policy Based Routing

2007-05-15T10:32:09Z

Nbkr:

Policy Based Routing

2007-05-15T10:31:55Z

Nbkr: /* Was ist Policy Based Routing? */

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Based Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamische Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:29:47Z

Nbkr: /* Nachteile von PBR */

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

=== Nachteile von PBR ===
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamische Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:29:21Z

Nbkr:

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]"
[http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

== Nachteile von PBR ==
Die Nachteile von PBR liegen vor allem im höhren Administrationsaufwand. Das Regelwerk für die Router muss erstellt und gepflegt werden. Dynamische Routing wird schwieriger einzubinden und auch die Fehlersuche im Netzwerk wird komplizierter, da man nicht einfach ein Traceroute absetzen kann um zu sehen welche Route die Daten nehmen würden (dies kann sich von der Route des Traceroutes nämlich unterscheiden).

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:25:25Z

Nbkr: /* Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) */

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

Sie auch Quelle [2].

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]" [http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:24:56Z

Nbkr: /* Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) */

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===

==== Ereichen des gleichen Ziels über zwei Verbindungen ====
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

==== QoS ====
Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

==== Sonstiges ====
In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]" [http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

Für Weiteres siehe Quelle [2].

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:23:23Z

Nbkr: /* Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) */

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

In letzter Zeit kam leider auch das Thema "[http://de.wikipedia.org/wiki/Netzneutralit%C3%A4t Netzneutralität]" [http://www.heise.de/newsticker/meldung/69346 in den Medien] auf. Auch dies wäre ein Anwendungsfall für PBR.

Für Weiteres siehe Quelle [2].

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:20:49Z

Nbkr: /* Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) */

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von [http://de.wikipedia.org/wiki/VoIP VoIP] (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

Für Weiteres siehe Quelle [2].

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:20:18Z

Nbkr: /* Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) */

{{Vorlage:Wettbewerb}}

{{UnderConstruction}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

Heute dürfte [http://de.wikipedia.org/wiki/QoS QoS] (Quality of Service) eine größere Rolle spielen.

Angenommen ein Internetprovider hat zwei Kundengruppen: Privatkunden und Firmenkunden. Die Privatkunden zahlen nur einen geringen Preis für die Internetanbindung, wärend die Firmenkunden einen hohen Preis zahlen. Nun möchten die Firmenkunden natürlich auch einen höhere Verbindungsgeschwindigkeit garantiert bekommen als dies für die Privatkunden üblich ist. In einem solchen Umfeld könnte der der Internetprovider an Hand der Quelle eines Datenpaketes entscheiden ob dieses mit Vorgang behandelt wird oder nicht.

Ein weiteres Szenario kennt man von VoIP (Voice over IP). Die Datenpakete eines Telefongespräches müssen zügig beim Empfänger ankommen, wenn man vermeiden will dass dieser ein Echo, oder einfach eine "schlechte Leitung" im Gespräch hört. Bandbreite steht leider nicht unbegrenzt zur Verfügung, so dass man entscheiden muss welches Datenpaket über eine bessere Leitung (weil schneller) übertragen wird und welche nicht. Auch hier kann PBR wieder helfen. Anhand des im Paket eingesetzten Protokolls kann ein Router der PBR-fähig ist entscheiden ob ein Datenpaket über ein gute Leitung geschickt werden muss, oder ob es eine weniger gute Leitung nehmen kann.

Für Weiteres siehe Quelle [2].

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:07:06Z

Nbkr:

Policy Based Routing

2007-05-15T10:05:15Z

Nbkr: /* Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) */

{{Vorlage:Wettbewerb}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden. Das sonst übliche Routing auf Basis des Zieles konnte man hier nicht einsetzen, da das Ziel ja jedesmal identisch war.

Für Weiteres siehe Quelle [2].

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T10:03:13Z

Nbkr: /* Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) */

{{Vorlage:Wettbewerb}}

Dieser Artikel will die Grundlagen von Policy Based Routing sowie die zugehörigen Konfigurationsmöglichkeiten unter Linux erklären. Der Artikel setzt voraus, dass der Leser grundlegendes Verständnis im Thema Routing unter Linux hat. route, nestat, Routing Table, NAT, Masquerading und ähnliches sollten als keine Fremdwörter für den Leser sein.

== Was ist Policy Based Routing? ==
Unter dem Begriff "Policy Bassed Routing" versteht man die Möglichkeit Routing Entscheidungen an Hand eines vordefinierten Regelwerkes
zu treffen. Dies unterscheided sich stark von den bisher eingesetzten Routingmöglichkeiten bei welchen ein Router nur an Hand des Zieles eines Datenpaketes entscheided an welchen Next Hop das Paket weitergereicht wird.

Mit PBR ist es nun möglich das ein Router auch die Quelle eines Paketes, die Größe des Paketes, bestimmte Flags, das Protokoll und noch vieles mehr berücksichtig und dann entscheided was der Next Hop für das Paket sein soll.

Für Weiteres siehe Quelle [1].

=== Vorteile von PBR (Oder: Wozu braucht man das überhaupt?) ===
In der Vergangenheit als das Internet noch überschaubar war, hatte man oftmals zwei Anbindungen an seine Kommunikationspartner. Eine über ein kommerzielles Netz, welche zuverlässig aber teuer war und eine Anbindung über das Internet, welche günstig aber unzuverlässig war.

Je nachdem von wo nun Daten zum Partner geschickt wurden, wurde entweder die kommerzielle oder die öffentliche Anbindung genutzt. Man musste also an Hand der Quelle der Daten unterschieden welche Daten wie geroutet wurden.

Für Weiteres siehe Quelle [2].

== Konfiguration von PBR unter Linux ==

== Quellen ==
# [http://en.wikipedia.org/wiki/Policy_based_routing Englischer Wikipedia Eintrag zum Thema Policy Based Routing]
# [http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html Policy Based Routing with Linux - Online Edition]

Policy Based Routing

2007-05-15T09:43:42Z

Nbkr: /* Quellen */

Policy Based Routing

2007-05-15T09:42:35Z

Nbkr:

Policy Based Routing

2007-05-15T09:37:51Z

Nbkr:

Firewall

2007-05-14T15:23:52Z

Nbkr: /* Grundsätze zur Gestaltung des Regelwerkes */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 das 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ü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.

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB, eben alles was als Broadcast geschickt wird und was das eigene Netzwerksegement 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-14T15:22:40Z

Nbkr: /* Die Firewall als Allheilmittel? */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 das 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ü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.

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB''
* 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-14T15:20:30Z

Nbkr: /* Die Firewall als Allheilmittel? */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

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

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 welche Sicherheitslücken aufmacht.

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

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB''
* 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-14T15:19:57Z

Nbkr: /* SuSE-Firewall */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

= Wichtige Sicherheitshinweise zu Firewalls =

== Die Firewall als Allheilmittel? ==

Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt öffent 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.

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 welche Sicherheitslücken aufmacht.

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

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB''
* 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-14T15:18:50Z

Nbkr: /* Proxy */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein Oberfläche für iptables. Somit kann die SuSE Firewall alles 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

= Wichtige Sicherheitshinweise zu Firewalls =

== Die Firewall als Allheilmittel? ==

Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt öffent 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.

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 welche Sicherheitslücken aufmacht.

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

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB''
* 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-14T15:18:16Z

Nbkr: /* Applicationlayerfirewalls */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

Oftmals werden Applicationslayerfirewalls durch eine Kombination von Proxies und "normalen" Netzwerkfirewalls realisiert.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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. Applicationlayer Firewalls werden meist über Proxies realisiert.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein Oberfläche für iptables. Somit kann die SuSE Firewall alles 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

= Wichtige Sicherheitshinweise zu Firewalls =

== Die Firewall als Allheilmittel? ==

Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt öffent 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.

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 welche Sicherheitslücken aufmacht.

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

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB''
* 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-14T15:17:35Z

Nbkr: /* Proxy */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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. Applicationlayer Firewalls werden meist über Proxies realisiert.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein Oberfläche für iptables. Somit kann die SuSE Firewall alles 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

= Wichtige Sicherheitshinweise zu Firewalls =

== Die Firewall als Allheilmittel? ==

Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt öffent 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.

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 welche Sicherheitslücken aufmacht.

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

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB''
* 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]

Firewall

2007-05-14T15:12:29Z

Nbkr: /* Applicationlayerfirewalls */

{{Wettbewerb}}

Dieser Artikel beschäftigt sich mit Firewalls allgemein. Es geht nicht um die Konfiguration einer spezielle 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 [http://de.wikipedia.org/wiki/Netzwerksegment Netzwerksegmente] kontrollierbar miteinander verbinden. Das bedeutet die einzelnen Rechner in den verschiedenen Netzwerksegmenten sollen bestimmte Verbindungen untereinander aufbauen können, jedoch nicht jede beliebige Kommunikation durchführen können.

= Firewalltypen =

== Netzwerkfirewall ==

Eine Netzwerkfirewall läuft auf einem Rechner mit mindestens zwei Netzwerkkarten. Diese Netzwerkkarten sind an die Netzwerksegmente angeschlossen deren Verbindungen kontrolliert werden soll. Die Firewall ist somit Teil beider Netzwerke und hat somit 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 [http://de.wikipedia.org/wiki/Router Router] dienen und das Routing innerhalb der Netzwerke richtig gesetzt werden.

Tatsächlich kann man eine Netzwerkfirewall auch als Layer-4 Firewall bezeichnen, denn sie arbeitet ([http://www.linux-magazin.de/heft_abo/ausgaben/2004/12/zugbruecke meistens]) im Layer 4 des [http://de.wikipedia.org/wiki/ISO/OSI#Schicht_4_.E2.80.93_Transportschicht ISO OSI Modells]. Eine Firewall die keinerlei Verbindungen blockiert verhält somit für alle anderen Netzwerkkomponenenten wie ein normaler Router.

== 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, in dem 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 somit nicht von einer Firewall geschützt werden. Auch das zweite Argument hält einer sachlichen Prüfung nicht stand: Wen man nicht möchte das bestimmte Daten ins Netzwerk gesendet werden, warum deinstalliert dann nicht einfach das Programm welches diese Daten sendet?

== Applicationlayerfirewalls ==

Unter dem Begriff Applicationlayerfirewall versteht man Firewalls welche den Datenverkehr nicht nur auf Basis von Quelladdresse, Zieladresse und Service, sondern auch anhand des tatsächlichen Inhalts eines Datenpaketes. Eine Applicationlayerfirewall 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 in dem er so tut als wäre es eine Webanfrage. So kann eine Applicationlayerfirewall z.B. Webseiten ausfiltern welche versuchen eine bekannte Browserlücke auszunutzen, oder verhindern das ein Benutzer einen Virus herunterlädt.

= Firewalltechnologien =

== Paketfilter ==
Praktisch alle gängigen Firewalls sind Paketfilterfirewalls. D.h. sie anaylsieren einzelne Datenpakete und entscheiden anhand bestimmter Kriterien ob diese Paket weitergeleitet oder vernichtet 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 "im Weg" der Datenpakete liegt. Die Firewall nimmt das Datenpaket und extrahiert, von wo die Daten kommen (QuellIP), nach wo die Daten sollen (ZielIP), sowie welcher Port verwendet wurden (z.B. http oder ssh, also der Port und das Protokoll). Diese Daten vergleicht sie mit ihrem Regelwerk.

Wenn es eine Regel gibt welche diese Verbindung explitziert 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 Defaultpolicy. Dies ist im Prinzip eine Regel die angewendet wird wenn keine andere Regel zu finden ist.

== Statefullinspection ==
Eine Firewall die Statefullinspection 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, in dem 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 Statefullinspection kann, so muss der Administrator eine Regel einbauen welche den Schülern immer erlaubt Daten an den Lehrer zu schicken. Das würde bedeutet die Schüler könnten dem Lehrer ständig ins Wort fallen.

Kann der Aufpasser aber Statefullinspection, 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 warten. 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 dem Statefullinspection noch etwas oben drauf. Eine Statefullinspectionfirewall 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. D.h. eine ''Proxyfirewall'' "weiß" welche Antwort Sinn macht und lässt ein Datenpaket nur dann zu. Die Idee hinter einer solchen Firewall ist, zu verhindern das z.B. ein Browser eine Verbindung zu einem Webserver aufmacht und dieser im eine mit einem Trojaner gespickte Seite zurückliefert.

Um im Beispiel des Aufpassers zu bleiben: Bisher konnte der Lehrer z.B. die Frage stellen: "Was ist die Hauptstadt von Deutschland" und ein Schüler konnte antworten "Der Lehrer ist doof" und 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.

== 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 das ein Angreifer seine QuellIP fälscht und somit Daten über die Firewall schicken zu können.

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 welcher 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ß das 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 konnte 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 (Statefullfailover) ==
Unter Statefullfailover versteht man die Fähigkeit zwei Firewalls zu koppeln so dass keine Verbindung
unterbrochen wird, auch 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 drigenden Arztermin 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 Statefullfailover. 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 Statefullfailover-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 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 wurden nur einige herausragende Vertreter aufgeführt.

=== netfilter/iptables ===

Aktuelle Linuxkernel haben eine Firewall mit eingebaut. Diese nennt sich "Netfilter" und kann über den Befehl "iptables" konfiguriert werden. Oftmals wird auch einfach von iptables gesprochen wenn man von Netfilter spricht.
Ein älteres Frontend für Netfilter war ipchains. Dieses sollte man heute allerdings nicht mehr einsetzen, da iptables ipchains vollkommen ersetzt.

netfilter beherrscht das Statefullinspection, kann also Verbindung anhand ihrem Zustand 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 Statefullfailover-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 in den Linuxkernel integriert.

=== TuxGuardian ===

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, wodurch man es manuell nachinstallieren muss.

=== pf ===

pf steht für Paket Filter und ist der Name der Firewallsoftware von OpenBSD. pf beherrscht Statefullinspection und kann mit Hilfe von pf_sync sogar Hochverfügbar gemacht werden (Ein Howto hierzu findet sich am Ende der Seite).

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

== Administrationsoberflächen ==

=== SuSE-Firewall ===
Die SuSE-Firewall ist keine neue Firewall, sondern einfach nur ein Oberfläche für iptables. Somit kann die SuSE Firewall alles 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. Hierin speichert YaST die Firewalleinstellungen in Form eines Shellscriptes.

=== Firewall Builder ===

Neben Distributionsabhängigen Werkzeugen zur Firewallkonfiguration gibt es auch unabhängige Softeware zur Konfiguration von Netfilter wie z.B. [http://www.fwbuilder.org/ Firewall Builder]. Der Firewall Builder ist eine GUI in welcher 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 [http://www.hideaway.net/iptables/ Easy Firewall Generator for IPTables] ist ein 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_selber_erstellen]] bei jedem Start ausführen.

= Wichtige Sicherheitshinweise zu Firewalls =

== Die Firewall als Allheilmittel? ==

Eine Firewall alleine macht noch kein sichers Netzwerk. Gerade wenn man Verbindungen zulässt öffent 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.

Darüber hinaus muss man sicherstellen das die Firewall "im Weg" steht. D.h. es darf keine Verbindungsmöglichkeiten um die Firewall herum geben (Bypass). Das wäre wie wenn 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. PC 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 welche Sicherheitslücken aufmacht.

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

In diesem Beispiel wird davon ausgegangen das 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).

'''Broadcast Regel'''
* Position im Regelwerk: Ganz vorne
* Quelle: Alle
* Ziel: Broadcast IP Adresse der Netzwerksegmente
* Service: ''unterschiedlich, meist MS RPC, RIP, SMB''
* 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 müssen 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.

'''Stealth Regel'''
* Position im Regelwerk: Vorne
* Quelle: Alle
* Ziel: IP Adresse der Firewall
* Service: Alle
* Aktion: Paket verwerfen
* Ins Log schreiben? Ja

Die sogenannte Stealthregel sorgt dafür das 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 das die Firewall nicht reagiert weiß der Angreifer schonmal das 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 eine Firmennetzwerk mit dem Internet verbinden.

= Quellen & Weiterführendes =

* [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.benjaminfleckenstein.de/de/anleitungen/pfcluster/index.html Firewallcluster mit OpenBSD, pf und pf_sync]
* [http://de.wikipedia.org/wiki/Firewall Deutscher Wikipediaartikel zum Thema Firewall]
* [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]