Normalerweise senden IPtables-Firewalls ihre Protokolle an den Syslog-Daemon. Doch bei größeren Datenmengen wird der Dienst zum Engpass für System und Admin. Dann helfen der Log-Daemon Ulogd und das Analysetool Nulog, beide verwenden eine MySQL-Datenbank für die Protokolle.

Spätestens seit Kernel 2.4 sind Linux-Firewalls [1] mindestens gleichwertig zu kommerziellen Produkten. Sie loggen vergleichbar ausführlich und exakt, oft sogar besser. Nur ist der einfache Syslog mit dieser Aufgabe schnell überfordert und manuell die »/var/log/messages« durchsuchen verschwendet Zeit (siehe den Artikel zur Log-Auswertung in diesem Heft). Netfilter-Projektleiter Harald Welte hat mit seinem Ulogd [2] daher einen leistungsfähigen und flexiblen, datenbankgestützten Syslog-Ersatz geschaffen, mit dem Linux auch beim Logging zur Spitzengruppe aufschließt.

Neues IPtables-Target

Statt Meldungen an das »LOG«-Target zu senden (Syslog) setzt der Admin in seinen »iptables«-Aufrufen »-j ULOG« ein. Der Kernel sendet die Logs dann über Netlink-Multicast-Sockets an das Userspace-Gegenstück namens Ulogd. Dieser flotte Daemon schreibt die Einträge zum Beispiel in Syslog-ähnliche Protokolldateien oder in eine Datenbank. Letzteres ist vor allem bei größeren Log-Mengen zu empfehlen. Außerdem ist das ULOG-Target mit Parametern einstellbar, um das Datenvolumen an die Leistung der Hardware anzupassen. Die Anleitung in [3] beschreibt diese Parameter.

Doch das Gespann funktioniert nur, wenn im Kernel der »ULOG target support« aktiviert ist. Die Option heißt in der Konfigurationsdatei »IP_NF_TARGET_ULOG«, in der grafischen »make xconfig«-Konfiguration versteckt sie sich recht gut im IPtables-Support (Abbildung 1). Zudem ist der Userspace-Daemon Ulogd [2] nötig. Er lässt sich schnell installieren:

./configure --with-mysql=/usr/lib/mysql
make
make install

Treten Probleme beim Übersetzen auf, fehlt meist das MySQL-Devel-Paket (also Header und Bibliotheken).

Nach der Installation liegt die Konfigurationsdatei in »/usr/local/etc/ulogd.conf« (Listing 1). Die meisten Einstellungen sind sinnvoll vorbelegt. Wichtig ist, die Plugins für die gewünschten Speichermethoden zu aktivieren. Das Beispiel schreibt Syslog-ähnliche Protokolldateien (»LOGEMU«, Zeile 2), Datenbankeinträge (»MYSQL«, Zeile 3) und Traceroute-ähnliche Dumps (»PCAP«, Zeile 4).

Jedes Plugin erhält eine eigene Konfigurationssektion. Während »[LOGEMU]« und »[PCAP]« nur einen Dateinamen brauchen sowie die Angabe, ob jeder Eintrag ohne Zwischenspeichern auf der Platte landen soll (»sync=1«), verlangt der Datenbank-Connect mehr Informationen (Zeilen 10 bis 15).

Für den ersten Start mit »/usr/local/sbin/ulogd -c /usr/local/etc/ulogd.conf« empfiehlt es sich, das MySQL-Plugin (Zeile 3) auszukommentieren, da Ulogd schnell mit einem Speicherzugriffsfehler abstürzt, wenn die MySQL-Konfiguration nicht passt. Folgender IPtables-Eintrag sendet erste Daten an Ulogd:

iptables --dst www.linux-magazin.de -A OUTPUT -j ULOG

Als Test genügt ein Ping-Aufruf: »ping -c3 www.linux-magazin.de«. Im Log sollten unverzüglich die ersten Einträge landen. Listing 2 zeigt, wie das beim Syslog-Emulationsmodus von Ulogd aussieht: Die Einträge in »/var/log/ulogd.syslogemu« protokollieren mit Datum, Uhrzeit und Hostnamen alle erforderlichen Infos. Zu sehen ist dort, dass der Host mit der IP-Adresse 10.1.1.2 das Ziel 62.245.157.216 über das Interface »wlan0« mittels ICMP-Typ 8 erreicht hat. Eleganter als diese Syslog-Nachahmung ist es allerdings, die Meldungen in einer MySQL-Datenbank zu protokollieren.

Integration mit MySQL

Um die Ulogd-Einträge aufzunehmen, braucht der MySQL-Server eine separate Datenbank und einen separaten User. Die Datenbank heißt laut Zeile 14 von Listing 1 »ulogd« und der User »ulog« (Zeile 13), das Passwort lautet »geheim« (Zeile 12). Die erforderlichen Tabellen erzeugt ein Skript, das dem Ulog-Analysetool Nulog [4] beiliegt. Es erzeugt nebenbei ein paar zusätzliche Tabellen und Indizes, um performanter zu arbeiten.

Abbildung 1: Im Kernel (hier 2.6.13) muss das ULOG-Target aktiviert sein. Die Option versteckt sich unter »Networking | Network Options | Network packet filtering | IP: Netfilter Configuration | IP tables support | ULOG target support«.

Analyse mit Nulog

Nulog ist ein in PHP programmiertes Webinterface für das Auswerten von Ulogd-Daten, die in einer MySQL-Datenbank liegen. Es genügt bereits, das Tar-Archiv von [4] im Wurzelverzeichnis des Webservers zu entpacken und auf die Dateiberechtigungen und die Besitzrechte zu achten.

Im Unterordner »nulog/scripts« finden sich diverse Hilfsprogramme, unter anderem »ulogd.mysqldump« zum Anlegen der MySQL-Tabellen. Leider hat sich in Zeile 53 dieses Skripts ein Fehler eingeschlichen:

user_id smallint(5) unsigned default NULL
user_id smallint(5) unsigned NOT NULL

Die erste Zeile zeigt die Originalfassung, darunter steht die Korrektur.

Zunächst erzeugt der Admin die Datenbank per »mysqladmin create ulogd«, danach bereitet der Aufruf »mysql -u ulog -p ulogd < ulogd.mysqldump« die Datenbank auf den Ulogd-Nulog-Betrieb vor. Nun fehlen dem Nulog-Interface nur noch ein paar Anpassungen in der zentralen Konfigurationsdatei »include/config.inc«, Listing 3 zeigt die dafür relevanten Einträge.

Abbildung 2: Das Firewall-Analysewerkzeug Nulog liest die mit Ulogd gesammelten Logs aus der MySQL-Datenbank und stellt sie übersichtlich per Webinterface dar. Hier ist ein einzelner Zugriff auf die Webseite des Linux-Magazins protokolliert, zu sehen sind der Quellrechner 10.1.1.2 und der TCP-Port 80.

Der erste Versuch des Autors, auf Nulog zuzugreifen, schlug fehl. Es stellte sich heraus, dass die Skripte bei allen SQL-Abfragen störende runde Klammern »(« oder »)« hinzufügen. Das lässt sich durch eine Änderung in der Datei »include/functions.inc« abstellen:

$query = preg_replace("/(+|)+/", "", $query);

Dieser reguläre Ausdruck – eingefügt in Zeile 111 der Datei – entfernt die Klammern aus den Abfragen, dann präsentiert ein Aufruf der Startseite »http://localhost./nulog« das Interface.

Für Leben im Log sorgt ein Besuch auf der Internetseite des Linux-Magazins. In Abbildung 2 ist zu erkennen, dass der Host mit der IP-Adresse 10.1.1.2 für diesen Abruf 61 Pakete übertragen hat. Erstmals aufgezeichnet wurde der Zugriff am 6.9.2005 um 23:04 Uhr. Die Tabelle enthält folgende Felder:

• Die Spalte »Host« gibt an, welche IP-Adresse die
  Verbindung initiiert hat.
• »Pckts« zeigt, wie viele Datenpakete der Host
  bereits gesendet hat.
• Die letzten beiden Spalten nennen den Zeitstempel der ersten
  und letzten Datenübertragung.

Ein Klick auf die IP-Adresse eines Hosts führt zu einer Detailansicht seiner Verbindungen (Abbildung 3).

01 # output plugins.
02 plugin="/usr/local/lib/ulogd/ulogd_LOGEMU.so"
03 plugin="/usr/local/lib/ulogd/ulogd_MYSQL.so"
04 plugin="/usr/local/lib/ulogd/ulogd_PCAP.so"
05 
06 [LOGEMU]
07 file="/var/log/ulogd.syslogemu"
08 sync=1
09 
10 [MYSQL]
11 table="ulog"
12 pass="geheim"
13 user="ulog"
14 db="ulogd"
15 host="localhost"
16 
17 [PCAP]
18 file="/var/log/ulogd.pcap"
19 sync=1

01 Jul 27 13:39:53 baldur IN= OUT=wlan0 MAC= SRC=10.1.1.2 DST=62.245.157.216 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=50443 SEQ=0
02 Jul 27 13:39:54 baldur IN= OUT=wlan0 MAC= SRC=10.1.1.2 DST=62.245.157.216 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=1 DF PROTO=ICMP TYPE=8 CODE=0 ID=50443 SEQ=1
03 Jul 27 13:39:55 baldur IN= OUT=wlan0 MAC= SRC=10.1.1.2 DST=62.245.157.216 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=2 DF PROTO=ICMP TYPE=8 CODE=0 ID=50443 SEQ=2

Die Stats-Übersichtsseite stellt viele Möglichkeiten bereit, um Datenverbindungen zu verfolgen. Zieladresse und Zielport verlinken auf Seiten, die zeigen, welche Hosts versucht haben, die IP-Adresse 62.245.157.216 zu erreichen, oder welche Kommunikation über den HTTP-Port (80) lief. Suchfelder im unteren Rand der Webseite erlauben gezielte Abfragen nach Quellhost, Zielport und Transportprotokoll (TCP oder UDP).

Abbildung 3: Die Nulog-Statistikseite für Host 10.1.1.2 listet jedes Paket auf, das dieser Rechner versandt hat. Die Hyperlinks bei den einzelnen Einträgen führen zu weiteren Analyseseiten.

Abbildung 4: Die übersichtlichen Stats-Seiten von Nulog entlarven Portscans: Vom gleich bleibenden Quellport sendet die Maschine 192.168.13.1 in schneller Folge einzelne Pakete an wechselnde Zielports des Opfers 192.168.13.10.

Weniger ist mehr

Um auch bei vielen Verbindungen die Datenmenge in erträglichen Größen zu halten, liefert Nulog die Skripte »scripts/ulog_rotate_daily.sh« und »scripts/ulog_rotate_weekly.sh«. Sie befreien die Datenbank von älteren Einträgen und vermeiden damit unnötige Geduldsproben, die bei Statistiken zu Millionen von Datensätzen auftreten.

01 # Whether your firewall is a
02 # NuFW (users aware) firewall.
03 $nufw_enabled="no";
04 # database host
05 $db_host="localhost";
06 # database name
07 $db_ulog="ulogd";
08 # database user
09 $db_user="ulog";
10 # database password
11 $db_pwd="geheim";

Portscans erkennen

Ein kleines Praxisbeispiel zeigt, wie schnell Admins dank Ulogd Unregelmäßigkeiten auf die Schliche kommen. Vielen Einbruchsversuchen geht ein Portscan voraus. Dieses neugierige Datensammeln sollten Firewall-Betreuer erkennen und richtig bewerten. Hierfür reicht es aus, die Input-Chain mit genereller Überwachung zu versehen:

iptables -A INPUT -i eth0 -m state --state NEW -j ULOG

Nun meldet IPtables jeden Verbindungsaufbau an das ULOG-Target und Ulogd protokolliert diesen Versuch. Wenn ein entfernter Angreifer einen Portscan gegen den Rechner richtet, fällt das schnell auf. Abbildung 4 zeigt, dass von einem Source-Port (»Sport«, in diesem Fall 43131) verdächtig viele Verbindungen zu wechselnden Ziel-Ports (»Dport«) gehen. Die »PacketId« erhöht sich meist nur um eins, der Absender schickt also jeweils nur ein einzelnes Datenpaket an den Dienst. Ein weiteres Indiz ist die »Date«-Spalte. Sie belegt, dass die Datenpakete in sehr kurzen Zeitabständen eintreffen.

Performant und praktisch

Die Kombination aus dem Webinterface Nulog und dem Syslog-Ersatz Ulogd dient Firewall-Admins als mächtiges Werkzeug. Sie sammeln detailreiche Protokolle und helfen dabei, die Übersicht im Log zu behalten. (fjl)