Beispielhack:
Hack #59 Aggregieren Sie Protokolle von entfernten Sites
Integrieren Sie benachbarte und andere entfernte Systeme oder Netzwerke in Ihre zentrale Syslog-Infrastruktur.
Die Überwachung der Protokolle einer entfernten Site oder nur eines angrenzenden Servers kann oftmals übersehen werden, wenn die Aktivitäten im lokalen Netzwerk überwacht werden sollen. Sie könnten die herkömmlichen Syslog-Einrichtungen benutzen, um Protokollierungsinformationen von entfernten Netzwerken oder Systemen zu verschicken, aber da der Syslog-Daemon UDP für den Versand auf entfernte Systeme benutzt, ist dies keine ideale Lösung. UDP stellt keine zuverlässige Kommunikation zur Verfügung, weshalb Sie riskieren, Protokollierungsinformationen zu verlieren. Des Weiteren besitzt der herkömmliche Syslog-Daemon keine Mittel, um den Datenverkehr, den er verschickt, zu verschlüsseln, weshalb Ihre Protokolle für jedermann sichtbar sein könnten, der Zugriff auf die dazwischen liegenden Netzwerke zwischen Ihnen und Ihren entfernten Hosts oder Netzwerken hat.
Um diese Probleme zu umgehen, müssen Sie auf den Syslog-Daemon verzichten, der mit Ihrem Betriebssystem daherkommt, und einen Ersatz finden müssen. Ein solcher Ersatz-Syslog-Daemon ist syslog-ng (http://www.balabit.com/products/syslog_ng/). syslog-ng ist nicht nur ein voll funktionsfähiger Ersatz für den herkömmlichen Syslog-Daemon, sondern fügt noch flexible Fähigkeiten zur Filterung von Nachrichten sowie die Unterstützung von Protokollierung auf ein entferntes System über TCP hinzu (zusätzlich zur Unterstützung des üblichen UDP-Protokolls). Mit der Ergänzung der TCP-Unterstützung können Sie auch stunnel oder ssh einsetzen, um die Protokolle sicher über nichtvertrauenswürdige Netzwerke zu verschicken.
Um syslog-ng zusammenzubauen, benötigen Sie zusätzlich zu dem Paket syslog-ng noch das Bibliothekspaket libol (http://www.balabit.com/downloads/syslog-ng/libol/). Nachdem Sie diese Pakete heruntergeladen haben, entpacken Sie sie und bauen dann libol zusammen:
$ tar xfz libol-0.3.9.tar.gz
$ cd libol-0.3.9
$ ./configure && make
Wenn Sie syslog-ng zusammenbauen, können Sie es statisch nach libol linken, weshalb die Bibliothek nicht unbedingt vollständig installiert werden muss.
Um syslog-ng nun zusammenzubauen:
$ tar xfz syslog-ng-1.5.26.tar.gz
$ cd syslog-ng-1.5.26
$ ./configure --with-libol=../libol-0.3.9
$ make
Wenn Sie die Unterstützung von TCP-Wrappern einkompilieren möchten, können Sie das Flag --enable-tcp-wrapper hinzufügen, um das Skript zu konfigurieren. Nachdem syslog-ng die Kompilierung beendet hat, werden Sie zu root und führen make install aus. Dies wird die Binärdatei von syslog-ng sowie die Manpages installieren. Um den Daemon zu konfigurieren, erstellen Sie das Verzeichnis /usr/local/etc/syslog-ng und dann die Datei syslog-ng.conf, um sie darin abzulegen. Für den Anfang können Sie eine der Beispiel-Konfigurationsdateien in dem Verzeichnis doc der syslog-ng-Distribution benutzen.
Es gibt fünf Arten von Konfigurationsdateieinträgen für syslog-ng, jede davon beginnt mit einem bestimmten Schlüsselwort. Der Eintrag options ermöglicht Ihnen, das Verhalten des Daemon zu optimieren, wie zum Beispiel festzulegen, wie oft der Daemon die Protokolle auf die Festplatte synchronisieren soll, ob der Daemon Verzeichnisse automatisch erstellen soll, und das Verhalten bei der Erweiterung der Hostnamen. Die source-Einträge sagen syslog-ng, von wo es die Protokolleinträge einsammeln soll. Eine Quelle kann Unix-Sockets, TCP- oder UDP-Sockets, Dateien oder Pipes enthalten. destination-Einträge ermöglichen es Ihnen, syslog-ng mögliche Orte anzugeben, an die es Protokolle schicken soll. Sie können Dateien, Pipes, Unix-Sockets, TCP- oder UDP-Sockets, TTYs oder Programme angeben. Quellen und Ziele werden dann mit Filtern kombiniert (mit Hilfe des Schlüsselworts filter), die Sie die Syslog-Einrichtungen und Protokollstufen auswählen lassen. Schließlich wird das alles zusammen in einem log-Eintrag eingesetzt, um genau anzugeben, wo die Information protokolliert wird. Folglich können Sie alle Quellen willkürlich miteinander kombinieren, auswählen, welche Syslog-Einrichtungen und Stufen Sie davon haben möchten, und dann alles auf ein beliebiges Ziel umleiten. Das ist es, was syslog-ng zu einem unglaublich mächtigen und flexiblen Werkzeug macht.
Um syslog-ng auf dem entfernten Ende so einzurichten, dass es den syslogd auf dem System ersetzen und Datenverkehr auf einen entfernten syslog-ng senden kann, müssen Sie zuerst Ihre syslog.conf auf entsprechende source-, destination- und log-Einträge abbilden.
Hier ist die syslog.conf für ein FreeBSD-System:
*.err;kern.debug;auth.notice;mail.crit /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
auth.info;authpriv.info /var/log/auth.log
mail.info /var/log/maillog
lpr.info /var/log/lpd-errs
cron.* /var/log/cron
*.emerg *
Als Erstes müssen Sie eine Quelle (source) konfigurieren. Unter FreeBSD ist /dev/log ein Link auf /var/run/log. Der folgende source-Eintrag sagt syslog-ng, dass es Einträge aus dieser Datei lesen soll:
source src { unix-dgram("/var/run/log"); internal( ); };
Würden Sie Linux einsetzen, würden Sie unix-stream und /dev/log folgendermaßen angeben:
source src { unix-stream("/dev/log"); internal( ) };
Der Eintrag internal( ) steht für Nachrichten, die von syslog-ng selbst generiert wurden. Beachten Sie, dass Sie in einem source-Eintrag mehrere Quellen haben können. Als Nächstes fügen Sie destination-Einträge für jede der tatsächlichen Protokolldateien hinzu:
destination console { file("/dev/console"); };
destination messages { file("/var/log/messages"); };
destination security { file("/var/log/security"); };
destination authlog { file("/var/log/auth.log"); };
destination maillog { file("/var/log/maillog"); };
destination lpd-errs { file("/var/log/lpd-errs"); };
destination cron { file("/var/log/cron"); };
destination slip { file("/var/log/slip.log"); };
destination ppp { file("/var/log/ppp.log"); };
destination allusers { usertty("*"); };
Zusätzlich zu diesen Zielorten sollten Sie noch einen für die entfernte Protokollierung auf einen anderen syslog-ng-Prozess angeben. Dies kann mit einer Zeile wie dieser vorgenommen werden:
destination loghost { tcp("192.168.0.2" port(5140)); };
Die Portnummer kann jeder verfügbare TCP-Port sein.
Die Definition der Filter ist unproblematisch. Sie können einfach einen für jede Syslog-Einrichtung und -Protokollstufe erstellen oder Sie können sie entsprechend denen in Ihrer syslog.conf erstellen. Wenn Sie Letzteres machen, müssen Sie nur einen Filter in jeder Protokollanweisung angeben; es wird aber immer noch einige Arbeit nötig sein, um Ihre Filter zu erstellen.
Hier sind Beispiel-Filter für die Syslog-Einrichtungen:
filter f_auth { facility(auth); };
filter f_authpriv { facility(authpriv); };
filter f_console { facility(console); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_ftp { facility(ftp); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_news { facility(news); };
filter f_security { facility(security); };
filter f_user { facility(user); };
filter f_uucp { facility(uucp); };
Und hier sind Beispiele für die Protokollstufen:
filter f_emerg { level(emerg); };
filter f_alert { level(alert..emerg); };
filter f_crit { level(crit..emerg); };
filter f_err { level(err..emerg); };
filter f_warning { level(warning..emerg); };
filter f_notice { level(notice..emerg); };
filter f_info { level(info..emerg); };
filter f_debug { level(debug..emerg); };
Jetzt können Sie innerhalb der Protokolleinträge die Quelle mit dem richtigen Filter und dem Zielort kombinieren:
# *.err;kern.debug;auth.notice;mail.crit /dev/console
log { source(src); filter(f_err); destination(console); };
log { source(src); filter(f_kern); filter(f_debug); destination(console); };
log { source(src); filter(f_auth); filter(f_notice); destination(console); };
log { source(src); filter(f_mail); filter(f_crit); destination(console); };
# *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
log { source(src); filter(f_notice); destination(messages); };
log { source(src); filter(f_kern); filter(f_debug); destination(messages); };
log { source(src); filter(f_lpr); filter(f_info); destination(messages); };
log { source(src); filter(f_mail); filter(f_crit); destination(messages); };
log { source(src); filter(f_news); filter(f_err); destination(messages); };
# security.* /var/log/security
log { source(src); filter(f_security); destination(security); };
# auth.info;authpriv.info /var/log/auth.log
log { source(src); filter(f_auth); filter(f_info); destination(authlog); };
log { source(src); filter(f_authpriv); filter(f_info); destination(authlog); };
# mail.info /var/log/maillog
log { source(src); filter(f_mail); filter(f_info); destination(maillog); };
# lpr.info /var/log/lpd-errs
log { source(src); filter(f_lpr); filter(f_info); destination(lpd-errs); };
# cron.* /var/log/cron
log { source(src); filter(f_cron); destination(cron); };
# *.emerg *
log { source(src); filter(f_emerg); destination(allusers); };
Sie können die Maschine, die die Protokolle empfängt, beinahe auf die gleiche Weise einrichten, als würden Sie den aktuell eingesetzten syslogd ersetzen.
Um syslog-ng so zu konfigurieren, dass er Nachrichten von einem entfernten Host empfängt, müssen Sie einen source-Eintrag angeben:
source r_src { tcp(ip("192.168.0.2") port(5140)); };
Alternativ können Sie alle Protokolle der entfernten Maschinen an denselben Stellen ablegen, die Sie für Ihre lokalen Protokolleinträge benutzen. Das wird nicht wirklich empfohlen, da es ein Alptraum sein kann, diese zu verwalten, kann aber eingerichtet werden, indem Sie mehrere Quelltreiber in dem source-Eintrag einfügen, den Sie für Ihre lokalen Protokolle verwenden:
source src {
unix-dgram("/var/run/log");
tcp(ip("192.168.0.2") port(5140));
internal( );
};
Jetzt werden alle Protokolle, die von entfernten Hosts gesammelt werden, in jedem der Zielorte auftauchen, die mit dieser Quelle kombiniert wurden.
Wenn Sie möchten, dass alle Protokolle von entfernten Hosts in einer separaten Datei landen, die nach den einzelnen Hosts unter /var/log benannt wird, könnten Sie einen Zielort wie diesen verwenden:
destination r_all { file("/var/log/$HOST"); };
syslog-ng wird das $HOST-Makro auf den Hostnamen des Systems erweitern, das ihm Protokolle schickt, und eine Datei unter /var/log erstellen, die nach diesem System benannt ist. Ein passender log-Eintrag, der damit verwendet werden könnte, wäre:
log { source(r_src); destination(r_all); };
Eine noch bessere Methode wäre es jedoch, alle entfernten Protokolldateien von syslog-ng auf Ihrem zentralen Protokollserver erneut zu erstellen. Ein Zielort für die messages-Datei einer entfernten Maschine würde zum Beispiel folgendermaßen aussehen:
destination fbsd_messages { file("/var/log/$HOST/messages"); };
Beachten Sie, dass hier das $HOST-Makro anstelle des Verzeichnisnamens verwendet wird. Wenn Sie einen destination-Eintrag wie diesen verwenden, vergessen Sie nicht, das Verzeichnis im Voraus zu erstellen oder die Option create_dirs( ) zu verwenden:
options { create_dirs(yes); };
Die Makros von syslog-ng sind ein sehr mächtiges Feature. Wenn Sie zum Beispiel die Protokolle anhand des Hostnamens und des Tages voneinander trennen wollen, könnten Sie einen Zielort wie diesen verwenden:
destination fbsd_messages {
file("/var/log/$HOST/$YEAR.$MONTH.$DAY/messages");
};
Sie können die entfernten Quellen mit den zugehörigen Zielorten für die Protokolle, die vom Netzwerk hereinkommen, genauso kombinieren, wie Sie das gemacht haben, als Sie syslog-ng für die lokale Protokollierung konfiguriert haben - geben Sie einfach die entfernte Quelle mit dem richtigen Ziel und den Filtern an.
Eine andere nette Sache, die Sie mit syslog-ng machen können, ist die Protokolle von einer Reihe von entfernten Hosts zu sammeln und dann all die Protokolle auf einen weiteren syslog-ng-Daemon zu schicken. Sie können das machen, indem Sie eine entfernte Quelle und ein entferntes Ziel mit einem log-Eintrag kombinieren:
log { source(r_src); destination(loghost); };
Da syslog-ng jetzt TCP-Ports verwendet, können Sie jeden beliebigen verschlüsselnden Tunnel benutzen, den Sie möchten, um den Datenverkehr zwischen Ihren syslog-ng-Daemons abzusichern. Sie können SSH-Port-Forwarding [Hack #72] oder stunnel [Hack #76] einsetzen, um einen verschlüsselten Kanal zwischen jedem Ihrer Server aufzubauen. Indem Sie die Verbindungen auf dem lauschenden Port so einschränken, dass er nur localhost enthält (unter Verwendung von Firewall-Regeln wie in »Einrichten einer Firewall mit Netfilter« [Hack #33] oder »Einrichten einer Firewall mit PacketFilter von OpenBSD« [Hack #34]), können Sie die Möglichkeit von gefälschten Protokolleinträgen oder Denial-of-Service-Angriffen ausschließen.
Server-Protokolle sind mit die entscheidendsten Informationen, die ein Systemadministrator benötigt, um seinen Job zu machen. Mit Hilfe von neuen Tools und starker Verschlüsselung können Sie Ihre wertvollen Protokolldaten vor allzu neugierigen Blicken schützen.
Zurück zu Netzwerksicherheits Hacks
O'Reilly Home |
O'Reilly Partnerbuchhandlungen |
Bestellinformationen
Kontakt |
Über O'Reilly |
Datenschutz

© 2004, O'Reilly Verlag GmbH & Co.KG
webmaster@oreilly.de
|