Automatically Blocking SSH Attackes From Script Kiddies?

Posted by ajt on Thu 22 Sep 2005 at 12:30

As everyone knows there are a lot of script kiddies out there, running port scanners and SSH dictionary attack tools. Assuming you have proper SSH configuration, this isn't a problem, but it is a nuisance as it clogs up the logs.

In this article Protecting Linux against automated attackers, Ryan Twomey suggests some tools for automatically blacklisting an IP based on failed login attempts.

Which tools have people found useful, and actually worth using?

I already read the suggestion here Using iptables to rate-limit incoming connections and Keeping SSH access secure.

 

 


Posted by gna (212.40.xx.xx) on Thu 22 Sep 2005 at 14:50
[ View Weblogs ]
I mentioned in my weblog a package named KnockD.

The idea is:
  • You open access only for trusted IPs and disallow any other.
  • Allow only those IPs who knocked in the right order on the right ports, for opening the connection, and close the door again, but the alive connetion will not be terminated.

    You need a good configured firewall, and the clients (linux/win exists) need to knock before attempting to connect.

    I will post a sample config on firewall and knockd.conf soon if needed in my weblog here.

[ Parent | Reply to this comment ]

Posted by yomguy (134.157.xx.xx) on Thu 22 Sep 2005 at 15:11
Hi !

I highly recommend the python tool fail2ban [1][2] which creates blocking iptable rules automatically when the number of loging tries reaches a given limit.

[1] http://fail2ban.sourceforge.net
[2] http://packages.debian.org/unstable/net/fail2ban

Regards,
Yomguy

http://yomix.org

[ Parent | Reply to this comment ]

Posted by Anonymous (159.117.xx.xx) on Fri 23 Sep 2005 at 01:30
fail2ban is great. The package is very good, with minimal config. It inserts a rule at the top of your iptables input chain that directs all new ssh connections to its own chain. It then manages this chain for you adding and removing banned IPs.

[ Parent | Reply to this comment ]

Posted by Piem (81.178.xx.xx) on Fri 23 Sep 2005 at 18:34
[ View Piem's Scratchpad ]
Very nice indeed, thanks for the info Yomguy. The package currently in sid installs fine on sarge too. Beware of not banning your own ip though, fail2ban is working as soon as you install it.

[ Parent | Reply to this comment ]

Posted by Anonymous (65.78.xx.xx) on Sun 25 Sep 2005 at 19:53
Thanks for suggesting fail2ban. Perfect for me on sarge. Instant satisfaction!

aptitude install fail2ban

[Remember to pull this from the 'unstable' repository.]

[ Parent | Reply to this comment ]

Posted by Anonymous (65.68.xx.xx) on Thu 22 Sep 2005 at 15:18
Denyhosts is a good tool. It's a python script and will update your hosts.deny file. Works in daemon or cron modes. Link...

[ Parent | Reply to this comment ]

Posted by Anonymous (71.136.xx.xx) on Thu 22 Sep 2005 at 16:48
that's what i use. i run as a cron job every 5 minutes. clean and simple. it would be great to have a central list ip addresses you could download, like the blocklists available for p2p apps.

[ Parent | Reply to this comment ]

Posted by Anonymous (130.184.xx.xx) on Thu 30 Jul 2009 at 18:19
Another vote for Denyhosts. It's easy to install and configure. Works like a charm. Just make sure you don't lock yourself out.

[ Parent | Reply to this comment ]

Posted by Anonymous (130.184.xx.xx) on Thu 30 Jul 2009 at 18:19
Another vote for Denyhosts. It's easy to install and configure. Works like a charm. Just make sure you don't lock yourself out.

[ Parent | Reply to this comment ]

Posted by blackm (212.202.xx.xx) on Thu 22 Sep 2005 at 18:18
[ View Weblogs ]
Since my sshd is running on an other port, there was not a single script-kiddie login attempt. Very easy and very effective. No maintenance.

Martin

[ Parent | Reply to this comment ]

Posted by Anonymous (83.131.xx.xx) on Mon 3 Oct 2005 at 23:07
So am I. The best solution ever. The "only" problem is with user notification, but such users are mostly regulary e-mail readers.

[ Parent | Reply to this comment ]

Posted by Anonymous (139.80.xx.xx) on Thu 27 Oct 2005 at 02:18
This is a good practice since it adds another layer of obfuscation, but that's all it is. It won't stop anyone determined enough.

Anyone with a port scanner can easily discover what port sshd is running on, so you still need some additional layer of security.

Stephen Frost's 'ipt_recent' patch for iptables works great against brute force attacks.

See:
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions -HOWTO.txt

[ Parent | Reply to this comment ]

Posted by steveaz98 (68.236.xx.xx) on Thu 22 Sep 2005 at 19:53
Be careful automatically blocking ports as it would be easy to create a dos attack this way preventing authorized IPs from connecting.

[ Parent | Reply to this comment ]

Posted by El_Cubano (66.93.xx.xx) on Fri 23 Sep 2005 at 23:43

Agreed. I was going to package a port knowking daemon called doorman just for this, then I finally figured it wasn't worth it. In my case, I decided to use tha facilities provided by shorewall (an awesome firewall tool):

ACCEPT          net       $FW           tcp     22      -          - 1/min:2

Basically, ssh login attempts from an IP on the public internet are restricted to once a minute, with a surge of 2 (basically allowing two attempts in the first 60 seconds). The nice thing is that it doesn't run the risk of someone DOSing me by using up all the concurrent connections or whatever. Additionally, the script kiddies get tired of waiting and I rarely ever get more than two attempts from the same IP. Some are real persistent and stick it out for 10 minutes or so, but that only gets them 11 attempts.

[ Parent | Reply to this comment ]

Posted by helmetedwarrior (217.72.xx.xx) on Tue 22 Nov 2005 at 10:29
This is exactly what I have done as well. Like you I only get a few log in attempts at the most.

[ Parent | Reply to this comment ]

Posted by daedalus (80.126.xx.xx) on Thu 22 Sep 2005 at 20:40
I found this article: Protecting Linux against automated attackers (http://security.linux.com/article.pl?sid=05/ 09/15/1655234)

and this tool wil also help:
Fail2Ban, bans IP that makes too many password failure
(http://fail2ban.sourceforge.net/)

[ Parent | Reply to this comment ]

Posted by singe (146.231.xx.xx) on Thu 22 Sep 2005 at 20:46
PSAD is great, Bastille Linux will help you set it up quickly and easily. It will even help you with adding deny rules for attackers and will educate you along the way.

[ Parent | Reply to this comment ]

Posted by Anonymous (198.203.xx.xx) on Thu 22 Sep 2005 at 20:56
check this also: http://www.debian-administration.org/articles/87

and you can also find a lots of good comments...

[ Parent | Reply to this comment ]

Posted by Anonymous (80.185.xx.xx) on Thu 22 Sep 2005 at 21:09
fail2ban is the tool of choice

[ Parent | Reply to this comment ]

Posted by Anonymous (202.58.xx.xx) on Tue 16 Jan 2007 at 12:11
+

fail2ban was 10 seconds to download, 1 minute to configure. Now it is happily banning the kiddies. Way to go!

[ Parent | Reply to this comment ]

Posted by Anonymous (81.56.xx.xx) on Fri 23 Sep 2005 at 01:35
What about ssh ? ;-) From the man sshd_config :
MaxStartups

Specifies the maximum number of concurrent unauthenticated connections to the sshd daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10.

Alternatively, random early drop can be enabled by specifying the three colon separated values “start:rate:full” (e.g., "10:30:60"). sshd will refuse connection attempts with a probability of “rate/100” (30%) if there are currently “start” (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full” (60).
Of course logs will still be full of script kiddies attempts but certainly less...

[ Parent | Reply to this comment ]

Posted by Anonymous (62.6.xx.xx) on Fri 23 Sep 2005 at 16:30
It is interesting looking through the word lists used in these attacks. They are very similar across geographically remote IP ranges.

My SSH setup now uses -
- An alternative port
- Public key authentication, with password authentication disabled
- no root logins
- DenyHosts running as a daemon

I had set up DenyHosts as a cron job every 10 minutes, but was shocked at the number of login attempts made in this space of time. Running as a daemon it picks things up much faster.

HTH

Neil

[ Parent | Reply to this comment ]

Posted by tenaka (82.77.xx.xx) on Sat 24 Sep 2005 at 16:34
strangely I saw no one mentioning portsentry. Thats what I use for securing ports... of course it does not help against someone trying exactly port 22 an no one else... but one could combine it with tools mentioned here already...

[ Parent | Reply to this comment ]

Posted by Anonymous (141.154.xx.xx) on Mon 26 Sep 2005 at 14:14
...which is why you can brute force them with so little effort. Use key-based authentication and disable passwords. Running ssh on a different port is wise too, for much the same reason: by definition, script kiddies are going for the lowest common denominator in system security, the out-of-the-box install, with typical users (and weak passwords). It's pretty simple to take yourself off their radar.

[ Parent | Reply to this comment ]

Posted by Anonymous (83.161.xx.xx) on Thu 29 Sep 2005 at 05:09
Ryan Twomey suggests to use the limit module from iptables, but you should use the 'recent' module in iptables, it allows real blacklists that are working much better.

a description of a firewall with 'ipt_recent' blacklists can be found here:
http://olivier.sessink.nl/publications/blacklisting/index.html

[ Parent | Reply to this comment ]

Posted by Anonymous (84.133.xx.xx) on Sat 24 Dec 2005 at 15:12
Sure there are may ways to block the script kiddies' ssh experiments...

But that are not the only ports they can play with.

I am looking for a more central place to catch such misbehaviour. Maybe there is a syslogD out somewhere with pluggable modules to monitor the events and draw decissions based on that?

[ Parent | Reply to this comment ]

Posted by Anonymous (116.71.xx.xx) on Fri 4 Jul 2008 at 13:48
Your article is mighty helpful but I have only one thing in mind......Can these Attacks be made on Windows also & is it the same procedure to prevent them as well ?
http://www.eletrocomputerwarehouse.com/

[ Parent | Reply to this comment ]

Posted by ajt (195.112.xx.xx) on Sat 5 Jul 2008 at 15:18
[ View Weblogs ]

Windows does not come with SSH so it's not vulnerable to this particular attack, however in general Windows is more vulnerable to a Unix system of any flavour. As a general rule NEVER connect a Windows machine directly to the Internet, always connect via a NATing router or something similar.

--
"It's Not Magic, It's Work"
Adam

[ Parent | Reply to this comment ]

Posted by Anonymous (24.91.xx.xx) on Sat 28 Mar 2009 at 02:42

The article, "Protecting Linux against automated attackers", has moved.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 676 votes ~ 10 comments )