RE: [Full-disclosure] SSH Bruteforce blocking script

From: Michael L Benjamin (mike.benjamin_at_clarinet.com.au)
Date: 09/02/05

  • Next message: Michael Stone: "[Full-disclosure] [SECURITY] [DSA 799-1] New webcalendar packages fix remote code execution"
    Date: Fri, 2 Sep 2005 19:33:02 +0800
    To: <full-disclosure@lists.grok.org.uk>
    
    

    -----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/


  • Next message: Michael Stone: "[Full-disclosure] [SECURITY] [DSA 799-1] New webcalendar packages fix remote code execution"

    Relevant Pages

    • Question about RSA1 vs DSA fingerprint
      ... I'm connecting to a solaris 8 box on a university LAN, ... This is the "remote" host. ... cygwin, via Sympatico ADSL, ssh version ...
      (comp.security.ssh)
    • Re: ssh/scp forwarding
      ... > a host on a home LAN behind a firewall. ... > firewall host run Linux and I have logins on both. ... The simplest is to ssh to the firewall, then ssh in from there, which does ... would only be 1 host key associated with that public name or IP. ...
      (comp.os.linux.networking)
    • starting remote server(s) with ssh
      ... How can I start a server on a remote ... ssh -n -x -l user host start_server.sh ... The problem is that this keeps the ssh connection ...
      (SSH)
    • [opensuse] Re: envvar DISPLAY not set on bash invocation fr/sshd
      ... host before calling ssh, as recommended by Sam. ... Your ssh client can connect to:0 fine, ... and she wants to use X clients on the other hosts via ssh X11 forwarding and *not* via remote X. ...
      (SuSE)
    • Re: [opensuse] kicker, gnome-panel through ssh - issues
      ... menus and GUI applications etc. on the remote host *without* a 'vnc-style' ... With the amount of windows I have open, ... doing 'remote stuff' on some host or other *does* ... commandline in an ssh shell. ...
      (SuSE)