chr.istoph, der Blog

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.

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.

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.

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:

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.
(mehr …)

In einem KVM DRBD Setup hatte sich auf Dauer eine Menge wait I/O angesammelt.

Zunächst habe ich herausgefunden, dass die einzelnen VMs sehr viel write barriers erzeugen. Dies konnte ich bei den VMs, bei denen ich root Zugang habe, mit der Option barrier=0 in der /etc/fstab einstellen.
Bei den VMs, bei denen ich keinen root Zugang habe, ging das leider nur auf der DRBD Schicht. Dazu habe ich in den /etc/drbd.d/.res folgende Einstellung hinzugefügt:

disk {
    disk-barrier no;
    disk-flushes no;
}

Quelle: drbd.linbit.com

Die hieraus resultierende bessere IO Permanenz für alle VMs entnimmt man den oben aufgeführten Zabbix Graph.