OpenBSD Journal

Several approaches to defending against sshd brute force attacks

Contributed by grey on from the mind over brute force dept.

There has been a really interesting discussion on misc@ of late titled "Stopping SSH dictionary attacks." Undoubtedly this was spawned by the appearance of an ssh brute forcing tool, which began circulating in the wild earlier in the year. However, in this discussion there have been a number of proposed defensive techniques ranging from having sshd listen on a different port and using strong password generation tools to scripts and patches such as the following.

Juan J. Martinez's ssh-blocker script

Wolfgang S. Rupprecht's sshd configuration recommendations.

Ingo Schwarze offered up some patches he has made to sshd and pfctl here.

And lastly, Jose Nazario pointed out timelox from br1an (of Stephanie and metawire.org). From the README: "Timelox is code to be used in network services to help fight brute force attacks." Keeping it relevant to the discussions of ssh brute force attack defenses, br1an has included a patch specifically for sshd.

Naturally, none of these patches or recommendations are official, but our readers may find some of them useful.

(Comments are closed)

Comments

  1. By James (67.167.226.90) on

    Without reading the mailing list thread, I've got to wonder if someone really wouldn't notice say 200 failed login attempts for a particular user without wondering what's up...

    Comments

    1. By tedu (64.173.147.27) on

      maybe they're sleeping? or maybe it's new year's eve and they're gonna take some time off?

      Comments

      1. By siltech @ RAC (59.93.35.238) on

        What about piping the auth messages from syslog to a fifo and using a permanent script to parse it and provide iptables or tcprules based blocks ?

        see the doc here
        http://www.saturninfolabs.com/docs/sshd-logwatch.html

    2. By almeida (66.31.180.15) on

      On my server at least, they happen in bursts and only continue for a couple of minutes at a time. Tthe individual IPs usually don't appear again. I've been manually adding them to a blacklist while I've been working on some scripts to automate the process, but it seems mostly pointless. Even if I had the thing running from cron every couple of minutes, I'd miss most of the hosts because they try for such a short period of time. Because they never try again, I'm not really gaining anything. Here's the latest one from my server.

      Dec 31 12:45:59 headless sshd[7885]: Failed password for nobody from 83.17.209.58 port 3005 ssh2
      ...
      Dec 31 12:51:13 headless sshd[24499]: Failed password for root from 83.17.209.58 port 1566 ssh2

      This guy tried one password each for apache, cosmin, cyrus, horde, iceuser, jane, matt, mysql, nobody, operator, pamela, rolo, www, www-data, and wwwrun; two passwords each for adm, irc, and patrick; four passwords for test; and 21 passwords for root.

      Comments

      1. By Anonymous Coward (24.201.62.155) on

        LOL, what an idiot he is. Why not just report him to his ISP, then maybe his parents will halt his internet usage.

        Comments

        1. By almeida (66.31.180.15) on

          Because he's in Poland. The others are from Korea mostly. I doubt I'd get anywhere by complaining to the abuse department.

          Comments

          1. By Anonymous Coward (81.26.253.124) on

            What the fuck do you have against Polish people ?!

          2. By Janusz Gumkowski (158.75.1.33) on

            > Because he's in Poland. [...]
            > I doubt I'd get anywhere by complaining to the abuse department.

            You may.
            This IP belongs to the largest internet provider in Poland. Being constantly accused of monopolistic practices, they're currently paying greater and greater attention to criticizm and public relations.
            After lots of bad press, they also started reacting properly to attacks that their customers are launching against other networks. Like in your case.

            It's a DSL line, IP is given statically. Provided you are informative enough, they won't have problems tracking those kiddies down.

            Greetings from Poland :)

      2. By Joel (81.172.173.155) joel@acc.umu.se on

        Theres a program called swatch that does this for you, it's in packages.

  2. By almeida (66.31.180.15) on

    There was also a discussion on comp.unix.bsd.openbsd.misc (search for "ssh hackers" if that link doesn't work). In addition to having sshd listen on different ports, the suggestions that came out of it were:

    My suggestion was to modify the scripts Daniel Hartmeier uses to blacklist misbehaving crawlers.

    Nicholas Marriott suggested using his program, Log file monitor. This one looks pretty cool.

    And Daniel himself pointed to a new rate-limiting feature in -current. This would block hosts that exceed 10 connections per 60 seconds.

      pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
        keep state (max-src-conn-rate 10/60, overload )
  block in on $ext_if proto tcp from  to $ext_if port ssh

    Comments

    1. By almeida (66.31.180.15) on

      Forgot to convert the brackets to HTML... 
        pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
        keep state (max-src-conn-rate 10/60, overload <scanners>)
  block in on $ext_if proto tcp from <scanners> to $ext_if port ssh

    2. By Tib (66.80.174.214) archerfish@gmail.com on

      -current is referring to what.. ssh? Also - the code referred to is useful, but where does one find it. Post or pre 'make'?

  3. By Anonymous Coward (85.72.60.14) on

    On Linux I use port knocking. Not the safestt techniqes around, but safes me from most headaches. Take a look here : http://www.l0t3k.org/security/tools/portknocking/

  4. By Chris Laverdure (69.156.179.171) on

    Actually, I was thinking about something. I have remote root logins disabled (something I think everyone should do), and every such attack I've seen tries to brute force root at least once.

    I have a table called /etc/pf-enemies, and in it are IPs and ranges of people that I want barred from my server. I was thinking about writing a program that analized authlog, and if it saw a remote root attempt it automatically put the IP in that table and refreshed the PF config.

    Comments

    1. By jakari (216.24.217.3) on

      Strangely, I actually played with this last week without reading the misc discussion - just kept seeing more and more ssh attempts on the consoles.

      My half-assed attempt at doing something about it:
      http://www.bithose.com/jakari/blog/index.cgi/2004/12/30#obsd_autoblacklist

      Not entirely novel but it was pretty easy to do.
      Probably would have been easier to just move ssh to a different port. ;)

    2. By WK (66.24.0.248) on

      I protect SSH logins for 2 reasons. First, I layer security and don't want to take a chance on a lucky attempt. Second, I view my server as a resource -- abuse it and get denied.

      I've been using logsurfer, and in addition to providing warnings for unusual activities, I use it to block hosts that attempt the following more than a few times within a certain time limit:

      - root SSH logins
      - SSH logins for invalid users
      - failed SSH password attempts

      It's an easy setup. When logsurfer detects these actions, it runs a script that adds the IP (via sudo) to a pf table, and it logs the addition. (The IP is actually added to to a file that is then loaded to the pf table.)

      Since I set this up, activity in my authlog has dropped off dramatically. For those interested, there's a good collection of logsurfer resources at http://www.crypt.gen.nz/logsurfer/

      I do a couple of other things to keep SSH secure. Mail and daemon users belong to classes that have no login, and SSH users have UID's that are not common.

  5. By SH (82.182.103.172) on

    As for strong password generation, one can use www.diceware.com approach if you have some dices available....

  6. By Paul (81.168.250.11) biesdi@gmail.com on http://zrytyberet.org

    I wrote a short instruction about protecting more then bruteforce on ssh
    without changing ssh/auth.c or some special timeouts or shells.

    http://81.168.250.31/ll/tabele.howto.en
    user: pf password: pfpf

    p.s.
    happy new year

  7. By djm@ (203.217.30.86) on

    If your passwords can be guessed by an exhaustive search, then you are an idiot to begin with. Even relatively short (7 char) passwords are well beyond feasible attack if they are reasonably random. People figured this stuff out 20+ years ago, and it is ridiculous that people need to be reminded.

    Comments

    1. By almeida (66.31.180.15) on

      All passwords can be guessed by an exhaustive search. That's the whole point: you exhaust all possibilities until you arrive at the right one.

      Comments

      1. By tedu (67.124.88.142) on

        that's true, but a few dozen guesses is hardly exhaustive.

      2. By djm@ (203.217.30.86) on

        Go and calculate how long it would take to exhaust a random 7-char password at a guessing rate that one could achieve via remote ssh connection (e.g. <32/sec). Exhaustive *local* search of 8-char DES hashed passwords is out of most people's capabilities.

        Comments

        1. By almeida (66.31.180.15) on

          I know how the math works out, but you said, "If your passwords can be guessed by an exhaustive search, then you are an idiot to begin with," which simply isn't true. If you want to qualify you statement even further by saying "via remote ssh" etc, then fine, but you didn't say that.

          Regardless, we're not worried about <i>our</i> passwords. We're worried about jane, matt, pamela, and patrick, who might not pick very good passwords. The point of this whole thing was coming up with another line of defense to keep hackers away. Saying people with bad passwords are idiots might be true, but it doesn't make your box more secure.

          Comments

          1. By djm@ (203.217.30.86) on

            I didn't it necessary to remind anyone of the context when the top of the page screams "Several approaches to defending against sshd brute force attacks".

            Your users shouldn't be permitted (by either policy or technology) to choose bad passwords. If you are responsible for systems and policies that allow trivially guessable passwords, then *you* are the idiot.

            The current generation of ssh worms doesn't seem to do remote brute force guessing. It seems to try a small dictionary of default accounts, possibly supplemented with locally cracked passwords.

  8. By Sven Beukenex (80.126.65.121) on

    I personally only allow ssh connections from a fixed set of hosts. I know this is not a feasible solution with a large number of users and it's a pain in the proverbial backside with regards to dynamic IPs. If this would become unmanagable I guess I'd go with Daniels suggestions (connection limiting and/or blacklisting).

  9. By Anonymous Coward (68.202.41.228) on

    If you just want to filter out the noise in your logfiles, change sshd's port assignment. Since doing that I haven't had a single bad password authentication attempt (before I would get at least 30-50 per day). And as somebody else mentioned, most of these attempts seem to come from Korea, China, and other places where nobody cares about abuse for the most part, so emailing NIC contacts is useless.

  10. By Nikademus (212.88.244.240) on

    On my "most secure boxes" I changed ssh port, put a public key only authentication, and set up a 2 connections/min on the firewall.. Although I doubt someone would ever pass the key authentication even if the port was 22 and connections were unlimited.

    So I think the solution is don't use a password only...

  11. By jkm (217.215.66.75) joakim@aronius.com on

    I got this on misc a few weeks ago, blocks Linux hosts that tries to connect to sshd, works great.

    # Don't allow Linux hosts to connect to the sshd.
    block drop in log on $ext_if proto { tcp, udp } from any os Linux to any port ssh label "Block ssh from Linux hosts"

  12. Comments

    1. By byte (192.94.73.35) on

      Some people consider 1024 bit keys too weak and that's the maximum DSA allows.

      Comments

      1. By RC (4.8.17.8) on

        > Some people consider 1024 bit keys too weak

        Fair enough...


        > and that's the maximum DSA allows.

        Not true. 1024-bits may be the maximum in the specs, but most programs have implimented workarounds for that. ssh-keygen has no problem generating a 2048 or 4096-bit DSA key (I just created one of each).

    2. By Anonymous Coward (81.26.253.124) on

      Read the PuTTY docs for a good reason why RSA is better.

  13. By max (207.38.217.7) on www.neuropunks.org

    Hello a little ugly perl script i wrote (for FreeBSD originally) to look at daily security report sent via email and notify the email adress for abuse/owner of the ip block about their possibly compromised machine. Now, since this is quite ugly, it will send out one email per attemt, so you think about that. But I felt compelled to write it anyway, as a semi-vigilante response to general internet carelessness. I call it from procmail to parse the periodic(8) security report. www.neuropunks.org/~max/parse_ssh.pl

  14. By Anonymous Coward (134.178.63.3) on

    My strategy is to first realise that the weakest link isn't a brute force attack managing to randomly guess the password. Rather, the weakest link is users writing passwords down, telling other people the password etc. Therefore, I have implemented the following login policy: 1) All remote logins must be via SSH, and must use skey one time passwords. This is a bit of a nuisance, but at least I know that if a password is compromised by someone looking over my shoulder, they won't be able to use it again. I keep a list of the next few passwords on a piece of paper in my wallet. I reckon this is still more secure than having a static password, because if anyone finds the list, they won't know what machine or user the passwords are for. It also rules out the possibility of passwords captured over insecure networks, or by key stroke logging, being reused. 2) Remote root logins are disabled. 3) Only specified users are allowed to log in remotely (this prevents a large portion of the brute force attacks, which use random user names in their login attempts). 4) Only one "normal" user is in the wheel group, and logins to this account are monitored carefully. Therefore, even if a normal user account is broken in to, hopefully the root account will still be safe (because only people in wheel can su to root). Aside from that, it is necessary to accept that break ins might occur from time to time (hopefully very rarely), and it is wise to have good backups in case it is necessary to rebulid the system.

  15. By Anonymous Coward (69.3.118.48) on

    Passwords have been a problem for a long long time. Using RSA keys (perhaps also with passwords on them) is a great idea. Another great idea is using various key generators. I have wanted to see support for Cryptocards (http://www.cryptocard.com) in OpenSSH for a long long time. These really make sense. Even if you use one to log in from an unsecured terminal, at least your password cannot be compromised, because there is no password. Btw, I have no association with Cryptocard; I'm just someone who wishes he could use Cryptocard to access his box. It's all great and wonderful having security audits, etc, but if you can't access the box in a secure way... well, all the other stuff might do no good. Would it be possible to implement Cryptocard support through the pluggable authentication modules?

  16. By Saad, Zamzuri (218.111.71.17) zamzuri@gmail.com on http://www.hackstreet.com

    How to install BFD (Brute Force Detection) What is BFD (Brute Force Detection)? BFD is a modular shell script for parsing applicable logs and checking for authentication failures. There is not much complexity or detail to BFD yet and likewise it is very straight-forward in its installation, configuration and usage. The reason behind BFD is very simple; the fact there is little to no authentication and brute force auditing programs in the linux community that work in conjunction with a firewall or real-time facility to place bans. BFD is available at: http://www.rfxnetworks.com/bfd.php This guide will show you how to install and configure BFD to protect your system from brute force hack attempts. Requirements: - You MUST have APF Firewall Installed before installing BFD - it works with APF and requires some APF files to operate. - Root SSH access to your server Lets begin! Login to your server through SSH and su to the root user. 1. cd /root/downloads or another temporary folder where you store your files. 2. wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz 3. tar -xvzf bfd-current.tar.gz 4. cd bfd-0.2 5. Run the install file: ./install.sh You will receive a message saying it has been installed .: BFD installed Install path: /usr/local/bfd Config path: /usr/local/bfd/conf.bfd Executable path: /usr/local/sbin/bfd 6. Lets edit the configuration file: pico /usr/local/bfd/conf.bfd 7. Enable brute force hack attempt alerts: Find: ALERT_USR="0" CHANGE TO: ALERT_USR="1" Find: EMAIL_USR="root" CHANGE TO: EMAIL_USR="your@yourdomain.com" Save the changes: Ctrl+X then Y 8. Prevent locking yourself out! pico -w /usr/local/bfd/ignore.hosts and add your own trusted IPs Eg: 192.168.1.1 Save the changes: Ctrl+X then Y BFD uses APF' cli insert feature and as such will override any allow_hosts.rules entries users have in-place. So be sure to add your trusted ip addresses to the ignore file to prevent locking yourself out. 9. Run the program! Happy Protecting dude!! :) /usr/local/sbin/bfd -s

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]