Für das Einrichten eines zabbix-agent habe ich mir ein Skript geschrieben, das nach der Installation die Konfigurationsdateien anpasst.
apt-get update
apt-get install zabbix-agent -y
sed -i 's/^Server=.*/Server=zabbix.chr.istoph.de/g' /etc/zabbix/zabbix_agentd.conf
sed -i 's/^Hostname=.*/Hostname='`cat /etc/hostname`'/g' /etc/zabbix/zabbix_agentd.conf
/etc/init.d/zabbix-agent restart
/var/log/auth.log:
lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory
Behoben habe ich dies, indem ich die Datei einfach mit den richtigen Rechten angelegt habe.
touch /var/log/lastlog
chmod 0644 /var/log/lastlog
chown root:root /var/log/lastlog
Zu erst muss man die Quellen des offiziellen Zabbix Repository einbinden und den dazugehörigen GPG-Key importieren.
echo "#Zabbix 2.2
deb http://repo.zabbix.com/zabbix/2.2/debian/ wheezy main" > /etc/apt/sources.list.d/zabbix.list
wget -O - http://repo.zabbix.com/zabbix-official-repo.key|apt-key add -
apt-get update
Wenn man sich für die MySQL Variante entschieden hat, sollte man zu erst die Datenbank installieren und ein root Passwort setzen. Wird die Datenbank noch für andere Dienste benötigt, sollte man natürlich einen zabbix User mit den entsprechenden Rechten anlegen.
apt-get install mysql-server
Dann kann man mit der Installation des Servers und des Frontends beginnen:
apt-get install zabbix-server-mysql zabbix-frontend-php
Für die abschließende Konfiguration wird noch die Konfiguration der PHP Zeitzone benötigt. Dazu muss man diese in der /etc/php5/apache2/php.ini setzen.
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = "Europe/Berlin"
Anschließend muss der Apache neu gestartet werden
/etc/init.d/apache2 reload
Dann kann man der Konfiguration auf der Webseite folgen, diese befindet sich im Unterordner zabbix.
http://server/zabbix
Abschließend kann man sich mit dem Adminuser einloggen und sollte natürlich als erstes das Passwort ändern.
user admin
password: zabbix
UPDATE: es liegt eine Aktualisierte lösung für diese Problem vor
Aktuell finden heftige Angriffe auf WordPress Accounts statt. Die schnellste und einfachste Möglichkeit dies zu unterbinden, ist das Droppen aller Aufrufe der wp-login.php mittels iptables:
iptables -I INPUT -i eth0 -p tcp -m tcp --dport 80 -m string --algo bm --string "/wp-login.php" -j DROP
[Update] Besser:
iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-auth"
iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 240 --hitcount 10 --name "wp-auth" -j DROP
Alternativ kann man auf fail2ban eine Regel mitgeben um beispielsweise folgende Logeinträge zu filtern:
10.0.0.1 - - [15/Aug/2014:09:07:39 +0200] "POST https://blog.chr.istoph.de/wp-login.php/wp-login.php/ HTTP/1.1" 200 3552 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2"
10.0.0.1 - - [15/Aug/2014:09:08:28 +0200] "POST /blog/wp-login.php HTTP/1.1" 200 2653 "https://blog.chr.istoph.de/blog/wp-login.php" "[% tools.ua.random() %]"
/etc/fail2ban/filter.d/wp-auth.conf
# WordPress brute force auth filter [Definition] failregex = ^< HOST > .* "POST*/wp-login.php* ignoreregex =
/etc/fail2ban/jail.local
[wp-auth] enabled = true filter = wp-auth action = iptables-multiport[name=NoAuthFailures, port="http,https"] logpath = /var/www/vhosts/*/statistics/logs/access_log bantime = 1200 maxretry = 3
Wie immer bei solchen Aktionen werden wir nicht informiert und ich deswegen im Urlaub angerufen. Bei den Geplanten Stromanschlusarbeiten des neuen Verwaltungsgebäuden in der Bayernalle wurde am Freitag Abend der Strom abgeschaltet. Nach knapp 12 Stunden hatte die USV im Serverraum der Bayernallee 9 keinen Strom mehr, woraufhin die Switche ausfielen. Dies führte zwangsläufig dazu das bei uns der Link zum Nachbargebäude weg war und wir auf Fehlersuche gingen.
