Zaf’s Blog

My network is often subjected to brute-force SSH attacks. I have no idea how many attacks would actually occur if not for my various defense mechanisms. The first layer of defense is very very good passwords on all accounts, but the next layer is SSH rate limiting. Only a few connections per minute are allowed from each IP to the SSH port. This is done using the IP tables recent module, which is a very powerful module. There are many examples of using this module to block SSH, and the one below is very well published.

The first part consists of a new table that does the actual checking, then in the INPUT table, I call the SSH_Brute_Force table. The actual values used here (eg 10 attempts per 3 minutes) can be easily changed, and my system uses much more stringent values.

iptables -N SSH_Brute_Force

# Set or update this IP's record in the sshattack table
iptables -A SSH_Brute_Force -m recent --set --name sshattack

# Check if in recent, and log
# Check if its in the list, and it was seen less than 180 seconds ago, and
# if there were at least 10 attempts in the last 180 seconds
# If it matches those conditions, continue, otherwise return

iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 180 --hitcount 10 --name sshattack -j  RETURN

# Ok, so it was seen making 10 attempts in the last 180 seconds
# So log it, and REJECT
iptables -A SSH_Brute_Force -m limit --limit 3/min -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_Brute_Force -j REJECT
iptables -A INPUT -i $IFACE_DMZ -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force

$IFACE_DMZ is of course the interface that faces the Internet. I don’t rate limit internal connections, because I hope that my own users aren’t going to brute force the firewall. If they do, a LART will be coming their way.

The above method was successful for a long time, and greatly reduced the number of attempted logins. Essentially each IP gets only 10 attempts at most to login. If they fail, they are locked out until they reduce their rate. I have only seen one attack where the attacker actually rate-limited himself to keep under the system rate limiting. He tried for about 6 hours and never once even had a valid username.

These days however the number of attacks are getting higher and higher, and using a tool I’ll mention later, I’ve determined that almost all the attacks come from IP addresses in net-blocks from either China or Taiwan, with the occasional attack from Korea.

This has lead me to my next layer of defense. Using this tool, I have generated an IP tables table (named asia-network) that matches all IP’s belonging to China, Taiwan and Korea. The result of the match is a DROP, and in the INPUT table, I call the asia-network table if the connection is coming in on port 22.

iptables -N asia-network

iptables -A asia-network -s 58.14.0.0/15 -j DROP
........ Many rules later..........

iptables -A INPUT -i $IFACE_DMZ -p tcp --dport 22 -m state --state NEW -j asia-network

This has lead to an almost total reduction of SSH brute force attempts. The only disadvantage is there is a slight performance hit when dealing with over 700 ip tables rules. I’m hoping that by having these rules in their own table that only gets called for SSH connections, the performance hit will only apply to SSH traffic.

The final tool in my kit is a RSS feed and webpage showing me the last 3 days worth of failed SSH attempts. I would make the page public, but our users occasionally mistype their own passwords, and I don’t want valid accounts showing up on a publicly accessible list.

The tool consists of a cron script that runs every few minutes, that parses the auth.log, looking for failed password messages, it outputs the date, time, username and IP to a simple text file. This file is then parsed by a php script, that outputs both an RSS feed and a webpage displaying the bits of information.

If anyone wants the 3 scripts required to generate this, then please feel free to email me.

This entry was posted on Monday, August 20th, 2007 at 12:36 pm and is filed under post. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.