Uno de los servidores que cuido parece estar participando en ataques de fuerza bruta contra instalaciones de Wordpress.
He sido víctima de esto muchas veces, por lo que estoy muy familiarizado con los pasos que se pueden tomar para evitarlo. Sin embargo, lo que me cuesta es detectar ataques salientes. El servidor es un servidor Apache típico con varios vhosts; aquí es donde, por supuesto, viene la complicación: si solo hubiera uno allí, ¡no sería tan difícil!
Actualmente estoy usando tcpflow para registrar el tráfico que va desde cualquier puerto de este servidor al puerto 80 de cualquier otra máquina usando este comando:
tcpflow -i eth0 dst port 80 and src host <my_servers_ip> and port not 22
He encontrado que esto es preferible a tcpdump. Examinar su resultado puede resultar algo desgarrador después de un tiempo :) tcpflow coloca cada solicitud en un archivo separado.
Aquí hay algunos resultados de un archivo que creo que es una actividad sospechosa:
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
Tenga en cuenta que he ofuscado el "Host:" arriba, creo que ese es el host que está siendo atacado (¿es correcto?).
Entonces, mi pregunta realmente es: ¿cómo hago para detectar el host virtual que genera este tráfico malicioso? Si puedo hacer eso, puedo informarle a mi cliente y él puede tomar medidas para investigar el sitio y realizar los cambios necesarios para detenerlo.
Cualquier solución recibida con mucha gratitud :)
Respuesta1
Por lo que dices, supongo que estás en una configuración en la que no puedes restringir la descarga de URL de tus clientes con enable_url_fopen.
En cuyo caso, en realidad es bastante difícil volver al script php de origen, ya que el registro de tcpflow que muestra en realidad no incorpora esa información.
Una opción fácil de considerar sería forzar que cualquier solicitud saliente tenga un agente de usuario revelador que pueda utilizar para identificar al cliente real que la realizó.
Por ejemplo, podría agregar a la definición de vhost del sitio web client1 una instrucción
php_admin_value user_agent client1
Eso obligará a cualquier solicitud http realizada por ese sitio web a utilizar el agente de usuario "cliente1", que aparecerá en su registro de tcpflow, permitiéndole saber quién lo originó.
Tenga en cuenta que si le preocupa la privacidad, es posible que desee utilizar un user_agent que solo usted pueda asignar al cliente real (como un cifrado del nombre del cliente).
Sin embargo, puede perjudicar la usabilidad, ya que algunos sitios web se mostrarán de manera diferente según el user_agent proporcionado, y esta configuración impide intencionalmente cualquier intento de su cliente de cambiarlo.