8

I've been the target of a brute force attack on two WordPress sites I own. The attacker is using the good old XML-RPC thing to amplify brute-force password attacking. Luckily we have extremely well-generated passwords, so I highly doubt he'll ever get anywhere.

I've just been using iptables to block his requests whenever he pops up again (always from the same virtual cloud provider), but I would much rather modify the server so that whenever his IP address requests any page, he gets a response telling him to get a life. Most of the requests are POSTs, so I would ideally just like to modify the reponse header to include something like "Better luck next time!" or something equally satisfying.

Is this possible? I'm far from an expert with Apache, so I'm not certain how difficult this would be to implement. But even if it takes me hours, the satisfaction will be priceless.

For reference, I'm running Ubuntu 16.04.2 LTS, with Apache 2.4.18 hosting Wordpress 4.7.3.

Improve this question
2
  • "always from the same virtual cloud provider" OVH? I've noticed a lot of script kiddies using their services for some reason.
    – hd.
    Mar 28, 2017 at 15:24
  • Nope, online.net ... they have so far not responded to a single one of my abuse reports. Also, the first time I sent an abuse request, I found out that they automatically forward the complaint to the customer. Hence how he found my personal website. Good work, online.net....
    – Aurelius
    Mar 28, 2017 at 21:25

4 Answers 4

Reset to default
25

Just install fail2ban with the appropriate jail and be done with it. Don't bother to give a custom response, as it's most likely that it will never be seen.

Improve this answer
5
  • 1
    For sure. But this is definitely something I've always wanted to do. Even if he never sees it, just the possibility makes me laugh so hard I almost cry.
    – Aurelius
    Mar 27, 2017 at 18:36
  • 14
    Well: 1) IMHO figuring out how to display a petty insult to a script kiddie is off-topic here. 2) Doing so will still consume your apache resources, whereas fail2ban/iptables blocks the requests upstream so your application never has to deal with it.
    – EEAA
    Mar 27, 2017 at 18:39
  • 1
    Oh for sure. But I want to have a little fun before the perma-ban. Whether it's petty or not, I just want to have a laugh, and this is at the request of the person who's business uses the server.
    – Aurelius
    Mar 27, 2017 at 19:50
  • 4
    @Aurelius, if you know the ip, and this person doesn‘t mask it why don‘t you do this in the app itself, php in this case. Just verify if it‘s ip xx.xx.xx.xx and if it is just kill the script with a response, die("blah blah");
    – Miguel
    Mar 27, 2017 at 21:58
  • Accepted as the answer, mostly because I didn't know about fail2ban and so that's really helpful in general. Miguel's answer above, as well as BlackWebWolf's answer below, are both things I'm going to look into!
    – Aurelius
    Mar 28, 2017 at 21:31
5

There is a possibility, and we did it quite a lot, to reverse possible attacks. Use iptables to redirect the cloud provider (address range) to a different port - and there serve the attacker a response, even in plain headers.

In Apache you can modify headers by example:

Header set GetOut "Better luck next time!"
Improve this answer
5
  • Hehehe!! Now that's what I'm talking about. Good idea! I will look into this.
    – Aurelius
    Mar 27, 2017 at 19:49
  • 5
    this strategy will probably backfire re the response, because it lets the attacker know what is working and what isn't, it's far better to just silently pass the request to nothing and not trip any alert flags in his bot attack software. Ideally returning the html of the page requested, for example. they never know you caught them, nothing happens, and your site is safer. Resist the urge to let them know, that's a MISTAKE, always. It simply helps them debug the issue. In your case, simply switching to more dynamic IP ranges, etc, making the problem MUCH harder to resolve.
    – Lizardx
    Mar 28, 2017 at 1:28
  • 1
    You're right, it is not reccomended - it is even possibly dangerous. Strategy with honeypot always is better, yet question was clear - how to troll an attacker:)
    – BlackWebWolf
    Mar 28, 2017 at 6:47
  • I don't really care if it's a mistake -- I've installed fail2ban, and he'll get banned anyway. I highly doubt he's going to actually get anywhere; as far as I know, the recent releases of WordPress actually fixed this security bug? Not to mention, brute forcing passwords that are longer than 20 characters.... yeah, not happening in the lifetime of our universe.
    – Aurelius
    Mar 28, 2017 at 21:30
  • blackwebwolf, it's similar to someone asking how to implement php's deprecated mysql_ extension, while one can technically answer that question, that answer is wrong because the real answer means to do it right, in that case, for example, using mysqli_ instead or xpdo. It's just the notion, which many of us have done in our pasts as well, that responding in any way like trolling is anything other than a huge negative, should be corrected, because that's a serious mistake, and if one has ever suffered because of that mistake, one would immediately understand why the question was wrong.
    – Lizardx
    Mar 28, 2017 at 23:00
3

This is very easy with ModSecurity which is a third-party WAF module for Apache. Though it does involve learning its rule language syntax.

You can also use ModSecurity to just drop the connection rather than respond at all.

Saying that, installing ModSecurity just for this, when, as others have suggested, it's likely the responses will be ignored may well be overkill.

Improve this answer
2

I'd go with fail2ban and dropping requests from known abuse locations. And if you feel that the attacker's service provider is not to blame, report the attacks to their abuse email address.

If you want to spend time making something that will slow down the attacker, you might want to try making a tarpit. First you must of course know where the attacks come from. Then you could use apache to redirect the request from the ip (range?) to a specific script. This might do the trick although I haven't tried it myself. Then just implement a script that, for example, prints out a dot (or something from /dev/null) every 15 seconds to keep the attacker's connection open indefinitely.

Since the attacker is most likely using scripts to attack your site, it might take time to notice that the attacks have stalled, since the connections are all seemingly active, there will be no timeout and the request isn't denied on the spot.

The problem is that you devote you time and resources to something that probably won't be as helpful as the more important concern: securing your login. It's hard to attack when you don't know where to attack. Consider some of the following:

  • restrict access to the login page (only your intranet? ip range? vpn? other?).
  • add reCaptcha or other verification question to login.
  • use Multi-factor authentication.
  • hide your login page. If possible, don't link to it from your main page and don't use /login or other obvious location.
Improve this answer
5
  • Thanks for the info! So, to clear things up, A) the two users that are able to log in have randomly-generated long passwords. B) There is a sort-of captcha on the login page. C) I am trying to get .htaccess working to prevent access to that page. However it seems the standards for .htaccess have changed multiple times -- I keep seeing different syntax everywhere and so far htaccess barely works at all.
    – Aurelius
    Mar 28, 2017 at 21:26
  • Also, I've reported all the attacks to online.net with no response whatsoever.
    – Aurelius
    Mar 28, 2017 at 21:32
  • Some useful tips for htaccess: stackoverflow.com/questions/6441578/… (I strongly recommend digest authentication).
    – user391905
    Mar 29, 2017 at 8:22
  • Looking at the comments on this page, digest doesn't seem like a great idea? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html
    – Aurelius
    Mar 30, 2017 at 9:37
  • 1
    You got me there. Yes, I remembered that from the time when I used digest authentication and then we didn't have https everywhere. The reason why we don't use htacces passwords is that it isn't a long term solution. It's okay to use it to hide something a week before publishing, but for everyday use you don't want another level of passwords. It isn't even that much safer. When the resource is in place that doesn't show in public Internet at all, then we're on the right track.
    – user391905
    Mar 31, 2017 at 11:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .