Endlich erwachsen...

Bessere Linux-Firewalls mit Netfilter und Iptables

von Jörg Frühbrodt, IT-Consultant

erschienen in LinuxEnterprise 6/2001, Software & Support Verlag, Frankfurt a.M.

Mit dem neuen Kernel 2.4.X wurde auch die Paketfilter-Firewall von Grund auf neu entwickelt. Iptables ist sicherer und erheblich einfacher zu administrieren als sein Vorgänger IPCHAINS.

Technologisch ist IPCHAINS nicht mehr auf dem aktuellen Stand der Paketfilter-Technik. Einige Defizite hätten möglicherweise durch eine Erweiterung der Funktionalität aufgefangen werden können. Doch dazu fehlte eine definierte Schnittstelle, die ein Weiterleiten von Paketen aus den Niederungen des Kernels in den Userspace ermöglicht hätte. Darüber hinaus war der Sourcecode nicht modular strukturiert und deshalb nur schwer zu pflegen. Das Ablaufdiagramm verdeutlicht die umständliche Filterlogik:

Abb. 1 IPCHAINS-Ablaufdiagramm

Besonders das Forwarding wird unnötig kompliziert, da jedes Paket dazu alle drei Tabellen durchläuft. Die Filterregeln müssen angepasst werden, da das Masquerading und der Paketfilter keine logisch selbstständigen Einheiten sind. Kommen auch noch zahlreichen Hosts mit einer Vielzahl netzwerkorientierter Anwendungen hinzu, werden die IPCHAINS-Regelketten schnell unübersichtlich und damit fehleranfällig.

Das Bessere ...

ist des Guten Feind. Den IPCHAINS-Entwicklern Russell, Boucher und Morris waren die konzeptionellen Schwächen bewusst, weshalb sie Netfilter in 12 Monaten vollkommen neu entwickelten. Sie selbst bezeichnen ihr Werk als „framework for packet manipulation“. Entwickler bekommen mit ihm die Basisfunktionen zur Erweiterung von Netfilter an die Hand, ohne sich mit Kernelprogrammierung befassen zu müssen.

Das Framework selbst ist vollkommen protokollunabhängig und damit beliebig erweiterbar. Auf ihm baut iptables auf, dessen Filterlogik grundlegend überarbeitet wurde. Wie die Abb. 2 zeigt, sind die Tabellen filter, NAT und mangle voneinander vollkommen unabhängig. Jede Tabelle verfügt über ihre eigenen Regelketten (chains).

Abb. 2 Netfilter-Architektur

Der Weg eines Pakets durch die iptables wird wesentlich vereinfacht, was das Beispiel verdeutlicht: Trifft ein Paket am Netzwerkinterface ein, führt der Kernel zunächst den Sanity Check durch. Er überprüft es auf Einhaltung der Protokollstandards und rechnet die Checksumme nach. Ist nichts zu beanstanden, trifft iptables sinnvollerweise zuerst die Routing-Entscheidung, wie das Ablaufdiagramm in Abb. 3 zeigt:

Abb. 3 Netfilter-Ablaufdiagramm

Ist das Paket für den Firewall-Rechner selbst bestimmt, gelangt es zur Filtertabelle INPUT. Die Tabelle FORWARD erreicht es nur, wenn das Forwarding im Kernel aktiviert und ein entsprechender Eintrag in der Routing-Tabelle zu finden ist. Die Verbindung zur Außenwelt stellt die Firewall über OUTPUT her. Die in den Tabellen gespeicherten Regeln werden von oben nach unten durchlaufen, bis eine Regel zutrifft. Dort ist auch ein Sprungziel festgelegt, zudem nun verzweigt wird. Dieses Sprungziel kann eine der vordefinierten Aktionen (targets) ACCEPT, DROP, QUEUE, RETURN oder vom Anwender selbst definiert sein. Trifft keine der Regeln zu, kommt die Standard-Regel (Default-Policy) zur Anwendung, die für jede der drei Regelketten einzeln festlegt werden. Die Vorteile der klaren Struktur werden wieder beim Forwarding deutlich. Iptables ist schon mit dieser einfachen Regel zufrieden, die mit dem gleichnamigen Kommandozeilen-Programm erzeugt wird:

iptables -A FORWARD -i <input-interface> -o <output-interface> ...

Es genügt die Angabe der FORWARD-Chain, des Input-und Output-Interface. IPCHAINS benötigt mindestens drei Regeln für diese Aufgabe.

Neben Masquerading steht jetzt vollständiges NAT zur Verfügung. DNAT kann als Ziel der umgeleiteten Pakete sogar ganze Bereich von IP-Adressen einsetzten. Die eingehenden Verbindungen werden dann eine nach der anderen darauf verteilt. Selbst Low-Budget-Projekte können mit diesem einfachen Load Sharing aufgewertet werden.

Logging

Auch ein leistungsfähiger und professionell konfigurierter Filter ist nicht unüberwindbar. In der Regel geht gezielten Angriffen ein mehr oder weniger vorsichtiges Auskundschaften der gegnerischen Schwachstellen voraus. Von diesen Vorgängen erfahren Administratoren nur durch flexible Logging-Mechanismen. Auch hier haben die Entwickler das Rad neu erfunden. Die rudimentäre Option -l in IPCHAINS gibt es in Netfilter nicht mehr. Für das Logging wird der SYSLOG-Daemon und seine Prioritätenstufen benutzt. Benutzerdefinierbare Logeinträge mit einer Länge von bis zu 29 Zeichen erleichtern die Auswertung. Neben der Quell- und Zieladresse lassen sich die im TCP- und IP-Header enthaltenen Optionen ebenso protokollieren wie die TCP-Sequenznummern. Zum besseren Schutz vor DoS-Attacken gibt es einen Parameter, der die Anzahl der Logdatei-Einträge innerhalb eines frei wählbaren Zeitintervals begrenzt.

Connection tracking

Der größte Fortschritt ist sicher das connection tracking. Netfilter überwacht Verbindungen und ordnet ihnen einen der vier Verbindungszustände NEW, ESTABLISHED, RELATED und INVALID zu. Die Erkennung von nicht zu einer Verbindung gehörenden Paketen und ihre Validierung durch den Kernel erhöhen die Sicherheit beträchtlich. Für komplexere Anwendungsprotokolle wie aktives FTP, verwendet Netfilter anwendungsbezogene Helper-Module, die es derzeit nur für FTP und IRC gibt.

Packet Mangling

Wie es der Name für diese Netfilter-Funktion schon verrät, beeinflusst sie Steuerdaten auf der Paketebene.wie das Type-of-Service-Byte (ToS), indem es die Priorität von Diensten beeinflusst. Auf stark ausgelasteten Leitungen kann es sinnvoll sein, interaktive Dienste wie TELNET oder SSH mit einer kürzeren Antwortzeit oder Downloads per FTP mit einem maximierten Durchsatz zu bevorzugen.

Eine hübsche Idee ist das noch experimentelle MIRROR. Das Modul vertauscht einfach die Quell- mit der Zieladresse und schickt das Paket mit besten Grüßen an den neugierigen Absender zurück.

Netfilter-Praxis

Viele Anwender benutzen nur einen einfachen Einwahlzugang über ein Modem oder ISDN mit dynamischer Vergabe der IP-Adresse. Zwar ist allein schon deshalb ein gewisser Schutz gegeben, der sich aber mit netflter ohne großen Aufwand weiter ausbauen lässt. Das Shell-Skript SOHO-Firewall im Anhang basiert auf Russels „Really Quick Guide to Packet Filtering“. Um Eindringlingen das Leben zu erschweren, verwendet es benutzerdefinierte Regelketten und Connection Tracking. Nach der Netfilter-Installation wird es in das Verzeichnis /etc/init.d/ kopiert und bei jedem Systemstart ausgeführt. Wenn eine ISDN-Wählverbindung benutzt wird, muss die Variable DEV_EXT entsprechend angepasst werden.

Im nächsten Anwendungsbeispiel arbeitet der PC mit dem treffenden Namen „Tuersteher“ als Router für eine einfache ISDN-Wählverbindung. Für die Fernwartung aus dem internen Netz mit der IP-Adresse 192.168.1.0 bekommt er einen Zugang über SSH. Bevor die ersten Regeln definiert werden, sind neben einigen Variablen zunächst dynamische Kernelparameter zu setzen, die DoS-Angriffe erschweren helfen. Wer sich für die Details interessiert, findet in

/usr/src/linux/Documentation/networking/ip-sysctl.txt

mehr Informationen.

#!/bin/bash
IPTABLES=/usr/local/sbin/iptables
DEV_LOC=eth0
DEV_EXT=ippp0
for IF in $DEV_LOC $DEV_EXT ; do
echo "1" > /proc/sys/net/ipv4/conf/$IF/rp_filter
echo "0" > /proc/sys/net/ipv4/conf/$IF/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/$IF/accept_source_route
echo "0" > /proc/sys/net/ipv4/conf/$IF/bootp_relay
echo "1" > /proc/sys/net/ipv4/conf/$IF/log_martians
done
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo "5" > /proc/sys/net/ipv4/icmp_destunreach_rate
echo "5" > /proc/sys/net/ipv4/icmp_echoreply_rate
echo "5" > /proc/sys/net/ipv4/icmp_paramprob_rate
echo "10" > /proc/sys/net/ipv4/icmp_timeexceed_rate

„Alles was nicht ausdrücklich erlaubt ist, ist verboten.“ ist die geltende Devise. Deshalb setzen wir zunächst die Standardregeln (default policies) auf DROP und verhindern damit, daß Pakete akzeptiert werden, die nicht explizit durch eine Regel zugelassen werden.

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

Damit sich Netfilter in einem definierten Zustand befindet, werden zu Beginn alle möglicherweise noch im Kernel gespeicherten Regelketten gelöscht:

$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X

Für Testzwecke sind mitunter Verbindungen zum eigenen Rechner notwendig, die über das Loopback-Interface aufgebaut werden. Auch einige lokale Prozesse wie BIND verwenden es für die interne Kommunikation., die wir besser zulassen:

$IPTABLES -A OUTPUT -o lo -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPT

Alle externen Verbindungsversuche und andere Merkwürdigkeiten werden von der benutzerdefnierten Regelnirwana aufgefangen, im Systemlog vermerkt und dann unschädlich gemacht. Je nach Protokoll wird ein eigenes Prefix verwendet, das die spätere Auswertung erleichtert.

$IPTABLES -N nirwana
$IPTABLES -A nirwana -p TCP -j LOG --log-prefix "NIRWANA: TCP "
$IPTABLES -A nirwana -p UDP -j LOG --log-prefix "NIRWANA: UDP "
$IPTABLES -A nirwana -p ICMP -j LOG --log-prefix "NIRWANA: ICMP "
$IPTABLES -A nirwana -p TCP -j DROP

Über die Einwählverbindung zum ISP erhalten wir dynamische IP-Adressen zugewiesen. Wir sind deshalb auf Masquerading angewiesen, das unsere private IP-Adresse mit der vom Provider zugewiesenen überschreibt. Vor dem Einsatz des Masquerading muss unbedingt der Kernel auf den Umgang mit dynamischen IP-Adressen vorbereitet und das IP-Forwarding aktiviert werden:

echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo "1" > /proc/sys/net/ipv4/ip_forward
IPTABLES -t nat -A POSTROUTING -o $DEV_EXT -j MASQUERADE

Für alle bereits bestehenden ein- und ausgehenden Verbindungen definieren wir zwei gemeinsame Regeln. Die dritte Regel verhindert alle neuen von außen aufgebauten Verbindungen und springt zur benutzerdefinierten Regelnirwana, die alle Merkwürdigkeiten im Systemlog vermerkt und dann unschädlich macht.

$IPTABLES -A FORWARD -i $DEV_LOC -o $DEV_EXT -m state /
        --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $DEV_EXT -o $DEV_LOC -m state /
        --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $DEV_EXT -o $DEV_LOC -m state /
        --state NEW,INVALID -j nirwana

Wartung

Sicherheitsfanatiker werden ihre Firewall mit Hilfe eines seriellen Terminals administrieren, wir benutzen im Testaufbau die Secure Shell für die Fernadministration. SSH nutzt auf dem Client für jede ausgehende Verbindung einen Quellport zwischen 1000 und 1023. Der Verbindungsaufbau lässt sich gut überwachen, da SSH glücklicherweise TCP als Protokoll verwendet. Die Filterregeln soll nur eingehende SSH-Verbindungen zulassen:

$IPTABLES -A INPUT -i $DEV_LOC -s 192.168.1.0/255.255.255.0 -p TCP /
        --sport 1000:1023 --dport ssh -m /
        state --state NEW, ESTABLISHED, RELATED -j ACCEPT
$IPTABLES -A OUPUT -o $DEV_LOC -d 192.168.1.0/255.255.255.0 -p TCP /
        --dport 1000:1023 --sport ssh -m /
        state --state ESTABLISHED, RELATED -j ACCEPT

Die INPUT-Regel erlaubt am Interface eth0 neue und bestehende TCP-Verbindungen aus dem Netz 192.168.1.0, ausgehend von den Ports 1000-1023 mit dem Zielport 22. Die Output-Regel öffnet entsprechend den Rückkanal.

Komplex

Weitaus schwieriger ist aktives FTP. Es wird von den meisten Client-Programmen wie z.B. ncftp als Standardeinstellung verwendet. Anders als andere Anwendungsprotokolle verwendet aktives FTP mehr als eine TCP-Verbindung. Der Client öffnet die Control Connection genannte Verbindung von einem Port mit einer Portnummer größer als 1023 und verbindet sich per TCP mit dem Port 21 des FTP-Servers. Über diese Verbindung teilt der Client dem Server nun einen beliebigen Port mit, über den der Datenaustausch stattfinden soll. Nun kontaktiert der Server seinerseits den Client auf diesem Port und der Datenaustausch kann endlich beginnen. Diese Verbindung wird als Data Connection bezeichnet und belegt beim Server den Port 20. Die Problematik ist offensichtlich: Es ist nicht vorhersehbar, welchen Port der Client für den Datenaustausch anfordert. Zu allem Überfluss baut der Server die Verbindung auf. Eine denkbar schlechte Lösung wäre das Offenhalten ganzer Portbereiche. Die bessere Lösung ist, das connection tracking von iptables anzuwenden. Es analysiert den Datenaustausch zwischen Client und Server nicht nur auf der Paket-, sondern auch auf der Anwendungsebene. Nur so kann iptables den Port für den Datenaustausch erfahren. Entsprechend einfach ist die Regel für neue Verbindungen:

$IPTABLES -A FORWARD -o $DEV_EXT -p tcp --sport 1024:65535 /
        --dport ftp -m state --state NEW -j ACCEPT

Die gängigen Browser verwenden hingegen passives FTP. Auch hier öffnet der Client eine Control Connection und teilt dem Server den Wunsch nach einer passiven FTP-Verbindung mit. Der bestätigt und kündigt gleichzeitig an, einen Port offen zu halten und passiv auf die vom Client aufzubauende Data Connection zu warten:

$IPTABLES -A FORWARD -o $DEV_EXT -p tcp --sport 1024:65535 /
        --dport 1024:65535 -m state --state NEW -j ACCEPT

Damit die Clients im lokalen Netz beliebige Server im Internet mit ping erreichen können, wird ausgehendes ICMP erlaubt. Eingehende Pings werden von der nirwana-Regel aufgefangen, geloggt und verworfen.

$IPTABLES -A FORWARD -o $DEV_EXT -p ICMP --icmp-type /
        echo-request -j ACCEPT

Alle übrigen Regeln für die Dienste DNS, SMTP, POP3 und HTTP arbeiten nach dem gleichen Schema. Über das Output-Device ippp0 bauen sie von einem Quell-Port (>= 1024) eine neue Verbindung zu einem privilegierten Ziel-Port (< 1024) auf. Um die Pakete, die zu den bereits bestehenden Verbindungen gehören, kümmern sich die weiter oben gezeigten Regeln.

# DNS 
# IP-Adresse des Nameserver beim ISP: 194.64.64.1
$IPTABLES -A FORWARD -o $DEV_EXT -p tcp --sport 1024:65535 /
        --dport domain -d 194.64.64.1 -m state --state NEW -j ACCEPT
# SMTP: ausgehende Emails
$IPTABLES -A FORWARD -o $DEV_EXT -p tcp --sport 1024:65535 /
        --dport smtp -m state --state NEW -j ACCEPT
# POP3: Emails abholen
$IPTABLES -A FORWARD -o $DEV_EXT -p tcp --sport 1024:65535 /
        --dport pop3 -m state --state NEW -j ACCEPT
## HTTP
$IPTABLES -A FORWARD -o $DEV_EXT -p tcp --sport 1024:65535 /
        --dport http -m state --state NEW -j ACCEPT
## HTTPS (Secure HTTP)
$IPTABLES -A FORWARD -o $DEV_EXT -p tcp --sport 1024:65535 /
        --dport https -m state --state NEW -j ACCEPT

Nun ist es noch an der Zeit, sich um alle Pakete zu kümmern, die die Regelkette bis zu diesem Punkt durchqueren konnten:

$IPTABLES -A INPUT -j nirwana
$IPTABLES -A OUTPUT -j nirwana
$IPTABLES -A FORWARD -j nirwana

Zugaben

Einige weitere Möglichkeiten von iptables konnten im Rahmen unseres Beispiels nicht behandelt werden, da sie meist in komplexeren Firewalltopologien zum Einsatz kommen. Dort müssen eingehende Verbindungen meist an mehrere Rechner weitergeleitet werden. Die Lösung heißt Destination NAT (DNAT), das die Zieladresse überschreibt. Damit lassen sich alle Verbindungen eines lokalen Netzes zum Internet auf einen Proxy-Servers umleiten (Port-Forwarding):

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT /
        --to 192.168.0.3:8080

Alle HTTP-Anfragen an den Port 80 am Interface eth0 werden so zur IP-Adresse 192.168.0.3 weitergereicht, wo beispielsweise schon der SQUID-Proxy wartet. Um SQUID 2.3 als transparenten Proxy zu benutzen, sind in seiner Konfigurationsdatei /etc/squid.conf noch einige zusätzliche Parameter zu ergänzen:

http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on 

Von der Umleitung bemerken die Clients nichts, der Proxy erscheint quasi „transparent“. Da alle Pakete nicht beim Ziel, sondern beim Proxy eintreffen, muss dieser irgendwie die Zieladresse herausfinden. SQUID liest sie einfach aus dem HTTP-Request-Header und sendet sie an diese Adresse.

Ein weitere, sehr nützliche Anwendung für DNAT ist das Umleiten von Emails zu einem Mailrelay in einer Demilitarisierten Zone (DMZ). Für externe Adressaten bestimmte Emails kann der Mailserver im lokalen Netz nur an den Relay weiterleiten, der zum Schutz vor Spammern entsprechend konfiguriert ist.

Kleinere Unternehmen verfügen aus Kostengründen häufig nur über eine offizielle IP-Adresse. Dank DNAT gibt es keinen Grund mehr, Email- und Web-Server auf dem Firewall-Rechner zu installieren. Eingehende HTTP-Verbindungen werden einfach an den Webserver 192.168.1.3 und SMTP-Verbindungen zu einem weiteren Server 192.168.1.4 weitergeleitet:

iptables -t nat -A PREROUTING -i eth1 -pt tcp --dport http /
        -j DNAT --to 192.168.1.3
iptables -t nat -A PREROUTING -i eth1 -pt tcp --dport smtp /
        -j DNAT --to 192.168.1.4

Das Verfahren lässt sich leicht abgewandelt für das bereits erwähnte, einfache Load-Sharing nach dem Round-Robin-Verfahren einsetzen:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT /
        --to-source 192.168.0.10-192.168.0.15

Am Interface eth0 eingehende Verbindungen werden nacheinander auf die IP-Adressen 192.168.0.10 bis 192.168.0.15 verteilt. Natürlich muss der angegebene Dienst auf allen sechs Hosts identisch sein.

Mit SNAT wird die Source-IP-Adresse von Paketen mit einer neuen IP-Adresse überschrieben. Besitzt man nur eine offzielle IP-Adresse 194.64.64.30 und verfügt aber über eine Standleitung, werden mit SNAT die internen Adressen einfach überschrieben:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 194.64.64.30

Mit geringem Aufwand kann iptables Netzwerk-Scannern wie nmap ihr Schnüffelwerk erschweren. Pakete mit vollständig gesetzten TCP-Flags werden als XMAS-Pakete, mit nicht gesetzten Flags als NULL-Pakete bezeichnet. Beide befördert man mit einem Vierzeiler zum Daten-Orkus:

iptables -A INPUT -p tcp  --tcp-flags ALL ALL -j DROP
iptables -A FORWARD -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp  --tcp-flags ALL NONE -j DROP
iptables -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP

Never...

change a running system. Dieses Systemadministratoren-Motto verliert auch mit der Entwicklung des neuen Kernel 2.4 und Netfilter trotz aller Vorteile seine Berechtigung nicht. Wer die Vorgänger Kernel 2.2.X und IPCHAINS im Produktionsbetrieb einsetzt sollte noch warten, bis sich Netfilter vollends stabilisiert hat. Während der Arbeiten an diesem Artikel wurde eine Sicherheitslücke im Connection-Tracking-Modul von iptables bekannt, die in kürzester Zeit durch einen Patch geschlossen werden konnte. Einen Grund zur Eile bei der Umstellung gibt es nicht: IPCHAINS wird weiterhin im Kernel 2.4. enthalten sein und die Entwickler werden es voraussichlich bis zum Jahr 2004 unterstützen.

Die Marktführer werben mit Begriffen wie "stateful firewall" und "connection tracking". Diese Eigenschaften bietet nun auch netfilter. Die Integration und den Bedienungskomfort der kommerziellen Produkte wollten und konnten die Entwickler nie erreichen. Verglichen mit dem Vorgänger IPCHAINS ist den Entwicklern jedenfalls ein kleiner Quantensprung gelungen.

Netfilter installieren

Netfilter ist derzeit noch nicht integraler Bestandteil des Kernel , sondern muss von http://netfilter.samba.org geholt werden. Voraussetzung ist mindestens der Kernel 2.4.0. Der ist zwar bei der hier verwendeten SuSE 7.1 enthalten, aber seit seiner Veröffentlichung haben Allan Cox und andere Kernel-Hacker zahlreiche Patches veröffentlicht, die nicht fehlen sollten. Deshalb wird der Kernel Version 2.4.2 und netfilter 1.2.1averwendet. Die komprimiert rund 20 MB große Kernel-Sourcedatei findet man auf www.kernel.org oder einem der zahlreichen Mirrors. Wir kopieren die Datei in ein eigenes, vorher erstelltes Verzeichnis z.B. /usr/src/linux-2.4.2 und entpacken sie dort. Ebenso verfahren wir mit der Datei iptables-1.2.1a.tar.bz2, die sie auf http://netfilter.samba.org finden. Bevor iptables installiert wird, muss noch die möglicherweise bereits installierte Vorversion aus der SuSE-Distribution entfernt werden.

rpm -e iptables
bzcat linux-2.4.2.tar.bz2 | tar -x
bzcat iptables-1.2.1a.tar.bz2 | tar -x
cd iptables-1.2.1a
make KERNEL_DIR=“/usr/src/linux-2.4.2“
make install KERNEL_DIR=“/usr/src/linux-2.4.2“

Nachdem die Vorarbeiten abgeschlossen sind, müssen wir noch den Kernel konfigurieren, bevor wir ihn kompilieren können:

cd /usr/src/linux-2.4.2
make menuconfig

Im grauen Kasten „Kernel-Module für Netfilter“ sind alle notwendigen Einstellungen aufgeführt und erläutert. Zwar lassen sich Teile von Netfilter auch fest in den Kernel kompilieren, für Testzwecke ist die Übersetzung als Module aber von Vorteil. Im Falle einer neuen Version von Netfilter muss in der Regel nicht der gesamte Kernel neu übersetzt werden, im Moment kommen wir darum aber nicht herum:

make dep clean bzImage modules
modules_install
cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.4.2
cp /usr/src/linux-2.4.2/System.map /boot

Nachdem der neue Kernel in das Wurzelverzeichnis kopiert ist, wird die Datei /etc/lilo.conf angepasst.

image=/boot/vmlinuz-2.4.2
label=linux-2.4.2
initrd=/boot/initrd.img
read-only
root=/dev/hda1

Einige Parameter wie root sind systemabhängig und müssen unter Umständen angepasst werden. Ausführliche Informationen dazu findet man im KERNEL-HOWTO auf www.linuxdoc.org. Abschließend wird lilo ausgeführt. Nach einem Reboot stehen der neue Kernel und Netfilter zur Verfügung.

SOHO-Firewall

#!/bin/bash
IPTABLES=/usr/local/sbin/iptables
# Statt ppp0 kann auch ippp0 für ISDN eingesetzt werden
DEV_EXT=ppp0
# Laden der Module für das connection-tracking
modprobe ip_tables
modprobe ip_conntrack
modprobe ip_conntrack_ftp
# Löschen aller möglicherweise noch vorhandenen Regelketten
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X
# loopback für lokale Prozesse offenhalten
$IPTABLES -A OUTPUT -o lo -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPT
# Erzeugen der benutzerdefnierten Regelkette wall
$IPTABLES -N wall
# Lässt Pakete bereits bestehender Verbindungen
# in beiden Richtungen passieren (ESTABLISHED)
# und solche, die in Beziehung dazu stehen (RELATED)
$IPTABLES -A wall -m state --state ESTABLISHED,RELATED -j ACCEPT
# Erlaube keine neuen Verbindungen, die über das 
# Device $DEV_EXT hereinkommen
$IPTABLES -A wall -m state --state NEW -i ! $DEV_EXT -j ACCEPT
# Verwerfe alle Pakete, auf die keine der Regeln zutrifft.
$IPTABLES -A wall -j DROP
# Sprung zu der benutzerdefinierten Regelkette wall über die
# „eingebauten“ Regelketten INPUT und FORWARD.
$IPTABLES -A INPUT -j wall
$IPTABLES -A FORWARD -j wall

Weitere Artikel zu ähnlichen Themen:

Harte Zeiten! (1)

Harte Zeiten! (2)

Harte Zeiten! (3)

Literatur & Links

Linux 2.4 Netfilter FAQ, http://netfilter.samba.org/documentation/FAQ/netfilter-faq.html

Linux 2.4 Packet Filtering HOWTO, http://netfilter.samba.org/unreliable-guides/packet-filtering-HOWTO/index.html

Linux 2.4. NAT HOWTO, http://netfilter.samba.org/unreliable-guides/NAT-HOWTO/index.html

Netzwerk in Ketten, Linux 2.2 als Internet-Gateway, Router und Firewall von Henning Emmerich, C'T17/99, Verlag Heinz Heise

Statful inspection in action, Beschreibung der „Stateful Inspection Technology“der Check Point FW-1 Firewall

Beschreibung der Unterschiede zwischen den Firewall-Technologien, http://www.avolio.com/apgw+spf.html