Das Paket logcheck ist in Debian auf drei Pakete verteilt: logcheck (das Hauptprogramm), logcheck-database (eine Datenbank regulärer Ausdrücke für das Programm) und logtail (gibt Protokollzeilen aus, die noch nicht gelesen wurden). Der Standard unter Debian (in /etc/cron.d/logcheck) ist, dass logcheck jede Stunde und nach jedem Neustart ausgeführt wird.

Wenn dieses Werkzeug in geeigneter Weise angepasst wurde, kann es sehr nützlich sein, um den Administrator zu alarmieren, wenn etwas ungewöhnliches auf dem System passiert. Logcheck kann vollständig angepasst werden, so dass es Mails über Ereignisse aus den Protokollen sendet, die Ihrer Aufmerksamkeit bedürfen. Die Standard-Installation umfasst Profile zum Ignorieren von Ereignissen und Verstößen gegen die Sicherheitsrichtlinie für drei unterschiedliche Einsatzbereiche (Workstation, Server und paranoid). Das Debian-Paket umfasst die Konfigurationsdatei /etc/logcheck/logcheck.conf, die vom Programm eingelesen wird, und die definiert, an welchen Benutzer die Testergebnisse geschickt werden sollen. Es stellt außerdem einen Weg für Pakete zur Verfügung, um neue Regeln in folgenden Verzeichnisses zu erstellen: /etc/logcheck/cracking.d/_packagename_ /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_, und /etc/logcheck/ignore.d.workstation/_packagename_. Leider benutzen das noch nicht viele Pakete. Wenn Sie ein Regelwerk entwickelt haben, dass für andere Benutzer nützlich sein könnte, schicken Sie bitte einen Fehlerbericht für das entsprechende Paket (als ein wishlist-Fehler). Mehr Informationen finden Sie unter /usr/share/doc/logcheck/README.Debian.

logcheck konfiguriert man am besten, indem man nach der Installation die Hauptkonfigurationsdatei /etc/logcheck/logcheck.conf bearbeitet. Verändern Sie den Benutzer, an den die Berichte geschickt werden (standardmäßig ist das Root). Außerdem sollten Sie auch den Schwellenwert für Berichte festlegen. logcheck-database hat drei Schwellenwerte mit steigender Ausführlichkeit: Workstation (Arbeitsplatz), Server und paranoid. »server« ist der Standardwert, »paranoid« wird nur für Hochsicherheitsmaschinen empfohlen, auf denen so wenig Dienste wie möglich laufen. »workstation« eignet sich für relativ geschützte, nicht kritische Maschinen. Wenn Sie neue Protokoll-Dateien hinzufügen wollen, müssen Sie diese nur zu /etc/logcheck/logcheck.logfiles hinzufügen. Es ist für die standardmäßige Syslog-Installation eingerichtet.

Wenn Sie dies geschafft haben, sollten Sie die nächsten Tage/Wochen/Monate die verschickten Mails überprüfen. Falls Sie Nachrichten finden, die Sie nicht erhalten wollen, fügen Sie die regulären Ausdrücke (regular expressions, vergleiche regex(7) und egrep(1)), die zu diesen Nachrichten passen, in /etc/logcheck/ignore.d.reportlevel/local ein. Versuchen Sie, dass der reguläre Ausdruck mit der gesamten Protokollzeile übereinstimmt. Details, wie man Regeln schreibt, finden Sie in /usr/share/doc/logcheck-database/README.logcheck-database.gz. Das ist ein andauernder Prozess der Abstimmung. Wenn nur noch relevante Meldungen verschickt werden, können Sie davon ausgehen, dass dieser Prozess beendet ist. Beachten Sie, dass logcheck, selbst wenn er läuft, Ihnen keine Mail schickt, wenn er nichts Relevantes auf Ihrem System findet (so bekommen Sie höchstens eine Mail pro Woche, wenn Sie Glück haben).

Debian wird mit einer Standardkonfiguration für Syslog (in /etc/syslog.conf) ausgeliefert, so dass Meldungen je nach System in die passenden Dateien geschrieben werden. Das sollte Ihnen bereits bekannt sein. Falls nicht, werfen Sie einen Blick auf die Datei syslog.conf und deren Dokumentation. Wenn Sie ein sicheres System betreuen wollen, sollte Ihnen bekannt sein, wohin Protokoll-Meldungen geschickt werden, so dass sie nicht unbeachtet bleiben.

Zum Beispiel ist es für viele Produktiv-Systeme sinnvoll, Meldungen auch auf der Konsole auszugeben. Aber bei vielen solcher Systeme ist es wichtig, eine neue Maschine zu haben, die für die anderen als ein Loghost fungiert (d.h. sie empfängt die Protokolle aller anderen Systeme).

Sie sollten auch an Mails für Root denken, da viele Programme zur Sicherheitskontrolle (wie snort) ihre Alarme an die Mailbox von Root senden. Diese Mailbox zeigt normalerweise auf den ersten Benutzer, der auf dem System erstellt wurde (prüfen Sie dazu /etc/aliases). Sorgen Sie dafür, dass Roots Mails irgendwo hin geschickt werden, wo sie auch gelesen werden (lokal oder in der Ferne).

Es gibt noch andere Konten mit besonderen Funktionen und andere Aliase auf Ihrem System. Auf einem kleinen System ist es wohl am einfachsten, sicherzustellen, dass alle Aliase auf das Root-Konto verweisen, und dass Mails an Root in das persönliche Postfach des Systemadministrators weiter geleitet werden.

FIXME: It would be interesting to tell how a Debian system can send/receive SNMP traps related to security problems (jfs). Check: snmptrapfmt, snmp and snmpd.

Ein Loghost ist ein Server, der die syslog-Daten über ein Netzwerk sammelt. Wenn eine Ihrer Maschinen geknackt wird, kann der Eindringling seine Spuren nicht verwischen, solange er den Loghost nicht ebenfalls geknackt hat. Demzufolge muss der Loghost besonders sicher sein. Aus einer Maschine einen Loghost zu machen, ist relativ einfach: Starten Sie den syslogd einfach mit

syslogd -r

und ein neuer Loghost ist geboren. Um dies unter Debian dauerhaft zu machen, editieren Sie /etc/default/syslogd und ändern Sie die Zeile

SYSLOGD=""

in

SYSLOGD="-r"

Als nächstes konfigurieren Sie die anderen Maschinen, so dass sie ihre Daten an den Loghost zu senden. Fügen Sie einen Eintrag, ähnlich dem Folgenden, zu der /etc/syslog.conf hinzu:

  facility.level            @Ihr_Loghost

Schauen Sie in die Dokumentation, um zu erfahren, wodurch Sie facility und level ersetzen können; sie sollten nicht wörtlich übernommen werden. Wenn Sie alles in der Ferne mitprotokollieren wollen, schreiben Sie einfach:

  *.*                       @Ihr_Loghost

in Ihre syslog.conf. Sowohl lokal als auch aus der Ferne mitzuprotokollieren, ist die beste Lösung (ein Angreifer könnte davon ausgehen, dass er seine Spuren verwischt hat, nachdem er die lokale Log-Datei gelöscht hat). Für weitere Informationen sehen Sie sich die Handbuchseiten syslog(3), syslogd(8) and syslog.conf(5) an.

Es ist nicht nur wichtig zu entscheiden, wie Warnungen genutzt werden, sondern auch, wer hierauf Zugriff hat, d.h. wer Protokolldateien (falls Sie nicht einen Loghost verwenden) lesen oder verändern kann. Sicherheitsalarme, die ein Angreifer verändern oder abschalten kann, sind im Falle eines Eindringens nicht viel wert. Außerdem sollten Sie berücksichtigen, dass Protokolldateien einem Eindringling ziemlich viel Informationen über Ihr System verraten, wenn er auf sie Zugriff hat.

Einige Zugriffsrechte auf Protokolldateien sind nach der Installation nicht gerade perfekt (aber das hängt natürlich von Ihrer lokalen Sicherheitsrichtlinie ab). Zuerst einmal müssen /var/log/lastlog und /var/log/faillog nicht für normale Benutzer lesbar sein. In der Datei lastlog können Sie sehen, wer sich zuletzt angemeldet hat. In faillog befindet sich eine Zusammenfassung fehlgeschlagener Anmeldeversuche. Der Autor empfiehlt, die Rechte von beiden auf 660 zu setzen (mit chmod 660). Werfen Sie einen kurzen Blick auf Ihre Protokolldateien und entscheiden Sie sehr vorsichtig, welche Protokolldateien Sie les- oder schreibbar für einen Benutzer mit einer anderen UID als 0 und einer anderen Gruppe als »adm« oder »root« machen. Sie können dies sehr leicht auf Ihrem System überprüfen:

  #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
  (überprüfen, welchen Benutzern die Dateien unter /var/log gehören)
  #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
  (überprüfen, welchen Gruppen die Dateien unter /var/log gehören)
  # find /var/log -perm +004
  (Dateien, die von jedem Benutzer gelesen werden können)
  #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
  (Dateien, die nicht der Gruppe root oder adm gehören)

Um anzupassen, wie neue Protokolldateien erstellt werden, müssen Sie wahrscheinlich das Programm anpassen, das sie erstellt. Wenn die Protokolldateien ausgewechselt werden, können Sie das Verhalten der Erstellung und Auswechslung anpassen.