Unresponsive B3

[Binkem]

Hi all,

Every once in a while i suffer from a very unresponsive B3. Usualle there is a lot of HDD activity and acessing the B3, via SMB, SSH or otherwise takes minutes. When I use the TOP command to see what's blocking the B3 all processes use less than 10% processor power. I do see a number of Apache2 threads pop up in the process-list though. Restarting Apache2 (this takes several minutes at that time) seems to help.
I've got a Wordpress site running from my B3.
Are there others with the same problem?
Is it perhaps caused by (a lot of) external access to my page?
Is there a way to stop this from happening?

Martijn

[Ubi]

This sounds like an I/O problem, which indeed does not show up on the CPU usage and is quite annoying to debug. Considering this is wordpress you may just bu under dictionary attack . Can you shut down some processes to see if things approve?

[Binkem]

I have installed a log plugin into my website and there is a link between login attempts and unresponsiveness. Now I've got the choice between removing the web-site (it wasn't really being used that much anyway) and devising some sort of counter-measure, which will be hard as every login attempt seems to come from a different IP.Anyone got any thoughts as to the second option?

[Ubi]

fail2ban has a wordpress module. Works wonders for my servers. In your case it may not be so effctive. Putting wp-login.php behind an apache login could work

[Gordon]

Usually wordpress hacks are part of a larger scheme to find web vulnerabilities. You're therefore likely to find requests for /w00tw00t.at.<something> from the same addresses as well in your apache log file.

Here's a little trick you can use in iptables:

Code: Select all

# Create httphack chain
iptables -N httphack
iptables -A httphack -m recent --update --seconds 3600 --name blacklist --rsource -j DROP
iptables -A httphack -m recent --remove --name blacklist --rsource

# Insert rules in INPUT chain
iptables -I INPUT 6 -i eth0 -m recent --rcheck --name blacklist --rsource -j httphack
iptables -I INPUT 7 -p tcp -m tcp --dport 80 -m string --string "GET /w00tw00t" --algo bm --to 60 -m recent --set --name blacklist --rsource -j DROP

This blocks every IP that attempts to access /w00tw00t for one hour and for every time it revisits your B3 within that hour it will reset the timer to one hour again.

[Ubi]

I guess in a similar manner you can block anyone trying to access wp-login, but whitelist your own IP befor that line.

Still, wouldnt it scale better to add the w00tw00t rule to failtoban with a grace of 0? This will also take care of removing stale entries (i.e. keep for 48 hours or so), and the data is persistent over reboots.

[Gordon]

Granted... there are other solutions

If my counting is correct, inserting at lines 6 and 7 should place the lines behind the rule to accept all from LAN. Anyone wanting to use this might want to verify this though.

As for testing on wp-login, the deeper the file is in the directory structure the more CPU the test will require. Similar for fail2ban, if the number of violators increases then testing for each IP individually will put a bigger strain on the B3 CPU - and in fact take longer - then when using the 'recent' module or ipsets (the latter requiring a kernel module that is not present in the bubba-kernel package).

Also, you can actually access the list(s) and add or delete entries in them. It is therefore possible to create some form of persistency. e.g. you could use cron to save the IP addresses in the blacklist to a regular file every 10 minutes:

Code: Select all

cat /proc/net/xt_recent/blacklist | cut -d= -f2 | awk '{print "+"$1}'>/etc/net/blacklist.txt

After restarting your firewall you could then reload the addresses with:

Code: Select all

while read perp; do echo $perp>/proc/net/xt_recent/blacklist; done </etc/net/blacklist.txt

[Binkem]

I just checked my access.log and there is just one attempt to access w00tw00t. Actually most of the log is filled with bubbamon checking my B3 stats.

[Gordon]

You're bound to see more attempts if you also check access.log.1 and access.log.*.gz

According to this page there does not appear to be not much sense in checking for wp-login to be included on the uri; I guess wp-login.php can be included by other wordpress php files?

As far as limiting attacks is concerned, I think you can achieve a lot by moving your site to a named vhost and point the default host to /var/www (which is where the apache install put the "It Works!" page). Any attack against your raw IP address, which is probably over 90% of them, will then never see the wordpress pages.

Check this thread in the howto section if you don't know how to do this.