|
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.
|
Eine Angriffsmöglichkeit gegen Protokollierungsmechanismen
besteht darin, wahnsinnig viele Log-Einträge zu
generieren, so das
- der begrenzte Speicherplatz aufgebraucht und
- 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.
|
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.
|
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 **
|
|
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
root@linux #
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)).
|
|
|