Full Disclosure mailing list archives
RE: SSH Bruteforce blocking script
From: "Michael L Benjamin" <mike.benjamin () clarinet com au>
Date: Fri, 2 Sep 2005 19:33:02 +0800
-----Original Message----- From: full-disclosure-bounces () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of Pedro Hugo Sent: Friday, 2 September 2005 05:53 PM To: full-disclosure () lists 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- SSH Bruteforce blocking script Michael L Benjamin (Sep 02)
- Re: SSH Bruteforce blocking script Alejandro Barrera (Sep 02)
- Re: SSH Bruteforce blocking script Christoph Moench-Tegeder (Sep 02)
- Re: SSH Bruteforce blocking script Gerald Holl (Sep 03)
- <Possible follow-ups>
- RE: SSH Bruteforce blocking script Michael L Benjamin (Sep 02)
- RE: SSH Bruteforce blocking script Michael L Benjamin (Sep 02)
- RE: SSH Bruteforce blocking script Michael L Benjamin (Sep 02)
- Re: SSH Bruteforce blocking script Christoph Moench-Tegeder (Sep 02)
- Re: SSH Bruteforce blocking script Pedro Hugo (Sep 02)
- RE: SSH Bruteforce blocking script Michael L Benjamin (Sep 02)
- Re: SSH Bruteforce blocking script miah (Sep 02)
- RE: SSH Bruteforce blocking script Michael L Benjamin (Sep 04)
- Re: SSH Bruteforce blocking script miah (Sep 06)
- RE: SSH Bruteforce blocking script Ron DuFresne (Sep 06)
- FW: SSH Bruteforce blocking script Michael L Benjamin (Sep 04)
- FW: SSH Bruteforce blocking script Michael L Benjamin (Sep 04)
- Re: FW: SSH Bruteforce blocking script Valdis . Kletnieks (Sep 04)