Iptables and SSH rate limiting

Arty Ziff · 05-20-2011, 11:24 AM

I'd like to discourage the SSH bots that try to log into my system (CentOSv5), and among other things, I've changed my SSH port to someting other than 22.

As well, I've been playing around with the idea of some iptables rules (note port 22 is used here as example):

Code:

# Allow SSH with a rate limit 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -m hashlimit --hashlimit 15/hour --hashlimit-burst 3 --hashlimit-htable-expire 600000 --hashlimit-mode srcip --hashlimit-name ssh -j ACCEPT 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j LOG --log-prefix "[DROPPED SSH]: " 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j DROP

I am *NOT* an iptables expert. What do you all think about the above code snip?

rhbegin · 05-20-2011, 08:58 PM

Quote:

Originally Posted by Arty Ziff

I'd like to discourage the SSH bots that try to log into my system (CentOSv5), and among other things, I've changed my SSH port to someting other than 22.

As well, I've been playing around with the idea of some iptables rules (note port 22 is used here as example):

Code:

# Allow SSH with a rate limit 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -m hashlimit --hashlimit 15/hour --hashlimit-burst 3 --hashlimit-htable-expire 600000 --hashlimit-mode srcip --hashlimit-name ssh -j ACCEPT 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j LOG --log-prefix "[DROPPED SSH]: " 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j DROP

I am *NOT* an iptables expert. What do you all think about the above code snip?

I setup rate-limiting on 2 email servers do to malicious attackers trying to 'mail-bomb' the servers.

If you want my rules I put in place in production I can post, I do not have logging on my drops since the servers are very busy with thousands of accounts. I have logged some traffic to see the traffic and it is same ip ranges trying to come back.

It works great, the trick with email servers they are very busy and the spam/firewall devices had to take precedence and the gateway ip/dns as well.

For email I found 20 hits in 60 seconds and you are dropped, with thousands of accounts you have to be very careful with email servers.

Are you getting hits, I turned on logging and found the malicious ip ranges were still working at it but to no avail they get trash-canned.

Arty Ziff · 05-20-2011, 11:32 PM

Yes, I'd like to see your rules...

And, there are some ip ranges I can outright block.

hua · 05-21-2011, 02:51 AM

On my most restricted server I limit the connections with these rules:

Quote:

iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 -j DROP

I don't know if those rules are perfect but it works for me.

The logic here is:
Since I use strong passwords for the users who are allowed to login via ssh, I want to stop the brute force password guessing.
In my understanding brute-force attacks are about time - how much combinations of characters/numbers/.. can be tested within a period of time. But this can be the same for dictionary too, depends on how long the password/user dictionary is.
When the attacker tries several thousand passwords in a period of time and continue to do this for weeks this stops him/her.
After two attempts he cannot connect for several minutes. This makes the time period lot longer then acceptable for this type of attack.

First time when I tried this rule I didn't know whether it will work or not but now I see that it helps.
There are still several attackers who tries to login with dictionary passwords but usually I see in my logs that they try approximately ten times, wait for the timeouts and then give up.
Brute force attacks it stopped totally.

I use this rules for other services too. For example pop3 - which my users don't use but I need to run it. Next most brute-forced service after ssh is this. (in my experience) The same rule I use but with different hit-count and update time.

salasi · 05-21-2011, 02:03 PM

Quote:

Originally Posted by Arty Ziff

I'd like to discourage the SSH bots that try to log into my system (CentOSv5), and among other things, I've changed my SSH port to someting other than 22.

As well, I've been playing around with the idea of some iptables rules (note port 22 is used here as example):

Code:

# Allow SSH with a rate limit 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -m hashlimit --hashlimit 15/hour --hashlimit-burst 3 --hashlimit-htable-expire 600000 --hashlimit-mode srcip --hashlimit-name ssh -j ACCEPT 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j LOG --log-prefix "[DROPPED SSH]: " 
iptables -A INPUT -i ppp0 -p tcp --syn --dport 22 -j DROP

I am *NOT* an iptables expert. What do you all think about the above code snip?

Let me give this to you straight; I think that you are attacking this problem in the wrong way.

So, currently, if you get too many ssh login attempts, you'll drop new ssh attempts, whether these are 'good' or 'bad' attempts. Locking yourself out, even if only temporarily, seems to me to be a bad move. Some day you'll want to get in a hurry, and you won't be able to do it. that is going to be an irritant. And I don't think that this is the best way to get protection.

So, something like denyhosts or fail2ban works in what seems to me to be a much better way.

Furthermore, don't confuse 'clean log files' with 'security'; once you've got that distinction clear in your head, you'll realise that a little 'junk' in your logfiles isn't necessarily a bad thing, if it tells you clearly what threats you are seeing, because the more warning you get of what is going on, the better.

Also read:
http://la-samhna.de/library/brutessh.html
This details in a clear and easy-to-understand way the options for protecting ssh; moving to an unconventional port, if that is all that you do, really isn't good enough. It may be an excellent measure to take, in combination with other things.