Gentoo Logo

[ << ] [ < ] [ Hauptseite ] [ > ] [ >> ]


3. Protokollierung

Inhalt:

3.a. Einleitung

Zusätzliche Protokollierung sollte hinzugefügt werden, um Warnungen oder Fehler aufzuspüren, die auf einen momentanen oder bereits durchgeführten Angriff hinweisen könnten. Angreifer beobachten ein Netzwerk oder durchsuchen dies oft, bevor sie angreifen.

Es ist auch unersetzlich, dass die Protokolldateien einfach zu lesen und zu verwalten sind. Gentoo Linux gibt ihnen die Möglichkeit bei der Installation zwischen drei verschiedenen Protokollierungsprogrammen zu wählen.

3.b. Loggen: Syslogd

Syslogd ist das gängigste Protokollierungsprogramm für Linux und Unix. Es beinhaltet ein wenig Protokollrotation aber die Verwendung von /usr/sbin/logrotate in einem Cron Job (logrotate wird in /etc/logrotate.conf konfiguriert) könnte sich als leistungsfähiger heraustellen, denn logrotate hat viele Funktionen. Wie oft die Protokollrotation stattfinden sollte hängt von der Systembelastung ab.

Hierunter sehen Sie die Standard Konfiguration /syslog.conf mit einigen zusätzlichen Features. Wir haben die cron und tty Zeilen entkommentiert und einen Remote Logging Server hinzugefügt. Um die Sicherheit weiter zu erhöhen, können Sie Logs an zwei Orten schreiben lassen.

Befehlsauflistung 2.1: /etc/syslog.conf

#  /etc/syslog.conf      Configuration file for syslogd.
#
#                       For more information see syslog.conf(5)
#                       manpage.
#                       This is from Debian, we are using it for now
#                       Daniel Robbins, 5/15/99

#
# Zuerst einige Standardprotokolldateien.
# Protokollierung nach Einrichtung.
#

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
uucp.*                          -/var/log/uucp.log
local6.debug                    /var/log/imapd.log

#
# Protokollierung für das Mailsystem. Trennung erfolgt so,
# dass es einfach ist Skripte, zum parsen dieser Dateien, zu schreiben.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Protokollierung für INN News Systeme
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Einige `catch-all' Protokolldateien
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Notfälle und Warnungen werden an alle eingeloggten Benutzer geschickt.
#
*.emerg                         *
*.=alert                        *

#
# Ich bevorzuge es Nachrichten auf der Konsole angezeigt zu bekommen, jedoch
# nur auf einer virtuellen Konsole die normalerweise ungenutzt ist.
#
daemon,mail.*;\
       news.=crit;news.=err;news.=notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       /dev/tty8

#Einrichten eines entfernten Protokollierungsservers
*.*                        @logserver

# Die genannte Pipe /dev/xconsole ist für das `xconsole' Programm. Um es zu
# verwenden müssen Sie `xconsole' mit der `-file' Option aufrufen:
#
#    $ xconsole -file /dev/xconsole [...]
#
# Anmerkung: passen Sie die folgende Liste an oder Sie werden wahnsinning,
# sofern ihre Seite eine gewisse Größe hat...
#
#daemon.*,mail.*;\
#       news.crit;news.err;news.notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

local2.*                --/var/log/ppp.log

Der Angreifer wird höchstwahrscheinlich versuchen seine Spuren zu verwischen, indem er Protokolldateien bearbeitet oder löscht. Sie können es für den Angreifer schwerer machen indem Sie das Protokoll an einen oder mehrere Protokollserver auf verschiedenen Maschinen schicken. Mehr Informationen über syslogd finden Sie durch Aufruf von man syslog.

3.c. Metalog

Metalog von Frank Dennis bietet nicht die Möglichkeit Protokolle an einen entfernten (remote) Server zu senden, aber es hat Vorteile im Bereich der Performance und der Protokollierungsflexibilität. Es kann nach Programmnamen, Dringlichkeit oder nach Einrichtung protokollieren (wie syslogd) und beinhaltet reguläre Ausdrucksübereinstimmung und die Möglichkeit Befehle auszuführen. Es ist sehr gut um Handeln zu können, wenn nötig.

Die Standard Konfiguration ist meistens ausreichend. Wenn Sie benachrichtigt werden wollen, wenn z.B. ein Anmeldevorgang fehlschlägt benutzen Sie eines der folgenden Skripte.

Für postfix:

Befehlsauflistung 3.1: /usr/local/sbin/mail_pwd_failures.sh für postfix

#! /bin/sh
echo "$3" | mail -s "Warning (program : $2)" root

Für netqmail:

Befehlsauflistung 3.2: /usr/local/sbin/mail_pwd_failures.sh für netqmail

#!/bin/sh
echo "To: root
Subject:Failure (Warning: $2)
$3
" | /var/qmail/bin/qmail-inject -f root

Denken Sie daran das Skript mit /bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh ausführbar zu machen.

Kommentieren Sie dann die Zeile unter "Password failures" in /etc/metalog/metalog.conf wie folgt aus:

Befehlsauflistung 3.3: /etc/metalog/metalog.conf

command  = "/usr/local/sbin/mail_pwd_failures.sh"

3.d. Syslog-ng

Syslog-ng enthält einige derselben Funktionen wie Syslog und Metalog mit einem kleinen Unterschied. Es ermöglicht die Filterung von Nachrichten basierend auf Level und Inhalt (wie Metalog), bietet entferntes Protokollieren (wie syslog), kann Protokolle von syslogd verarbeiten (sogar Streams von Solaris), auf ein TTY ausgeben, Programme ausführen und auch als Protokollierungsserver dienen. Grundlegend ist dies das Beste aus beiden Protokollierern kombiniert mit einer erweiterten Konfiguration.

Eine klassische, leicht modifizierte Konfigurationsdatei:

Befehlsauflistung 4.1: /etc/syslog-ng/syslog-ng.conf

options {
        chain_hostnames(no);

        # Die standardmäßige Aktion von syslog-ng ist es, alle 10
        # Minuten eine STATS-Zeile zu loggen. Das wird nach einer Weile recht
        # ekelig. Ändern Sie dies auf 12 Stunden, so dass Sie ein nettes
        # tägliches Update darüber erhalten, wie viele Nachrichten
        # syslog-ng entgangen sind (0).
        stats_freq(43200);
};

source src {
    unix-stream("/dev/log" max-connections(256));
    internal();
};

source kernsrc { file("/proc/kmsg"); };

# Ziele festlegen
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };

destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };

destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };

destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };

# Standardmäßig werden alle Nachrichten nach tty12 protokolliert...
destination console_all { file("/dev/tty12"); };

# ...wenn Sie vorhaben /dev/console für Programme wie xconsole zu
# verwenden, können Sie die obige destination-Zeile, die sich auf /dev/tty12
# bezieht, auskommentieren und die unten stehende Zeile entkommentieren.
#destination console_all { file("/dev/console"); };

# create filters
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
        and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };

filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { message("failed"); };
filter f_denied { message("denied"); };

# Filter und Ziele verbinden
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };

log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };

# Standard-Protokoll
log { source(src); destination(console_all); };

Syslog-ng ist sehr einfach zu konfigurieren, aber es ist auch sehr einfach etwas zu übersehen, da die Konfigurationsdatei riesig ist. Der Autor verspricht zudem noch einige zusätzliche Funktionen wie Verschlüsselung, Authentifizierung, Komprimierung und MAC (Mandatory Access Control) Kontrolle. Mit diesen Optionen wird es perfekt sein für Netzwerkprotokollierung, da der Angreifer die Protokolle nicht ausspionieren kann.

Syslog-ng hat auch noch einen anderen Vorteile - es muss nicht als root laufen!

3.e. Protokollanalyse mit Logcheck

Natürlich ist das Erstellen von Protokollen nur die halbe Miete. Ein Programm wie Logcheck kann die regelmäßige Analyse von Protokollen sehr vereinfachen. Logcheck ist ein Skript, zusammen mit einem Binary namens logtail, welches vom Cron aufgerufen wird und die Protokolle regelmäßig mit einer Liste verdächtiger Aktivitäten vergleicht; dann versendet es die Ausgabe per Mail an root.

Logcheck und logtail sind Teil des app-admin/logsentry Pakets.

Logcheck verwendet vier Dateien um wichtige Einträge von den unwichtigen zu filtern. Diese Dateien sind logcheck.hacking, welche Nachrichten bekannter Hackerangriffe enthält, logcheck.violations, mit den Signaturen von Sicherheitsverletzungen, logcheck.violations.ignore, welche Schlüsselwörter enthält, die vermutlich durch die violations Datei erkannt würden, so dass normale Einträge ignoriert werden können und logcheck.ignore, mit Einträgen, die ingnoriert werden sollen.

Warnung: Lassen Sie logcheck.violations.ignore nicht leer, da Logcheck grep zum Durchsuchen der Protokolle einsetzt und einige Versionen hiervon interpretieren eine leere Datei als Platzhalter, was dazu führen könnte, dass alle Einträge in der violations Datei ignoriert werden.


[ << ] [ < ] [ Hauptseite ] [ > ] [ >> ]


Drucken

Alles ansehen

Seite aktualisiert 2. April 2010

Zusammenfassung: Gentoo Linux lässt Sie zwischen drei verschiedenen Protokollierdiensten wählen.

Kim Nielsen
Autor

John P. Davis
Bearbeiter

Eric R. Stockbridge
Bearbeiter

Carl Anderson
Bearbeiter

Jorge Paulo
Bearbeiter

Sven Vermeulen
Bearbeiter

Benny Chuang
Bearbeiter

Sune Jeppesen
Bearbeiter

Tiemo Kieft
Bearbeiter

Zack Gilburd
Bearbeiter

Dan Margolis
Bearbeiter

Joshua Saddler
Bearbeiter

Jan Hendrik Grahl
Übersetzer

Tobias Scherbaum
Übersetzer

Matthias Geerdsen
Übersetzer

Tobias Heinlein
Übersetzer

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.