Jedes UNIX-System ist mit umfassenden Protokollierungs- und Loggingmöglichkeiten ausgestattet. Hierbei werden Informationen auf System-, Anwendungs- und Protokollebene verarbeitet und an Standard- oder gemeinsam genutzten Logdateien ausgegeben. Teilweise gestaltet es sich jedoch als äußerst mühsam aus den Dateien die Informationen zu ziehen, die gerade zu einem bestimmten Zeitpunkt benötigt werden. Um dieser Problematik zu entgehen gibt es eine Reihe von zusätzlichen Hilfsmitteln, mit denen die Dateien gezielt aufbereitet und analysiert werden können.
Die meisten systemeigenen Logdateien werden zeilenweise von irgendwelchen Systemaktivitäten »gefüllt«, so wird beispielsweise jedes Mal, wenn sich ein Anwender an- oder abmeldet, ein entsprechender Eintrag in der Datei wtmp protokolliert, unabhängig davon ob der Versuch erfolgreich war oder nicht.
Die meisten Logdateien befinden sich entweder im Verzeichnis /var/adm bzw. unter /var/log (Solaris, Linux, FreeBSD). Sehen wir uns die wichtigsten Dateien einmal genauer an. Dabei kann es vereinzelt zu Abweichungen bezüglich der Dateinamen kommen bzw. es müssen auch nicht alle aufgezählten Logdateien auf dem jeweiligen System vorhanden sein.
Mit den Dateien utmp und wtmp liegen zwei Binärdateien vor, die Informationen über die Login-Zeiten der Anwender liefern. Die erstgenannte Datei befindet sich normalerweise, abweichend im Verzeichnis /etc. Die Datei utmp wird bei Aufrufen von finger, who, users, usw. ausgewertet, das heißt sie liefert die Informationen über die Anwender, die sich zum gegenwärtigen Zeitpunkt eingewählt haben.
Die zweite Datei, wtmp, protokolliert außerdem den Zeitpunkt, wann sich ein Anwender abgemeldet hat und bezieht sich nicht nur auf den gegenwärtigen Zeitpunkt.
Eine Auswertung erfolgt durch den Befehl last,
# last root root ttyv0 Mon Jun 18 07:40 still logged in root ttyv0 Sat Jun 16 08:29 - shutdown (13:15) root ttyv0 Fri Jun 15 19:21 - shutdown (01:50) root ttyv0 Thu Jun 14 08:25 - shutdown (05:55) root ttyv0 Tue Jun 12 15:56 - shutdown (05:00) root ttyv0 Tue Jun 12 08:44 - shutdown (04:32) root ttyv1 Mon Jun 11 08:34 - shutdown (14:19) root ttyv0 Mon Jun 11 08:31 - shutdown (14:21) root ttyv0 Sun Jun 10 16:25 - shutdown (05:29) root ttyv0 Sun Jun 10 16:19 - shutdown (00:03) wtmp begins Sun Jun 10 16:16:50 2001
Die obige Ausgabe wurden einem Host entnommen, auf dem FreeBSD neu installiert wurde. Die Datei wtmp hat, im Gegensatz zu utmp, die Angewohnheit relativ schnell und stetig anzuwachsen. Deshalb sollten hier regelmäßig Backups durchgeführt werden.
Falls der Verdacht besteht, dass ein unbefugter Eindringling auf einem Host war, kann die Auswertung der obigen Dateien wertvolle Informationen liefern. Allerdings sind beide Dateien, mit den entsprechenden »Hilfsprogrammen«, relativ leicht manipulierbar.
Somit stellt sich die Frage, wie derartige Manipulationen abgewehrt werden können. Generell ist es am sinnvollsten, zusätzliche Tools zu nutzen. Diese Vorgehensweise bietet zwei Vorteile, zum einen sind diese Tools von Eindringlingen schwer zu umgehen und zum anderen werden, zumindest teilweise unabhängige Logdateien generiert, die nicht die systemeigenen Logdateien als Ausgangsbasis nutzen. Ein möglicher Eindringling muss demnach sowohl die systemeigenen als auch die durch Zusatztools generierten Logdateien manipulieren, um unbemerkt zu bleiben.
Eine weitere Möglichkeit besteht in der regelmäßigen Überprüfung der Datei mit chkwtmp, welches unter [1.] erhältlich ist. Nachdem das Programm entpackt, installiert und aufgerufen wurde, wird eine mögliche Manipulation beispielsweise wie folgt angezeigt,
# chkwtmp 1 deletion(s) between Sat May 12 16:16:50 2001 and Sun May 20 23:34:56 2001
chkwtmp wurde für SunOS geschrieben und muss für weitere Derivate eventuell angepasst werden.
Die meisten unter UNIX vorhandenen Logdateien haben eine Gemeinsamkeit. Für die Generierung ist ein Programm verantwortlich, welches die ganze Zeit über ausgeführt wird, syslogd. Wenn eine Nachricht, Fehler oder Warnung protokolliert werden soll, wird zuerst syslog aufgerufen, welcher die Information anschließend syslogd übergibt, der wiederum die Meldung in die zugehörige Logdatei schreibt. Die jeweiligen Meldungen werden nach zwei Eigenschaften protokolliert, des jeweiligen Typs und der Priorität.
Bezüglich des Typs sind folgende Eigenschaften zugelassen:
| Typ | Beschreibung | facility |
|---|---|---|
| auth | Authorisierungsprogramme jeglicher Art | LOG_AUTH |
| cron | Cron-Daemon | LOG_CRON |
| daemon | verschiedene System-Daemons | LOG_DAEMON |
| kern | vom Kernel generierte Nachrichten | LOG_KERN |
| local0 - 7 | reserviert für lokale Zwecke | LOG_LOCAL0 - 7 |
| lpr | Druckersysteme | LOG_LPR |
| Mailsystem | LOG_MAIL | |
| news | Newssystem | LOG_NEWS |
| syslog | syslogd selbst | LOG_SYSLOG |
| user | Nachrichten von weiteren Prozessen | LOG_USER |
| uucp | UUCP-System | LOG_UUCP |
Mit der Priorität können weitere Angaben zu den zu protokollierenden Fehler gemacht werden, es sind folgende Einträge (von der höchsten zur niedrigsten Priorietät) möglich:
| Priorität | Beschreibung | priority |
|---|---|---|
| emerg | System ist nicht mehr benutzbar | LOG_EMERG |
| alert | sofortige Ausführung einer Aktion | LOG_ALERT |
| crit | kritischer Notfall | LOG_CRIT |
| err | allgemeine Fehlersituation | LOG_ERR |
| warning | Warnung | LOG_WARNING |
| notice | Standardmeldungen | LOG_NOTICE |
| info | Informationsmeldungen | LOG_INFO |
| debug | Debugging | LOG_DEBUG |
In dem ersten Feld müssen mindestens eine der beiden Angaben eintragen werden. Wenn beispielsweise alle Meldungen, cron betreffend, in der Datei /var/log/cron protokollieren werden sollen, ist folgender Eintrag in der Konfigurationsdatei syslog.conf vorzunehmen,
cron.* /var/log/cron
Werden nur Informationsmeldungen bezüglich des Mailsystems benötigt, können diese wie folgt realisiert werden,
mail.info /var/log/maillog
Allerdings sollten kritische Fehlermeldungen die das Mailsystem betreffen, direkt auf der Konsole ausgegeben werden,
mail.crit /dev/console
Aus diesen Beispielen ist auch ersichtlich wofür das zweite Feld zu nutzen ist, der Angabe wie mit den jeweiligen Meldungen zu verfahren ist. Außer der Möglichkeit eine bestimmte Datei oder die Konsole anzugeben, können unter anderem entfernte Rechner, bestimmte Anwender oder auch alle Anwender angegeben werden.
Ernstzunehmende Fehlermeldungen, jeglicher Art, sollen dagegen grundsätzlich an den Anwender admin erfolgen,
*.alert admin
In der Regel ist eine Beispielversion von syslog.conf auf dem System vorhanden, die den jeweiligen Bedürfnissen angepasst werden kann.
Bei der Konfiguration ist unbedingt darauf achten, die zwei Felder mittels TAB-Taste getrennt werden. Leerzeichen erzielen zwar optisch den gleichen Effekt, aber syslog funktioniert nicht einwandfrei bzw. überhaupt nicht.
Auf größeren Systemen oder Netzwerken empfiehlt es sich generell, dass die Logs sowohl lokal als auch auf einem entfernten Rechner verwaltet werden. Auf diese Weise wird eine Redundanz und damit eine zusätzliche Sicherheit geschaffen, die später einmal vielleicht mehr als nützlich ist.
Das Systemlogging bietet einfache und effektive Möglichkeiten, eigene (C- oder Perl-) Programme zur Überwachung der Systemaktivitäten zu schreiben. Welche Möglichkeiten sich hierbei ergeben, wird im weiteren Verlauf dargestellt (das Folgende beziehet sich auf RedHat 7.0, sollte aber auf anderen Systemen ähnlich verlaufen).
Um syslog zu nutzen stehen drei Funktionen zur Verfügung:
Der Aufruf von openlog() ist optional, unterbleibt der Aufruf, erfolgt automatisch beim ersten Aufruf von syslog(), der Aufruf der Funktion. Mit dem ersten Argument ident kann ein String angegeben werden, der zu jeder generierten Meldung hinzugefügt wird. Üblicherweise wird hier der Name des Programms angegeben.
Mit option ist eine der folgenden Konstanten anzugeben, die mit einer ODER-Verknüpfung auch kombiniert werden können:
Das letzte Argument facility erlaubt es den Nachrichtentyp zu definieren (vgl. Tabelle 1). Der Aufruf von syslog generiert die jeweilige Nachricht. Mit der Angabe von priority können verschiedene Prioritäten (vgl. Tabelle 2) gesetzt werden. Die Angabe von format und eventuell weitere Argumente werden zur Beschreibung der eigentlichen Nachricht genutzt. Die Benutzung entspricht der für die Funktion vsprintf().
Die dritte Funktion closelog() ist ebenfalls optional und schließt den Deskriptor, der zur Kommunikation genutzt wurde.
Das folgende Programm verzichtet auf die optinalen Aufrufe der Funktionen openlog() und closelog().
#include <syslog.h>
main(int argc, char *argv[])
{
syslog(LOG_CRIT, "Kritischer Fehler\n");
syslog(LOG_ERR, "Allgemeine Fehlersituation\n");
}
Nachdem es kompiliert und ausgeführt wurde sollten sich in der Datei /var/log/messages folgende Einträge befinden:
Jul 1 09:30:00 my-secret.net my_syslog: Allgemeine Fehlersituation Jul 1 09:31:49 my-secret.net my_syslog: Kritischer Fehler
Die Einbindung in bestehende oder zukünftige Programme kann beispielsweise folgendermaßen aussehen:
if (....)
print_error();
void print_error()
{
syslog(LOG_ERR | LOG_MAIL, "Kann %s nicht oeffnen: %m", datei_name);
exit(1);
}
Es bieten sich eine Vielzahl von Programmen an, mit denen Systemaktivitäten kontrolliert werden können. Da eine ständige manuelle Überprüfung relativ zeitaufwendig ist oder oftmals nur ganz bestimmte Informationen benötigt werden, ist es mitunter sinnvoll derartige Prozesse automatisch zu steuern. Im weiteren Verlauf werden zwei derartiger Programme ausführlich gezeigt.
Eine manuelle Überprüfung der systemeigenen Log-Dateien kann relativ viel Zeit in Anspruch nehmen. Wenn kein dringender Verdacht, eines unbefugten Eindringens besteht, ist es sinnvoll diesen Prozess automatisch zu steuern. Eines dieser Programme, das diese Funktion erfüllt ist logcheck, welches unter [2.] erhältlich ist. Das Programm ist Teil des Abacus Projektes, welches verschiedene Tools zur Erhöhung der Systemsicherheit unter UNIX bietet.
logcheck besteht aus mehreren Scripten und Dateien, welche die Log-Dateien automatisch auf unübliche Aktivitäten und Verletzungen der Sicherheit in einem festgelegten Zeitintervall überprüfen. Dabei handelt es sich im einzelnen um,
Sowie um die folgenden vier Konfigurationsdateien, anhand denen definiert wird was mitprotokolliert werden soll und was nicht:
Bei den beiden zuerst genannten Dateien wird zwischen Groß- und Kleinschreibung unterschieden, bei den letzten beiden nicht.
Vor der Installation sind einzelne Pfadangaben im Makefile anzupassen. Falls hier irgendwelche Änderungen vorgenommen werden, müssen diese ebenfalls in logcheck.sh erfolgen. Das Script befindet sich in dem Verzeichnis systems/, in dem verschiedene UNIX-Derivate aufgeführt sind. Die Installation sollte relativ problemlos mit dem folgenden Aufruf erfolgen,
# make <systype>
Anschließend sollte ein entsprechender Eintrag in crontab erfolgen, beispielsweise für eine stündliche Analyse,
00 * * * * root /bin/sh /usr/bin/logcheck.sh
Das Script logcheck.sh wird stündlich ausgeführt und ruft logtail auf, welches die Überprüfung der Log-Dateien vornimmt. Bei der Überprüfung werden die Dateien, in der obigen Reihenfolge bei logcheck.hacking beginnend bis zu logcheck.ignore, überprüft und abschließend wird der Systemadministrator über das Ergebnis unterrichtet.
Mit logcheck können aus umfangreichen Log-Dateien, den jeweiligen Bedürfnissen angepasste und damit übersichtlichere Meldungen generiert werden. Zum einen ist der Umfang der durchzusehenden Meldung geringer und zum anderen muss nicht jede Log-Datei einzeln, nach bestimmten Mustern durchgesehen werden, da diese in einer Meldung präsentiert werden.
swatch wurde an der Stanford Universität in Kalifornien entwickelt, als Programmiersprache wurde ausschließlich Perl genutzt. Zusätzlich zu Perl müssen noch folgende Module installiert werden,
Die Module sind unter [3.] das Programm selbst ist unter [4.] erhältlich.
Die Installation von swatch und der Module erfolgt nach - bekanntem - Schema,
# perl Makefile.PL # make # make test # make install # make realclean
Die Konfiguration erfolgt über die Datei .swatchrc, die per default im Home-Verzeichnis des aufrufenden Nutzers gesucht wird. Alternativ können mit dem Aufruf swatch -c filename auch abweichende Angaben gemacht werden. Im Verzeichnis examples/ befinden sich zwei Beispielkonfigurationen. Sehen wir uns ein paar dieser Einträge an.
# Alert me of bad login attempts and find out who is on that system
watchfor /INVALID|REPEATED|INCOMPLETE/
echo inverse
bell 3
Kommentare werden mit einem Doppelkreuz # eingeleitet, mit diesem Eintrag wird nach verschiedenen Mustern gesucht (watchfor), die auf fehlgeschlagene Einwahlversuche hindeuten. Wird eines dieser Muster in den Log-Dateien gefunden, erfolgt eine entsprechende Meldung und ein dreimaliger Warnhinweis. Die Meldung kann in verschiedenen Farben, unterstrichen, blinkend, usw. erfolgen, nähere Angaben dazu in den manuals zu swatch(1).
# System crashes and halts
watchfor /(panic|halt)/
echo
bell
mail
exec call_pager 3667615 0911
Mit diesem Eintrag wird zusätzlich zu der Meldung, eine Mail versandt. Erfolgt keine weitere Angabe erhält die Mail der Nutzer, der das Programm gestartet hat. Außerdem wird ein weiteres Programm aufgerufen, welches eine zusätzliche Meldung mittels Pager generiert.
# Ignore this stuff ignore /sendmail/,/nntp/,/xntp|ntpd/,/faxspooler/
Mit ignore können bestimmte Muster angegeben werden, die nicht berücksichtigt werden sollen.
Für einen ersten Test können in der Regel eine der beiden Beispielkonfigurationen übernommen werden und swatch gestartet werden. Bei einem anschließenden, erfolglosen »su-Versuch« eines Anwenders, ergibt sich folgender Aufruf,
# swatch --config-file=/etc/swatch.cfg *** swatch-3.0b5 (pid:2038) started at Sat May 26 16:44:23 CET 2001 May 26 16:44:32 my-secret.net PAM_unix[2042]: authentication fail ure; root(uid=500) -> root for system-auth service
In diesem, unter RedHat ausgeführtem Beispiel, wird die Datei /var/log/messages ausgewertet, auf anderen UNIX-Systemen wird alternativ die Voreinstellung /var/log/syslog genutzt. Außerdem wurde eine abweichende Konfigurationsdatei angegeben. Mit -help werden weitere mögliche Optionen angezeigt.
swatch bietet Möglichkeiten, welche die des »normalen Loggings« bei weitem übertreffen,
Das »Angebot« an Analyseprogrammen ist relativ vielfältig. Stellvertretend für ein Vielzahl weiterer Tools werden deshalb abschließend einige der »interessanteren Vertreter« kurz beschrieben, für die ein »weiterer Blick lohnenswert erscheint«.
Jedes UNIX-System verfügt über eine mehr oder minder große Auswahl an systemeigenen Log-Dateien, die detaillierte Informationen zu den verschiedensten Anwenderaktivitäten liefern. Derartige Informationen sollten niemals unterschätzt werden, »denn man weiß nie, wofür sie später einmal benötigt werden«. Dementsprechend gewissenhaft sollte eine regelmäßige Auswertung inklusive Backup der Dateien vorgenommen werden. Die gezeigten Hilfsprogramme können diese Arbeit weiter erleichtern. Wenn beispielsweise kein Verdacht eines unbefugten Eindringens besteht, ist eine automatische Überprüfung der Programme, mittels eines der Analyseprogramme, durchaus ausreichend und weniger zeitaufwendig. Befindet sich dagegen ein »ungebetener Gast« auf dem System, kann eine eingehende Analyse weitreichende Informationen über die jeweiligen Aktivitäten liefern. Außerdem sucht ein Eindringling oftmals nur nach den ihm bekannten Log-Dateien und lässt weitere Dateien »links liegen«. Somit steigen die Chancen einer nicht manipulierten Auswertung.
Die gezeigten Tools können die tägliche Arbeit stark vereinfachen, haben jedoch auch den Nachteil, dass bei einer fehlerhaften Konfiguration wichtige Meldungen untergehen können. Aus diesem Grunde sollten derartige Programme stets nur als weiteres Hilfsmittel angesehen werden und nicht als vollwertiger Ersatz für eine notwendige manuelle Überprüfung.
[2. ] Automatisierte Überprüfung der systemeigenen Log-Dateien.
http://www.psionic.com/abacus/logcheck
[3. ] Comprehensive Perl Archive Network - CPAN
http://www.cpan.org
[4. ] Einfach zu konfigurierendes Protokollierungs-Tool.
ftp://coast.cs.purdue.edu/pub/tools/unix/logutils/swatch/
[5. ] Überprüfung der Web-Logs
http://www.statslab.com.ac.uk/ sret1/analog/
[6. ] Überprüfung der Log-Dateien auf vorher festgelegte Ereignisse.
http://packetstorm.securify.com/UNIX/IDS/
[7. ] Analyse der Log-Dateien und ausführen verschiedener Aktionen.
ftp://ftp.cert.dfn.de/pub/tools/audit/logsurfer/
[8. ] Analyse-Tool mit dem Zeitraum und Ausgabe selbst definiert werden kann.
http://www.kaybee.org/~kirk/html/linux.html
[9. ] Protokollierung ein- und ausgehender TCP- und UDP-Verbindungen.
http://net.tamu.edu/ftp/security/TAMU/
[10.] Umfassende Protokollierungsmöglichkeiten der verschiedensten
Server-Dienste.
http://www.netplex-tech.com/software/nocol
[11.] Automatisierte Überprüfung der Log-Dateien.
http://www.i-pi.com/