chr.istoph, der Blog

Ein Raid kann natürlich nicht gestoppt werden, wenn es noch verwendet wird. In meinem Fall:
# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[1]
966994808 blocks super 1.2 [2/1] [_U]

unused devices: < none >

# mdadm --stop /dev/md0
mdadm: failed to stop array /dev/md0: Device or resource busy
Perhaps a running process, mounted filesystem or active volume group?

Eigentlich war das System nicht mehr gemountet. Nur noch das LVM war auf der Platte in Verwendung. Dafür musste ich das VG erst mal stoppen:
# vgchange -a n vg0
0 logical volume(s) in volume group "vg0" now active

Dann ging es auch mit dem Aushängen der Platte.
# mdadm --stop /dev/md0
mdadm: stopped /dev/md0

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

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

Beim booten eines Servers standen die Logical Volume nicht zur Verfügung. Beim Aufrufen von lvs kam folgende fehlermeldung die einen hinwies auf die volle Platte gab.
# lvs
No volume groups found
/etc/lvm/cache/.cache.tmp: write error failed: Auf dem Gerät ist kein Speicherplatz mehr verfügbar


# ls /etc/lvm/cache/.
./ ../ .cache .cache.tmp


Nach dem aufräumen des Root-Filesystems muss man erst das pv nach vgs durchsuchen.
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg1" using metadata type lvm2


# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv1 vg1 -wi--- 100,00g


Anschließend musste man das vg aber noch starten.
# vgchange -a y vg1
7 logical volume(s) in volume group "vg1" now active