Dan Widyono on 12 Jun 2009 09:57:45 -0700 |
Disclaimer: I'm collecting this info all into one post from various other folks' research. I do know it works, however. Thanks to Bob Williams on our team for the research and implementation. Here's a simple ipt_recent module recipe that doesn't do quite the same, but is quick to set up and somewhat effective. It prevents "too many" SSH logins (at all, successful or unsuccessful) within "too short" a period of time. The quotes mean those are variables you can tune (to an extent). -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name sshcnt -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 20 --rttl --name sshcnt -j DROP where --seconds 300 == 5 minutes, --hitcount 20 == 20 ssh connections before triggering drops. If you want to use a --hitcount greater than 20 and your kernel is 2.6.25 or above, you'll need to set the ip_pkt_list_tot parameter for ipt_recent to the same value (in modprobe.conf): options ipt_recent ip_pkt_list_tot=50 Unfortunately, using SSH for something legitimate which opens sessions frequently (e.g. CVS over SSH) also triggers the above rule. To work around that, use ControlMaster connection as discussed recently on PLUG. So recently that the search option of the archives does not appear to find them, so here is Paul Snyder's post: http://lists.netisland.net/archives/plug/plug-2009-06/msg00055.html which references ControlMaster, and it can look something like this in your SSH config file: Host ssh.server.host.name ControlMaster auto ControlPath /tmp/%r@%h:%p Dan W. On Fri, Jun 12, 2009 at 04:53:57AM -0700, Edmond Rodriguez wrote: > I recently allowed a port for ssh (default settings) on my machine/router > so a friend could try and connect to it. > > Within days someone tried to log on to my machine over 30,000 times in > about one hours time. > > What I found surprising was that ssh by default did not recognized this > rapid fire attempt to log on my machine and create some sort of delay > between each attempt. > > I guess all the configurations that have been written about recently help > prevent such password guessing games. I guess they eliminate the idea of > an unknown machine trying to log on. If possible at all, do they limit > the number of times an unauthorized person can try to log on? > > Having seen the attempts to log into my machine, I learned there are ways > with iptables and I think ssh itself (recent discussion at a PLUG meeting) > to cause it to delay some time after a few attempted logins. So that if > someone tries unsuccessfully to log in say 10 times, a delay will be > created to force a one minute wait time before the next attempt. > Edmond > > --------------------------------------------------------------------------- > > From: Fred Stluka <fred@bristle.com> > To: Philadelphia Linux User's Group Discussion List > <plug@lists.phillylinux.org> > Sent: Thursday, June 11, 2009 5:47:50 PM > Subject: Re: [PLUG] Pros and cons of key-pair based vs password based > SSH... > Thanks for all the great suggestions everyone! I've followed a > bunch of the links you sent, read the man page for ssh_config > and sshd_config, and made some changes. I especially like the > idea of limiting which users can login via AllowUsers and/or > AllowGroups. OpenSSH has a ton of features. I had no idea about > the possibility of sharing access to the same connection to get > remote filename completion on scp, etc. Cool! > > --Fred > --------------------------------------------------------------------- > Fred Stluka -- [1]mailto:fred@bristle.com -- [2]http://bristle.com/~fred/ > Bristle Software, Inc -- [3]http://bristle.com -- Glad to be of service! > --------------------------------------------------------------------- > > Michael Bevilacqua wrote: > > On Wed, Jun 10, 2009 at 8:42 PM, Richard Freeman > <[4]r-plug@thefreemanclan.net> wrote: > > The other thing I do is to modify my pam config for ssh to only allow > particular accounts to log in > > Note that, if you have access to /etc/ssh/sshd_config you could simply > use this configuration option: > > AllowUsers user1 user2 user3 > > See sshd_config(5) for more details on this option. > > -- > Michael D. Bevilacqua > [5]michael@bevilacqua.us > > ------------------------------------------------------------------ > > ___________________________________________________________________________ Philadelphia Linux Users Group -- [6]http://www.phillylinux.org Announcements - [7]http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- [8]http://lists.phillylinux.org/mailman/listinfo/plug > > References > > Visible links > 1. mailto:fred@bristle.com > 2. http://bristle.com/%7Efred/ > 3. http://bristle.com/ > 4. mailto:r-plug@thefreemanclan.net > 5. mailto:michael@bevilacqua.us > 6. http://www.phillylinux.org/ > 7. http://lists.phillylinux.org/mailman/listinfo/plug-announce > 8. http://lists.phillylinux.org/mailman/listinfo/plug > ___________________________________________________________________________ > Philadelphia Linux Users Group -- http://www.phillylinux.org > Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce > General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|