Brute force issue with a HostMonster site

Server Config
1

I have a site which is temporarily hosted w/ HostMonster and it appears to be getting attacked by some loser in Ukraine. As per CPANEL logs, it looks like my .htaccess is giving them 301 responses, but I’m worried that my interpretation of the logs I see may not be 100% truthful because I know you can bypass .htaccess files through some clever packet / header manipulation. So I’d love some input on this…

Here’s a sample of what’s been constantly going on now for the past 3 days (as per the CPANEL “Latest Visitors” page; it’s a Wordpress site, so this isn’t necessarily surprising or new but the aggressiveness of this attack is what’s worrisome: this attack “process” happens every 2 minutes and doesn’t show any signs of stopping):

…
[TABLE]
[TR=“class: yui-dt-rec yui-dt-even”]
[TD=“class: yui-dt0-col-ip yui-dt-col-ip yui-dt-desc yui-dt-sortable yui-dt-resizeable yui-dt-first”]46.119.124.230
[/TD]
[TD=“class: long_string yui-dt0-col-url yui-dt-col-url yui-dt-sortable yui-dt-resizeable”]/wp-login.php
[/TD]
[TD=“class: yui-dt0-col-localtime yui-dt-col-localtime yui-dt-sortable yui-dt-resizeable”]10/13/12 10:00 AM
[/TD]
[TD=“class: numeric_data yui-dt0-col-size yui-dt-col-size yui-dt-sortable yui-dt-resizeable”]698
[/TD]
[TD=“class: yui-dt0-col-status yui-dt-col-status yui-dt-sortable yui-dt-resizeable”] 301
[/TD]
[TD=“class: yui-dt0-col-method yui-dt-col-method yui-dt-sortable yui-dt-resizeable”]POST
[/TD]
[TD=“class: yui-dt0-col-protocol yui-dt-col-protocol yui-dt-sortable yui-dt-resizeable”]HTTP/1.1
[/TD]
[TD=“class: long_string yui-dt0-col-referer yui-dt-col-referer yui-dt-sortable yui-dt-resizeable”]http://www.mywebsite.com/wp-login.php

[/TD]
[TD=“class: long_string yui-dt0-col-agent yui-dt-col-agent yui-dt-sortable yui-dt-resizeable yui-dt-last”]Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
[/TD]
[/TR]
[TR=“class: yui-dt-rec yui-dt-odd”]
[TD=“class: yui-dt0-col-ip yui-dt-col-ip yui-dt-desc yui-dt-sortable yui-dt-resizeable yui-dt-first”]46.119.124.230
[/TD]
[TD=“class: long_string yui-dt0-col-url yui-dt-col-url yui-dt-sortable yui-dt-resizeable”]/wp-login.php
[/TD]
[TD=“class: yui-dt0-col-localtime yui-dt-col-localtime yui-dt-sortable yui-dt-resizeable”]10/13/12 9:58 AM
[/TD]
[TD=“class: numeric_data yui-dt0-col-size yui-dt-col-size yui-dt-sortable yui-dt-resizeable”]697
[/TD]
[TD=“class: yui-dt0-col-status yui-dt-col-status yui-dt-sortable yui-dt-resizeable”] 301
[/TD]
[TD=“class: yui-dt0-col-method yui-dt-col-method yui-dt-sortable yui-dt-resizeable”]POST
[/TD]
[TD=“class: yui-dt0-col-protocol yui-dt-col-protocol yui-dt-sortable yui-dt-resizeable”]HTTP/1.1
[/TD]
[TD=“class: long_string yui-dt0-col-referer yui-dt-col-referer yui-dt-sortable yui-dt-resizeable”]http://www.mywebsite.com/wp-login.php

[/TD]
[TD=“class: long_string yui-dt0-col-agent yui-dt-col-agent yui-dt-sortable yui-dt-resizeable yui-dt-last”]Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
[/TD]
[/TR]
[TR=“class: yui-dt-rec yui-dt-even”]
[TD=“class: yui-dt0-col-ip yui-dt-col-ip yui-dt-desc yui-dt-sortable yui-dt-resizeable yui-dt-first”]46.119.124.230
[/TD]
[TD=“class: long_string yui-dt0-col-url yui-dt-col-url yui-dt-sortable yui-dt-resizeable”]/wp-login.php
[/TD]
[TD=“class: yui-dt0-col-localtime yui-dt-col-localtime yui-dt-sortable yui-dt-resizeable”]10/13/12 9:56 AM
[/TD]
[TD=“class: numeric_data yui-dt0-col-size yui-dt-col-size yui-dt-sortable yui-dt-resizeable”]699
[/TD]
[TD=“class: yui-dt0-col-status yui-dt-col-status yui-dt-sortable yui-dt-resizeable”] 301
[/TD]
[TD=“class: yui-dt0-col-method yui-dt-col-method yui-dt-sortable yui-dt-resizeable”]POST
[/TD]
[TD=“class: yui-dt0-col-protocol yui-dt-col-protocol yui-dt-sortable yui-dt-resizeable”]HTTP/1.1
[/TD]
[TD=“class: long_string yui-dt0-col-referer yui-dt-col-referer yui-dt-sortable yui-dt-resizeable”]http://www.mywebsite.com/wp-login.php

[/TD]
[TD=“class: long_string yui-dt0-col-agent yui-dt-col-agent yui-dt-sortable yui-dt-resizeable yui-dt-last”]Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
[/TD]
[/TR]
[TR=“class: yui-dt-rec yui-dt-odd”]
[TD=“class: yui-dt0-col-ip yui-dt-col-ip yui-dt-desc yui-dt-sortable yui-dt-resizeable yui-dt-first”][/TD]
[/TR]
[/TABLE]
…

[TABLE]
[TR=“class: yui-dt-rec yui-dt-odd”]
[TD=“class: yui-dt0-col-ip yui-dt-col-ip yui-dt-desc yui-dt-sortable yui-dt-resizeable yui-dt-first”]Obviously, they’re attacking the login page and I’d love to see what they’re submitting, but due to HostMonster’s wonderful tech support, I can’t access my raw access logs on my Windows machines nor even on their own servers (HostMonster doesn’t have a single Windows machine in their entire building as per what one of their tech support people told me yesterday over the phone, and since they could see the raw logs fine on their end, they basically implied that I was SOL–which has me looking for a new host). I actually posted about this issue yesterday and will update that thread here in a few…
[/TD]
[/TR]
[/TABLE]

But that aside, should CPANEL be trusted in this case? Is this just some automated bot that nobody has turned off or programmed to better interpret 301s or is this something more insidious? The site is working fine and I haven’t seen or suspected that this attack has done anything… YET.

I’ve contacted authorities about it–which I don’t expect to see anything happen from–and I even contacted the RIPE people to see if there’s anything they can do about it (which, again, I don’t expect to see any action from). I also created a ticket w/ HostMonster people to see if they can blacklist the IP at the firewall level–which hasn’t been responded to yet since being created yesterday (not surprisingly).

Any suggestions or insight into this is appreciated. FWIW, I have blocked the IP in .htaccess as well as through CPANEL. Not sure what else I can do. I’ll admit that I don’t have any CAPTCHA installed on my login, but the only reason for this is because I didn’t think I’d have to go that far with it (especially since I’m planning on replacing the site anyway).

2

I think you have over reacted to a basic hacker bot. Automated hacker bots are constantly looking for vulnerabilities and spammer bots are out doing there thing, too. Every website gets them. Mine included. My sites get probed constantly. It’s not a big deal unless you’ve got a vulnerability (other than the fact they are consuming your data transfer).

I am not aware of any server logs that log POST data. I just read it is possible to do this. But probably not on a shared host. Besides, it would log every POST request including logins and passwords which would pose an even bigger security threat.

My guess is that the hacker bot is randomly trying various logins to gain access to your site. Probably using the admin username and various passwords.

Since you’ve already blocked the bot using htaccess, that’s about all you can do. Just don’t waste time worrying about it. Keep your Wordpress updated. Choose a strong password. Etcetera.

If you want to complain to someone, complain to the company that appears to be the ISP of that IP address, Golden Telecom Ukraine.

http://whois.domaintools.com/46.119.124.230

By the way, the design of your site breaks if the browser window isn’t open far enough. Your register/login column drops down unless I have my browser maximized. You might want to take a look at that. I’m using the latest version of Firefox.

3

I did send them an e-mail but I’m not sold on thinking that I’m overreacting. This isn’t your typical spam or kiddie bot that scans a couple URLs (2-20 times) and suddenly hangs up. This thing has been bouncing against that login page now for the past 2-3 days NON STOP every 2 minutes and it’s still doing it.

You’ve had situations like this too and you don’t see it as anything worth worrying about?

Off Topic:

I thought I removed all the URLs to my site… :confused: That WYSIWYG must’ve copied some hidden data or something–or else, you looked me up?

4

Of course I’ve had situations like that. Probably every webmaster has. They don’t dig through their logs. If you have a Wordpress, a forum, or any other type of site requiring a login, bots are going to be trying to get in. Think about how many thousands of attempts hacker bots make on Facebook each day. Not only will they be trying to get in to areas requiring authentication, they will be looking for other exploits like SQL injection vulnerabilities, file include exploits, and probably more than that.

And no, I don’t worry about it at all. I don’t like it. I don’t like the bandwidth hacker bots consume. That’s what bothers me the most, not the fact they are trying to get in. Because there is nothing that you or I or anyone else can do about it. As long as your site is publicly accessible, some hacker or hacker bot is going to try to get in. That’s all there is to it.

Yes, it looks like that is what happened. I see your post was edited to remove the URL.

5

W_22,

Believe me, you are NOT overreacting. Unfortunately, there is little you can do except to use a VERY STRONG password for your account.

My WHM (with WebHostingBuzz) offers a Configure Security Policies which can “Limit logins to verified IP Addresses”. This has been fantastic as EVERYONE is locked out (if I use another IP address to login, I must also answer some security questions to be granted access). THAT is the sort of feature that you need to absolutely stop your Ukrainian script kiddie’s attacks.

I’ve had some attempt to attack prior to my implementing this feature but WHM/cPanel also has a counter feature which will autoban an IP address after x unsuccessful login attempts. I had my x set pretty low but even that stopped many attackers.

Finally, unless you have access to cPanel’s directory, you should be UNABLE to block access via .htaccess (regular updates should replace your .htaccess even if you are able to alter the file). Obviously, CAPTCHA would do no good, either.

If you’re only/also concerned with access to your WP installation, FIRST, rename the admin directory to something really funky (i.e., can’t be guessed). Security by obfuscation is hardly any security at all but no sense in making things easy for hackers. Of course, you can implement CAPTCHA and ban IP addresses (for all the good that will do - I would ban all but my own IP address; you can your WP admin’s .htaccess via cPanel’s File manager) but a STRONG WP password (and immediate updates of your WP installation upon every security update release) should keep that safe.

Regards,

DK

6

Thanks for the info, David.

I have a pretty good password (I think), so I’m not too worried about the jerk breaking in. But yeah, it’s still occurring, and nope, HostMonster (HM) hasn’t responded to the ticket I created asking them to block this IP address at the firewall…

It’s not surprising in the least. For the most part, HM hasn’t been too bad but when situations like this pop up, they’re a host I wish I wasn’t with. I’ll check out WebHostingBuzz, btw. How long have you been with them? It’s been a good experience? Do you have access to things like your own php.ini?

I’ve never had an experience were my .htaccess file was wiped out–thankfully.

I’m coming close to rolling out a Drupal multisite install, so hopefully that will nip some of this stuff that’s going on. I believe that Drupal is a little better with handling things like this, but in any event, my time is limited with HostMonster. This experience has definitely soured my perspective of them.

7

They aren’t going to. No host is going to do that.

As I write this, a Chinese bot is trying to login and post on a forum I run using a bunch of different IP addresses. Had another Chinese bot earlier doing a bunch of funky URLs probably looking for an exploit.

And this morning there was a Ukrainian spammer bot trying and failing Captchas to post on the forum as well.

That’s the reality of being a webmaster. All day long hacker and spammer bots will be probing that site along with a couple others. I don’t worry about it. It’s something you have no control over.

I hope when IPv6 comes they allocate addresses by country so we can easily block entire nations. Almost all the spam and hacker bots I get comes from Russia/Ukraine and China.

8

cd,

Too true - unless you’re running a dedi server. IP blocking is a rather serious thing.

True, too, that webmasters have to learn not only to use CAPTCHA to block bots but to LOG the bot’s address and block it (at least on a temporary basis; yes, you can modify .htaccess on the fly to add IPs to a blocking scheme).

W_22,

HM is a large outfit and they, typically, won’t take the time to address what they consider “minor annoyances.” It’s poor service and they need to shrink to the point that providing service to their customers return to a high priority.

Somehow, there are two threads in this one as you’ve addressed cPanel logins as well as WP logins. As I mentioned above, you can’t do much more than USE the WHM/cPanel protections (within the WHM and cPanel “applications”) and use incredibly strong passwords (http://strongpasswordgenerator.com is a great source if you’re not a good random character generator yourself). You CAN do a LOT with WP admin logins, though, from using another strong password to CAPTCHA (difficult to sort through the WP modules to find where to locate the login module and integrate with that) to putting your own (Apache) password protection on the WP admin directory to using your own script as a front door to the WP admin directory which can examine your IP Address and block all others. As mentioned above, it’s also possible to log failed attempts and use that to rewrite your .htaccess to block the attacking IP address, too.

FWIW, WHB does specialist hosting, too. I have a Joomla account for one client (I don’t use Joomla but the client requested vast increases in capability to support Joomla and this account filled the bill for him) and they also have a Drupal account. It might pay to have a look at that, too, as is may suit better than a small VPS or dedi (at a far lower cost to you/your client).

Regards,

DK

9

Well, they answered my SOS. They blocked the jerks.

I also contacted RIPE about all this. My world is in peace again. :.)

10

There will other hacker bots along soon, I’m sure.

11

You’re right, but each case is different and each merits their own specific response, reaction, prosecution, etc.

With some jerks, it’s okay to shrug your shoulders and assume that your upgraded software is enough to withstand whatever they try to do… Sometimes.

Then you have others which deserve a finer set of proactive detective skills, defensiveness, paranoia; whatever you want to think of it as.

I’ve had plenty of bots do stupid things with my site(s) too, lord knows that’s what many years of experience clues you in on, but none so openly and concentrated as this one–which is why I reacted like I did–and I’m happy I did, too! When some stupid idiot tries to attack a specific login page for 4-5 days NON-STOP every 2 minutes with a variable type of GET request each time, you don’t just sit there and do nothing and hope nothing bad happens with your site… I’ll be damned if that’s nothing to worry about.

I’m just happy some hosts obviously care about things like this. I’ll be sleeping soundly tonight–but your concern is appreciated, cheesedude. Good luck with your bots. :.)