Versuch II: Statische Paketfilterung mit Netfilter

In den folgenden Aufgaben werden wir - Schritt für Schritt - einen Konfigurationsskript für unsere Paketfilterfirewall erstellen. Sie sollten dabei von dem rudimentären Skript /tmp/firewall/firewall ausgehen, weil es nämlich schon einige Definitionen enthält, die Ihnen nützlich sein könnten. Um vernünftig arbeiten zu können, sollten Sie dieses Skript ins Verzeichnis /etc/init.d/ kopieren und überdies folgenden Link setzen:

ln -s ../../etc/init.d/firewall /usr/sbin/rcfirewall

Anschließend können Sie das Konfigurationsskript bequem mit dem Kommando rcfirewall [start|stop|close] ausführen.

Wir wollen von einer pessimistischen Vorgehensweise bei der Konfiguration unseres Paketfilters ausgehen. Das Rahmenskript sollte so erweitert werden, dass beim Aktivieren der Firewall (rcconfig start) vorerst jeglicher Datenverkehr verhindert wird und somit das interne Netz abgeschottet ist. Es bietet sich an, diese Regeln auch gleich in die hierfür vorgesehene Abteilung close) zu schreiben, welche genau für diesen Zweck (der Abschottung) angelegt wurde. Der Abschnitt unter stop) soll so erweitert werden, dass die Firewall abgeschaltet wird. In diesem Fall soll die Firewall wieder normal routen und alle Datenpakete akzeptieren.
Für die Verwendung von auf dem Rechner lokal installierten Diensten, wie z.B. DNS, NIS oder HTTP, steht normalerweise ein loopback Interface zu Verfügung (Auf einem reinen Paketfilter hätten dieses natürlich nichts verloren). Ein loopback Interface kann aber auch für Testzwecke (z.B. des Protokollstacks oder der obigen Dienste) nötig sein. Das firewall Skript soll nun so erweitert werden, dass bei aktivierter Firewall ein uneingeschränkter Zugriff auf das loopback Interface möglich ist.
Bevor in den folgenden Abschnitten der Paketfilter immer weiter geöffnet wird, um bestimmte Dienste anzubieten, sollte noch eine Einschränkung vorgenommen werden. Weil unser zu schützendes Netz einen festen IP Bereich besitzt, sollten alle Datenpakete, welche am externen Interface (pcfwXext) des Paketfilters einlaufen, darauf überprüft werden, ob ihre angegebene Quelladresse außerhalb des IP Bereichs des internen Netzes liegt. Einlaufende Pakete an pcfw1ext, deren Quell-IP-Adresse behauptet von einem internen Rechner zu stammen ("gespoofte Adresse"), zeugen mit ziemlicher Sicherheit von einem Angriffsversuch (oder von einem falsch konfigurierten Rechner).
Um die Realisation der Aufgabe einfach zu halten, demonstrieren wir das Antispoofing nicht am externen sondern am internen Interface (pcfwXint), indem wird umgekehrt fordern, dass die Quelladressen aller dort einlaufenden Pakete tatsächlich aus dem internen Netz stammen. Zum "internen Netz" rechnen wir die Subnetze 192.168.215.80 und .96 (Gruppe 1) bzw. 192.168.215.144 und .160 (Gruppe 2). Wir stellen dabei uns auf den Standpunkt, dass die Subnetze 192.168.215.112 bzw. .176 nicht zu unserem "internen Netz" gehören und der Host pcrtXsub2 "feindlich" ist und in unserem Netz eigentlich nichts zu suchen hat (mit ihm können wir dann bequem IP-Pakete mit "gespoofter" Quelladresse senden).
Schreiben Sie also statische Firewallregeln, welche diese gefälschten Adressen protokollieren und anschließend verwerfen. Sorgen Sie dafür, dass die entsprechenden Meldungen unter /var/log/messages eindeutig auffindbar sind und überprüfen Sie dies, indem Sie sich diese Datei anzeigen lassen und nach entsprechenden Meldungen suchen. Verwenden Sie hierbei die Möglichkeit eigene (sub-) chains zu erstellen, um ihr Konfigurationsskript übersichtlich zu halten. Testen Sie die Antispoofing-Konfiguration ihrer Firewall. Zur Überprüfung der Konfiguration steht auf dem Rechner pcrtX das tool spoof zu Verfügung. Beim Aufrufen dieses Programmes wird eine Befehlssyntax ausgegeben.
Für administrative Zwecke ist das ICMP Protokoll eine große Hilfe. Schreiben Sie einen Regelsatz, welcher die häufigsten Dienste (ping, traceroute) in jeglicher Richtung erlaubt (auch wenn dies sicherheitstechnisch bedenklich ist, weil ping an Broadcastadressen zum Spionieren und für DoS-Attacken benutzt werden kann). Wenn genügend Zeit vorhanden ist, steht es ihnen natürlich frei, auch einen feingranulareren Filter zu entwerfen. Beachten Sie auch die Kernelparameter, welche Sie am Ende des Theorieteils untersucht haben. Vergessen sie nicht, ihre Regeln zu testen.
Hinweis: Teilweise können sich hier die Funktionen der Kernelparamter mit denen der Regeln überschneiden. Dies ist bewusst so gewählt. Zum einen könnten Situationen auftreten in denen die Parameter nicht zu Verfügung stehen, zum anderen ist es schwierig die Korrektheit der Funktionsweise der Kernelparameter zu überprüfen.

Hinweis

#!/bin/sh

# Rahmen des Konfigurationsskripts für Netfilter/iptables

IPTABLES="/usr/sbin/iptables"
DEVEXTERN="eth0"
DEVINTERN="eth1"

# Einschränkung auf pcfw1int (Gruppe 1)
NETZINTERN_A="192.168.215.80/28"
NETZINTERN_B="192.168.215.96/28
LO="127.0.0.1"

case "$1" in
  start)
    echo "Firewall wird aktiviert"

    exit 1
    ;;
  stop)
    echo "Firewall wird deaktiviert"
    # Rechner arbeitet als normaler Router

    exit1
    ;;
  close)
    echo "Firewall abschotten"
    # Rechner routet nicht und blockt jeden Datenverkehr

    exit1
    ;;
  *)
    echo usage: $0 start|stop|close"
    exit 1
esac

exit 0