[ale] Pretty Ugly Out There!

[Michael Still]

I am in the middle of implementing a solution for this problem at
$WORK.  At first I looked at sshdfilter because it does appear the
most powerful and faster reacting than DenyHosts, but our firewall
rule setup is too complicated and specialized to implement this
nicely.  DenyHosts is a close second best solution that I've found and
so far it has been pretty nice.  If you're trusting, then the sync
feature is pretty cool letting you proactively deny attempts from
known scanning IPs, but stick a static trusted IP in /etc/hosts.allow
if you use it.

On 3/8/06, Steven A. DuChene <linux-clusters at mindspring.com> wrote:
> I have found sshfilter to do a VERY good job of stoping these ssh attempts
> on my systems. It places rules into your firewall rules dynamically based
> on common criteria that matches almost all (like 99.9%) of these ssh hack
> attempts. After some tune-able period of time the added rules are expired
> as well.
>
> http://www.csc.liv.ac.uk/~greg/sshdfilter/
>
> -----Original Message-----
> >From: Ben Alexander <ben-ale at bensbox.com>
> >Sent: Mar 8, 2006 7:08 AM
> >To: Atlanta Linux Enthusiasts <ale at ale.org>
> >Subject: Re: [ale] Pretty Ugly Out There!
> >
> >Here are three different suggestions -- I got these from a thread that
> >started a few days ago on *incidents at securityfocus.com:
> >
> >*DenyHosts is a python script that will drop offending IPs into hosts.deny.
> >
> >denyhosts.sourceforge.net
> >
> >----
> >
> >PermitRootLogin no
> >AllowUsers <xx> <yy> <zz>
> >
> >       where <xx>, <yy> and <zz> are the users that REALLY require ssh
> >access,
> >after checking they do not have a weak user name (like 'john' or 'mary')
> >and/or a weak password.
> >
> >----
> >
> >The rules track ssh new ssh connections. If there have been 5
> >connections from a single host in the past 60 seconds then the
> >connection is dropped. Theoretically a worm could wait and attempt
> >connecting again, but they don't seem to.
> >
> >
> >iptables -A INPUT -i $EXTERNAL -p tcp --dport 22 -m conntrack --ctstate
> >NEW -m recent --set --name sshscans
> >iptables -A INPUT -m recent --rcheck --seconds 60 --hitcount 5 --name
> >sshscans --rsource -j DROP
> >
> >
> >----
> >
> >Ben
> >
> >
> >**
> >On 3/8/06, Mills, John M. <Mills.J at ems-t.com> wrote:
> >>
> >> ALErs -
> >>
> >> I'm currently logging many hundreds - perhaps thousands - of daily
> >> attempts to get SSH logins on my home box. They come in sequences of
> >> user names (10-20 typically) from one IP, then a different bunch from
> >> another. The guessed account names are starting to cycle through searchs
> >> that might actually hit a real username.
> >>
> >> I would like to lock any given originating IP out of access or out of
> >> SSH login for some period after some number of failures (against
> >> different usernames). Is there a simple way to do this with or between
> >> 'ipchains' and 'open-ssh'?
> >>
> >> Also, what steps should I take to smoothly migrate a user from one
> >> username to another? I.e. if I just change the login name in 'passwd',
> >> shadow' and 'groups', what side effects am I likely to hit?
> >>
> >> This box started as RH-7.3, though it's evolved quite a bit with time
> >> (SSH updates in particular).
> >>
> >> Thanks.
> >>
> >> - Mills
> >>
> >> _______________________________________________
> >> Ale mailing list
> >> Ale at ale.org
> >> http://www.ale.org/mailman/listinfo/ale
> >>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>


--
[stillwaxin at gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwaxin at gmail.com ~]$