denying spam hosts ssh access - good idea?

Anton Shterenlikht mexas at
Mon Jan 11 15:59:55 UTC 2010

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 : : 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,
> 	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 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

More information about the freebsd-questions mailing list