Ataques de força bruta de saída do meu servidor

Question

Um dos servidores que cuido parece estar participando de ataques de força bruta contra instalações do Wordpress.

Eu já estive recebendo isso muitas vezes, então estou muito familiarizado com as medidas que podem ser tomadas para evitar isso. O que eu estou lutando, no entanto, é detectar ataques de saída. O servidor é um típico servidor Apache com um número de vhosts - é aí que a complicação vem, é claro - se houvesse apenas um lá, não seria tão difícil!

Atualmente estou usando o tcpflow para registrar o tráfego de qualquer porta neste servidor para a porta 80 em qualquer outra máquina usando este comando:

tcpflow -i eth0 dst port 80 and src host <my_servers_ip> and port not 22

Eu achei isso preferível ao tcpdump. Olhando através de sua saída pode ser um pouco de derretimento mental depois de um tempo :) tcpflow coloca cada pedido em um arquivo separado ..

Aqui estão alguns resultados de um arquivo que acredito ser uma atividade suspeita:

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

Por favor note, eu ofusquei o "Host:" acima, eu acredito que o host está sendo atacado (está correto?).

Então, minha pergunta é como eu detecto o vhost que está gerando esse tráfego malicioso? Se eu puder fazer isso, posso informar meu cliente e ele pode tomar medidas para investigar o site e fazer as alterações necessárias para pará-lo.

Qualquer solução recebida com gratidão:)

    

Answer 1

Eu presumo, pelo que você diz, que você está em uma configuração onde você não pode restringir o download de URL de seus clientes com allow_url_fopen.

Nesse caso, é realmente muito difícil voltar ao script php de origem, já que o log tcpflow que você mostra não incorpora essa informação.

Uma opção fácil de considerar seria forçar qualquer solicitação de saída a ter um agente do usuário revelador que você poderia usar para identificar o cliente real que a criou.

Por exemplo, você pode adicionar à definição vhost do website client1 uma instrução

php_admin_value user_agent client1

Isso forçará qualquer solicitação http feita por esse site a usar o user-agent "client1", que será exibido em seu log tcpflow, permitindo que você saiba quem o originou.

Observe que, se a privacidade é uma preocupação, convém usar um user_agent que somente você pode mapear para o cliente real (como uma criptografia do nome do cliente).

No entanto, pode prejudicar a usabilidade, já que alguns sites serão exibidos de forma diferente, dependendo do user_agent fornecido, e que essa configuração evita propositalmente qualquer tentativa feita pelo seu cliente de alterá-lo.