No worries @Michael. Had a ping from Gilles to come and look at it as it was possibly offtopic here.
–
Rory AlsopSep 27 '11 at 9:09

@Rory Ok, I'll ask him about it; he's usually pretty good at convincing me something I think is {off,on}topic is actually {on,off}topic
–
Michael Mrozek♦Sep 27 '11 at 13:44

1

My question seems to have been changed beyond recognition. In my original question I was really trying to find out if it was common for every site to experience brute force attacks - i.e. is it a fact of life. This was answered by Matteo with "It is indeed a fact of life.". The second part of the question was asking what i could do to actively stop these attacks apart from putting up defences. This would have been a relevant secondary question if only certain sites suffered from brute force attacks. It was answered by Bruce with his tarpit idea. I didn't really ask for defensive tips.
–
JW01Sep 27 '11 at 17:09

@whoami Thanks for the link, a nice summary. Although one thing that always goes though my mind when I see the use a different port tip is 'how do you know that the alternative port that you choose is not used by something else already?'
–
JW01Sep 26 '11 at 17:20

I followed these instructions to add a 7-second delay to each wrong-password SSH login attempt. I made my sshd into a "tarpit" for the brute-force scanners.

I should also add that I have my modified, tarpit sshd log the failed passwords. This may not be entirely ethical, as it gvies the root user a look at what regular users mis-type as their own passwords, but since I'm the only "real" user, I figure that's OK.

I don't have it run on a non-standard port, as the "tarpit" aspect would not waste anyone's time.

Also, use a non-standard port and use keys instead of passwords. Then they have almost no hope (providing they don't get ahold of the keys, which should all be passworded anyway).
–
Callum RogersSep 26 '11 at 17:49

This is a nice answer because it has a bit of an 'offensive' approach rather than being purely 'defensive' which I think adds to moral.
–
JW01Sep 27 '11 at 4:24

If you can manage it, I find the best way to deal with stuff like this is to use a VPN. That way, the only thing they can target is the VPN. There shouldn't be any services open to the world at large, except those which are necessary for "everyone" to access, such as your web server. Everything else should be blocked by the firewall. Now the only thing you really have to worry about securing is your VPN. If you can, get a static IP for the computers you manage your servers from, and lock your VPN down to that specific IP address. This is really the only way to stop people from trying to brute-force the passwords.

If only a small number of people need to SSH to the system then consider moving SSH to a non-standard port (e.g. 6422, 8080, etc.) That alone will reduce the number of login attempts greatly (and possibly protect you from some unpatched SSH exploit based worm, for example).

+1 Rather useful as it limits the annoyance, but do not mistake this for a security measure - this is a closer equivalent of a screen door against mosquitoes than of a security lock.
–
PiskvorSep 27 '11 at 9:36

1

+1 This is also a save on server resources.
–
XeoncrossSep 27 '11 at 18:07

Concur with @Matteo's answer; what you're seeing is essentially thousands of zombie'd systems executing a distributed brute-force attack on your server because there is a website running on it, which means there may be users that might have a login account that might possibly be guessed with minimal effort on the part of the script kiddie - he's got a program that orders the thousands of zombies to make the bruteforce attempts on a few hundred website hosts at a time and just compile a list of the successful returns.

Similarly, you may sometimes see lots of permuations of "http://your.web.host/phpmyadmin/" in your /var/log/apache2/access.log files; these are automated scans for the most common ways of setting up PHPMyAdmin, and will attempt a number of known exploits if one is found (this, incidentally, is why I've started telling customers to please use the PMA site I personally set up and keep up to date rather than installing their own version and forgetting to keep it updated, but now we're off on a tangent).

Aside from sending out the original command, it doesn't even cost him time or bandwidth; it's fire and forget.

Another very useful bit of software for situations like this is fail2ban, which uses iptables to block connection attempts after multiple clearly false logon or other exploit attempts.