Vorsorge ist besser

Die aktuellen Nachrichten lassen kaum einen Zweifel zu: Microsofts Windows-Betriebssysteme scheinen sehr viren- und wurmanfällig zu sein. Linux-Anwender dürfen in den meisten Fällen gelassen auf solche Hiobsbotschaften reagieren; ihr Schaden beschränkt sich darauf, dass das höhere Verkehrsaufkommen im Internet auch sie belastet.

Schadenfreude ist hier aber fehl am Platz: Vielleicht gibt es auch bei Linux und seinen Anwendungen ähnlich fatale Sicherheitslücken, die noch nicht erkannt wurden oder in zukünftigen Versionen erst programmiert werden. Gerade der erfolgreiche Angriff auf die zentralen Debian-Server [1] zeigt, dass sich selbst erfahrene Administratoren nicht gegen alle Sicherheitslücken verteidigen können. Daher sollte jeder Linux-Anwender grundlegende Kenntnisse über die Sicherheit seines Systems, das Erkennen von Angriffen und Einbrüchen und die Reaktion darauf erwerben. Dieser Artikel zeigt, wie sich die Gefahr, Opfer eines Angriffs zu werden, gering halten lässt.

Regelmäßige Updates

Viele Hacker veröffentlichen die von ihnen gefundenen Sicherheitslücken, oft in Mailinglisten [2,3]. Häufig erhalten die Anwendungsprogrammierer und die Linux-Distributoren diese Informationen bereits im Vorfeld, so dass sie meist recht zeitnah einen Patch und Updates zur Verfügung stellen.

Am einfachsten und besten schützen sich Linux-Anwender daher vor Einbrüchen, indem sie ihr System auf dem aktuellen Stand halten. Fast jede Distribution bietet hier Update-Möglichkeiten an, die der Benutzer mit Hilfe des Cron-Daemons [4] auch automatisieren kann. Fedora aktualisiert der Anwender mit yum update; Debianer verwenden zum Beispiel die Befehle

/usr/bin/apt-get update -q -y
/usr/bin/apt-get upgrade -q -y

Dabei bringt der apt-get update-Befehl die Paketlisten der Distribution auf den aktuellen Stand. Dieser Schritt sollte vor jedem Upgrade erfolgen. Die Option -q unterdrückt unnötige Ausgaben ("quiet") auf dem Bildschirm; -y beantwortet alle auftretenden Fragen automatisch mit Ja ("yes"). Der Befehl apt-get upgrade spielt anschließend die neuesten Versionen aller installierten Pakete ein.

In dieser Form eignen sich beide Kommandos auch für einen automatischen täglichen oder stündlichen Aufruf mit dem Cron-Daemon. Dazu erzeugt der Administrator eine kleine Datei /etc/cron.daily/aktualisierung, in die er die zwei Zeilen einträgt. Nachdem er die Datei mit

chmod 755 /etc/cron.daily/aktualisierung

ausführbar gemacht hat, ruft sie der Cron-Daemon automatisch auf.

Ein sauber gepatchtes System bietet mehr Sicherheit als jede Firewall und jeder Virenscanner: Sein Verwalter muss dann nur neue, noch unbekannte Sicherheitslücken fürchten.

Minimalismus

Der zweite Schritt auf dem Weg zu einem nicht angreifbaren Rechner besteht darin, alle nicht benötigten Dienste abzuschalten. Erfreulicherweise aktivieren moderne Linux-Distributionen nicht mehr per Default sämtliche installierten Dienste.

Will der Administrator die aktuell laufenden ermitteln, so stehen hierfür zwei Möglichkeiten zur Wahl: Er kann lokal den Befehl lsof -i absetzen oder mit nmap den Rechner von außen scannen. Der Befehl lsof zeigt die offenen Dateien auf einem Linux-Rechner an. Getreu dem Unix-Spruch "Alles ist eine Datei" werden auch Netzwerkverbindungen als Dateien verstanden. Mit der Option -i zeigt lsof alle Internet-Verbindungen an; Listing 1 zeigt ein Beispiel.

[root@kermit root]# lsof -i
COMMAND    PID    USER   FD   TYPE DEVICE SIZE NODE NAME
ntpd       882     ntp    4u  IPv4   2788       UDP *:ntp
ntpd       882     ntp    5u  IPv4   2789       UDP localhost:ntp
sshd       942    root    3u  IPv4   2858       TCP *:ssh (LISTEN)
master    1019    root   11u  IPv4   2972       TCP *:smtp (LISTEN)
cupsd     1569    root    0u  IPv4   3720       TCP localhost:ipp (LISTEN)
cupsd     1569    root    2u  IPv4   3721       UDP *:631

Die erste Spalte verrät den Befehl, der die Netzwerkverbindung geöffnet hat. Rechts daneben steht seine Prozessnummer; die dritte Spalte enthält den Namen des Benutzers, mit dessen Rechten der Dienst läuft. Interessant wird es in den letzten beiden Spalten: Unter der Überschrift NODE steht das Protokoll, das der Dienst für seine Kommunikation mit der Außenwelt benutzt (TCP oder UDP), unter NAME verrät lsof die IP-Adresse und den Port des Dienstes. Dabei setzt das Programm sowohl für die IP-Adresse als auch für den Port die entsprechenden Klartextnamen aus den Dateien /etc/hosts und /etc/services ein. Dieses Verhalten lässt sich mit den Optionen -n ("no host names") und -P ("no port names") unterdrücken.

Auf dem Rechner in Listing 1 sind die folgenden Dienste aktiv: ntpd, sshd, master und cupsd. Hierbei handelt es sich um einen Zeitsynchronisationsserver, den Secure-Shell-Server, den Master-Server des Mail-Servers Postfix und den Cups-Druck-Server. Sobald als Adresse in der letzten Spalte localhost (oder 127.0.0.1) erscheint, lässt sich dieser Dienst nicht von außen, sondern nur lokal erreichen. Am interessantesten sind also die erste und die letzte Spalte der Ausgabe. Dabei kann der lsof-Befehl aber nicht erkennen, ob eine Firewall diese Dienste zusätzlich schützt.

Hierzu dient der Befehl nmap. Er ist in der Lage, die offenen Ports von außen zu erkennen. Jeder offene Port weist auf einen laufenden Netzwerkdienst hin. Anders als lsof überprüft nmap aber nicht, welcher Dienst auf diesem Port läuft, und gibt nur den wahrscheinlichen Service an. Um alle verfügbaren TCP-Dienste anzuzeigen, verwendet der Anwender den Befehl

nmap -sS IP-Adresse

.

# nmap -sS kermit
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on kermit (192.168.0.202):
(The 1594 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh
25/tcp     open        smtp
Nmap run completed – 1 IP address (1 host up) scanned in 3 seconds

Im Beispiel aus Listing 2 lassen sich von außen nur der Secure-Shell-Server auf dem Port 22 und der Postfix-Mail-Server auf dem Port 25 erreichen. Der Cups-Druckserver, über den Listing 1 informierte, ist über TCP von außen nicht ansprechbar.

Die UDP-Dienste ermittelt die Option -sU anstelle von -sS. Dabei steht hinter dem -s der Scan-Typ. Ein U weist auf einen UDP-Scan hin, während ein S einen sogenannten TCP-Syn-Scan durchführt.

Im Falle eines UDP-Scans kann nmap den Zustand des Ports nicht einwandfrei ermitteln. Da das Programm in diesem Fall auch alle Ports, die nicht antworten, als offen kennzeichnet, kommt es zu einer verwirrenden Situation: Befindet sich eine Firewall vor dem gescannten Rechner, die diese Pakete verwirft, kennzeichnet nmap alle UDP-Ports als offen!

Nicht benötigte Dienste sollten rigoros abgeschaltet werden. Üblicherweise werden sie beim Startvorgang der Linux-Distribution aktiviert. Dabei gibt es grundsätzlich zwei unterschiedliche Methoden: Entweder setzt ein eigenes Startskript im Verzeichnis /etc/init.d den Dienst in Gang oder inetd bzw. xinetd übernehmen diese Aufgabe. Die beiden letztgenannten Dienste öffnen bereits bei ihrem Start den Port und starten erst bei Bedarf den eigentlichen Dienst.

Wie man die verschiedenen Dienste deaktiviert, unterscheidet sich von Distribution zu Distribution zum Teil stark, und selbst innerhalb einer Distribution führen viele verschiedene Wege zum Ziel. (Red Hat bietet zum Beispiel die Befehle chkconfig, ntsysv und redhat-config-services für diesen Zweck an.) Daher sei an dieser Stelle auf die Artikel [5] und [6] verwiesen.

Bei unbekannten Diensten hilft häufig der Befehl man Dienstname, um zu ermitteln, ob sie benötigt werden oder nicht. Für Dienstname setzt man das Kommando ein, das lsof anzeigt. Leider sind die Informationen in diesen Manpages nicht immer sofort verständlich.

Verfügt der Anwender über ein Handbuch zur Distribution, findet er über dessen Index häufig weitere Erläuterungen zum Dienst. Eine Suche auf Google hilft ebenfalls oft weiter. Schließlich spricht nichts dagegen, einfach mal auszuprobieren, was passiert, wenn der Dienst deaktiviert und der Rechner neu gebootet wird. In den seltensten Fällen führt dies zu einem instabilen Rechner.

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.

Firewall-Meldungen analysiert

Nur die Firewall-Meldungen analysiert FWLogwatch [13]. Das Programm kann von seiner Homepage als RPM-Paket heruntergeladen werden, einige Distributionen liefern es von Haus aus mit.

FWLogwatch kennt drei verschiedene Modi (Zusammenfassung, Bericht und Echtzeitantwort), die der Anwender in der Konfigurationsdatei auswählt. Der Zusammenfassungsmodus erzeugt aus mehreren tausend Firewall-Protokolleinträgen in wenigen Sekunden eine Übersicht. So erhält der Anwender einen Überblick über die Situation seiner Firewall in den letzten Stunden und darüber, welche IP-Adressen die Firewall-Regeln am häufigsten verletzen.

Im Berichtsmodus generiert FWLogwatch für jeden Angriff automatisch eine E-Mail, die das Tool an den Administrator des "angreifenden" Rechners sendet, um ihn über das Unwesen zu informieren, das von seinem Computer bzw. seinem Netzwerk ausgeht. Häufig ist er selbst für den Angriff nicht verantwortlich, sondern selbst Opfer eines dritten Angreifers. Allerdings sollte man diesen Modus mit Vorsicht einsetzen.

Am interessantesten ist der Echtzeitmodus. Hier beobachtet FWLogwatch die Protokolle in Echtzeit und kann bei einem Angriff direkt eine E-Mail versenden. Zu diesem Zweck definiert der Administrator einen Schwellwert, bei dessen Überschreiten ein Skript aufgerufen wird. Eine Beispielkonfiguration in der Datei /etc/fwlogwatch.config zeigt Listing 5.

realtime_response = yes
parser = n
run_as = fwloguser
alert_threshold = 5
notify = yes
notification_script = /usr/sbin/fwlw_notify
server_status = yes
bind_to = 192.168.0.1
listen_port = 8888
status_user = ralf
status_password = gieOlzYkkk9sQ
refresh = 10

Dabei aktiviert realtime_response = yes den Echtzeitmodus. Da FWLogwatch die Meldungen vieler verschiedener Firewall-Werkzeuge auswerten kann, wählt man den Netfilter/IPTables-Modus für die Linux-Kernel-Firewall mit parser = n aus.

Dank run_as = fwloguser läuft FWLogwatch mit den Rechten des weniger privilegierten Benutzers fwloguser. Dieser User muss natürlich existieren (also bei der Installation angelegt werden) und Leserechte für die Protokolldatei /var/log/messages besitzen.

alert_threshold definiert die Anzahl der Ereignisse, die eine Benachrichtigung auslösen. notify = yes und notification_script = ... veranlassen mit Hilfe des angegebenen Skripts (im Beispiel /usr/sbin/fwlw_notify) eine Nachricht an den Administrator.

Zusätzlich startet FWLogwatch im Echtzeitmodus einen Webserver (server_status = yes), der den Zugriff auf die aktuelle Situation der Firewall über die IP-Adresse 192.168.0.1 (bind_to) und den Port 8888 (listen_port) erlaubt (Abbildung 2). Dazu verbindet sich der Anwender mit einem Webbrowser mit http://192.168.0.1:8888 und meldet sich als Benutzer ralf (status_user) mit seinem Kennwort (status_password) an. Das Passwort kann mit dem Befehl htpasswd -n ralf erzeugt werden.

FWLogwatch sollte nun nach jedem Rechnerneustart zu Diensten stehen. Bei der Red-Hat-Distribution aktiviert man das Programm zum Beispiel mit dem Befehl

chkconfig fwlogwatch on

Manuell lässt sich FWLogwatch mit dem Befehl /etc/init.d/fwlogwatch start aufrufen.

Abbildung 2: FWLogwatch bringt einen eigenen Webserver mit, über den sich der aktuelle Zustand der Firewall abfragen lässt.

Alle diese Vorsichtsmaßnahmen schützen jedoch nur vor aktiven Angriffen von außen. Häufig erfolgen Attacken aber über Trojaner und Viren, die der Angreifer mit Hilfe des Anwenders einschleust. So lockt der Angreifer arglose Benutzer auf eine bestimmte Webseite, auf der er ein neues Programm anbietet. Diese Software installiert gleichzeitig einen Trojaner, der anschließend die Verbindung zum Angreifer aufbaut.

Unter Linux ist das Einspielen derartiger Software zum Glück nur mit root-Privilegien möglich. Wenn der Linux-Administrator darauf achtet, nur Software aus vertrauenswürdigen Quellen zu installieren und nicht mit dem root-Konto im Internet zu kommunizieren, ist die Gefahr recht gering.

Allerdings schützt auch ein allzeit aktuell gehaltenes System nicht vor Attacken, die bislang nicht bekannte Sicherheitslücken ausnutzen. Daher kann es trotzdem immer noch zu Angriffen und erfolgreichen Einbrüchen kommen. In einer der nächsten Ausgaben zeigen wir, wie man Einbrechern auf die Schliche kommt und was im Falle eines Angriffs zu tun ist.