Vorsorge ist besser

Brandmauer

Erst nach diesen Vorarbeiten lohnt es sich überhaupt richtig, mit einer Firewall zusätzliche Sicherheit zu schaffen, die den Zugriff auf die noch vorhandenen Dienste überwacht und steuert. Ein einfaches Firewall-Skript, welches lediglich ausgehende Verbindungen und deren Antworten auf einem Linux-Rechner erlaubt, zeigt Listing 3.

Mit dem iptables-Befehl [7] verwaltet man die Firewall-Regeln im Linux-Kernel. Zunächst löscht er, mit der Option -F versehen, ein möglicherweise vorhandenes Regelwerk. Wenn Sie bereits Firewall-Regeln gesetzt haben, setzt er auch diese außer Kraft!

Anschließend legt die Option -P die Policy für die drei Ketten INPUT, FORWARD und OUTPUT auf DROP fest. So verwirft die Firewall grundsätzlich alle Netzwerkpakete, die nicht ausdrücklich akzeptiert werden. Die Kette INPUT ist für alle Pakete zuständig, die an den Rechner selbst gerichtet sind. OUTPUT filtert alle Pakete, die den Rechner verlassen. FORWARD schließlich kümmert sich auf einem Gateway um alle Pakete, die durch den Rechner geroutet werden. Listing 3 ist jedoch nicht für ein Gateway gedacht, sondern für einen normalen Arbeitsplatzrechner.

Daher betrachten wir von nun an nur die INPUT- und die OUTPUT-Kette. Da der Rechner selbst neue Netzwerkverbindungen aufbauen darf, muss OUTPUT Pakete, die dies tun (NEW), und Pakete, die zu bereits aufgebauten Verbindungen gehören (ESTABLISHED), akzeptieren. Die Angabe RELATED ist nötig, um spezielle Netzwerkfehlermeldungen und zum Beispiel FTP-Verkehr zu erlauben.

In der INPUT-Kette akzeptiert die Firewall nun alle Pakete, die zu einer vorher vom User (oder seinem Rechner) aufgebauten Verbindung gehören (ESTABLISHED) oder wieder den Zustand RELATED haben. Die letzte Zeile protokolliert nun alle weiteren Pakete, die die INPUT-Kette verarbeitet und die zuvor nicht akzeptiert wurden. Im Logfile erscheinen diese Meldungen mit dem Präfix Firewall: markiert.

#!/bin/bash
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "Firewall: "

Dieses Skript muss nun sinnvoll in den Boot-Vorgang des Rechners eingebaut werden. Dabei empfehlen sich bei den verschiedenen Distributionen unterschiedliche Herangehensweisen. In vielen Fällen reicht es, zunächst das Skript (mit root-Rechten) aufzurufen bzw. die darin stehenden iptables-Befehle auf der Kommandozeile per Hand einzugeben und anschließend den Befehl

/etc/init.d/iptables save

abzusetzen. Dieser Befehl speichert die Konfiguration so ab, dass sie bei einem Neustart automatisch wieder eingelesen wird. Weitere Informationen liefert [7].

Abbildung 1: Firestarter zeigt alle "bösen" Pakete an, die nicht von den Firewallregeln akzeptiert wurden. Die Regeln legt der Anwender zuvor mit einem Druiden fest.

Wem diese Kommandozeilenbefehle nicht geheuer sind, findet in Firestarter [9,10] (Abbildung 1) Abhilfe. Die grafische Oberfläche trügt jedoch: Ganz ohne zu wissen, wie Firewalls funktionieren, geht es trotzdem nicht. Das Firestarter-Handbuch und die IPTables-Homepage [8] bieten einen ersten Einstieg.

Protokollanalyse

Jede Firewall ist jedoch nur so gut, wie die Protokolle, die sie erzeugt, und der Administrator, der diese (und die Logdateien der übrigen aktiven Dienste auf dem Rechner) liest. Leider (oder erfreulicherweise?) erzeugt ein Linux-Rechner bis zu mehreren MByte solcher "Mitschriebe" am Tag. Es ist üblich, diese Protokolle im Verzeichnis /var/log zu speichern. Die wichtigste Protokolldatei unter Linux heißt /var/log/messages, ein Firewall-Eintrag sieht darin so aus:

Mar 19 10:12:15 kermit kernel: Firewall: IN=eth0 OUT= MAC=00:20:E0:6C:72:1E:00:50:56:C0:00:01:08:00 SRC=130.232.213.6 DST=192.168.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=29280 SEQ=1

Er besagt, dass der Kernel am 19. März um 10:12 Uhr und 15 Sekunden auf dem Rechner kermit eine Meldung erzeugte. Mit dem Log-Präfix Firewall: (vgl. Listing 3) registrierte er ein ICMP-Paket (ICMP Typ 8, Code 0 ist ein Ping-Paket) auf der Netzwerkkarte eth0. Absender war ein Rechner mit der IP-Adresse 130.232.213.6.

Dies alles zu lesen und manuell auszuwerten, ist ein Ding der Unmöglichkeit, zumal die Logdateien meist recht umfangreich ausfallen. Da greift man besser zu Werkzeugen, die diese Arbeit automatisieren. Hier hat der Administrator die Qual der Wahl: Neben auf Webserver (siehe Seite 68 ff.) oder auf Firewalls spezialisierten Tools gibt es Alleskönner wie Logwatch [11] und Logsurfer [12].

Logwatch ist Bestandteil vieler Distributionen und komplett vorkonfiguriert. Mit dem Befehl logwatch manuell gestartet, analysiert das Tool die Protokolldateien des Rechners und meldet ungewöhnliche Einträge per E-Mail an den Administrator. Bei vielen Distributionen startet es der Cron-Daemon bereits von sich aus. Hierzu existiert meist im Verzeichnis /etc/cron.daily ein kleines Skript oder eine Verknüpfung, über die Cron das logwatch-Kommando täglich aufruft.

Anhand von Meldungen, die auf Fehler oder Einbrüche hinweisen, kann der Mensch die Protokolldatei dann genauer analysieren. So zeigt Logwatch fehlerhafte Anmeldeversuche so an wie in Listing 4.

Subject: LogWatch for kermit.spenneberg.de
Date: Tue, 27 Jan 2004 10:33:29 +0100 (CET)
From: root@kermit.spenneberg.de (root)
 ################### LogWatch 4.3.1 (01/13/03) ####################
       Processing Initiated: Tue Jan 27 10:33:28 2004
       Date Range Processed: yesterday
     Detail Level of Output: 0
          Logfiles for Host: kermit.spenneberg.de
 ################################################################
 ——————— pam_unix Begin ————————
su:
   Authentication Failures:
      spenneb(500) -> root: 1 Time(s)
xscreensaver:
   Unknown Entries:
      authentication failure; logname= uid=500 euid=500 tty=:0.0 ruser= rhost= user=spenneb 1 Time(s)

Hier scheiterte der Benutzer spenneb einmal beim Versuch, mit dem Befehl su root-Rechte zu erlangen, und einmal bei der Angabe des Passworts beim Bildschirmschoner xscreensaver.

Während Logwatch die Protokolldateien in regelmäßigen Abständen analysiert, überwacht Logsurfer sie in Echtzeit. Damit meldet dieses Tool mutmaßliche Angriffe und Einbrüche wesentlich zeitnaher. Allerdings erfordert Logsurfer eine recht aufwändige Konfiguration, die den Rahmen des Artikels sprengen und einen eigenen Artikel verdienen würde. Interessierten Lesern sei die Logsurfer-Homepage [12] und [14] empfohlen.