\documentclass[a4paper,11pt]{article} \usepackage{ngerman} \usepackage[latin1]{inputenc} \setlength\parskip{\medskipamount} \setlength\parindent{0pt} \begin{document} % Syslog % Copyright Steffen Dettmer % Lizenz: GFDL % % $Name: $ % $Revision: 1.1.2.19 $ % $Source: /cvsroot/selflinux/tutorial/adminbasics/syslog/syslog,v $ % SelfLinux-0.7.2 % % Diese Datei ist Teil von SelfLinux http://www.selflinux.de % %%% $Id: syslog,v 1.1.2.19 2003/04/20 12:20:25 std Exp $ \title{Syslog} \author{Steffen Dettmer} %\url{mailto:steffen@dett.de} \maketitle %\ref{../index.tex} %\ref{adminbasics1.tex} Elementare Systemverwaltung \ref{Syslog} \par{Layout} Matthias Hagedorn %\url{mailto:herbert-kw@t-online.de} \par{Lizenz} GFDL \tableofcontents{} \section{Einleitung} \label{d33e70} \par Auf einem System laufen, selbst wenn man momentan gerade nicht direkt damit arbeitet, stets viele Dienste. Bei typischen Linuxinstallationen sind es schnell einhundert Prozesse, die im Hintergrund ihre Arbeit verrichten. Auf einem Server ist ''ständig was los'', auch wenn man diesem das nicht unbedingt ansieht. \subsection{Hintergrundaktivitäten} \label{d33e80} \par Etliche dieser Hintergrundprozesse sind Dienste, Server oder Daemons. Alle drei Begriffe meinen im Wesentlichen das Gleiche. \par Beispiele für solche Dienste sind FTP-, Web- und Mailserver. Da ein Dienst über keine direkte Benutzerschnittstelle verfügt (das heißt, er hat kein ''Fenster''), kann er Meldungen und Fehler nicht direkt an den Benutzer melden. Oft sind die Benutzer, die gerade mit einem System arbeiten, auch die nicht gewünschten Empfänger, denn viele Meldungen sind eher für Systemadministratoren gedacht. Auf kleinen Systemen jedoch sind die Benutzer oft gleichzeitig Administratoren. \par Um einen ordnungsgemäßen Betrieb zu gewährleisten, muß das System überwacht, und gegebenenfalls auf Fehler reagiert werden. \par Auch der Linux-Kernel selbst erzeugt Meldungen, beispielsweise über Hardwarefehler (wie kaputte Festplatten). \subsection{Logdateien} \label{d33e100} \par Um derartige Meldungen zu verarbeiten, können diese beispielsweise in Logdateien geschrieben werden. Diese können dann von Zeit zu Zeit von einem Administrator geprüft werden, oder bei Fehleranalysen verwendet werden. Der Apache-Webserver schreibt beispielsweise solche Logdateien. \par Dieser Weg ist aber für Meldungen von vielen kleineren Diensten umständlich, da man viele Logdateien in unterschiedlichen Formaten analysieren müßte: Zwanzig verschiedene Dienste würden zwanzig verschiedene Logdateien schreiben. \par Hier gibt es jedoch einen Dienst, der dafür zuständig ist, von beliebigen Diensten Meldungen einzusammeln, und zentral in Logdateien zu schreiben. Der Dienst, der sehr häufig hierfür eingesetzt wird, ist Syslog. \subsection{Syslog - der System Logger} \label{d33e117} \par Syslog bietet anderen Diensten eine Schnittstelle, über die Meldungen übergeben werden. Syslog verarbeitet diese Meldungen dann weiter, in dem sie in Dateien geschrieben werden. \par Dieser Dienst ist einfach zu handhaben und wird deshalb insbesondere von kleineren Diensten gerne verwendet. Diese Dienste müssen sich dann nicht alle einzeln um Logdateien kümmern. Für den Administrator hat dies Vorteile: Es gibt eine zentrale Konfigurationsdatei und zentrale Logdateien. \par Zusätzlich erlaubt es Syslog auch, Logmeldungen an andere Server über das Netzwerk weiterzureichen. Auf dem Zielserver nimmt wiederum Syslog diese Nachrichten ab, und schreibt sie in Logdateien. Damit lassen sich die Nachrichten von mehreren Systemen auf einem Server zusammenfassen. \section{Meldungen} \label{d33e138} \par Wenn ein Dienst den Syslog-Dienst verwendet, schickt er seine Meldungen also einfach an Syslog. Eine Meldung ist im Wesentlichen eine Textzeile. Zusätzlich enthält diese noch einige Statusinformationen, beispielsweise wie wichtig diese Meldung ist und zu welchem ''Themengebiet'' sie gehört bzw. von welcher Quelle sie kommt. \par Syslog prüft anhand dieser Werte, ob und wie diese Meldung verarbeitet werden soll. Man kann Syslog zum Beispiel so konfigurieren, daß wichtige Meldungen in der einen und unwichtige in einer anderen Datei stehen, oder daß alle Meldungen, die vom Mailsystem kommen, auf einen anderen Rechner übertragen werden sollen und weiteres. \subsection{Quellen von Meldungen} \label{d33e149} \par Syslog definiert eine Reihe von Quellen oder Themengebieten für Meldungen. Diese werden als {\bf facilities} bezeichnet. Dabei ist es nur eine Konvention, wann welche Facility verwendet wird. Manchmal ist eine eindeutige Zuordnung nicht einfach möglich. Hier muß man nachsehen, welche Facility ein Dienst benutzt (bei manchen Diensten läßt sie diese auch einstellen). \par Die nachfolgende Übersicht beschreibt die Facilities kurz: %table \begin{tabular}{|l|l|} \hline \begin{minipage}{60mm} Name \end{minipage} & \begin{minipage}{60mm} Bedeutung \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf auth, authpriv} \end{minipage} & \begin{minipage}{60mm} Meldungen, die zur Authentifizierung \linebreak gehören, beispielsweise falsche \linebreak Passwörter. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf cron} \end{minipage} & \begin{minipage}{60mm} Meldungen, die von Cron erzeugt wurden, \linebreak oder von Prozessen, die von Cron \linebreak gestartet werden (die Standard-Ausgabe \linebreak und Stardard-Fehler-Ausgabe werden jedoch \linebreak von Cron nicht an Syslog gereicht, \linebreak sondern per EMail verschickt). \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf daemon} \end{minipage} & \begin{minipage}{60mm} Meldungen von allgemeinen Diensten, wie \linebreak zum Beispiel einem FTP-Server. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf kern} \end{minipage} & \begin{minipage}{60mm} Meldungen des Systemkernels. Sollte von \linebreak keinem Dienst verwendet werden. Hierzu \linebreak gehören beispielsweise Hardware-bezogene \linebreak Meldungen. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf lpr} \end{minipage} & \begin{minipage}{60mm} Meldungen des Drucksystems \linebreak (Druckerspooler). \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf mail} \end{minipage} & \begin{minipage}{60mm} Meldungen des Mailsystems (beispielsweise \linebreak von sendmail und fetchmail). \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf mark} \end{minipage} & \begin{minipage}{60mm} Nur für Syslog-interne Zwecke, sollte nie \linebreak verwendet werden. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf news} \end{minipage} & \begin{minipage}{60mm} Meldungen des News-Systems, zum Beispiel \linebreak eines Newsservers. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf syslog} \end{minipage} & \begin{minipage}{60mm} Meldungen von Syslog selbst. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf user} \end{minipage} & \begin{minipage}{60mm} Meldungen von Benutzersystemen wie zum \linebreak Beispiel eigenen Scripten. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf uucp} \end{minipage} & \begin{minipage}{60mm} Meldungen von Unix-Unix-Copy (UUCP \linebreak wird heute kaum noch verwendet). \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf local0} bis {\bf local7} \end{minipage} & \begin{minipage}{60mm} Diese sind frei und können nach Belieben \linebreak verwendet werden. Bei Diensten, bei \linebreak denen man die zu verwendende Facility \linebreak einstellen kann, kann man diese verwenden \linebreak und je nach Bedarf verteilen. \end{minipage} \\ \hline \end{tabular} \subsection{Priorität von Meldungen} \label{d33e345} \par Syslog definiert eine Reihe von Namen, die die Wichtigkeit beschreiben. Diese Priorität wird englisch als {\bf priority} oder {\bf severity} bezeichnet. Manchmal spricht man auch vom {\bf log level}. Auch diese Eigenschaft kann man verwenden, um die Meldungen differenziert zu verarbeiten, wie bereits angedeutet. \par Die folgende Übersicht nennt die definierten Prioritäten: %table \begin{tabular}{|l|l|} \hline \begin{minipage}{60mm} Name \end{minipage} & \begin{minipage}{60mm} Beschreibung \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf debug} \end{minipage} & \begin{minipage}{60mm} Unwichtige Meldungen, dienen nur zu \linebreak Debug-Zwecken (Fehlerfindung \linebreak vor allem bei der Entwicklung). \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf info} \end{minipage} & \begin{minipage}{60mm} Informative, nicht weiter wichtige \linebreak Meldungen. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf notice} \end{minipage} & \begin{minipage}{60mm} Informative Meldungen, die größere \linebreak Bedeutung haben als {\bf info}. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf warning} \end{minipage} & \begin{minipage}{60mm} Warnungen, also Meldungen, die \linebreak nicht-fatale Fehler anzeuigen. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf err} \end{minipage} & \begin{minipage}{60mm} Fehlermeldungen, die kleine \linebreak Störungen anzeigen. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf crit} \end{minipage} & \begin{minipage}{60mm} Kritische (schwerere) Fehler, die \linebreak beispielsweise Teilausfälle anzeigen. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf alert} \end{minipage} & \begin{minipage}{60mm} Schwere Fehler, die erhebliche Störungen und \linebreak Ausfälle anzeigen. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf emerg} \end{minipage} & \begin{minipage}{60mm} Sehr schwere Fehler, die beispielweise \linebreak den Totalausfall des Systems anzeigen \linebreak können und schwere Kernelfehler \linebreak (Hardwareausfälle). \end{minipage} \\ \hline \end{tabular} \par Als Faustregel gilt hier: Alles, was wichtiger oder gleich {\bf warning} ist, verdient auf jeden Fall Aufmerksamkeit. \subsection{Weitere Eigenschaften von Meldungen} \label{d33e491} \par Zu diesen beiden essentiellen Eigenschaften kommt die Information über den Zeitpunkt der Meldung hinzu (diese wird von Syslog automatisch beigefügt), die Prozeß-ID des Prozesses, der diese Meldung erzeugte, und ein {\bf Tag}, das meistens den Namen des Programmes enthält, das die Meldung erzeugte (beispielsweise verwendet Sendmail das Tag {\bf sendmail}). Auch der Hostname des Systems wird hinzugefügt, was insbesondere wichtig ist, wenn man von mehreren Systemen über das Netzwerk auf ein zentrales loggt. \subsection{Festes Format der Meldungen} \label{d33e508} \par Beim Schreiben in Logdateien verwendet Syslog ein festes Format. Eine Meldung ist immer eine Zeile. Zu Beginn steht der Zeitstempel, dann folgt der Hostname des Systems. Das dritte Feld ist das Tag (also meistens der Programmname) und in eckigen Klammern dessen Prozeß-ID. Der Rest der Zeile ist die Textnachricht dieser Meldung. Bei einigen Meldungen weicht das Format geringfügig ab, beispielsweise kann die Prozeß-ID entfallen (wie etwa bei Kernel und syslog Meldungen). \par Die Facility und Priority sind aus einer solchen Zeile leider nicht mehr erkennbar. \par Ein Beispiel für eine Logmeldung: \begin{tabular}{|l|} \hline \begin{tt} /var/log/messages \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} Mar 10 13:30:30 atlas syslogd 1.3-3: restart. \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Diese Meldung wurde am 10. März um 13:30 Uhr auf einem Host namens {\bf atlas} erzeugt, und gibt an, daß Syslog gestartet wurde (diese Meldung erzeugt Syslog selbst beim Start). \subsection{Meldungen des Kernels} \label{d33e540} \par Der Kernel verschickt seine Meldungen auf eine etwas andere Art. Der Kernel kann sich nicht wie ein normales Programm verhalten, beispielsweise weil er als erstes läuft, kein {\bf normaler} Prozeß ist, und weil er aus Performancegründen nicht auf die Fertigstellung von Schreiboperationen warten kann. \par Der Kernel legt alle Meldungen in einem speziellen Speicherbereich ab. Diese kann man zunächst überhaupt nicht lesen. Es gibt nun einen speziellen Dienst, den Kernel-Logger {\bf klogd}. Dieser Dienst holt die Meldungen aus dem Speicherbereich ab und wandelt sie auch in menschenlesbare Meldungen um. Der Kernel-Logger kann die Kernelmeldungen in eine Datei schreiben, oder an Syslog weiterversenden. Die zweite Möglichkeit ist die Voreinstellung. Startet man den Kernel-Logger, holt er die Kernelmeldungen sofort ab, und verschickt diese an Syslog. Syslog schreibt sie dann in eine Datei. Normalerweise wird {\bf klogd} automatisch direkt nach {\bf syslogd} gestartet. \section{Konfiguration von Syslog} \label{d33e570} \par Über eine zentrale Datei wird das Verhalten von Syslog gesteuert. Zusätzlich akzeptiert Syslog einige Kommandozeilen-Parameter, die das Verhalten beinflussen. \subsection{Die Konfigurationsdatei} \label{d33e580} \par Fast immer heißt diese Datei {\bf /etc/syslog.conf}. Hier wird eingestellt, wie Meldungen in Dateien zu schreiben sind, bzw. wie diese über das Netzwerk übertragen werden. \par Diese Datei ist zeilenorientiert. Zeilen, die mit einem Hashmark (''\#'') beginnen, sind Kommentare und werden ignoriert. \par Zeilen bestehen aus zwei Teilen, die durch mindestens einen Tabstop getrennt sind (moderne GNU/Linux Syslog Implementierungen erlauben oft auch Leerzeichen, es sollten aber sicherheitshalber Tabstops verwendet werden). Zu Beginn der Zeile, also auf der linken Seite, steht eine Beschreibung der Nachricht. Hier können über die Facility und Priority Meldungen {\bf ausgewählt} werden. \par Der zweite Teil gibt dann an, was mit diesen ausgewählten Meldungen passieren soll. Hier steht meistens ein Dateiname. In diese Datei werden dann die Meldungen geschrieben. Es sind nicht nur Dateinamen erlaubt: Netzwerkaddressen (IP-Addressen oder Hostnamen) sind hier erlaubt und auch Benutzernamen können hier stehen. Im letzen Fall werden die Meldungen auf die Konsolen der entsprechenden Benutzer geschrieben. Das kann für sehr wichtige Meldungen Sinn machen, wird aber im Allgemeinen als störend empfunden. Oft verwendet man als einzigen Benutzernamen {\bf root}, damit ein eventuell angemeldeter Administrator wichtige Meldungen sofort auf sein Terminal bekommt (insbesondere bei Störungen und der Suche nach den Ursachen für diese ist das oft hilfreich). \par Es werden immer alle Aktionen ausgeführt, deren Beschreibung auf die Meldung paßt. Dadurch kann ein- und dieselbe Meldung in mehrere Dateien geschrieben und gleichzeitig beispielsweise über das Netzwerk verschickt werden. \subsubsection{Meldungsbeschreibung} \label{d33e611} \par Die Meldungsbeschreibung ist eine Liste aus Facility/Priority-Paaren. Das wird so verwendet: Ist eine Meldung der entsprechenden Facility mindestens so wichtig, wie die Priority angibt, wird die rechte Seite verwendet (die Aktion wird ausgeführt). Hat man viele Regeln, so werden wichtige Meldungen damit oft in mehrere Dateien geloggt; dies ist erwünscht. \par Der Grundaufbau der durch Semikolon ({\bf ;}) getrennten Facility/Priority-Paaren ist einfach: Facility und Priority stehen in dieser Reihenfolge durch einen Punkt getrennt. Wichtige Kernelmeldungen lassen sich beispielsweise durch: \par {\bf kern.warning} \par beschreiben. Hier sind nicht nur die Meldungen der Priorität {\bf warning}, sondern auch alle höheren (also {\bf err}, {\bf crit}, {\bf alert} und {\bf emerg}) gemeint. Man kann auch Wildcards verwenden, so zum Beispiel {\bf *.warning} für alle wichtigen Meldungen und {\bf kern.*} für alle Kernelmeldungen. Hierbei ist jedoch zu beachten, daß nicht alle Syslogdienste Wildcard verstehen (aber die unter GNU/Linux verwendeten können dies). Bei GNU/Linux-Syslog kann man auch mehrere Facilities durch Komma ({\bf ,}) getrennt aufführen. Dies ist jedoch nur zulässig, wenn diese alle die gleiche Priorität haben (die nur an der letzten Facility angehängt steht). Nach dieser komplizierten Erklärung ein einfaches Beispiel: Wichtige Meldungen von News oder Mail: \par {\bf news,mailwarning} \par Oft wird jedoch auch hier lieber eine durch Semikolon getrennte Liste verwendet, weil es als lesbarer und weniger verwirrend empfunden wird: \par {\bf news.warning;mail.warning} \par Verwendet man Wildcards, kann man sämtliche Meldungen mit {\bf *.*} erfassen. GNU/Linux-Syslog bietet neben Wildcards weitere nützliche Erweiterungen: Möchte man nicht, daß alle Meldungen auch höherer Priorität passen, kann man vor die Priority ein Gleichheitszeichen ({\bf =}) setzen, beispielsweise {\bf *.=warning}. In solchen Fällen muß man aber unbedingt Regeln haben, die auch die wichtigeren Meldungen verarbeiten, sonst fehlen am Ende die wichtigsten Meldungen! \par Es ist auch möglich, mit einem Ausrufezeichen ({\bf !}) eine Priorität auszuschließen, zum Beispiel {\bf *.=!warning}, was man aber sehr selten sieht. \par Widersprechen sich Bedingungen einer durch Semikolon getrennten Bedingungsliste, so gilt die zuletzt beschriebene, also \par {\bf kern.=!info;kern.* } \par loggt jegliche Kernelmeldung (hier meinte man vermutlich einfach {\bf kern.=!info}). Solche Konstrukte sind natürlich zu vermeiden. \par Es gibt eine spezielle Priority {\bf none}, die für keine Priority der dazugehörigen Facility steht: \par {\bf *.info;mail.none } \par bezeichnet alle Meldungen mit Priority {\bf info}, außer von der Facility {\bf mail}. \subsubsection{Meldungsaktion} \label{d33e733} \par Auf der rechten Seite steht dann, was mit Meldungen geschehen soll. Im einfachsten Fall steht hier ein Dateiname. Diese müssen mit vollem Pfad angegeben werden, sie beginnen also mit einem Slash ({\bf /}). Beispiel: {\bf /var/log/messages}. Möchte man nicht-synchronisiert schreiben (später mehr dazu), schreibt man noch ein Minus ({\bf -}) davor: {\bf -/var/log/messages}. Als spezielle Datei kann man auch ein Terminal, zum Beispiel {\bf /dev/tty10}, verwenden. Dann erscheinen die Meldungen auf der Konsole 10 (die man meist über ATL+F10 oder STRG+ALT+F10 erreicht). \par Neben Dateien kann man auch sogenannte {\bf named FIFOs} verwenden. Diese beginnen mit einem Pipezeichen ({\bf |}), gefolgt vom Dateinamen. Für diese Spezialität erfolgt an dieser Stelle jedoch keine detailierte Diskussion. \par Soll die Meldung an einen anderen Server übertragen werden, schreibt man ein At-Zeichen ({\bf @}) und den Hostnamen oder besser eine IP-Adresse des Systems, zum Beispiel {\bf @192.168.1.14}. \par Um die Meldung auf die Terminals von Benutzern zu schreiben, schreibt man einfach dessen Accountnamen, beispielsweise {\bf root}. Hier darf auch ein {\bf *} stehen. Dann werden alle Benutzer (also alle Terminals) informiert. Das kann jedoch stören, denn die Meldungen erscheinen dann ''mitten im Terminaltext'' und ''verunstalten'' das Layout der laufenden Anwendung (wenn man zum Beispiel gerade einen Editor offen hat. Etliche Anwendungen haben eine Möglichkeit, die Anzeige neuzuzeichnen, häufig STRG+L ). \subsubsection{Beispielkonfigurationsdatei} \label{d33e816} \par Es folgt ein Beispiel mit ausführlichen Kommentaren. \begin{tabular}{|l|} \hline \begin{tt} /etc/syslog.conf \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} #/etc/syslog.conf: Syslogkonfigurationsdatei #Zur Trennung der "linken" und "rechten" Seite sollten # Tabstops verwendet werden (moderne GNU/Linux Syslog # Implementierungen kommen meist auch mit Leerzeichen klar) #sehr wichtige Warnungen vom Kernel, und alle Fehler außer # evtl. Passwortvertipper auf die Konsole ALT-F10 loggen. # Zur Erinnerung: .warn schließt höhere Meldungen (also err, # crit, alert, emerg) mit ein. Diese landen also auch auf # ALT-F10. kern.warning;*.err;authpriv.none /dev/tty10 #Die gleichen Meldungen für die xconsole bereitstellen # (Hier wird ein FIFO verwendet, der von xconsole # ausgelesen wird) kern.warn;*.err;authpriv.none |/dev/xconsole #ALLE Meldungen auf ALT-F9. Das ist für einen schnellen Überblick # bei "Echtzeit-Fehleranalyse" hilfreich *.* /dev/tty9 #alle sehr schweren Fehler direkt an alle Benutzer in die Konsolen # schreiben. In solchen Fällen ist das System vermutlich eh kaum # noch benutzbar. Eventuell sieht man aber kurz vor dem Absturz # noch eine Fehlermeldung und kann nach einem Neustart etwas # ändern *.emerg * #Root möchte eventuell auch schon "crit" auf der Console sehen, # wenn er zufällig gerade an dem System arbeitet: #*.crit root #Alle EMail-Meldungen in eine eigene Datei. Diese Datei wird # aus Performance-Gründen nicht nach jeder Zeile synchronisiert, # (aber schwere Fehler schreiben wir nochmal in eine extra Datei) mail.* -/var/log/mail #Warnungen in eine extra Datei. Diese wird hier nicht sync'd (bei # langsameren Systemen hilfreich) *.=warn;*.=err -/var/log/warn #"crit" und höhere kommen in die gleiche Datei, aber sync'd *.crit /var/log/warn #alles außer "debug" und mail in eine andere Datei *.info;mail.none -/var/log/messages #Für die Fehlersuche hilft oft eine Datei, die sämtliche #Informationen enthält #*.* -/var/log/allmessages #Hat man einen Loghost, soll dieser eine Kopie von allen # Meldungen erhalten #*.* @192.168.1.1 #Weniger wichtige Systeme sollen das Netzwerk nicht unnötig # belasten #*.warn @192.168.1.1 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsection{Kommandozeilenoptionen} \label{d33e843} \par Kommandozeilenoptionen steuern das Verhalten von Syslog ebenfalls. Über Kommandozeilenoptionen kann Syslog konfiguriert werden, daß Meldungen vom Netzwerk (also anderen System-Loggern) akzeptiert und verarbeitet werden. Man kann Syslog auch veranlassen, eine andere Konfigurationsdatei zu verwenden. %table \begin{tabular}{|l|l|} \hline \begin{minipage}{60mm} Option \end{minipage} & \begin{minipage}{60mm} Beschreibung \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -a} \verb+<+Socket\verb+>+ \end{minipage} & \begin{minipage}{60mm} Öffnet \verb+<+Socket\verb+>+ zum Lesen von Meldungen. \verb+<+Socket\verb+>+ ist auf {\bf /dev/log} voreingestellt. Hier kann zum Beispiel zusätzlich ein {\bf dev/log} aus einer ''chroot'' Umgebung angegeben werden, damit die ''chroot'' Umgebung auch Syslog verwenden kann. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -d} \end{minipage} & \begin{minipage}{60mm} Debug Modus (für Entwickler gedacht) \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -f} \verb+<+Konfigdatei\verb+>+ \end{minipage} & \begin{minipage}{60mm} Lädt eine andere Konfigdatei. \linebreak Normalerweise wird {\bf /etc/syslog.conf} \linebreak verwendet. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -h} \end{minipage} & \begin{minipage}{60mm} Über das Netzwerk empfangene Meldungen \linebreak auch über das Netzwerk weitersenden. \linebreak Damit kann man mehrere Netzwerk-Syslogs \linebreak ''in Reihe schalten'', um Beispielsweise \linebreak Meldungen durch mehrere Firewalls oder \linebreak aus einer DMZ zu bekommen. {\bf -t} sollte \linebreak auch verwendet werden, siehe dort. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -l} \verb+<+Hostnamen\verb+>+ \end{minipage} & \begin{minipage}{60mm} Eine durch {\bf :} getrennte Liste von \linebreak Hostnamen, die in kurzer Form in der \linebreak Logdatei stehen. Gewöhnlich bevorzugt man \linebreak die Option {\bf -s}, die ähnliches Verhalten \linebreak bringt. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -m} \verb+<+Mark Zeit\verb+>+ \end{minipage} & \begin{minipage}{60mm} Syslog schreibt alle 20 Minuten einen \linebreak Eintrag {\bf --MARK--} in ein Logfile. Daran \linebreak kann man erkennen, daß das System noch \linebreak lebt. Bei der nachträglichen Analyse kann \linebreak man dadurch beispielsweise nächtliche \linebreak Abstürze zeitlich eingrenzen. Durch diese \linebreak Option kann man anstatt 20 (Minuten) auch \linebreak einen anderen Wert verwenden. Der Wert {\bf 0} \linebreak schaltet die Funktion ab. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -n} \end{minipage} & \begin{minipage}{60mm} Syslog soll nicht automatisch in den \linebreak Hintergrund gehen. Diese Option wird im \linebreak Normalfall nicht verwendet. Auf \linebreak speziellen Systemen (Rettungs- oder \linebreak Installationsystemen) wird diese manchmal \linebreak gesetzt. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -p} \verb+<+Socket\verb+>+ \end{minipage} & \begin{minipage}{60mm} Öffnet \verb+<+Socket\verb+>+ zum Lesen von Meldungen. \linebreak Siehe Option {\bf -a}. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -r} \end{minipage} & \begin{minipage}{60mm} Aktiviert den Empfang von \linebreak Netzwerkmeldungen. Aus Effizienz- und \linebreak Stabilitätsgründen sollte man alle IPs, von \linebreak denen man Meldungen empfängt, in die \linebreak Datei {\bf /etc/hosts} eintragen (diese werden \linebreak benutzt, um den Hostnamen für das Logfile \linebreak zu bilden) \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -s} \verb+<+Domains\verb+>+ \end{minipage} & \begin{minipage}{60mm} \verb+<+Domains\verb+>+ ist eine durch {\bf :} getrennte \linebreak Liste von Domains, die vor dem Loggen von \linebreak Hostnamen abgeschnitten werden. Das ist \linebreak in Verbindung mit {\bf -r} hilfreich, da die \linebreak FQDNs (vollen Namen) viel Platz im Logfile \linebreak wegnehmen, und die Hostnamen meistens \linebreak sowieso schon eindeutig sind. Hat man \linebreak einen host {\bf mail.selflinux.de} und ein \linebreak {\bf -s selflinux.de}, so wird der Hostname \linebreak also als {\bf mail} in den Logdateien stehen. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -t} \end{minipage} & \begin{minipage}{60mm} Weitergeleitete Meldungen (siehe Option \linebreak {\bf -h}) sollen den empfangenen Hostnamen \linebreak enthalten, nicht den eigenen. Das heißt \linebreak also, der Hostname der Meldung wird nicht \linebreak verändert; diese können damit weiterhin \linebreak eindeutig zugeordnet werden. \end{minipage} \\ \hline \end{tabular} \par Diese Optionen werden in der Regel vom Syslog-Startscript, häufig {\bf /etc/init.d/syslog}, beim Start von Syslog an diesen übergeben. Hier kann man also die eigenen Optionen für den Aufruf angeben. \par Bei SuSE-Systemen ist das Startscript intelligenter, es gestattet dem Administrator, auf einfachem Weg weiterere Startoptionen zu setzen. Hierzu öffnet man dazu einfach die Datei {\bf /etc/rc.config} und ändert \begin{tabular}{|l|} \hline \begin{tt} /etc/rc.config \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} SYSLOGD_PARAMS="" \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par so, daß die erwünschten Startoptionen verwendet werden. Diese werden hier einfach eingetragen. \par Auch unter RedHat muß man nicht mehr die Datei {\bf /etc/init.d/syslog} bearbeiten, unter {\bf /etc/sysconfig/syslog} kann man durch Ändern von {\bf SYSLOGD\_OPTIONS=''''} (z.B. {\bf ''-r -m 0 -s picard.inka.de:zeibig.net}'') die gewünschten Startoptionen angeben. \subsection{Remote-Logging} \label{d33e1165} \par Remote-Logging bedeutet, daß ein Host Syslog-Meldungen auf einen anderen Host weiterversendet. Dieser andere Host schreibt die Meldungen dann in Dateien. Gewöhnlich konfiguriert man das so, daß die Meldungen nicht nur über das Netzwerk verschickt, sondern daneben auch lokal in Dateien geschrieben werden. Dies beugt Informationsverlust bei Netzwerkausfällen oder Störungen vor. Da Syslog eine wichtige Informationsquelle zur Analyse von Störungen ist, soll hier natürlich möglichst nichts fehlen. \subsubsection{Vorteile des Remote-Logging} \label{d33e1175} \par Oft hat man in LANs einen zentralen Host, der Netzwerk-Syslog-Meldungen erhält, und diese in Dateien schreibt. Diesen Host nennt man {\bf Loghost}. \par Diese Konfiguration hat etliche Vorteile: So kommen die Meldungen zentral auf einer Maschine an, so daß man auch komplexere Störungen analysieren kann (wenn diese mehrere Server betreffen, zum Beispiel einen Mailserverausfall, weil DNS ausgefallen ist). \par Ein weiterer Vorteil liegt im Fall von erfolgreichen Angriffen vor. Wenn ein Angreifer ein System kompromitiert hat, wird er in den meisten Fällen die Syslogdateien löschen oder manipulieren, um sich zu tarnen und seine Herkunft zu verschleiern. Wenn nun aber der Administrator einen Loghost verwendet, ist es unwahrscheinlicher, daß auch dieser gleichzeitig gehackt wird. So kann er auf dem Loghost die Meldungen analysieren und wichtige Informationen über den Angriff erlangen. \par Ein dritter Vorteil der Zentralisierung ist die Vereinfachung automatischer Behandlung von Logfiles, zum Beispiel wird das Aufbereiten/Filtern und als Mail Verschicken erleichtert: Man muß diesen Vorgang nur auf einer Maschine pflegen. \subsubsection{Nachteile des Remote-Logging} \label{d33e1198} \par Remote-Logging hat aber auch Nachteile, gerade, wenn man Syslog einsetzt. Syslog verwendet ausschließlich das UDP Protokoll. UDP Pakete werden direkt verschickt, ihr Empfang wird nicht bestätigt. Auf stark ausgelasteten Netzen kann es daher vorkommen, daß Meldungen verloren gehen, ohne daß man es bemerkt. Weiterhin kann ein Angreifer den Loghost {\bf überfluten}, in dem er sehr viele sinnlose Meldungen verschickt. Dies kann die Last auf dem Loghost stark erhöhen, und im Extremfall dazu führen, daß er nur noch einen Teil der wichtigen Meldungen erhält, und die Netzwerklast kann zu weiteren Störungen führen. Bei sehr massiven Flut-Angriffen ist auch ein Vollaufen der Festplatte denkbar. In diesem Fall ist neben dem Verlust von Logmeldungen in der Regel mit weitereren empfindlichen Störungen zu rechnen, oft mit einem Totalausfall sämtlicher Dienste des Loghosts! \par Ein Angreifer, der eine Maschine gehackt hat, und hier über root-Rechte verfügt, kann auch einen Netzwerk-Sniffer verwenden, um die Syslog-Nachrichten, die über das Netzwerk verschickt werden, mitzulesen. Er kann dadurch wichtige Informationen ausspionieren. Syslog gestattet leider keine Verschlüsselung oder andere Absicherung der Netzwerkkommunikation. \subsubsection{Konfiguration des Loghosts} \label{d33e1218} \par Die Konfiguration des Loghosts ist einfach. Man muß lediglich den Empfang aktivieren, in dem man Syslog mit der Option {\bf -r} startet. Bei SuSE-Systemen öffnet man dazu einfach die Datei {\bf /etc/rc.config}, und ändert \begin{tabular}{|l|} \hline \begin{tt} /etc/rc.config \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} SYSLOGD_PARAMS="" \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par so, daß die Startoption {\bf -r} verwendet wird. Die IP Adressen der Hosts, die den Loghost verwenden, sollte man in die Datei {\bf /etc/hosts} eintragen, um Fehlern bei DNS Ausfällen vorzubeugen. \par Kommt nun eine Nachricht über das Netzwerk, schaut Syslog anhand der Sender-IP Adresse nach, wie der Hostname des Systems lautet. Ist dieser beispielsweise www.selflinux.de, so wird dieser Name im Logfile eingetragen. Dies ist unübersichtlich, und man möchte vermutlich die Ausgaben von ''{\bf .selflinux.de} unterdrücken (sofern der Teil davor eindeutig ist). Dazu verwendet man am einfachsten die Option {\bf -s}, die die Domainanteile abschneidet. In unserem Beispiel würde der Administrator also {\bf -r -s selflinux.de} verwenden. Hat er ein SuSE-System, trägt er einfach in {\bf /etc/rc.config} ein: \begin{tabular}{|l|} \hline \begin{tt} /etc/rc.config \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} SYSLOGD_PARAMS="-r -s selflinux.de" \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Syslog verwendet den UDP Port {\bf syslog}. Dieser wird in der Datei {\bf /etc/services} nachgesehen. Normalerweise soll Syslog die {\bf Portnummer 514} verwenden. Demzufolge muß folgende Zeile in der Datei {\bf /etc/services} vorhanden sein: \begin{tabular}{|l|} \hline \begin{tt} /etc/services \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} syslog 514/udp \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Dies ist bei gängigen Distributionen (SuSE, RedHat) jedoch bereits richtig eingetragen. \par Nun muß Syslog neu gestartet werden, damit die Änderungen aktiv werden. Dazu schreibt man beispielsweise: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ /etc/rc.d/syslog restart \end{scriptsize} \end{tt} \linebreak \par Auf SuSE Systemen kann man auch schreiben: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ rcsyslog restart \end{scriptsize} \end{tt} \linebreak \par Nun akzeptiert der Syslog Nachrichten vom Netzwerk. \subsubsection{Konfiguration der anderen Hosts} \label{d33e1328} \par Die Maschinen, die nun den Loghost verwenden sollen, müssen hierzu angepaßt werden. Ein neuer Eintrag in der Datei {\bf /etc/syslog.conf} ist auf jedem Server notwendig. Möchte man alle Nachrichten auf den {\bf Loghost 192.168.1.1} loggen, verwendet man: \begin{tabular}{|l|} \hline \begin{tt} /etc/syslog.conf \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} *.* @192.168.1.1 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Um nur wichtige Meldungen zu verschicken, kann man \begin{tabular}{|l|} \hline \begin{tt} /etc/syslog.conf \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} *.warn @192.168.1.1 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par verwenden. Es kann auch mehrere solcher Zeilen geben, so kann man sich auch eine Konfiguration mit zwei Loghosts vorstellen. Über den Sinn solchen Vorgehens kann man natürlich streiten. \par Nach dem Ändern dieser Datei muß Syslog neu geladen oder neu gestartet werden. Dazu kann man Syslog ein Hangup-Signal senden (SIGHUP), in dem man beispielsweise schreibt: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ killall -HUP syslog \end{scriptsize} \end{tt} \linebreak \par oder auf SuSE-Systemen das Startscript verwenden: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ rcsyslog reload \end{scriptsize} \end{tt} \linebreak \par Man kann Syslog aber auch einfach neu starten ({\bf stop/start}). Allerdings gehen hier möglicherweise für einige Sekunden Meldungen verloren. \subsubsection{Beispiel für Logeinträge} \label{d33e1393} \par Auf dem Loghost kann man dann gut das Netzwerksystem beobachten. Ein fiktives Beispiel: \begin{tabular}{|l|} \hline \begin{tt} /var/log/messages (fiktives Beispiel) \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} Mar 10 13:30:30 atlas syslogd 1.3-3: restart. Apr 1 13:02:01 ns1 named[124]: XX+/127.0.0.1/1.1.168.192. in-addr.arpa/PTR/IN Apr 1 13:02:01 www httpd[123]: GET /login.cgi?username=steffen Apr 1 13:02:03 www httpd[123]: Starting authorization for "steffen" from "ws1.selflinux.de" Apr 1 13:02:04 radius radiusd[125]: autorization request from "www.selflinux.de" for "steffen" Apr 1 13:02:04 db kernel: end_request: I/O error, dev 03:02 (hda), sector 58138452 Apr 1 13:02:04 db postmaster[111]: Database error: disk read failed (I/O error) Apr 1 13:02:04 radius radiusd[125]: authorization request for "steffen" failed (database error) Apr 1 13:02:03 www httpd[123]: Authorization for "steffen" failed (incorrect password) \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par In diesem fiktiven Szenario sieht man eine fehlgeschlagene Web-Anmeldung. Der Webserver (httpd) löste die IP Addresse auf (über ''named'' auf ''ns1'') und fragte dann bei einem Radius-Dienst auf einem separten Server nach. Dieser wiederum verwendete eine PostgreSQL Datenbank auf einem anderen Server. Diese hat ein großes Problem: Eine kaputte Festplatte ( {\bf sector 58138452 } konnte nicht gelesen werden). Demzufolge kann PostgreSQL ({\bf postmaster}) die Anfrage nicht bestätigen. Radius meldet also einen Fehler, den der Webserver als {\bf incorrect password } fehlinterpretiert. Nicht das falsche Passwort war das Problem, sondern eine kaputte Festplatte! In diesem Fall würde man im Webserverlog sehr viele {\bf incorrect password } finden, und einen Angriff vermuten. Doch durch die Verwendung eines Loghosts sind die Meldungen aller Komponenten zentral verfügbar. Hier hat das die Fehlersuche erheblich beschleunigt (der Administrator hat die Festplatte sofort gewechselt und die Bandsicherung zurückgespielt). \subsection{Serverkonfiguration} \label{d33e1434} \par Bei der Installation eines Servers kann man überlegen, wie man mit großen Logfiles umgehen möchte. Hier ist zunächst von Interesse, daß große Logdateien Filesysteme füllen können. Hat man die Logdateien (in der Regel also das Verzeichnis {\bf /var/log}) im selben Filesystem gemoutet wie beispielsweise das Root-Filesystem {\bf /}, so ist damit zu rechnen, daß nach einer Logflut das System vollkommen unbenutzbar ist, also mit dem Ausfall sämtlicher Dienste. \par Diese Gefahr kann man durch den Einsatz von Werkzeugen wie {\bf logrotate} oder dem SuSE-Linux {\bf /etc/logfiles} Mechanismus senken. Auf SuSE-Systemen trägt man hierzu jede Logdatei in {\bf /etc/logfiles} ein. Hinter den Dateinamen schreibt man die Größe (z.B. {\bf +1024k}) und den Zugriffsmodus (beispielsweise {\bf 640}) und den Eigentümer (beispielsweise {\bf root.root}). Die erste Option wird für das Dienstkommando {\bf find} als Parameter verwendet, der zweite für {\bf chmod} und der dritte für {\bf chown}. Die manpages dieser drei Werkzeuge geben Auskunft über Art der verwendbaren Werte. Auf SuSE-Systemen sind in dieser Datei die voreingestellten Logdateien bereits eingetragen. Eigene Dateien muß man hier natürlich hinzufügen. \par Eine weitere Möglichkeit wäre der Einsatz von separaten Filesystemen. Man kann z.B. {\bf /var} auf eine andere Partition oder ein anderes LVM LV (logical volume) mounten. Dies hat jedoch auch Nachteile: es wird nicht der gesamte verfügbare Platz für Logfiles verwendet (demzufolge fällt das Logging früher aus), und insbesondere Angriffe und Störungen sind damit nicht mehr rekonstruierbar. Daher ist eine regelmäßige Überprüfung der freien Plattenkapazität durchzuführen, vorzugsweise automatisch, dann kann man es nicht vergessen. \subsection{Bootkonfiguration} \label{d33e1487} \par Syslog sollte stets laufen. Syslog benötigt meist Schreibzugriff auf Festplatten. Bei Konfigurationen mit einem zentralen Loghost wird weiterhin das Netzwerk benötigt. Daher sollte man Syslog unmittelbar nach dem Hochfahren des Netzwerkes starten. Auf SuSE-Systemen verhält sich das bereits so. \par Es ist denkbar, den Start von Syslog vor dem des Netzwerkes durchzuführen, wenn man keinen Loghost verwendet. Eventuell erhält man so mehr Meldungen. \par Nach dem Start von Syslog sollte man den Kernel-Logger {\bf klogd} starten. Sicherheitshalber wartet man z.B. eine Sekunde dazwischen. Die GNU/Linux-Startscripte sollten dies bereits so machen (bei SuSE-Systemen ist es der Fall). \subsection{Syslog-Konfiguration} \label{d33e1507} \par Man sollte darauf achten, daß keine Meldungen überhaupt nicht geloggt werden. Meistens möchte man verschiedene Dateien haben, um schnell Meldungen zu finden. Oft werden mindestens die Dateien {\bf /var/log/messages} und {\bf /var/log/warn} verwendet. Letzere enthält nur wichtige Meldungen. Sehr üblich ist auch eine Datei {\bf /var/log/mail} und eventuell {\bf /var/log/news} für Meldungen des Mail- bzw. Newssystems. Häufig sieht man auch {\bf /var/log/allmessages} oder {\bf /var/log/allinone}, die sämtliche Meldungen enthalten. \par Zusätzlich empfiehlt es sich, Meldungen auf einer virtuellen Konsole zu haben. \par Weitere Informationen und ein Beispiel finden sich im Abschnitt ''Die Konfigurationsdatei'', siehe oben. \subsection{Einheitliche Netzwerkzeit} \label{d33e1542} \par Bei der Analyse von Störungen ist es wichtig, Reihenfolgen und Abstände von Fehlermeldungen oder Fehlermails richtig feststellen zu können. Oft sind Zeitstempel bekannt. Diese sind natürlich Rechner-übergreifend nur verwendbar, wenn auch alle Maschinen die gleiche Vorstellung der Netzwerkzeit haben, deren Uhren also genau gleich bzw. synchron sind. Es empfiehlt sich also (insbesondere, wenn man keinen Loghost verwendet), die Netzwerkzeiten zu synchronisieren. Dazu verwendet man üblicherweise einen NTP (Network Time Protocol) Dienst, beispielsweise xntpd. \subsection{Firewall-Konfiguration} \label{d33e1553} \par Firewalls sollten verhindern, daß UDP/514 Pakete vom Internet in das LAN geroutet werden, um Flut-Angriffen zu entgehen. Selbst wenn man keinen Loghost verwendet, könnte möglicherweise ein interner Host den Empfang von Netzwerk-Meldungen aktiviert haben. Auskunft darüber gibt das Kommando: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ netstat -an --inet | grep 514 \end{scriptsize} \end{tt} \linebreak \par Sicherheitshalber sollten Firewalls ohnehin alle nicht benötigten und nicht verwendeten Ports sperren. \par Interne Firewalls müssen diese Pakete natürlich zwischen Loghost und den Logsystemen erlauben, aber sollten so eingestellt werden, daß nur die betreffenden IP-Adressen erlaubt sind. \par Es ist zu beachten, daß die {\bf Absender-Adresse} von UDP Paketen sehr einfach fälschbar ist. Demzufolge kann man bei Firewalls diese Adressen nicht zum Filtern verwenden. Man sollte hier an Interfaces blocken. Hat eine Firewall beispielsweise ein externes Interface {\bf eth1}, sollte eine entsprechende Firewall-Regel den Empfang und Versand von Syslog-Paketen über dieses Interface unterbinden. Wenn die Firewall über {\bf eth0} an das interne Netz angebunden ist, kann hier dennoch ein Loghost verwendet werden, der die Firewallmeldungen empfängt. \par Bei der Verwendung von Firewalls und Loghosts ist zu beachten, daß normalerweise unerlaubte Pakete geloggt werden, was zu einen hohen Aufkommen an Meldungen führt. Hier sollte Syslog so konfiguriert werden, daß diese Meldungen nicht über das Netzwerk geschrieben werden, wenn sich hier Probleme ergeben (Portscans könnten beispielsweise zu Flut-Verhalten führen). \par Häufig sind aber die Außenanbindungen vergleichsweise langsam (beispielsweise E1 (2MBit) extern und 100Mbit intern), so daß hier interne Netzwerküberlastungen eher unwahrscheinlich sind. \section{Starten und Stoppen von Syslog} \label{d33e1598} \par Der Start erfolgt fast immer und ausschließlich automatisch beim Hochfahren des Systems über ein {\bf rc-Script}, häufig {\bf /etc/rc.d/syslog}. Bei gängigen GNU/Linux Distributionen ist das bereits so konfiguriert. Dieses Script startet oft (zum Beispiel bei SuSE-Systemen) auch automatisch den Kernel-Logger. Andere Systeme haben hier eventuell ein eigenes {\bf rc-Script}. Dieses sollte dann in jedem Fall direkt nach Syslog gestartet werden. \par Um Syslog manuell zu starten, verwendet man: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ /etc/rc.d/syslog start \end{scriptsize} \end{tt} \linebreak \par oder bei SuSE-Systemen kurz: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ rcsyslog start \end{scriptsize} \end{tt} \linebreak \par Um den Dienst zu stoppen, schreibt man analog dazu {\bf stop} anstatt {\bf start}. \section{Meldungen selbst erzeugen} \label{d33e1648} \par Es gibt mehrere Fälle, in denen man selbst Meldungen erzeugen möchte. Denkbar sind beispielsweise Cron-Jobs, die neben dem Verschicken der EMail mit den Script-Ausgaben kurze Erfolgs- oder Mißerfolgsmeldung über Syslog schreiben sollen. Eine weitere Anwendung sind automatisch ausgeführte Scripte, beispielsweise {\bf /etc/ppp/ip-up} oder {\bf rc-Scripte}. \par Es gibt ein kleines, einfaches Werkzeug, mit dem man Syslog-Meldungen erzeugen kann. Es heißt {\bf logger}. Diesem Werkzeug kann man über Optionen sagen, wie eine Meldung zu loggen ist. Hier kann man beispielsweise Priority und Facility angeben. \par Die wichtigsten Optionen sind: %table \begin{tabular}{|l|l|} \hline \begin{minipage}{60mm} Option \end{minipage} & \begin{minipage}{60mm} Beschreibung \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -i} \end{minipage} & \begin{minipage}{60mm} Prozeß-ID mit in die Nachricht schreiben \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -p} \verb+<+Fac.\verb+>+.\verb+<+Pri.\verb+>+ \end{minipage} & \begin{minipage}{60mm} Angegenene Priorität und Facility \linebreak verwenden. Mögliche Werte sind die \linebreak gleichen wie die in {\bf /etc/syslog.conf} \linebreak verwendbaren, siehe Abschnitt ''Quellen von \linebreak Meldungen'' und ''Priorität von Meldungen''. \linebreak Wird diese Option nicht angegeben, wird \linebreak {\bf user.notice} verwendet. \end{minipage} \\ \hline \begin{minipage}{60mm} {\bf -t} \verb+<+Tag\verb+>+ \end{minipage} & \begin{minipage}{60mm} Angegebenes ''Tag'' verwenden. Meist wird \linebreak hier der Name des Scriptes verwendet. \end{minipage} \\ \hline \end{tabular} \par Es gibt zwei Arten, logger aufzurufen. Einmal kann man die Meldungen mit in die Kommandozeile schreiben, direkt hinter die Optionen. Mindestens wenn die Meldung Minuszeichen ({\bf -}) enthalten könnte, sollte man sie mit {\bf --} abtrennen, um zu vermeiden, daß Meldungsteile als Optionen mißinterpretiert werden. Ein Beispiel: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ logger -i -t MeinProgramm -- Ich bin eine Meldung. \end{scriptsize} \end{tt} \linebreak \par Dies erzeugt dann folgenden Logdatei-Eintrag: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ logger -i -t MeinProgramm -- Ich bin eine Meldung. \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} Apr 13 13:02:04 atlas MeinProgramm[6178]: Ich bin eine Meldung.\end{scriptsize} \end{tt} \linebreak \par Die zweite Art des Aufrufes unterscheidet sich in der Art, wie die Meldung übergeben wird. Wird nämlich keine auf der Kommandozeile angeben, liest logger die Standard-Eingabe. Damit kann man also schreiben: \begin{tt} \begin{scriptsize} user@linux \~{}/ \$ echo ''Ich bin eine Meldung.'' | logger -i -t MeinProgramm \end{scriptsize} \end{tt} \linebreak \par was zum gleichen Ergebnis führt. logger geht auch mit mehreren Eingabezeilen korrekt um (jede Zeile wird eine Meldung). In Scripten kann man deshalb beispielsweise komfortabel schreiben: \begin{tabular}{|l|} \hline \begin{tt} Beispielscript \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} LOGGER="/usr/bin/logger -t `basename $0`[$$]" { test -e /etc/irgenteinedatei || echo "Error, Datei nicht gefunden!"; date; echo "eine andere Fehlermeldung"; } | $LOGGER \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Dies erzeugt auf elegante Art und Weise folgende Einträge: \begin{tabular}{|l|} \hline \begin{tt} /var/log/messages \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} Apr 13 13:20:45 atlas script.sh[6338]: Error, Datei nicht gefunden!
Apr 13 13:20:45 atlas script.sh[6338]: Sat Apr 13 13:20:45 MEST 2002
Apr 13 13:20:45 atlas script.sh[6338]: eine andere Fehlermeldung
\end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \section{Logdateien auswerten} \label{d33e1803} \par Sehr wichtig ist es natürlich, die erzeugten Logdateien auszuwerten. Gewöhnlich hat ein Administrator jedoch nicht die Zeit, täglich tausende von Zeilen zu lesen. \par Hier benutzt man Werkzeuge, um diese Arbeit zu automatisieren. Ein Beispiel hierfür ist {\bf LogWatch}, das von RedHat verwendet wird. Ein weiteres ist {\bf logmail}, das man sich von http://sws.dett.de/logmail herrunterladen kann (es enthält auch eine deutsche Dokumentation). Sicherlich gibt es viele weitere ähnliche und leistungsfähigere Werkzeuge. \par Verwendet man {\bf logmail}, so kann man sich eine Konfigurationsdatei anlegen, in dem spezifiziert wird, welche Einträge per EMail an wen verschickt werden. Bei Loghosts kann man zum Beispiel alle Meldungen von {\bf postmaster} an den PostgreSQL Administrator und alle Meldungen von {\bf named} an den DNS-Administrator verschicken, und alle Meldungen an einen dritten Administrator. Des weiteren sollte konfiguriert werden, welche Meldungen man nicht haben möchte, sonst erhalten die Administratoren viele {\bf langweilige} Meldungen. {\bf Logmail} gestattet es auch, Loghost-Meldungen anhand des Hostnamens per EMail zu verteilen. So kann man den entsprechenden Systemadministratoren {\bf ihre} Meldungen zustellen. \par Man kann sich alle Meldungen, die man per EMail erhält, aber nicht mehr erhalten möchte, einfach in die Konfigurationsdatei als Filter mit aufnehmen. Dann werden diese in Zukunft nicht mehr verschickt. Derartige Systeme bedürfen natürlich der Pflege. In wenigen Tagen erhält man dann aber nur noch neue, interessante Meldungen per EMail, und kann nicht vergessen, Logfiles auszuwerten. So erkennt man auch Störungen, die nachts auftraten, oder bekommt Mitteilungen über Angriffsversuche. Zusätzlich senkt das die Gefahr, daß ein Angreifer Logfiles manipulieren kann, da unter Umständen bereits eine EMail verschickt wurde, die der Angreifer nicht mehr {\bf aufhalten} oder ungeschehen machen kann. \par Nur durch derartiges Vorgehen ist es möglich, mehrere Server richtig zu betreuen, da im Produktionsbetrieb natürlich keine Zeit bleibt, täglich stundenlang Logfiles auszuwerten, die fast immer langweilig sind. \section{Andere Systemlogger} \label{d33e1862} \par Neben Syslog gibt es weitere Systemlogger, die man verwenden kann. Beispiele sind {\bf socklock} und {\bf syslog-ng}. Beide haben interessante Funktionen und Vorteile gegenüber Syslog. \section{Weitere Informationsquellen} \label{d33e1879} \par Es folgt eine unvollständige Liste: \par {\bf * syslog manpage } \par {\bf * klogd manpage } \par HOWTOs oder andere Dokumentationen sind mir nicht bekannt. Über Hinweise freue ich mich natürlich jederzeit. \ref{inhalt.tex} \end{document}