Einer der Server, die ich betreue, scheint an Brute-Force-Angriffen auf Wordpress-Installationen beteiligt zu sein.
Ich war schon oft Opfer eines solchen Angriffs und kenne mich daher mit den Schritten zur Vorbeugung sehr gut aus. Ich habe allerdings Probleme damit, ausgehende Angriffe zu erkennen. Der Server ist ein typischer Apache-Server mit einer Reihe von virtuellen Hosts – hier liegt natürlich die Komplikation – wenn nur einer darauf wäre, wäre es nicht so schwierig!
Ich verwende derzeit tcpflow, um den Datenverkehr von jedem Port auf diesem Server zu Port 80 auf jedem anderen Computer mit diesem Befehl zu protokollieren:
tcpflow -i eth0 dst port 80 and src host <my_servers_ip> and port not 22
Ich finde, das ist besser als tcpdump. Das Durchsehen der Ausgabe kann nach einer Weile ziemlich hirnschmelzend sein :) tcpflow legt jede Anfrage in eine separate Datei.
Hier ist die Ausgabe einer Datei, die meiner Meinung nach verdächtige Aktivitäten enthält:
POST /wp-login.php HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Host: somedomain.com
Accept: */*
Cookie: wordpress_test_cookie=WP+Cookie+check
Content-Length: 97
Content-Type: application/x-www-form-urlencoded
log=jacklyn&pwd=london&wp-submit=Log+In&redirect_to=http://somedomain.com/wp-admin/tes1a0&testcookie=1
Bitte beachten Sie, dass ich den „Host:“ oben verschleiert habe. Ich glaube, dass dies der Host ist, der angegriffen wird (ist das richtig?).
Meine eigentliche Frage ist also, wie ich den virtuellen Host erkenne, der diesen bösartigen Datenverkehr generiert. Wenn mir das gelingt, kann ich meinen Client informieren, und er kann Schritte unternehmen, um die Site zu untersuchen und die notwendigen Änderungen vorzunehmen, um sie zu stoppen.
Für alle Lösungen bin ich sehr dankbar :)
Antwort1
Ich gehe davon aus, dass Sie sich in einer Konfiguration befinden, in der Sie den URL-Download von Ihren Clients nicht mit allow_url_fopen einschränken können.
In diesem Fall ist es tatsächlich ziemlich schwierig, zum ursprünglichen PHP-Skript zurückzukehren, da das angezeigte TCPFlow-Protokoll diese Informationen nicht enthält.
Eine einfache Option wäre, für jede ausgehende Anfrage einen verräterischen User-Agent zu erzwingen, mit dem Sie den tatsächlichen Client identifizieren können, der die Anfrage gestellt hat.
Beispielsweise könnten Sie der vhost-Definition der Website client1 eine Anweisung hinzufügen
php_admin_value user_agent client1
Dadurch werden alle HTTP-Anfragen dieser Website an den Benutzer-Agenten „client1“ gesendet. Dieser wird in Ihrem TCPFlow-Protokoll angezeigt, sodass Sie wissen, von wem die Anfrage stammt.
Beachten Sie, dass Sie aus Datenschutzgründen möglicherweise einen User-Agent verwenden möchten, den nur Sie dem tatsächlichen Client zuordnen können (z. B. eine Verschlüsselung des Clientnamens).
Dies kann jedoch die Benutzerfreundlichkeit beeinträchtigen, da manche Websites je nach bereitgestelltem User-Agent anders angezeigt werden und diese Konfiguration absichtlich alle Versuche Ihres Clients verhindert, den Agent zu ändern.