Message-ID: <A54C844ED592544A8AA8EF69AAB0401803488B@sbswin001>
Date: Fri Sep  2 12:30:54 2005
From: mike.benjamin at clarinet.com.au (Michael L Benjamin)
Subject: SSH Bruteforce blocking script



-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Pedro
Hugo 
Sent: Friday, 2 September 2005 05:53 PM
To: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] SSH Bruteforce blocking script

Hi,

>I don't want to debate the goodness or badness of the strategy of
>blocking hosts like this in /etc/hosts.deny. It works perfectly for me,
>and most
>likely would for you, so no religious debates thanks. It's effective at
>blocking bruteforce attacks. If a host EXCEEDS a specified number of
>guesses
>during the (configurable) 30 seconds it takes the script to cycle, the
>host is blacklisted.
>

Why are you doing this the wrong way ? You should whitelist hosts,
instead blacklisting them.
Unless you have administrative reasons for such decision, hosts.deny
should be set to ALL:ALL, and you should allow specifically in
hosts.allow.
This way everything is dropped by default. Tcpwrappers should be
configured the same way a firewall is, unless there is something against
it. 
Even if you have customers who need remote access, adding a few ip's is
much better than having open by default.
Kind Regards,
Pedro Hugo


Hi Pedro,

As usual the "wrong way" for some is the right way for others. I do have
administrative reasons for handling it this way. This is why I didn't
want to enter such a debate. If I had a small, simple, internally facing
server, I could do what you propose, but I don't.

In this instance the server is accessible remotely. I need a method of
managing it remotely from anywhere in the world, and SSH2 is my best
method at present. It is not just an internal server.

I can never be sure of the exact IP address I will be logging in with
remotely, as I may have to travel, yet still be available to
troubleshoot anywhere, so I have to leave my options open. I do have a
VPN, but I do not count entirely on that to be available.

The server is also a publicly accessible web-server (among other
things), and attempting to white-list hosts would be futile. 

I have also had to live without the luxury of a fully configured Cisco
PIX (yes I know) firewall due to management decisions and a resource
constraint. I have made them aware of the short-comings. I have taken
measures to handle this, namely software firewalls until the firewall is
hardened.

Other programs also support similar functionality. Portsentry for
example automatically blacklists scanning hosts in this manner. I don't
see that as truly evil behaviour if it suits your needs.

The machine runs iptables which is a Linux firewall ruleset regardless,
so only essential ports are opened. It's the ACTIVITY on port 22 that
I'm acting upon.

I agree it would be wonderful to deny everyone access and open it up as
required, as many security pundits (particularly dedicated firewall
people) would proclaim, but in reality I've discovered, it's not always
feasible for every situation.

If (and when) I get a gateway host to manage my network remotely, it's a
different story, and I can introduce an iptables rule to only allow SSH
access from that host, but until then, this proves useful. That gateway
host will likely have SSH port-knocking active with SSH located on a
non-standard port, but it's not in the budget yet.

Cheers, Mike.

Powered by blists - more mailing lists