
Ask HN: Do you worry about ssh brute force attacks on your servers? - bengtan
Server logs on my internet facing servers indicate people brute force attack ssh by guessing passwords. This happens about an average of one person (or host) per day who tries for several hours and then they wander off to (presumably) try another target.<p>I realise there are things that can defend against this (ie. IP access control, moving ssh to a non-standard port number, root login disallowed etc.) and that, statistically, they will not guess a password correctly anytime soon. I'm not interested in discussion of these techniques (though others may be).<p>However, I think, psychologically, it can be a bit unpleasant knowing that people are attacking your servers. Do you guys worry about this? Even when knowing the probability of a successful guess is negligible?
======
noonespecial
On most of my servers that allow ssh, I use keys only and disable passwords. I
don't worry that my passwords will be guessed anytime soon as they are all
long and random, but I very much like that my logs don't fill with that crap.

------
semanticist
One of the first things I do when setting up a new VM is install DenyHosts:

<http://denyhosts.sourceforge.net/>

The out of the box config options are pretty decent, giving a few attempts to
most accounts but only one wrong password for root before blocking the IP
address.

I have it send email notifications to my support ticket tracking system, which
automatically sorts them so I can see how heavily I'm being attacked at any
given time, or if one VM in particular is being targeted. (One VM has been a
particular target over the holidays, so I just turned off SSH entirely and
access it using the Xen console for now.)

The down side of having a good understanding of how much you're under attack
is that it is a bit disturbing. In reality, I know that I could just leave SSH
running on all my VMs, but turning it off when someone's targeting one of them
reduces the flow of scary emails. The most disturbing thing is how many
machines these guys must have already compromised, since as soon as you block
one IP address another steps in.

------
bensummers
I use ssh on a non-standard port, not for security, but to avoid all the
annoying attempts in the logs.

I use ssh keys only. I've disabled the use of passwords for any account other
than root on the console, and for that, I use a very long random password
which is stored very carefully, encrypted with a long passphrase. This is only
needed in emergencies.

Be careful to protect your ssh keys (long passphrases and ssh-agent), and it's
probably a good idea to use hashes in your known_hosts file rather than
addresses so malware can't find all the hosts you can access.

~~~
kngspook
Yeah, my setup was already pretty secure; and I ended up just switching to a
non-standard port for cleaner logs.

But since then I haven't spotted a single brute-force attempt on any of my
boxes...

------
telemachos
There are good ways to prevent getting rooted, as you say, but I know exactly
what you mean. The first time I set up a virtual server, someone began a
dedicated brute-force, dictionary attack against ssh within 30 minutes. The
attack wasn't particularly aimed at me, of course, since I had an empty
virtual machine on an ip number that I had been given only a half hour
earlier. Still, it's a bizarre thing to watch the logs and see some machine
hammering at your door (even if you believe the door to be very solid). The
attack went on for over 12 hours, for whatever that's worth. It felt damn
scary the first time - even though I knew that I had absolutely nothing of
consequence in the server yet (brand-spanking new) and that I could wipe the
whole setup and start fresh with nearly zero effort. Nevertheless, it was
creepy. It's sort of like being in a horror movie: you simply watch and listen
as the monster pounds on the door. (Of course, you have a lot more options
than the twits in the movies, and your monster is usually either (1) a pimply-
faced kid in suburbia or (2) a cyber-criminal who doesn't much care where he
gets in and happily moves onto the next ip in short order. But the initial
_feeling_ was like that.)

Like most of the other posters, I ended up taking the following steps to cut
down on the problem: (1) disable root login at all, (2) switch sshd from port
22 to another, random port for listening (that alone cut the attacks way, way
down), (3) disable all password based logins; only key-based logins work now,
(4) limit the users who could login remotely at all to a very small group (you
can create a group just for this purpose, enroll two or three admins and edit
your sshd_config file to allow only members of that group to login at all),
(5) use rate-limiting in iptables to freeze out any attacking ip after two or
three failed attempts in a minute.

A link with lots of detailed methods to handle brute force attacks and their
pros and cons, in case anybody wants it: <http://la-
samhna.de/library/brutessh.html>

------
gcr
fail2ban solves all our problems. We only get about 5 hits a day total on each
host now.

<http://www.fail2ban.org/wiki/index.php/Main_Page>

~~~
bengtan
Thank you for pointing me to this. Looks very useful.

------
yourabi
Yes - three simple things to mitigate risk: 1)Run ssh on non-standard port
2)Disable root login PermitRootLogin No 3) Only allow specific users ssh acces
via AllowUsers directive

------
javert
"On the back of a napkin, so to speak, and with a number of reasonable
assumptions, I calculated that it would take 2.2098499729010715e+28 years to
do so, with a 1,000,000-strong botnet constantly hammering away." (That's with
a 20-char root pwd. Just make your root pwd strong.)

[1] [http://www.mollison.us/blog/2009/10/18/how-hard-is-it-to-
bru...](http://www.mollison.us/blog/2009/10/18/how-hard-is-it-to-brute-force-
a-root-password-over-ssh/)

~~~
dlsspy
1\. Disable root login. 2\. Disable passwords.

There's no excuse for root logins and passwords are harder to manage and less
secure.

~~~
gtani
I also limit port 22 or whatever to, say, 3 tries a minute (iptables) just so
you don't look like low-hanging fruit

something like this

[http://jonsbraindump.blogspot.com/2007/09/iptables-rules-
to-...](http://jonsbraindump.blogspot.com/2007/09/iptables-rules-to-lock-out-
multiple.html)

~~~
gtani
i just saw this on HN, a SSH blacklist

<http://isc.sans.org/diary.html?storyid=7855>

~~~
scumola
I use the ssh blacklist utility and it works pretty well. Although it opens up
the IPs after 4 days (default), which I don't really liked, so I pumped that
up to 14 days which seems to work nicely.

------
axod
You can use iptables to rate limit connections:

    
    
      -N SSH_RECENT
      -A INPUT -m state --state NEW -p tcp --dport 22 -j SSH_RECENT
      -A SSH_RECENT -m recent --set --name SSH
      -A SSH_RECENT -m recent --update --seconds 60 --hitcount 3 --name SSH -j DROP

------
rphlx
> moving ssh to a non-standard port number

+1. If/when there's an sshd remote exploit/worm, it will probably only scan
port 22.

"AllowUsers" is good too.

And, port knocking if you don't mind the hassle.

------
kunthar
ossec hids got active response and other cool helpers.

------
mschy
I started running ssh on port 443 when public ssh is required, because it
works more reliably when traveling. A nice side effect is that it also avoids
the Rumplestiltskin attacks.

That said, my preferred solution is openvpn.

