Comments on: Using IPTables to Prevent SSH Brute Force Attacks

By: Devon

Devon — Mon, 09 Nov 2009 18:16:57 +0000

Good to know. It looks like the deamon mode is new-ish. However it defeats the non-root aspect you mention:

If you are running DenyHosts in daemon mode then yes you must run DenyHosts as root.

By: tx

tx — Mon, 09 Nov 2009 18:13:19 +0000

Denyhosts can be run in daemon mode which will actively monitor ssh logins and update hosts.deny immediately. Further it is possible to run the daemon as a non-root user (see http://denyhosts.sourceforge.net/faq.html#3_1). And lastly it is possible to tell denyhosts to block only a specified service instead of all services. Personally, I would rather block all communication from a compromised host.

By: questionablemoose

questionablemoose — Fri, 06 Mar 2009 07:05:38 +0000

Instead of spending 15 minutes checking auth.log, I now spend about 30 seconds. Works brilliantly as far as I’m concerned. Thanks!

By: Devon

Devon — Fri, 09 Jan 2009 12:30:28 +0000

@James: Yes, it’s a similar approach. However there are a few reasons you might want to consider using the iptables rules instead of the denyhosts service:

DenyHosts runs periodically (either via cron or as a deamon), and in the FAQ the author recommends running it every 10 minutes. Your server will take a very high number of brute force attempts in 10 minutes. The iptables rule will block after 4 attempts, much more quickly than denyhosts, and hence reduces the chances of a successful brute forcing attempt.

I don’t like running processes as root, like DenyHosts. The only real advantage of DenyHosts is the new synchronization mode, which would let you block servers that haven’t even attacked you yet, saving your the four attempts the iptables rule would allow. However, running a python script as root, that pulls data from a 3rd party non-SSL server and then uses that data to modify my server’s hosts.deny file. Doubly so when that data is already being collected from other users of this 3rd party service. I’m not sure what prevents a malicious user of the service from submitting perfectly legit IPs or IP ranges and having the synchronization service push that data out to all the other users. I.e. I could submit all Comcast IPs and have them get blocked by users of the service, even though they are legit. Also, with the lack of SSL, I’d worry about the possibility of cache poisoning or DNS poisoning attacks being another vector to poison the data going into the hosts.deny file.

The hosts.deny file is used for ALL services, not just SSH. This would prevent people with infected PCs from visiting your websites.

The hosts.deny file is only read by tcpwrappers, and not all programs use it, so if I really did want to block all services, it might not suffice.

Mostly it comes down to me liking the control that iptables gives me, and being somewhat paranoid:)

By: James

James — Fri, 09 Jan 2009 10:54:03 +0000

Is this not similar (if a little simpler) to the denyhosts service?

By: Querystring » Brute force attack on Twitter

Querystring » Brute force attack on Twitter — Thu, 08 Jan 2009 08:32:28 +0000

[...] Wired Threat Level has posted an interview with the hacker who recently broke into several high profile twitter accounts, such as Fox News, and Barack Obama. Since we know how much you all love twitter, we thought you might want to learn more about it. Apparently he used a brute force method to get into a member of the support team. The password was “happiness” which was cracked pretty quickly. This might be a good time to review your own strategies to prevent brute force attacks. [...]

By: Brute force attack on Twitter - Hack a Day

Brute force attack on Twitter - Hack a Day — Thu, 08 Jan 2009 00:14:56 +0000

By: Tim

Tim — Fri, 22 Aug 2008 08:44:16 +0000

Thnx this helps me out a lot, I was looking for something like this already.

@Andries
Still some clients (like on iphone) don’t support different ports then 22

By: Devon

Devon — Sun, 10 Aug 2008 02:37:41 +0000

@Andreis: Good question.

A few answers:

1) a different port is a good idea for part of a security solution, but you should still have measures in place to prevent brute force attacks. Port scanning to identify ssh server ports isn’t hard. You might duck a large number of automated scanners, but it won’t do anything for a targeted attack. My solution will. So you should do the above anyhow:)

2) one of the main reasons I don’t run on a different port myself is convenience. I ssh in from a large number of other servers, and scp files frequently. Having to specify a port every time I do any of that would be a pain.

By: Andries Louw Wolthuizen

Andries Louw Wolthuizen — Sun, 10 Aug 2008 02:26:02 +0000

Why would you run SSH on port 22? Running sSH on a other port is a simple solution, that keeps most of the attempts out.