Brandmauer

Nur wer sein System selbst baut und sich nicht auf Fertigware von der Installations-DVD verlässt, kennt es so gut, dass er unnötige Sicherheitsrisiken ausschließen kann. Eine Bauanleitung zeigt, wie sich mit wenigen Tools eine komplette Linux-Firewall aufsetzen lässt.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 5 Min.
Von
  • Lukas Grunwald

Will man sich nicht darauf verlassen, dass man bei einer Installation einer fertigen Distribution alle Sicherheitslöcher schließen kann, kann man alternativ dazu ein eigenes minimales Linux-System selbst aufsetzen.

Die Beispielkonfiguration geht von folgendem Szenario aus: die Linux-Box dient als Paketfilter und Firewall, alle eingehenden Verbindungen in das Intranet sind blockiert, ausgehende FTP- und HTTP-Anfragen gehen über einen transparenten Proxy, SSL- und alle anderen ausgehenden Verbindungen sind erlaubt.

Ein Konsolenserver - über eine serielle Schnittstelle mit der Firewall verbunden - dient zur Outband-Administration, zum Ändern des Regelsatzes und zum Weiterleiten von Log-Meldungen zu einem Syslog-Server. Die Systemzeit ist via NTP synchronisiert, die Linux-Box verfügt über keine weiteren Dienste im Userspace. Auf Benutzer, ein Init-System und Anwendungen, die den Paketfilter aufblähen, wird gezielt verzichtet. Firewall und Paketfilter sind mit iptables realisiert.

Ein Vorteil von iptables gegenüber anderen Firewalls besteht darin, dass sie keine aufwendige Umgebung erfordert: Mit einer Hand voll Komponenten lässt sich ein System bauen, das auf eine Diskette passt. Neben einem monolithischen Kernel braucht man einen Bootloader wie syslinux oder GRUB, will man nicht von Ersterem booten. Für schlanke Systeme stellt außerdem die Kommandosammlung busybox auf Grundlage der ash eine Benutzerumgebung mit den wichtigsten Kommandos als so genanntes Multi-Call-Binary zur Verfügung. Für das Initialisieren der Filterregeln sorgt iptables, für die Zeitsynchronisation der ntp-Dämon.

Weitere Komponenten sind nicht nötig. Auf einen Syslog-Dämon kann ebenso verzichtet werden wie auf den Kernel-Log-Dämon, da der Linux-Kernel beim Fehlen eines Syslog-Services automatisch alle Meldungen auf die Konsole schreibt, in diesem Fall über die serielle Verbindung auf dem Konsolenserver ausgibt. Damit das System auf dynamische Libraries verzichten kann, sind alle Programme statisch gelinkt. Das macht das System nicht nur schlanker und übersichtlicher, sondern verhindert auch Schwachstellen durch die libc.

Aufgrund der Größe lässt sich das System komplett in einer RAM-Disk betreiben. Dazu benutzt man eine initrd (Initial RAM Disk), die das Rootfilesystem enthält und deren Image als Datei neben dem Kernel auf einem bootfähigen Medium liegt. Bootloader, Kernel und Image der Firewall können dadurch auf einer Embedded-Hardwareplattform mit Flash-Speicher, einem bootfähigen USB-Stick, einer CD oder einer Floppy mit Schreibschutz untergebracht sein. Ebenso kann man das System via PXE (Preexecution Environment) übers Netz starten und damit ein Cold-Standby-System aufbauen, das sich ohne Softwareinstallation etwa über einen Power-Switch hochfahren lässt, wenn das Erstsystem ausfällt. In allen Fällen sind als einzige Schnittstellen für den Betrieb die serielle Verbindung zum Konsolenserver und die Netzwerk-Interfaces vonnöten.

Um ein derartiges System bauen zu können, braucht man einen separaten Linux-Rechner mit RAM-Disk-Unterstützung, GCC (Gnu Compiler Collection), Kernelquellbaum und Openwall-Patches. Dazu gesellen sich die Quellen von busybox, ntp und iptables, da man alle Tools als statisch gelinkte übersetzen muss. Als Beispiel soll die Firewall in einer RAM-Disk liegen und von CD starten. In diesem Fall benötigt man noch einen CD-Brenner und die cdrtools. Als Vorarbeit sollte man zuerst ein CD-Wurzelverzeichnis - etwa ~/CD_ROOT - anlegen, aus dem später das CD-Image gebaut wird.

Beim Übersetzen des Kernels sind alle Regeln des Kernelhärtens zu befolgen: In den monolithischen - also nicht-modularen - Vanilla-Kernel mit Openwall-Patches gehören nur die Treiber, die für den Betrieb wirklich notwendig sind (s. Tutorial/1, iX 11/2003). Während der Kernelkonfiguration ist vor allem darauf zu achten, dass der RAM-Disk- und Initrd-Support ebenso wie ext2 und /proc aktiviert sind. Zusätzlich muss das Device-Filesystem devfs mit der Option „Automatically mount at boot“ eingebunden sein, um sich das manuelle Erzeugen der Device-Dateien in /dev zu ersparen - sonst schlägt das Booten fehl.

Soll das komplette Linux-System in einer RAM-Disk liegen, kann man auf SCSI-, IDE- respektive USB-Treiber getrost verzichten, Treiber für Festplatten oder andere Peripheriegeräte sind ebenfalls überflüssig. Lediglich die serielle Konsole sollte Unterstützung durch den Kernel finden. Außerdem ist es sinnvoll, neben den Netzwerkadaptern den „Dummy net driver support“ zu aktivieren. Für die Firewall gehören iptables und weitere erwünschte Filter- und Routing-Funktionen sowie Protokollunterstützungen in den Kernel. iptables und Kernel unterstützen, wenn angewählt, sowohl IPv4- als auch IPv6- und ARP-Filtering.

Um sich nicht den Kernel und die System.map auf seinem System zu überschreiben, empfiehlt es sich, im Haupt-Makefile vorübergehend den Installationspfad auf ~/CD_ROOT zu setzen: export INSTALL_PATH= ~/CD_ROOT, danach kann man ruhigen Gewissens den Befehl make dep && make && make install eingeben.

In der Printausgabe lesen Sie mehr über die Einrichtung der benötigten "Benutzerumgebung" und das Erstellen des Bootmediums. Außerdem im Heft: "Der Linux-Kernel 2.6."

Mehr Infos

Tutorial Inhalt

Teil 1: Härten und Abspecken eines sicherheitsrelevanten Linux-Minimalsystems am Beispiel eines dedizierten Webservers.

Teil 2: Erstellen von Ereignismitschnitten und Auswertung von Log-Dateien.

Teil 3: Konfigurieren und Härten einer Firewall am Beispiel von Linux. Planung, Dokumentation und Aufbau von Audit-Kreisläufen.


(sun)