Securing SSH server against bruteforcing

Question

I have a little SVN server, old dell optiplex running debian. I don't have that high demands on my server, because its just a little SVN server... but do want it to be secure.

I just renewed my server to a newer and better optiplex, and started looking a bit into the old server. I took it down after experiencing problems. When I check the logs, its full of brute-force attempts and somehow someone has succeeded to enter my machine. This person created some extra volume called "knarkgosse" with two dirs "root" and "swap1" or something. Don't really know why and what they do, but sure do want to prevent this from happening again. I find this a bit strange though because I change my password ever few months or so, and the passwords are always random letters and numbers put together... not easy to brute-force.

I know I can prevent root from logging in, and use sudoers... and change the SSH port, but what more can I do?

So I have a few questions:

1. How can I prevent logging in for 5 minutes after X amount of incorrect tries. Or slow tries down after each incorrect try?

2. Is there some kind of central blacklist which a server can connect to? A blacklist that keeps track of IP addresses that are "unsafe" and should never be granted access?

3. What more can I do to apply safety to my server?

Like I said earlier, I am running Debian 5 with Apache (www-data user problem?), svn, mysql, php, phpmyadmin, hudson. It is on a home network with port forwarding on 80, 443, 8080, 8180, 23 and 22.

Answer 1

Fail2ban and Port Knocking should address most of your needs.

Changing your SSH port and only allowing Key-based authentication are also recommended.

It can be argued that you may reach a point of diminishing returns in adding additional security measures, but then again, it's up to you to decide when you're "secure enough".

It's also a good idea to disallow root login.

Answer 2

There is no substitute for secure passwords AND key-authentication. That being said, Fail2Ban is a great tool for banning IPs of users who attempt to authenticate too many times. It's also available as a pre-built package for most distros. Be warned, you can accidentally get yourself banned, so make sure you have a recovery white-listed IP too or easy console access...

Fail2Ban has several good examples of how-to configure everything you asked... it does not however, have a universal repository of bad addresses. I don't think there is such a repository anyplace due to the ease of getting another IP (dhcp renew/bot-net attacks/etc...). I would also disable logging in via ssh using common 'administrator' type usernames (root/admin/administrator/sysop/etc..) as these are the most commonly banged on.

Answer 3

I've stopped brute force attacks with:

• fail2ban
• sshd.config:
  • PasswordAuthentication No
  • PermitRootLogin No
• Limiting SSH Connect rates with iptables (http://www.debian-administration.org/articles/187)

Answer 4

There are a number of good suggestions offered here. I respectfully suggest that three things should make this relatively secure:

1. Run the sshd on a random high port. The bots typically only go after port 22 and variations on port 22 like 2222.
2. Disable password based authentication in the sshd config:

UsePAM no

3. Only authenticate with this site via pre-shared SSH key pairs. Man on ssh-keygen to get started with PKI based authentication.

Hope this helps.

Answer 5

I've always been a big fan of CSF/LFD which can block IP addresses of people trying to bruteforce, portscan, and some other options. It's basically a huge perl-wrapper for IP tables, but the configuration file isn't hard to read and the documentation isn't bad.

Answer 6

You could also look into sshguard. I haven't used it but I've heard good things.

Sources:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

"Sshguard monitors servers from their logging activity. When logs convey that someone is doing a Bad Thing, sshguard reacts by blocking he/she/it for a bit. Sshguard has a touchy personality: when a naughty tyke insists disturbing your host, it reacts firmer and firmer."

Answer 7

I have an SSH server connected to the internet on the default port and have never experienced issues..

• tcp_wrappers (ie. hosts.allow hosts.deny) for SSH.. I dont think there is an SSH out there that doesn't have support compiled in it
• iptables this in conjunction with tcp_wrappers eliminated about 99% of my random port scans/bruteforce attempts.. the only problem is you need to know where you'll be connecting from in order to allow those IP/IP ranges... I simply did a lookup on popular providers around my area to see their IP ranges and allow those.. most scans seem to come from far away lands :)
• PermitRootLogin without-password (ie. only RSA/DSA key pairs that are encrypted with a pass-phrase) works wonderfully for automated tasks.. when I login to interact I obviously use my account (regular) which is configured with sudo access
• sudoers
• constant updates.. I update this box frequently with all security/critical updates
• password/passphrase changes
• run chkrootkit every now and again to see if I've got any issues.. (there are several out there that perform this function)

hope it helps!

Answer 8

There is a better way to do this, using fail2ban means you have to add an application, and it operates at the application layer.

If you use iptables it is more efficient as it operates at the network layer and you do not have to install an extra application.

Use the iptables recent module http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

Answer 9

An option (to be used in addition to other security measures) is have sshd listen on a port other than 22. I haven't tried it myself, but have heard it reduces the number of pure brute force attacks by bots.

I must emphasize that this isn't real security, just reduces the number of automated brute force attacks. Too much work to check every port I guess.

Answer 10

Something which isn't mentioned here and really should is limiting access via firewall. This doesn't suit every situation, but if you're connecting to the host from a consistent location with a static IP, you could just block off SSH entirely except to that IP. This will ensure that intruders cannot get in. As I mentioned though, this doesn't always suit every situation, especially if your IP is dynamic and changes often.

Answer 11

DenyHosts, http://denyhosts.sourceforge.net/, is a good project I have had luck with. If you set denyhosts up to synchronize it will download new IPs to add to a ban list that have had to bruteforce other systems using denyhosts. It also expires IPs that have not tried to brute force for a while.

Using public key authentication and disabling password logging is probably the best thing you could do though. Defeats any brute force attacks.

Answer 12

What has been effective for me:

1. As others have said, no root login, PasswordAuthentication set to no (only login w/keys) in sshd_config

2. Only one or two users allowed to log in via ssh and they've got quasi-obscure names that aren't on common brute-force tool user name lists (i.e., not "admin" or "apache" or "web" or "johnny")

3. Restrictive firewall rules (basically, everything's blocked but my service port and ssh). I even restrict ping, to ward off the more crude scans (much to my partner's chagrin).

4. On my web host, I do restrict access to a specific few IP addresses - but this looks like it's not an option for you. Certainly can't do it myself on all of our hosts. You may also want to look into "port-knocking."

5. And my favorite: OSSEC's active response module to block a number of brute force conditions and alerts on other errors, too. It detects x invalid logins in y amount of time, and then blocks (via an iptables firewall-drop command) for a certain period of time. I'm blocking for about 12 hours now for fun. :)

One thing I do here to make sure I don't block too much of the wrong thing, is that in /etc/ossec.conf, I set active response to a high level (that doesn't exist in default configuration) and then go through the sshd_rules.xml and set the rules I want to block to that level and modify thresholds for block vs. alert as needed.

If you're running Apache, you can block stuff that violates apache-rules, too. I don't block on these just because of the NAT issue, I want to think about blocking an entire university or something. :) In addition, you can write custom rules to block on certain conditions in log files, which can be really helpful.