SelfLinux Sicherheit Grundlagen Sicherheit Abschnitt 10 | SelfLinux-0.13.0

| Grundlagen Sicherheit | Autoren Formatierung GFDL

#### 10 Systemüberwachung (Logging und Accounting)

#### 10.1 Einleitung Systemüberwachung

Eine Grundforderung an vertrauenswürdige Systeme ist die Nachvollziehbarkeit des Systemverhalten. Bei Linux werden verhaltensrelevante Ereignisse in so genannten Logfiles gespeichert, die meist unter /var/log zu finden sind. Die wichtigsten Systemlogfiles sind:

- messages
- auth.log
- kern.log

In den Protokolleinträgen finden sich Hinweise, warum sich z.B. ein Dienst nicht starten läßt oder das mehrere Login-Versuche fehlgeschlagen sind. Meist erfolgt zu jedem Protokolleintrag eine Zeitangabe.

So wie der xinetd als Superserver für das Starten der Dienste zuständig ist, gibt es auch einen Protokolldienst, den syslogd. Dieser wurde äußerst detailliert in einem eigenständigen Selflinux- Kapitel beschrieben und soll deshalb an dieser Stelle nicht nochmals betrachtet werden. Thema dieses Abschnittes sind Mechanismen zum Schutz der Logfiles. (Kernelmeldungen werden vom klogd entgegengenommen und verarbeitet, das Programm dmesg gibt diese Meldungen aus.)

Weitaus mehr Schutzmöglichkeiten bietet die neue Variante von syslog, der syslog-ng. Dieser ist jedoch derart komplex, dass sich in Zukunft ein eigenständiges Kapitel damit beschäftigen wird.

Sehr interessant auch die Kombination von PHP, mySQL und syslog-ng, mit welcher sich das Open Source Projekt php-syslog-ng beschäftigt.

#### 10.2 Schutz vor "Überlaufen" der Logfiles

Eine Angriffsmöglichkeit gegen Protokollierungsmechanismen besteht darin, wahnsinnig viele Log-Einträge zu generieren, so das

1. der begrenzte Speicherplatz aufgebraucht und
2. die Logfiles sehr unübersichtlich

werden. Abhilfe verspricht das Programm logrotate, welches Log-Dateien rotieren lässt. Was heißt das? Wenn ein Logfile eine bestimmte Größe oder ein bestimmtes Alter erreicht hat, wird es komprimiert, gesichert und umbenannt. Die nun zu protokollierenden Meldungen werden in einem neu angelegten (leeren) Logfile gesichert. Die Anzahl der Rotationsvorgänge, nach denen ein Logfile-Backup endgültig gelöscht wird, kann man einstellen. In Kombination mit dem Schutz vor DOS-Attacken des xinetd (instances, per_source) kann ein Überlaufen der Logfiles verhindert werden, und die sicherheitsrelevanten Einträge bleiben bei einem versuchten Einbruch erhalten.

#### 10.3 Schutz vor Löschen und Manipulation der Einträge

Drucker

> Falls ein alter Drucker zur Verfügung steht, kann man diesen für die Protokollierung besonders sensitiver Logfiles benutzen. Die Konfiguration erfolgt innerhalb der /etc/syslogd.conf beziehungsweise der /etc/syslog-ng.conf .

Loghost

> Logfiles können auf einem dedizierten zentralen Server abgelegt werden. Einen solchen Rechner nennt man Loghost. Damit dieser Server auch Meldungen anderer Rechner entgegen nimmt, muss man den syslogd mit dem Parameter -r starten. Die Kommunikation zwischen Client und Loghost erfolgt auf Port 514/udp, und genau dies eröffnet einem Angreifer große Möglichkeiten (Beobachtung, Fälschen von Meldungen, DOS-Attacke). Deshalb sollte der Loghost niemals von außen erreichbar sein. Detaillierte Informationen zur Konfiguration und zu den damit verbundenen Gefahren finden Sie im syslog Kapitel.

Nun, welche Sicherheitsmaßnahmen sollten unbedingt erfolgen:

- Der Loghost sollte nur per Konsole zugänglich sein (nicht ssh, http, ftp oder Ähnliches). Somit kann ein Angreifer von Außen keine Log-Einträge löschen.
- Der Loghost ist der Loghost und nichts als der Loghost. (also keine weiteren Dienste wie Routing, Mail oder DNS)
- Der Loghost sollte zusätzlich durch einen für seine Anforderungen angepassten Paketfilter abgeschottet sein.
- Der Loghost sollte "nicht sichtbar sein" und somit nicht auf PING-Anfragen (ICMP Messages) antworten. (echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all)

Folgende Maßnahmen erfordern relativ großen Aufwand:

- Erlangt ein Angreifer die Macht über einen Client, so findet er in dessen sylog.conf den Hinweis auf den Server. Um diese Schwachstelle zu beseitigen, könnte man den syslog Dienst auf jedem Client derart manipulieren, dass dieser eine andere Konfigurationsdatei lädt. Dazu muss man natürlich den syslog-Quellcode patchen und neu übersetzen.... Darauf wird in einem später folgenden Artikel detaillierter eingegangen.
- Die Kommunikation zwischen Loghost und angeschlossenen Clients sollte verschlüsselt werden (z.B. stunnel).

Eine englischsprachige Kurzanleitung unter http://www.campin.net/newlogcheck.html beschreibt den Aufbau eines Loghosts mit syslog-ng, mysql, swatch und stunnel.

#### 10.4 Überwachung der Verbindungen (Login / Connection Accounting)

Die Verbindungszeiten der Systembenutzer, also WANN WER WO eingeloggt war, werden in der Datei /var/log/wtmp gespeichert. Da diese jedoch binär vorliegt, benötigt man das Programm last.

user@linux $ last root tty1 Sun Sep 3 11:45 -12:14 (00:29) ai114 tty7 Sun Sep 3 13:45 -15:56 (02:11) wtmp begins Tue Jan 15 13:54:09 2003

Mit lastlog wird die Datei /var/log/lastlog in menschenlesbarer Form ausgegeben.

user@linux $ lastlog Benutzer Port Von Letzter root tty1 Mon Jul 14 21:05:29 +0200 2003 daemon **Nie angemeldet ** bin **Nie angemeldet ** ai114 :0 Die Jul 15 12:58:19 +0200 2003 mysql **Nie angemeldet **

#### 10.5 Überwachung der Prozesse (Process Accounting)

Im Gegensatz zur Verbindungsüberwachung lassen sich beim Process Accounting genaue Aussagen über genutzte Systemressourcen (CPU, Speicher, IO) treffen.

Die Programme aus dem Paket acct erlauben detaillierte Aufstellungen der verbrauchten Ressourcen sowie einer Zuordnung zu einem Systembenutzer und natürlich dem genauen Zeitpunkt (minutengenau).

Connection Accounting muss explizit im Kernel aktiviert werden (General Setup --> BSD Process Accounting). Die eigentlichen Aufzeichnungen übernimmt jedoch wieder ein Daemon, er wird durch den Aufruf

root@linux # accton /var/log/logfile

gestartet und kann durch den Aufruf ohne zusätzliche Optionen wieder deaktiviert werden. (Optional SysV-Initskript analog zu "quota")

# Start der Aufzeichnung root@linux # accton /var/log/psacct # Ende der Aufzeichnung root@linux # accton

Für die Auswertung stehen drei Programme zur Verfügung:

lastcomm | vollständige Aufzeichnung aller Prozesse (user, tty, CPU Zeit, Zeitpunkt)
sa | statistische Zusammenfassung (verschiedene Sortieroptionen)
ac | Statistik der Verbindungszeiten

#Ausgabe aller Prozesse für Benutzer user007
root@linux # lastcomm user007
Eterm user007 ?? 2.05 secs Wed Jul 16 17:34
bash user007 ?? 0.43 secs Wed Jul 16 17:34
bash F user007 ?? 0.00 secs Wed Jul 16 17:56
tty user007 ?? 0.03 secs Wed Jul 16 17:56
mozilla-bin F user007 ?? 0.00 secs Wed Jul 16 17:52
mozilla-bin F user007 ?? 0.00 secs Wed Jul 16 17:52
mozilla-bin F user007 ?? 0.00 secs Wed Jul 16 17:52
mozilla-bin F user007 ?? 0.02 secs Wed Jul 16 17:52
quota user007 ?? 0.04 secs Wed Jul 16 17:43
rm user007 ?? 0.15 secs Wed Jul 16 17:43
# Statistik nach Nutzern
root@linux # sa -m
ai114 2644 14363398.28re 2248.20cp 0avio 10689k
root 22701 6829449.23re 314.14cp 0avio 552k
mail 54 984.15re 0.14cp 0avio 1006k
user007 15 3.78re 0.02cp 0avio 505k
mysql 20 0.35re 0.00cp 0avio 17392k
# Statistik nach IO-Operationen sortiert:
root@linux # sa -ad
25450 21211810.82re 2563.42cp 0avio 1621k
3508 4565.43re 8.46cp 0avio 340k grep
2183 23553.40re 1.74cp 0avio 347k mgetty
1999 272.72re 0.76cp 0avio 331k mv
1973 320.78re 0.77cp 0avio 297k basename
1957 162216.27re 6.55cp 0avio 644k sh
1483 4579495.53re 6.76cp 0avio 18518k mozilla-bin*
923 255.08re 0.47cp 0avio 363k rm
793 19297.68re 0.57cp 0avio 373k gcc
...
...
# Verbindungszeiten
root@linux # ac -d
Jul 15 total 9.29
Jul 16 total 14.55
Jul 16 total 1.20
Jul 16 total 0.91
Today total 7.86
#Verbindungszeiten aller Benutzer:
root@linux # ac -p
root 1.47
user007 32.37
total 33.84

Weitere Informationen sind wie gewohnt in den man-Pages zu finden (ac(1), accton(8), lastcomm(1) und sa(8)).