Bei der Einrichtung von Firewall Regeln muss man aufpassen, dass man sich nicht selbst aussperrt. Dies ist besonders ärgerlich, wenn man eine weit entfernte Firewall über eine Netzwerkverbindung konfiguriert. Dies kann im schlimmsten Fall dazu führen, dass man an diesen weit entfernten Ort reisen muss, um wieder Zugriff auf die Firewall zu bekommen.

In Teil 3 werden wir die ersten Firewall Regeln eingeben. Wichtig ist, sich zu merken, dass die Regeln beim nächsten Neustart wieder entfernt sind. Das ist für den Anfang auch gut so. Nur allzuleicht könnte man sonst den Zugang zum System vollständig blockieren.

Aus diesem Grund sollte man sich auch eine Regel zu Herzen nehmen: Erst denken, dann tippen!

Manuelle Konfiguration der Mac OS X ipfw

Wichtiger Hinweis: In den Beispielen erkennt Ihr am Prompt, mit welchen Berechtigungen das jeweilige Kommando ausgeführt wird. # steht für root Shell, % oder $ steht für Benutzer Shell. Zeilen ohne Prompt zeigen die Ausgabe der Shell. Eigentlich alle Firewall Kommandos erfordern root Rechte. Unter Mac OS X stellt man ein `sudo' voran, damit die nachfolgenden Befehle mit root Rechten ausgeführt werden. Im Gegensatz zur graphischen Einstellung, erlaubt die Konfiguration auf der Kommandozeile eine wesentlich differenziertere Erstellung von Regeln. Einzelheiten können mit "man ipfw" aufgerufen werden, aber Vorsicht, mit 1473 Zeilen (unter Mac OS X Tiger) ist die manpage der ipfw nicht gerade eine der kürzeseten.

Zunächst einmal wollen wir die aktuelle Einstellung der Firewall ausgeben.
# ipfw list
65535 allow ip from any to any
Beispiel 1

In Beispiel 1 wurde die Firewall entweder auf der graphischen Oberfäche gestoppt oder alle Regeln wurden gelöscht. Dadurch tritt die sog. default rule in Kraft, auf die ich später noch eingehen werde.

An diesem Beispiel kann man den generellen Aufbau einer Rule zumindest grob erläutern. Die ipfw arbeitet mit einer Liste von Regeln, die von oben nach unten abgearbeitet wird. Trifft eine Regel zu, wird die Liste üblicherweise verlassen und eine "action" ausgefürt.

  • Die Nummer am Anfang stellt den Platz dar, den die Regel in der Liste einnimmt. 65535 ist die höchstmögliche Nummer, das heisst diese Regel wird ganz am Schluss abgearbeitet. Es können Regeln mit identischen Nummern erstellt werden, was aber nach meiner Meinung nur in Ausnahmesituationen sinnvoll ist.
  • Mit dem zweiten Teil der Zeile, der "action", beginnt die eigentliche Rule. `allow' bedeutet, dass ein Pakete auf das die nachfolgene Bedingung zutrifft weitergeleitet werden soll.
  • Danach folgt das Protokoll, auf das diese Regel angewendet weren soll. Da es die Default-Rule ist, steht hier `ip'. Das bedeutet: alle IP-Protokolle. Dazu gehören z.B. TCP, UDP und ICMP.
  • Der letzte Abschnitt, `from any to any', bezieht sich auf die Adressen, auf die diese Regel zutreffen soll. Was das in diesem Fall bedeutet ist auch klar: von überall nach überall. Diesen Abschnitt können wir auf der graphischen Oberflächen Oberfläche nur sehr eingeschränkt konfigurieren. Hier werden wir später Ports und/oder Rechner- und Netzwerkadressen definiert.

Um die Funktion der Firewall zu verstehen ist es sehr wichtig zu begreifen, wie die Regeln von der ipfw angewendet werden. In einer ersten Vereinfachung kann man sagen, dass die Regeln von oben nach unten abgearbeitet werden. Sobald eine Bedingung - man nennt sie auch `rule body' oder einfach nur `body' - zutrifft, wird die `action' ausgeführt. Dann, und das ist sehr wichtig, wird die Prüfung abgebrochen. Weiter unten stehende rules werden ignoriert. Aus dieser Arbeitsweise lassen sich einige Schlussfolgerungen ableiten.

  1. Spezifische Regeln stehen in der Konfiguration weiter oben, allgemeine weiter unten. Wäre dies nicht so, würden bereits die allgemeinen Regeln greifen und die spezifischen praktisch nie zur Wirkung kommen.
  2. Soweit unter Berücksichtigung von Punkt 1 Spielraum besteht, empfielt es sich Regeln für häufig benutze Protokolle weiter oben anzusiedeln und für weniger benutzte weiter unten. Dies ist effizienter, da so insgesamt weniger Regeln durchlaufen werden müssen. Also häufig oben http, pop/imap/smtp und unten ftp und ssh. Im Einzelfall passt man das an seine persönlichen Bedürfnisse an.
  3. Am Ende der rulelist lässt sich erkennen, ob es sich um eine restriktive oder um eine liberale Konfiguration Firewalls (s. Teil 2) handelt. Bei einer restriktiven Konfiguration findet man an vorletzter Stelle eine `deny all' Regel, so dass die letzte Regel, die fest einkompiliert ist, nie erreicht wird. Die Folge: Alles was nicht explizit weiter oben erlaubt wird, ist verboten. Fehlt diese Regel ist es genau umgekehrt: Alles was oben nicht verboten wird, ist erlaubt.

Um eine Regel zu erstellen müssen folgende Überlegungen angestellt werden.

  • An welcher Stelle soll die Regel stehen?
  • Auf welche Protokolle soll die Regel ansprechen?
    Am häufigsten werden das wohl tcp, udp und vielleicht noch ICMP sein. Grundsätzlich sind aber alle Protokolle möglich, die in der Datei /etc/protocols verzeichnet sind.
  • Welche "action" soll mit einem passenden Paket durchgeführt werden?
    Die wichtigsten actions sind wohl allow und deny.
  • Zwischen welchen Computern soll die Kommunikation gefiltert werden?
    Mit den IP-Adressen können Computer und Computergruppen beschrieben werden.
  • Welche Ports sollen gefiltert werden?
    Mit der Definition von Ports erreicht man oft, dass bestimmte Dienste ereichbar sind oder eben nicht. Die Kombination von IP- und Portfilterung kann man sehr genau vorgeben, welche Computer welche Dienste nutzen können. Dabei kann man auch Gruppen und ganze Netzwerksegmente ansprechen.
    Man kann auch unterscheiden, in welcher Richtung ein Datenverkehr zulässig oder nicht.
  • In welchem Verbindunsgzustand (state) sollen Datenpakete weitergeleitet oder geblockt werden?
    Die Berücksichtigung "state" ist ein sehr wichtiger Sonderfall, der einer ganzen Gruppe von Firewalls ihren Namen gegeben hat: den stateful Firewalls, zu denen unsere ipfw auch gehört.

Bei den folgenen Beispielen werde ich nicht auf alle Möglichkeiten eingehen und die Syntax entsprechend vereinfachen. Dies soll den Einstieg nicht mit komplizierten Konstrukten unnötig erschweren. Die Grundyntax zum Erstellen von Regeln lautet folgendermaßen:

# ipfw [-q] add [number] rule-body

rule-body:
action [log] protocol from source to target [interface-spec]

action:
{ allow | deny | forward ipaddr[,port] | reset | unreach code }

Beispiel 2

Die Pipe Zeichen "|" bedeuten "oder", die geschweiften Klammern "{" und "}" fassen die erlaubten Ausdrücke zusammen und drücken aus, dass einer der Ausdrücke gewählt werden muss. Die eckigen Klammern "[" und "]" dagegen stellen optionale Angaben dar. Die wichtigsten actions sind "allow" und "deny". Unterstrichene Begriffe müssen durch einen zulässigen Wert ersetzt werden.

Ich halte mich an dieser Stelle nicht lange mit Erklärungen auf, sondern wir wollen nun eine Reihe von Regeln (sudo nicht vergessen!) erstellen, die immer erforderlich sind, um die ordnungsgemäße Funktion der Netzwerkschnittstelle sicherzustellen. Mac OS X erstellt diese Regeln automatisch, sobald wir die Firewall starten. Diese Regeln stehen in der Konfiguration ganz oben, damit die Funktion sichergestellt ist, auch wenn wir weiter unten Fehler machen. Bevor wir anfangen noch einmal der Hinweis: Sobald wir selbst Regeln erstellen, können wir die Firewall über die graphische Oberfläche nicht mehr bedienen. Es erscheint dann eine etwas verwirrende Meldung, dass eine andere Firewall auf dem Sytem aktiv sei, die man zuerst beenden solle. Um die Konfiguration über Systemeinstellungen > Sharing wieder zu ermöglichen müssen zuerst alle Regeln entfernt werden. Dies erreichen wir durch den folgenden Befehl, denn wir sicherheitshalber mit `y' bestätigen müssen.

# ipfw flush
Are you sure? [yn] y

Flushed all rules.
Beispiel 3

Mit diesem Wissen ausgerüstet können wir nun die ersten Regeln eingeben. Diese Regeln werden auch eingerichtet, wenn man in Systemeinstellungen > Sharing die Firewall startet. Sie sind für die ordnungsgemäße Funktion des Systems erforderlich.

# ipfw add 02000 allow ip from any to any via lo*
# ipfw add 02010 deny ip from 127.0.0.0/8 to any in
# ipfw add 02020 deny ip from any to 127.0.0.0/8 in
# ipfw add 02030 deny ip from 224.0.0.0/3 to any in
# ipfw add 02040 deny tcp from any to 224.0.0.0/3 in
Beispiel 4

Zunächst einmal fällt auf, dass die Nummern nicht fortlaufend nummeriert sind. Dies möglicht ein Einfügen von Regeln. Später verwende ich sogar Hunderter-Schritte um flexibel zu bleiben. Wieder müssen wir beachten, dass die Regeln von oben nach unten abgearbeitet werden. Sobald eine Regel passt, wird die action ausgeführt und die Liste verlassen. Wir müssen daher darauf achten, dass die Regeln in der richtigen Reihenfolge eingegeben werden, um Sicherheitsrisiken zu verhindern. "ip" heisst in diesem Fall: alle Protokolle. "any" bedeutet hier jede IP-Adresse und jeder Port. "via lo*" ist die optionale Interface-Specifikation und bedeutet Loopback Interface mit beliebiger Nummer (lo0, lo1 ...). Die erste Regel bedeutet also: Erlaube Datenpakete mit allen Protokollen von beliebigen Adressen zu beliebigen Adressen über das Loopback Interface. Dies erlaubt uns die Benutzung des Loopback-Interfaces, das für viele Systemprozesse erforderlich ist. Die nächsten beiden Zeilen verhindern jedoch die Benutzung des gesamten 127-er zes sowohl als Quell- als auch als Zieladresse für eingehenden (in) Datenverkehr. Dies auch richtig so, weil dieser Adressbereich keine zulässigen IP Adressen enthält. Es soll aber unterbunden werden, dass Angreifer mit einer solchen Adresse vortäuschen, ein lokaler Prozess zu sein (127.0.0.1 = localhost). Die beiden nächsten Zeilen beziehen sich auf sogenannte Multicastadressen. Unter Mac OS X werden Multicastadressen z. B. von Bonjour (früher Rendevouz) verwendet.

1   2   3   4   5