denying spam hosts ssh access - good idea?

[Anton Shterenlikht]

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