WordPress Angriffe filtern

Ich habe im August 2014 bereits eine Lösung mit iptables und fail2ban geschrieben. Da diese aber zu viele „fals positiv“ produziert hat, habe ich mich noch einmal hingesetzt und eine sowohl auf Performance als auch ohne fail2ban optimierte Lösung gesucht.

Mein zweiter Ansatz geht so vor, dass zuerst alle post requests in eine eigene iptbatles chain gepackt werden. Anschließen werden die in der chain noch übrig bleibenden anfragen nach den Schlüsselwörtern wie wp-login.php oder xmlrpc.php untersucht und mit einem Counter von 3 versehen. Beim dritten versuch ein falsches Passwort anzugeben werden die IPs der Botts für 600sec gesperrt.

iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "POST " -j HTTPPOST

iptables -A HTTPPOST -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-auth"
iptables -A HTTPPOST -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 600 --hitcount 3 --name "wp-auth" -j DROP

iptables -A HTTPPOST -m string --algo bm --string "/xmlrpc.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-xmlrpc"
iptables -A HTTPPOST -m string --algo bm --string "/xmlrpc.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 600 --hitcount 3 --name "wp-xmlrpc" -j DROP

iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT -m comment --comment "HTTP"

UPDATE: Danke an Jens, die SSL Regeln für Port 443 können so natürlich nicht funktionieren und wurden entfernt.

zabbix-check-mdadm

Auch zum überprüfen von Software Raids bringt Zabbix leider kein hauseigenes Tool mit. Wir heben zwei verschiedene Versionen geschrieben. Die Version von mir benötigt keine root rechte und ist recht rudimentär.

Das zabbix-check-mdadm Pakte befindet sich nun unter anderem in meinem repository und kann nach dem hinzufügen der Paketquellen mit folgenden Befehl, auf dem jeweiligen Server, installiert werden:
apt-get install zabbix-check-mdadm
Im Zabbix selbst muss dann nur noch das, nach der Installation, unter /usr/share/doc/zabbix-check-mdadm/mdadm_passive_checks_zabbix_template.xml befindliche Template einmalig im Zabbix Server importiert werden.

zabbix-check-postfix

Im Zabbix Wiki findet man einen menge toller Zabbix Plugins. Da man diese aber immer von Hand Installieren muss, habe ich mich mit Sebastian zusammen gesetzt und einige Plugins als Debian/Ubuntu Paket gebaut.

Unter anderem haben ich ein Postfix Plugin gefunden und erweitert:
zabbix-postfix-plugin

Das zabbix-check-postfix Pakte befindet sich nun unter anderem in meinem repository und kann nach dem hinzufügen der Paketquellen mit folgenden Befehl, auf dem jeweiligen Postfix Server, installiert werden:
apt-get install zabbix-check-postfix

Das Paket bring unter anderem ein Konfigurationsdatei für den Zabbix Server mit, die einmalig eingespielt werden muss:
/usr/share/doc/zabbix-check-postfix/examples/smtp_and_postfix_passive_checks_zabbix_template.xml

Auch dieses Paket findet Ihr auf GitHub

WordPress Admin mittels SQL Querry hinzufügen

Für einen Kunden sollte ich einen weiteren WordPress Admin anlegen. Da ich nur über die Konsole zugriff auf die MySQL Datenbank habe, sah dies folgender maßen aus. Die Querrys können aber für PHPMyAdmin und co. äquivalent übernommen werden.

Zuerst muss der Admin User inklusive Passwort angelegt werden.

INSERT INTO 
	wp_users 
SET 
	user_login='Admin2', 
	user_pass=md5('password'), 
	user_nicename='admin2', 
	user_email='chr@istoph.de', 
	user_registered=now(), 
	user_status='0', 
	display_name='Admin2';

Nach der Eingabe muss die ID ausgelesen werden, da sie im nächsten schritt wieder verwendet wird.

SELECT * FROM wp_users WHERE user_login='Admin';

+----+------------+----------------------------------+---------------+----------------------------
| ID | user_login | user_pass                        | user_nicename | user_email    | user_url | 
+----+------------+----------------------------------+---------------+----------------------------
|  9 | Admin2     | 286755fad04869ca523320acce0dc6a4 | admin2        | chr@istoph.de |          | 
+----+------------+----------------------------------+---------------+----------------------------
1 row in set (0.00 sec)

Anschließend werden mit der ersetzen user_id zwei weitere Metadaten, die eigentlichen Berechtigungen, geätzt.

INSERT INTO 
	`wp_usermeta` 
	(`umeta_id`, `user_id`, `meta_key`, `meta_value`) 
VALUES 
	(NULL, '9', 'wp_capabilities', 'a:1:{s:13:"administrator";s:1:"1";}');

INSERT INTO 
	`wp_usermeta` 
	(`umeta_id`, `user_id`, `meta_key`, `meta_value`)
VALUES
	(NULL, '9', 'wp_user_level', '10');

Hiernach kann die Anmeldung mit Adminrechten vorgenommen werden. Danach wird WordPress die zuvor eingegebene md5 summe durch ein Solt Hash ersetzen.

LVM2 RAID vs mdadm RAID 0, 5, 10

Ich habe mir 4 neue HGST Ultrastar A7K3000 2TB SATA6 Festplatten für meine Server gegönnt. Zum Vergleichen habe ich ein paar Tests mit LVM und mdadm gemacht.

Dafür habe ich je ein 5GB großes Setup gebaut und mit dd die Volumen erst gelesen und dann beschrieben. Dies habe ich in dieser Reihenfolge gemacht, um sicherzugehen, dass keine Daten aus dem cash gelesen werden.

Dabei bin ich zu folgenden spannenden Ergebnissen gekommen:

5GB READ/s READ/MB WRITE/s WRITE/MB
LVM RAID0 9,97195 s 538 MB/s 9,64365 s 557 MB/s
LVM RAID5 31,1128 s 173 MB/s 67,4213 s 79,7 MB/s
LVM RAID10 18,661 s 288 MB/s 26,5428 s 202 MB/s
MDADM RAID0 9,81575 s 547 MB/s 9,5395 s 563 MB/s
MDADM RAID5 20,528 s 260 MB/s 24,9739 s 214 MB/s
MDADM RAID10 17,5713 s 305 MB/s 19,529 s 275 MB/s

Mein Fazit: LVM ist doch deutlich langsamer als mdadm. Erschrocken hat mich die 2,6 fach schlechtere Schreibperformance bei LVM Raid5. Überrascht hat mich auch, dass ein mdadm raid10 fast die Nativ mögliche Geschmeidigkeit, 1/2 facht von reid0, erreicht hat.

Für die Testbedienungen habe ich ein aktuelles Ubuntu 14.04 LTS mit lvm2 2.02.98-6ubuntu2 und mdadm 3.2.5-5ubuntu4.2 verwendet.
Read the rest of this entry »