denying spam hosts ssh access - good idea?

[Samuel Martín Moro]

I had the same ssh-bruteforce troubles.
Here's the script I use against that.
It's in cron, launched every 2 minutes.

#!/bin/sh
AUTH=/var/log/auth.log
BKLST=/var/log/blacklist.log
HOSTS=/etc/hosts
DHOSTS=/etc/hosts.deny

cat $AUTH | egrep -i "(illegal|invalid|failed)" | awk -F "from" '{print $2}'
| awk '{print $1}' | sort -u >$BKLST

for i in `cat $BKLST`; do
    nerr=`cat $AUTH | egrep -i "(illegal|invalid|failed)" | grep $i | wc -l`
    if [ "$nerr" -ge "3" -a -z "`cat $HOSTS | grep $i`" -a -z "`cat $DHOSTS
| grep $i`" ]; then
        echo "ALL : $i  # matched on `date`" >>$DHOSTS
    fi
done
#nota: I added my home & work IPs to /etc/hosts

I can't use ssh-keys (many of my users don't know how that works/what it
is).
But if you can do it, you should.


Samuel Martín Moro


On Mon, Jan 11, 2010 at 4:59 PM, Anton Shterenlikht <mexas at bristol.ac.uk>wrote:

> On Mon, Jan 11, 2010 at 03:25:04PM +0000, Matthew Seaman wrote:
> > Anton Shterenlikht wrote:
> > > I'm thinking of denying ssh access to host from which
> > > I get brute force ssh attacks.
> > >
> > > HOwever, I see in /etc/hosts.allow:
> > >
> > > # Wrapping sshd(8) is not normally a good idea, but if you
> > > # need to do it, here's how
> > > #sshd : .evil.cracker.example.com : deny
> > >
> > > Why is it not a good idea?
> >
> > Probably because ssh is likely to be the only method of login access
> > you have to a remote server, and hosts.allow could conceivably be spoofed
> > into blocking your legitimate access?   In any case, hosts.allow is a
> poor relation to using a real firewall -- it has no access to the lower
> level bits
> > of the networking code, so has to allow a full tcp connection setup
> before it
> > can block anything.  Some daemons allow quite a lot of interaction with
> the
> > remote site when using hosts.allow functionality -- eg. sendmail will
> > apparently go through all of the stages of accepting an incoming e-mail
> from
> > a denied host, right up to the 'MAIL FROM...' section of the SMTP
> transaction
> > where it will respond with a 500 permanent failure error code.
>  [admittedly
> > this does have the benefit that the other side will then immediately give
> up
> > trying to send the message if it's playing by the RFC rules. (Most
> spam-bots
> > don't, of course.)  Otherwise, you'ld get the remote side retrying the
> message
> > several times an hour over the next 5 days before it timed out and gave
> up.
> >
> > > Also, apparently in older ssh there was DenyHosts option,
> > > but no longer in the current version.
> > > Is there a replacement for DenyHOsts?
> > > Or is there a good reason for such option not to be used?
> >
> > I believe you can do something like this:
> >
> > match address 192.168.23.0/24,172.16.0.0/16
> >       ForceCommand /usr/sbin/nologin
> >
> > but this is not foolproof, as it is run via the users' login shell
> > and a sufficiently cunning person can arrange for all sorts of
> interesting
> > things to happen from their shell initialization files...
>
> Matthew, this makes sense
>
> many thanks
> anton
>
> --
> Anton Shterenlikht
> Room 2.6, Queen's Building
> Mech Eng Dept
> Bristol University
> University Walk, Bristol BS8 1TR, UK
> Tel: +44 (0)117 331 5944
> Fax: +44 (0)117 929 4423
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>