LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-14-2010, 09:15 AM   #1
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,118

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Purposely Delay SSH Prompt After Bad Password


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
 
Old 05-14-2010, 09:21 AM   #2
bathory
Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 10,970

Rep: Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343
Hi

You can use fail2ban

Cheers
 
Old 05-14-2010, 09:58 AM   #3
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,118

Original Poster
Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Quote:
Originally Posted by bathory View Post
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
 
Old 05-14-2010, 03:29 PM   #4
BCarey
Senior Member
 
Registered: Oct 2005
Location: New Mexico
Distribution: Slackware
Posts: 1,489

Rep: Reputation: Disabled
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
 
Old 05-14-2010, 03:43 PM   #5
gezley
Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware-64, Crux-64, NetBSD-64
Posts: 557

Rep: Reputation: 270Reputation: 270Reputation: 270
Quote:
Originally Posted by tronayne View Post
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.
 
Old 05-14-2010, 03:51 PM   #6
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, Lubuntu, FreeBSD
Posts: 3,930
Blog Entries: 5

Rep: Reputation: Disabled
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. ]

Last edited by anomie; 05-14-2010 at 03:52 PM.
 
Old 05-14-2010, 04:02 PM   #7
bathory
Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 10,970

Rep: Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343Reputation: 1343
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
 
Old 05-14-2010, 04:59 PM   #8
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,118

Original Poster
Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
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.
 
Old 05-14-2010, 05:31 PM   #9
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,014

Rep: Reputation: 115Reputation: 115
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?
 
Old 05-14-2010, 06:07 PM   #10
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,574

Rep: Reputation: 463Reputation: 463Reputation: 463Reputation: 463Reputation: 463
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.
 
Old 05-14-2010, 07:04 PM   #11
BCarey
Senior Member
 
Registered: Oct 2005
Location: New Mexico
Distribution: Slackware
Posts: 1,489

Rep: Reputation: Disabled
Quote:
Originally Posted by tronayne View Post
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
 
Old 05-14-2010, 11:02 PM   #12
manwichmakesameal
Member
 
Registered: Aug 2006
Distribution: Slackware
Posts: 800

Rep: Reputation: 100Reputation: 100
I second moving ssh to a different port and using pub key auth.
 
Old 05-15-2010, 09:10 AM   #13
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,118

Original Poster
Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
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.

Last edited by tronayne; 05-15-2010 at 09:13 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Delay before password prompt over ssh. cov Linux - Networking 14 07-16-2009 02:53 PM
ssh no password prompt dtra Linux - Software 9 05-25-2005 02:08 PM
ssh password prompt delay long while chaze Linux - Networking 1 04-14-2005 11:03 PM
ssh without the password prompt markehb Linux - Networking 27 03-25-2004 12:12 PM
remote command over ssh, password prompt linowes Linux - General 2 10-27-2002 09:22 PM


All times are GMT -5. The time now is 01:53 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration