Eigentlich war der XEN-Server mit dem 5. Teil abgeschlossen, aber eine Kleinigkeit fehlte doch noch: Monitoring und Statistiken.
Für mich sind hier drei Dinge wichtig:
1. Alle Services sollen zu jedem Zeitpunkt laufen. Falls etwas hängt, soll es automatisch neugestartet werden mit einer Nachricht an mich.
2. Ich möchte den Speicherverbrauch, die Netzwerk- und die CPU-Nutzung etc. grafisch aufbereitet haben, ohne sehr viel konfigurieren zu müssen.
3. Über vorliegende Updates möchte ich jeden Tag per Mail benachrichtigt werden.
Glücklicherweise gibt es simple Tools für all diese Aufgaben und die Installation ist schnell erledigt, aber zunächst eine kleine Hilfe, die hier etwas aus dem Rahmen fällt:
fail2ban
Das Accesslog meines Servers ist so überflutet von Crackern, die versuchen, per Brute-Force einen SSH-Zugang zu bekommen, dass es im Grunde unbrauchbar ist. Mir ist nicht ganz klar, warum das nicht standardmäßig auf maximal 10 Versuche pro IP limitiert wird, aber fail2ban ist das optimale Tool, um genau diese Funktion nachzurüsten. Ich beziehe mich hier größtenteils auf dieses sehr hilfreiche Tutorial.
Wir installieren fail2ban wie üblich über:
# apt-get install fail2ban
fail2ban legt seine Konfigurationsdateien unter /etc/fail2ban/ ab. Dort findet sich auch die Standardkonfigurationsdatei jail.conf. Wir editieren nicht diese Datei, sondern erstellen eine eigene Datei mit dem Namen jail.local, die jeweils die Einstellungen in jail.conf aufhebt (kennt jemand ein deutsches Wort für override?) also:
# nano /etc/fail2ban/jail.local
Jetzt müssen wir uns entscheiden, was wir alles überwachen möchten. Ursprünglich hat mich zwar nur ssh interessiert, aber wenn wir schon dabei sind, können wir ja auch gleich Apache, Postfix und Courier überwachen lassen. Die Syntax der Datei ist ziemlich simpel. Erst stellen wir mit “ignoreip” eine IP ein, die niemals geblockt wird, damit wir uns nicht aus irgend einem Grund selbst aussperren. Bantime gibt in Sekunden an, wie lange eine IP gesperrt wird, wenn sie einmal geblockt wurde, und “maxretry” bestimmt, wie viele Versuche standardmäßig erlaubt sein sollen, das kann aber pro Anwendung übergangen werden.
Darauf folgt der anwendungsspezifische Abschnitt, hier beispielhaft dargestellt an ssh:
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
mit “enabled=true” legen wir fest, dass wir ssh überwachen möchten, “filter=sshd” bezieht sich auf die Filterdatei filter.d in /etc/fail2ban/, “logpath” gibt an, wohin geloggt werden soll und maxentry, wie viele Versuche möglich sind, bevor geblockt wird. Alles in allem also ziemlich einfach und logisch.
Meine Konfigurationsdatei sieht folgendermaßen aus:
[DEFAULT]
# “ignoreip” can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 78.46.34.54
bantime = 600
maxretry = 3
# “backend” specifies the backend used to get files modification. Available
# options are “gamin”, “polling” and “auto”.
# yoh: For some reason Debian shipped python-gamin didn’t work as expected
# This issue left ToDo, so polling is default backend for now
backend = polling
#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = root@localhost
# Default action to take: ban only
action = iptables[name=%(__name__)s, port=%(port)s]
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
[apache]
enabled = true
port = http
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 5
[apache-noscript]
enabled = true
port = http
filter = apache-noscript
logpath = /var/log/apache*/*error.log
maxretry = 5
[vsftpd]
enabled = false
port = ftp
filter = vsftpd
logpath = /var/log/auth.log
maxretry = 5
[proftpd]
enabled = false
port = ftp
filter = proftpd
logpath = /var/log/auth.log
failregex = proftpd: \(pam_unix\) authentication failure; .* rhost=
maxretry = 5
[wuftpd]
enabled = false
port = ftp
filter = wuftpd
logpath = /var/log/auth.log
maxretry = 5
[postfix]
enabled = true
port = smtp
filter = postfix
logpath = /var/log/mail.log
maxretry = 5
[courierpop3]
enabled = true
port = pop3
filter = courierlogin
failregex = courierpop3login: LOGIN FAILED.*ip=\[.*:\]
logpath = /var/log/mail.log
maxretry = 5
[courierimap]
enabled = true
port = imap2
filter = courierlogin
failregex = imapd: LOGIN FAILED.*ip=\[.*:\]
logpath = /var/log/mail.log
maxretry = 5
[sasl]
enabled = true
port = smtp
filter = sasl
failregex = warning: [-._\w]+\[\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed
logpath = /var/log/mail.log
maxretry = 5
Da ich keinen FTP-Server betreibe, habe ich die Überwachung dafür abgeschaltet, die failregex-Einträge sind für Debian Etch angepasst, offenbar funktionieren die Standard-Einträge nicht. Jetzt bleibt uns nur noch der Neustart des Dienstes und wir können uns darüber freuen, dass Brute-Force-Angriffe so schwer werden, wie es normalerweise sein sollte:
# /etc/init.d/fail2ban restart
Monit
Das nächste Tool, das ich hier vorstellen möchte, ist Monit. Monit ist dazu da, Prozesse auf dem Server zu überwachen und Alarm zu geben, wenn ein Dienst nicht so arbeitet, wie er soll. In dem Fall kann Monit beispielsweise den Webserver neustarten und eine Mail an den Admin senden. Es ist natürlich nicht ganz so günstig, dass der Dienst auf dem Rechnern liegt, der kontrolliert wird, falls der Server komplett down ist, läuft natürlich auch kein Monit mehr, das einen benachrichtigen könnte, aber für kleinere Ausfälle ist es bestens geeignet.
Wir beginnen mit der üblichen Installation:
# apt-get install monit
Jetzt müssen wir die Konfigurationsdatei an unsere eigenen Wünsche anpassen. Sie befindet sich unter /etc/monit/monitrc. Da wir nicht das Original verändern wollen, machen wir eine Kopie davon:
# cp /etc/monit/monitrc /etc/monit/monitrc_orig
# nano /etc/monit/monitrc
Ich zum Beispiel möchte den SSH-Daemon, den Webserver, MySQL und Postfix für Mails überwachen. Außerdem möchte ich Zugriff auf eine grafische Oberfläche auf Port 2812 des Servers, und dort möchte ich mich mit admin als Benutzername und test als Passwort anmelden. Entsprechend sieht meine Konfigurationsdatei folgendermaßen aus:
set daemon 60
set logfile syslog facility log_daemon
set mailserver localhost
set mail-format { from: monit@zfik.de }
set alert root@localhost
set httpd port 2812 and
allow admin:zfik.de
check process sshd with pidfile /var/run/sshd.pid
start program “/etc/init.d/ssh start”
stop program “/etc/init.d/ssh stop”
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout
check process mysql with pidfile /var/run/mysqld/mysqld.pid
group database
start program = “/etc/init.d/mysql start”
stop program = “/etc/init.d/mysql stop”
if failed host 127.0.0.1 port 3306 then restart
if 5 restarts within 5 cycles then timeout
check process apache with pidfile /var/run/apache2.pid
group www
start program = “/etc/init.d/apache2 start”
stop program = “/etc/init.d/apache2 stop”
if failed host www.example.com port 80 protocol http
and request “/monit/token” then restart
if 3 restarts within 5 cycles then timeout
check process postfix with pidfile /var/spool/postfix/pid/master.pid
group mail
start program = “/etc/init.d/postfix start”
stop program = “/etc/init.d/postfix stop”
if failed port 25 protocol smtp then restart
if 5 restarts within 5 cycles then timeout
Um den Webserver zu kontrollieren, schaut Monit, wie man hier sehen kann, unter example.com/monit/token nach, ob die Datei dort zu erreichen ist. Entsprechend erstellen wir ein Verzeichnis unter /var/www:
# mkdir /var/www/monit
und legen dort eine Datei an:
# echo "hello" > /var/www/monit/token
Jetzt müssen wir noch die Firewall so einstellen, dass der Port 2812 von Außen zugänglich ist.
# nano /etc/init.d/firewall
Hier fügen wir im Abschnitt Webserver den Port 2812 hinzu, der Abschnitt sieht dann folgendermaßen aus:
# Webserver
iptables -A INPUT -p tcp –dport 80 -j MYACCEPT
iptables -A OUTPUT -p tcp –dport 80 -j MYACCEPT
iptables -A INPUT -p tcp –dport 2812 -j MYACCEPT
iptables -A OUTPUT -p tcp –dport 2812 -j MYACCEPT
Nicht vergessen, die Firewall neuzustarten:
# /etc/init.d/firewall restart
Jetzt bleibt nur noch, Monit zu starten und so einzustellen, dass es bei jedem Systemstart automatisch mitgestartet wird. Dazu bearbeiten wir die Datei /etc/default/monit. Wir ändern den Wert startup zu 1 und CHECK_INTERVALS auf 60 oder auf die Anzahl der Sekunden, die man zwischen den Monit-Tests vergehen lassen möchte.
Zum Abschluss starten wir Monit:
/etc/init.d/monit start
Jetzt können wir uns unter www.example.com:2812 mit dem Benutzernamen admin und dem Passwort test auf einer Weboberfläche anschauen, wie lange die Dienste schon laufen, und ob es ein Problem gibt oder alles läuft, wie es soll.
Munin
Während Monit sehr praktisch ist, um sich über den Zustand bestimmter Dienste auf dem Laufenden zu halten, geht Munin darüber hinaus und bietet grafisch aufbereitete Statistiken über den Verlauf der CPU-Nutzung, die Speicherauslastung oder die genutzte Bandbreite. Meine Anleitung basiert im Wesentlichen auf diesem englischen Tutorial.
Wir beginnen mit der Installation:
# apt-get install munin munin-node
Als nächstes erstellen wir die Datei /var/www/munin und ändern die Gruppe zu munin
# mkdir /var/www/munin
# chown munin:munin /var/www/munin/
Jetzt müssen wir nur noch Munin neustarten:
# /etc/init.d/munin-node restart
Nach ein paar Minuten kann man die ersten Statistiken unter www.example.com/munin bestaunen.
Die meisten werden allerdings nicht wollen, dass jeder einfach so auf die Daten zugreifen kann. Wir vergeben also ein Passwort für das Verzeichnis. Dazu erstellen wir die Datei .htaccess in /var/www/munin:
# nano /var/www/munin/.htaccess
mit folgendem Inhalt:
AuthType Basic
AuthName "Members Only"
AuthUserFile /var/www/munin/.htpasswd
<limit GET PUT POST>
require valid-user
</limit>
Jetzt vergeben wir den Benutzernamen (admin) und das Passwort:
# htpasswd -c /var/www/munin/.htpasswd username
Das war’s schon.
Apticron
Das beste an Debian ist wohl, dass Updates wie auch die Installation von Paketen ziemlich unkompliziert über die Bühne gehen. Entsprechend muss man auch nur selten drüber nachdenken, ob man wirklich ein Update einspielen möchte. Das Problem ist vielmehr, dass man erst einmal wissen muss, dass es Updates für den eigenen Server gibt. Natürlich kann man sich dazu täglich auf dem Server einloggen und #apt-get update && apt-get upgrade ausführen, aber viel bequemer wäre es doch, bei anstehenden Updates per Mail benachrichtigt zu werden. Genau das leistet Apticron.
Wir installieren das Paket mit:
# apt-get install apticron
Bei der Installation wird man danach gefragt, in welcher Form man Benachrichtigungen erhalten möchte und die E-Mail-Adresse an die das gehen soll, ich entscheide mich hier für Text-Mail.
Mehr ist nicht nötig, damit bekommt man einmal täglich Bescheid über anstehende Updates. Klein, aber sehr hilfreich, um nicht mit veralteter Software dazustehen.
Das ist also vorerst der letzte Abschnitt des XEN-Servers, und ein Abschnitt, das im hervorragenden Buch von Erik Amberg leider fehlt. So wie in dieser Reihe dokumentiert, laufen auch die Server, die ich betreibe und auch der neue Firefox-Server wird nach diesem Muster installiert und eingerichtet.
