Home / server / Questions / 692601
In Process
ticktockhouse
Asked: 2015-05-18 06:18:38 +0800 CST

Outgoing brute force attacks from my server

  • 772

One of the servers I look after appears to be participating in brute force attacks against Wordpress installations.

I've been on the receiving end of this many times, so am very familiar with steps that can be taken to prevent this. What I'm struggling with, however, is detecting outgoing attacks. The server is a typical Apache server with a number of vhosts on it - this is where the complication comes of course - if there was just one on there, it wouldn't be as difficult!

I'm currently using tcpflow to log traffic going from any port on this server to port 80 on any other machine using this command:

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

I've found this preferable to tcpdump. Looking through its output can be somewhat brain-melting after a while :) tcpflow puts each request into a separate file..

Here is some output from a file which I believe to be suspicious activity:

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

Please note, I've obfuscated the "Host:" above, I believe that's the host being attacked (is this correct?).

So my question really, is how do I go about detecting the vhost that is generating this malicious traffic? If I can do that, I can let my client know, and he can take steps to investigate the site and make the necessary changes to stop it..

Any solutions very gratefully received :)

linux

1 Answers

  1. I assume from what you say that you are in a setup where you can't restrict url download from your clients with allow_url_fopen.

    In which case it is actually quite hard to go back to the originating php script, as the tcpflow log you show doesn't actually embed that information.

    One easy option to consider would be forcing any outgoing request to have a revealing user-agent that you could use to identify the actual client that made it.

    For instance, you could add to the vhost definition of client1 website an instruction

    php_admin_value user_agent client1

    That will force any http request made by that website to user the user-agent "client1", which will show up in your tcpflow log thus allowing you to know who originated it.

    Note that if privacy is a concern, you may want to use a user_agent that only you can map to the actual client (such as an encryption of the client's name).

    It may however harm usability, as some website will display differently depending on the provided user_agent, and that this setup purposely prevent any attempt made by your client to change it.

    • 1