Logs lesen und konfigurieren

Im letzten Kapitel Linux Server updaten haben wir das Betriebssystem auf den neuesten Stand gebracht.

In diesem Kapitel schauen wir uns an, wo die Log-Dateien gespeichert werden und wie wir sie auslesen können. Zugegeben, ist das nicht das spannendste Kapitel und die kleine Umkonfiguration, die wir vornehmen werden, wird keine Sicherheits- oder Performanzoptimierung bringen. Du könntest dieses Kapitel einfach überspringen und Dein Server würde genauso gut laufen. Dennoch sollte jeder Administrator über Log-Dateien Bescheid wissen. Wenn mal was nicht läuft, sind sie die erste Anlaufstelle bei der Fehlersuche.

Die Log-Datei, die das An- und Abmelden protokolliert, wird zusätzlich von Hintergrundprozessen beschrieben. Das macht sie unübersichtlich und schwierig zu lesen. Daher werden wir eine Einstellung vornehmen, um die "uninteressanten" Ereignisse separat zu erfassen. So sind die Einträge sauber getrennt, die leichter analysiert werden können.

Log Dateien

Die zentrale Stelle für Log-Dateien ist /var/log.


__$ sudo ls -l /var/log

Ausgabe:


total 11264
-rw-r--r--  1 root      root              31252 Jan  4 22:20 alternatives.log
drwxr-xr-x  2 root      root               4096 Jan  4 22:19 apt
-rw-r-----  1 syslog    adm             1294710 Jan  4 22:23 auth.log
-rw-r--r--  1 root      root             104003 Jan  3  2021 bootstrap.log
-rw-rw----  1 root      utmp            1100928 Jan  4 20:40 btmp
-rw-r--r--  1 syslog    adm              474428 Jan  4 22:28 cloud-init.log
-rw-r-----  1 root      adm               23633 Jan  4 22:28 cloud-init-output.log
drwxr-xr-x  2 root      root               4096 Jan  3  2021 dist-upgrade
-rw-r--r--  1 root      adm               61927 Jan  4 22:28 dmesg
-rw-r--r--  1 root      adm               61624 Jan  4 22:17 dmesg.0
-rw-r--r--  1 root      adm               16365 Jan  4 15:02 dmesg.1.gz
-rw-r--r--  1 root      adm               15996 Jan  4 15:00 dmesg.2.gz
-rw-r--r--  1 root      adm               16027 Jan  4 19:35 dmesg.3.gz
-rw-r--r--  1 root      adm               16092 Jan  4 19:34 dmesg.4.gz
-rw-r--r--  1 root      root             497519 Jan  4 22:21 dpkg.log
-rw-r-----  1 root      adm               20285 Jan  4 10:53 fail2ban.log
-rw-r--r--  1 root      root              32064 Jan  4 21:31 faillog
drwxr-xr-x  3 root      root               4096 Jan  4 12:09 installer
drwxr-sr-x+ 3 root      systemd-journal    4096 Jan  4 12:14 journal
-rw-r-----  1 syslog    adm             2322573 Jan  4 22:23 kern.log
drwxr-xr-x  2 landscape landscape          4096 Jan  4 12:18 landscape
-rw-rw-r--  1 root      utmp             292584 Jan  4 22:23 lastlog
-rw-r-----  1 syslog    adm                2627 Jan  4 22:12 mail.err
-rw-r-----  1 syslog    adm              303319 Jan  4 22:23 mail.log
drwx------  2 root      root               4096 Jan  3  2021 private
-rw-r-----  1 syslog    adm             1547818 Jan  4 22:23 syslog
-rw-r-----  1 syslog    adm             1683517 Jan  4 00:00 syslog.1
-rw-------  1 root      root                  0 Jan  3  2021 ubuntu-advantage.log
-rw-------  1 root      root                157 Jan  4 22:20 ubuntu-advantage-timer.log
-rw-r-----  1 syslog    adm             1723687 Jan  4 22:23 ufw.log
drwxr-x---  2 root      adm                4096 Jan  4 12:14 unattended-upgrades
-rw-rw-r--  1 root      utmp              83328 Jan  4 22:23 wtmp

Log-Dateien werden typischerweise in vier Kategorien aufgeteilt:

Applikation
Ereignis
Dienst
System

Der SSH Dienst protokolliert in die Datei /var/log/auth.log. Schauen wir da mal rein:


__$ sudo less /var/log/auth.log

Am Anfang jeder Zeile steht das Datum und am Ende Protokollnachricht. Wie Du vielleicht bemerkt hast, gibt es auch Anmelde-Ereignisse, die nicht von Dir sein können. Diese enthalten die Phrase pam_unix(cron:session) und stammen von internen Prozessen. Aber dazu später mehr.

Filtern können wir die Ausgabe zum Beispiel mit grep und einem Suchwort. Das nächste Kommando zeigt alle Zeilen, wo die Phrase user tom erwähnt wird:


__$ sudo less /var/log/auth.log | grep "user tom"

Noch ein Beispiel mit der Phrase cron:session:


__$ sudo less /var/log/auth.log | grep "cron:session"

Die letzten Ereignisse ausgeben und live mitlesen

Mit tail kann eine gewisse Anzahl der letzten Zeilen ausgeben werden. Zum Beispiel die letzten 10:


__$ tail -10 /var/log/auth.log

Log-Dateien können live mitgelesen werden. Das hilft, um nicht ständig die Log-Datei schließen und wieder öffnen zu müssen. Neue Einträge bzw. Änderungen werden mit dem Parameter -f ausgegeben:


__$ tail -f /var/log/auth.log

Die Tastenkombination STRG+c beendet die Ausgabe.

Im Moment passiert kaum etwas. Das wird später interessanter, wenn wir die Logs vom Server Dienst beobachten.

Logrotate

Nach einer Weile landen jede Menge Daten in den Logs. Die Dateien sind aufgebläht und verbrauchen entsprechend Festplattenplatz. Um dem entgegenzuwirken werden in gewissen Zeitabständen die Log-Dateien geleert, aber vorher natürlich kopiert und archiviert. Die Archive erhalten den ursprünglichen Dateinamen und zusätzlich noch eine fortlaufende Nummer. Dieser Vorgang wird als "Logrotate" bezeichnet. Alte Log-Archive werden dann irgendwann gelöscht. Jedes installierte Paket oder jeder Dienst, das protokolliert, kann dazu eine eigene Konfiguration bei dem logrotade.d Dienst hinterlegen und den Ablauf individuell gestalten.

Version von logrotade überprüfen:


__$ sudo logrotate --version

Die Konfigurationsdateien liegen in dem gleichnamigen Ordner /var/logrotate.d. Dort werden wir eine Weitere Logrotate Konfiguration anlegen, und zwar für den SSH Dienst.


__$ sudo ls -l /etc/logrotate.d

Exkurs Cron

Damit der nächste Abschnitt verständlicher wird, gibt es eine kurze Erklärung zu Crons. Ein Cron-Daemon ist ein Dienst, der im Hintergrund abläuft und Prozesse zu festgelegten Zeiten anstößt. Auch "Cronjob" genannt. Standardmäßig sind stündliche, tägliche und wöchentliche Intervalle konfiguriert. Jeder Benutzer kann seine eigene Cron Tabelle haben. Die Cronjobs vom root Benutzer stehen in der Datei /etc/crontab. Schauen wir kurz rein:


__$ sudo cat /etc/crontab

Bei mir sieht die crontab Tabelle so aus:


# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

Bei Dir stehen sehr wahrscheinlich andere Zahlen, da sie zum Zeitpunkt der Linux Installation festgelegt werden. Die unteren Zeilen bzw. die nicht kommentierten Zeilen, stellen eine Tabelle dar. Mit den ersten Spalten kann das Intervall eingestellt werden und am Ende stehen die Kommandos, die dann ausgelöst werden. In meinem Fall: Der stündliche Cronjob zur 17. Minute (rund um die Uhr) mit dem Kommando cd / && run-parts --report /etc/cron.hourly. Jede ausführbare Datei in dem Verzeichnis etc/cron.hourly wird mit run-parts ausgeführt. Schauen wir kurz in dem Ordner nach:


__$ sudo ls -l /etc/cron.hourly

Da sind wahrscheinlich momentan keine ausführbaren Dateien.

Anders sieht das bei den täglichen Crons aus:


__$ sudo ls -l /etc/cron.daily

Cron Sessions umleiten

Es kommt vor, dass Anwendungen, die bei Cronjobs gestartet werden, sich am System über die PAM Schnittstelle authentifizieren. Sie erzeugen die oben genannten cron:session Log-Einträge. Sie sind als Eintrag eigentlich uninteressant und machen die /var/log/auth.log nur unübersichtlich. Daher werden wir sie in eine andere Datei umleiten.

Legen wir zunächst eine Log-Datei für die Cron-Session Ereignisse mit touch an:


__$ sudo touch /var/log/pam-cron-session.log

Wir verändern die Dateirechte mit chmod 0640:


__$ sudo chmod 0640 /var/log/pam-cron-session.log

Da wir der Eigentümer der Datei sind, würde es nur Probleme geben, wenn Hintergrundprozesse ohne Berechtigung da reinschreiben wollten. Als neuen Eigentümer ernennen wir den Systembenutzer syslog aus der Gruppe adm. Besitzer und Gruppe ändern wir mit chown:


__$ sudo chown syslog:adm /var/log/pam-cron-session.log

Um die besagten Log-Ereignisse abzufangen, platzieren wir eine Konfigurationsdatei beim rysylog.d Dienst. Dieser Dienst wertet Ereignisse aus und schreibt Log-Nachrichten in entsprechende Log-Dateien. Legen wir eine neue Datei (/etc/rsyslog.d/30-cron.conf) mit nano an:


__$ sudo nano /etc/rsyslog.d/30-cron.conf

Und schreiben folgendes hinein:

Auszug aus /etc/rsyslog.d/30-cron.conf


# Cronjob-Spam redirect
:msg, contains, "pam_unix(cron:session):" -/var/log/pam-cron-session.log
& stop

Speichern und schließen (STRG+s, STRG+x).

Die Konfiguration besagt: wenn pam_unix(cron:session): in einer Log-Nachricht steht (:msg, contains), dann schreibe es in die Datei /var/log/pam-cron-session.log. Durch den Bindestrich -/ werden die Ereignisse zunächst zwischengespeichert bzw. gesammelt, bevor sie geschrieben werden. Das reduziert die Schreibzugriffe auf der Festplatte.

Optimieren wir das noch mit einem Logrotate. Wie oben schon besprochen legen wir eine Konfigurationsdatei für den logrotate.d Dienst an:


__$ sudo nano /etc/logrotate.d/pam-cron-session

Und schreiben Folgendes rein:

/etc/rsyslog.d/30-cron.conf


/var/log/pam-cron-session
{
  rotate 4
  weekly
  missingok
  notifempty
  compress
  delaycompress
  sharedscripts
  postrotate
    invoke-rc.d rsyslog rotate > /dev/null
  endscript
}

Speichern und schließen.

Damit wird wöchentlich (weekly) rotiert und es werden nicht mehr als 4 Archive angelegt. Das fünfte Archiv, also das Älteste, wird gelöscht.

Bleibt nur noch den rsyslog.d Dienst neu zu starten, damit die neue Konfiguration übernommen wird:


__$ sudo systemctl restart rsyslog.service