Purposely Delay SSH Prompt After Bad Password

tronayne · 05-14-2010, 08:15 AM

How can I delay the retry response from SSH (for, say, 10, 20 or 30 seconds) when a bad password is tried by a whacker? I mean, when I'm getting hit by 10 or more break-in attempts, is there some way to make SSH delay the next try from the site that's trying?

I seem to remember something about this but haven't been able to find it and, so far, reading the SSH documentation hasn't been too helpful.

I have DenyHosts running (that puts entries in /etc/hosts.deny after a few tries to break in) and I completely block China, Korea and a few others that are a constant annoyance with IPTABLES but I do get hit pretty much every day and would like to discourage the bastards as much as possible (the hits are a second or so apart which tells me they're automated and I figure delaying the response will discourage 'em).

For example, here's the overnight entries from /var/log/messages (the "refused connect" are from /etc/hosts.deny entries generated by DenyHosts):

Code:

May 13 03:49:50 fubar sshd[30255]: refused connect from 200.49.226.12 (200.49.226.12)
May 13 03:51:27 fubar sshd[30256]: refused connect from 200.49.226.12 (200.49.226.12)
May 13 05:23:14 fubar sshd[30363]: refused connect from 222.186.22.11 (222.186.22.11)
May 13 14:31:40 fubar sshd[11286]: refused connect from 85.17.155.134 (85.17.155.134)
May 13 17:18:03 fubar sshd[12932]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:21:42 fubar sshd[12984]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:22:04 fubar sshd[12985]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:22:26 fubar sshd[12986]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:22:48 fubar sshd[12987]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:23:10 fubar sshd[12988]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:23:33 fubar sshd[12989]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:23:55 fubar sshd[12990]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:24:17 fubar sshd[12991]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:24:39 fubar sshd[13011]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:25:01 fubar sshd[13012]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:25:23 fubar sshd[13013]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:25:45 fubar sshd[13014]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:26:07 fubar sshd[13015]: refused connect from 125.7.209.4 (125.7.209.4)
May 13 17:26:29 fubar sshd[13016]: refused connect from 125.7.209.4 (125.7.209.4)
May 14 05:42:23 fubar sshd[13220]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [218.29.42.116] failed - POSSIBLE BREAK-IN ATTEMPT!
May 14 05:42:23 fubar sshd[13220]: Failed password for root from 218.29.42.116 port 51402 ssh2
May 14 05:42:26 fubar sshd[13222]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [218.29.42.116] failed - POSSIBLE BREAK-IN ATTEMPT!
May 14 05:42:26 fubar sshd[13222]: Failed password for root from 218.29.42.116 port 51653 ssh2
May 14 05:42:29 fubar sshd[13224]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [218.29.42.116] failed - POSSIBLE BREAK-IN ATTEMPT!
May 14 05:42:29 fubar sshd[13224]: Failed password for root from 218.29.42.116 port 51848 ssh2
May 14 05:42:33 fubar sshd[13226]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [218.29.42.116] failed - POSSIBLE BREAK-IN ATTEMPT!
May 14 05:42:33 fubar sshd[13226]: Failed password for root from 218.29.42.116 port 52121 ssh2
May 14 05:42:36 fubar sshd[13228]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [218.29.42.116] failed - POSSIBLE BREAK-IN ATTEMPT!
May 14 05:42:36 fubar sshd[13228]: Failed password for root from 218.29.42.116 port 52317 ssh2
May 14 05:42:39 fubar sshd[13230]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [218.29.42.116] failed - POSSIBLE BREAK-IN ATTEMPT!
May 14 05:42:39 fubar sshd[13230]: Failed password for root from 218.29.42.116 port 52497 ssh2
May 14 05:42:43 fubar sshd[13232]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [218.29.42.116] failed - POSSIBLE BREAK-IN ATTEMPT!
May 14 05:42:43 fubar sshd[13232]: Failed password for root from 218.29.42.116 port 52693 ssh2

bathory · 05-14-2010, 08:21 AM

Hi

You can use fail2ban

Cheers

tronayne · 05-14-2010, 08:58 AM

Quote:

Originally Posted by bathory

Hi

You can use fail2ban

Cheers

Hm, interesting... kind of does the same thing as DenyHosts. I'll give it a shot and see what's what.

Thanks

BCarey · 05-14-2010, 02:29 PM

You should also consider disabling root login in sshd_config and disabling password authentication. Together with denyhosts this significantly reduced the number of these messages for me (as well as improving my security).

Brian

Gerard Lally · 05-14-2010, 02:43 PM

Quote:

Originally Posted by tronayne

How can I delay the retry response from SSH (for, say, 10, 20 or 30 seconds) when a bad password is tried by a whacker? I mean, when I'm getting hit by 10 or more break-in attempts, is there some way to make SSH delay the next try from the site that's trying?

I seem to remember something about this but haven't been able to find it and, so far, reading the SSH documentation hasn't been too helpful.

I have DenyHosts running (that puts entries in /etc/hosts.deny after a few tries to break in) and I completely block China, Korea and a few others that are a constant annoyance with IPTABLES but I do get hit pretty much every day and would like to discourage the bastards as much as possible (the hits are a second or so apart which tells me they're automated and I figure delaying the response will discourage 'em).

One way of limiting SSH attacks is to change the port your SSH listens on, to something like 52022. This should foil the automated attacks at least.

anomie · 05-14-2010, 02:51 PM

Quote:

Originally Posted by tronayne

How can I delay the retry response from SSH (for, say, 10, 20 or 30 seconds) when a bad password is tried by a whacker?

To get back to your original question, please see the manpages for pam_faildelay(8). I haven't used it, but it appears you can add it to the auth stack for a PAM-enabled service to insert an arbitrary delay following an authentication failure.

[ p.s. I'm writing this from a Fedora system. The module I mentioned may or may not be included as part of a base Slackware install. ]

bathory · 05-14-2010, 03:02 PM

Quote:

[ p.s. I'm writing this from a Fedora system. The module I mentioned may or may not be included as part of a base Slackware install. ]

Slackware does not use PAM.

Regards

tronayne · 05-14-2010, 03:59 PM

Thanks for all the input (actually, I do have PAM installed, need it for VMware and I'll give that method a shot).

I did find the following at http://www.aerospacesoftware.com/ssh-kiddies.html (inserted at the end of /etc/rc.d/rc.local:

Code:

# Use IPTables to limit Access
# limit new login attempts to once per minute
iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh \
       -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh -j DROP

Seems to work, it starts delaying the password prompt after the default 3 tries in sshd_conf for one minute (kinda eternity in confuser-land). Probably needs some fiddling and tweaking, but it does seem to work when I flog it from another intranet server.

Also, changing the port is a good idea (suggested all over the place in fact) and I'm going to experiment with that, too. Really looking for the quickest, most effective and reliable method (in keeping with the simplicity and effectiveness of DenyHosts, which works like a charm), and the port change may just be that.

And, lastly, I think I can live without the root login (although I do tend to use that now and again); can always connect as "me" and then "su -" to accomplish what I need to.

tuxdev · 05-14-2010, 04:31 PM

Actually, SSH does delay attempts to login. You don't need very much delay to make a brute force attack infeasible, and of course you're not using something easily guessable, right?

Richard Cranium · 05-14-2010, 05:07 PM

rc.local might be a little late in the boot process.

rc.firewall is where you probably should put your firewall rules. Look for the call to it in rc.inet2.

BCarey · 05-14-2010, 06:04 PM

Quote:

Originally Posted by tronayne

Thanks for all the input (actually, I do have PAM installed, need it for VMware and I'll give that method a shot).

I did find the following at http://www.aerospacesoftware.com/ssh-kiddies.html (inserted at the end of /etc/rc.d/rc.local:

Code:

# Use IPTables to limit Access
# limit new login attempts to once per minute
iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh \
       -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp -m state --syn --state NEW --dport ssh -j DROP

Seems to work, it starts delaying the password prompt after the default 3 tries in sshd_conf for one minute (kinda eternity in confuser-land). Probably needs some fiddling and tweaking, but it does seem to work when I flog it from another intranet server.

Very nice

Quote:

And, lastly, I think I can live without the root login (although I do tend to use that now and again); can always connect as "me" and then "su -" to accomplish what I need to.

Yes, much safer I think. Disabling password-based authentication altogether is even better, and easy to do.

Brian

manwichmakesameal · 05-14-2010, 10:02 PM

I second moving ssh to a different port and using pub key auth.

tronayne · 05-15-2010, 08:10 AM

I probably misstated "root login;" I only use public-key on all the machines I have access to. Much easier flipping back and forth when you need to, methinks. Too, my passwords are (more-or-less) uncrackable; Both the "old" Crack and the modern John the Ripper have run for about 24 hours trying to crack them and neither as been able to so I kind of figure they're good.

Dealing with these idiots can be time-consuming; among the reasons I've relied on DenyHosts for much of the work is that it not only identifies and denies (in /etc/hosts.deny) the bad guys automagically, it also merges my individual experience with other DenyHosts sites around the world; thus, a much larger pool of bad hosts is maintained. That's nice.

I'm always kind of loathe to fiddle with base settings (unless I have to) because then I have to remember what I did and why I did it on the next update or release. Of course, given the state of things in this world, you have to protect yourself; that's why you have locks on your doors and that's why you have firewalls and a plethora of tools on your systems to keep the jerks out of your pants. DenyHosts is one of those, IPTABLES is another and "fine-tuning" SSHD is yet another on top of those. Tis a sad thing, indeed.

So, we turn off root login in SSH, have DenyHosts running (they do try to walk system accounts, too), change the port SSHD listens on, add IPTABLES entries to /etc/rc.d/rc.firewall (thanks, Richard!), think about actually using PAM and setting pam_faildelay (well, not yet, but maybe), fiddle with fail2ban and see what that does, keep monitoring the logs and keep our collective fingers crossed, dammit.

Thanks to all for the ideas.