The superbotnet warnings have, of course, motivated me to check my logs. (In truth, part of the slow blogging just prior to the warnings were motivated by my seeing more bot activity at the domain I should have called ‘thebothoneypot.com’, but is instead called ‘banNasties.com’.) I installed a wordpress blog on the subdomain ‘blog.bannasties.com’. It is a very boring blog and, moreover, a bit dangerous for humans to visit. (Not the blog so much. But if you click links that run queries on banNasties.com, there is the possibility of getting banned.) From my point of view, the main function of that blog and domain is for me to keep track of things I noticed in my killed_log.txt files without filling up this blog with discussions of bot-attacks and to test stronger rules for ZBblock.
However, I also know that climate bloggers have been hacked, so I want to describe what I am seeing at that site which for various reasons lets me monitor rather intensively.
One of the things I noticed is that some ‘bad’ IPs have been trying to cloak their IP using proxies. For example: I’m having particular trouble with ‘41.129.119.143’ using a proxy to try to hack into wp-login.php at that site.
In the past two weeks ending yesterday, it has attempted to log in at least 59 times using these proxy IPs:
93.176.62.190 , 89.248.96.54 , 89.218.214.122 , 89.218.100.58 , 80.191.78.251 , 78.47.198.26 , 77.104.73.117 , 49.156.57.50 , 46.118.122.151 , 41.78.79.126 , 41.42.194.72 , 41.234.26.165 , 41.234.24.49 , 41.234.2.215 , 41.129.30.32 , 41.129.18.193 , 31.217.215.131 , 27.50.18.219 , 23.30.90.105 , 219.117.232.5 , 203.172.128.158 , 201.252.69.164 , 201.246.1.98 , 201.230.50.222 , 200.42.22.140 , 200.19.108.105 , 2.133.93.82 , 2.133.93.250 , 190.73.150.108 , 190.37.108.169 , 190.12.86.211 , 187.33.89.38 , 186.47.16.165 , 185.2.12.12 , 184.170.246.175 , 180.253.68.146 , 178.89.107.230 , 177.87.242.194 , 177.43.105.18 , 174.136.43.116 , 163.152.133.22 , 139.0.0.178 , 124.81.117.226 , 122.129.108.66 , 121.97.197.108 , 118.99.81.6 , 118.99.76.91 , 118.99.67.158 , 118.99.65.246 , 118.99.64.78 , 118.99.64.120 , 118.97.223.210 , 118.96.136.209 , 112.78.140.235 , 110.74.222.5 , 110.74.196.161 , 109.94.106.249 , 108.178.49.23
This list is limited to IPs that were blocked by my installation of ZBBlock (which includes my custom signatures). Any connections not stopped by ZBBlock would not have made it onto this list. Over the past two weeks, I beefed up blocking of bots visiting that bot-attractant site to block anything trying to log into that site if it’s headers indicate it is forwarding. I’m reasonably sure that my rules were missing some visits by 46.118.122.151 (or anything similar) at earlier times. (Why about two weeks ago? After all, the superbotnet warming was only last weekened. Well… let’s just say I noticed increased bot activity and increased forwarding. Taking time to tweak to see what the heck is going on so I could report is one of the reason I blogged so lightly here in early April!)
Since the time of super-bot net warning I looked at a few things. With respect to 46.118.122.151, it looks like this particular IP visits do this:
- IP 46.118.122.151 arrives behind a proxy.
- Many of the proxies themselves are either already identified in ZBblock’s default signatures or look suspicious to me anyway. ( Lots of ‘boys from Brazil’. Some sovam.net.ua forwarding through sovam.net.ua and so on.)
- It tries to connect with each proxy– each of which I ban. ( I’m pretty sure I ban that IP at Cloudflare for at least 7 days).
- I tend to see batches of 4 or 5 attempts, then the script gives up and comes back 3-4 hour later, but sometimes it skips a beat and comes back 6-7 hours later. By 3-4 hours later, I mean: one back came through around 15:57:xx for 4 visits on Monday and returned at 18:52:xx- 18:58:xx (5 visits). It skipped and came back again at 1:57:xx (6 visits). Sometimes there are somewhat longer interruptions between these pattern.
Of course I can’t be sure what is driving these visits. I certainly know if this is part of the super botnet or even a regular botnet consisting of zombie-drone pcs and macs to forward requests. The fact is, my skillzzzz in knowing what the script-kiddies could do are limited. But the regular timing could be consistent with a script kiddie (or even someone with script writing skillz of his own!) who has access to a batch of proxy IPs. He’s got a script programmed to visit certain uri’s which the script tries to load. If an IP is banned, it tries another one; eventually runs through those IPs and possibly moves to another uri. Later in the day, loads up a new batch of proxy IPs and comes back. Or something.
Anyway, I’d suggest it’s certainly a script and it’s certainly a break in attempt. The super botnet warning suggest that the script tries to brute force passwords for username ‘admin’. If so, that bot ain’t going to get in anyway. I haven’t tried to log whether it’s trying to post or send “admin” as the user name! If I get curious, I might do it. Checking that could constitute a new ‘good rule’ for ZBblock.
I would suggest those bloggers who self host consider monitoring their wp-login.php attempts for anything that’s obviously forwarding. Because these are forwarding, plugins like “Limit Login” or “Login Lockdown” probably can’t helpe. If there is a wordpress plugin that blocks IPs that shows multiple entries in the X_forward headers from wp-login, finding it and activating it would be prudent. Mind you, I currently prefer adding a rule to ZBBlock and I think it is a vastly superior solution to the plugins mentioned in various security announcements. So I’m not going to look for a WordPress plugin nor write it. But if you use plugins, try to find one that blocks connections to wp-login. php that are forwarding.
Open Thread.
I think there’s something missing in the phrase “wordpress plugin that blocks IPs show multiple entries in the X_forward headers from wp-login”.
I don’t know if the plugin “Wordfence” does what you’re thinking of, but its log is entertaining to watch. It is trivially configured for CloudFlare (the config page tells you what to enter).
AnonyMoose–
Thanks. I added “that”. The blurb doesn’t say whether Wordfence looks at the X_Forward_For headers. It does seem to run the logic for tests it does do on it’s servers. That reduces load. I suspect they then have data on many current threats which is nice. I wonder if it would catch anything my ZBblock catches?
One of the advantages of ZBblock is it can run before WordPress triggers. Also, I’ve set things up to then run the API and ban at Cloudflare. I’ll have to look at Wordfence a bit though.
More problems:
http://arstechnica.com/security/2013/04/admin-beware-attack-hitting-apache-websites-is-invisible-to-the-naked-eye/
dp, that is an interesting attack vector. I haven’t taken the time to analyze it fully (though I do have the code for it), but what I’ve seen seems to contradict common reports. A lot of sources seem to claim only active RAM is is modified by the attack (no actual files), but from what I’ve seen, it appears the httpd file is modified. Aside from that, I’m not sure how a machine gets infected by that attack. Do you know?
Anyway, this attack looks pretty interesting from what I’ve seen so far. I’ll try to look more into it later today. No guarantees though. I’ve seemed to contract something, and I’m not sure how long it’ll last. Respiratory problems are a huge pain.
Scary attack and beyond my paygrade. One this While researchers from Sucuri speculate it takes hold after attackers brute-force the secure-shell access used by administrators, I started using a 24 character long password some time ago. For the rest, I just have to let the server host handle apache.
Stepping away from security issues for a minute, I think the “skeptic” side of the global warming debate needs a Lewandowsky of its own. Skeptical Science, arguably the most important internet resource for global warming proponents, has now said disagreeing with them will send you to Hell:
And you’ll drag everyone else down with you!
There is a deep dive look at the beasty here:
http://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/
Lucia – As the other thread is closed I will make the observation that the cache settings are still an issue.
I now have to hit refresh for each page to see any new posts. Now that I know it is required then I can work round it though it is annoying. However other people may not be aware of the issue and if the header page does not appear to be updated will go away thinking nothing new to read!
clivere–
There is a long (security related) story about the cache I was using. A bug was reported by someone other than the author and the author rushed out a new plugin. I don’t know what the deal is, but for me, the behavior of the plugin changed– with caches not refreshing.
I changed cache plugins because the old one was having way to many mystery features. I have noticed the new one does not refresh the front page when a post is published. Caches stored by my server last 1 hour. I’ve been watching that, and I too have noticed the issue you notice. It bothers me.
Because this cache plugin works *better* than the other one. I’m planning to hunt down the bit that forces a cache to force caching when a post is published. Most cache plugins have a lot of “part”, so editing different bits can be a bit tricky. (Worse, you want to think of a way that perserves your “tweaks” when the author updates.) So I didn’t want to rush into that.
If I succeed, I’ll try to hook that into caching the front page when comments are published. Unfortunately, I do need to caching or server use goes through the roof.
Also: People’s browsers cache. That I have no control over that. But I don’t think that’s the main difficulty for you.