From CLUG Wiki

Contents 1 The Problem 2 Solutions 2.1 Reduce the number of open machines 2.2 Move SSH to a non-standard port 2.3 Set up Port Knocking 2.4 Only allow public key connections 2.5 Limit SYNs 2.5.1 Aftermath 2.5.2 Automated log monitoring 3 Maintaining this page 4 Comments

The Problem

It is becoming more and more common to see people brute-force attacking ssh ports.

Here is an example log from one of my servers:

Jun  5 21:31:16 stella sshd[7966]: Did not receive identification string from 72.29.68.65
Jun  5 21:32:27 stella sshd[7969]: Illegal user sun0s from 72.29.68.65
Jun  5 21:32:28 stella sshd[7971]: Illegal user reboot from 72.29.68.65
Jun  5 21:32:30 stella sshd[7973]: Illegal user reboot from 72.29.68.65
Jun  5 21:32:31 stella sshd[7975]: Illegal user ftp from 72.29.68.65
Jun  5 21:32:32 stella sshd[7977]: Illegal user ftp from 72.29.68.65
Jun  5 21:32:33 stella sshd[7979]: Illegal user ftp from 72.29.68.65
etc. for several screen-fulls

Update: Recently, I've seen fullblown dictionary attacks that run for over an hour (>2 000 attempts) :-( This is getting to be a serious problem!

Solutions

There are several options for defense (most of them can be combined to affect you as little as possible).

Reduce the number of open machines

You only need one (or two — for redundancy) ssh connections into a site. Lock down all the other boxes so that they can only be sshed into from the open gateway boxes.

Cons:

• Your gateways can still be scanned.
  • Use other methods to protect them.

Further Improvements:

• Close ssh access totally, and get a physical person on the other end to open it when you phone the site. This isn't convenient, but very secure.
• If you have a static IP address, only allow ssh connections from that address (you can then lock down your box to only 1 account with a 30 character password).

Move SSH to a non-standard port

Easy to do, edit the Port line in your /etc/sshd_config file.

Cons:

• It is irritating to have to remember what port it is on (and add it to your ssh command)
  • You can mitigate this by adding it to your ssh_config file, but this only applies to one source machine.
  • rsync commands become a nightmare... (rsync --rsh "ssh -p 9234" etc.)
• Any bandwidth shaping you have for ssh will probably not take affect.
• Anyone else who needs to access the site will have to do the same.
• Security through obscurity.

Set up Port Knocking

knockd is available as the Debian package knockd.

You could also set up a cgi that opens the ssh port when it receives a certain parameter (over SSL if you are paranoid). It is the same idea.

Cons:

• This complicates any connections.
• If you have a complex knock sequence, you will go mad if you don't have knockc at hand.
• cgi option: You need to run a suid cgi. Be Warned.

Only allow public key connections

Edit your /etc/sshd_config file:

PasswordAuthentication no
UsePAM no

Pros:

• If you always have your laptop on hand it won't affect you.

Cons:

• You can't phone home from an Internet cafe (unless you carry a flash-drive or can remember long sequences of hex digits ;-)
• Poor windows users who use putty now need re-training...

Limit SYNs

There is a nice netfilter extension called ipt_recent. It can allow (say) only one new connection every 60 seconds (and reset the counter if someone tries to break that rule).

Obviously, you will have to modify this to work with your firewall:

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 60 -j DROP
iptables -A INPUT -p tcp --dport ssh --tcp-flags syn,ack,rst syn -m recent --set -j ACCEPT

More documentation

Pros:

• If you do this properly, it won't affect you.

Cons:

• They can still get in one attempt.
  • In my experience this isn't true, because they normally port-scan you first. The port-scan will get them blocked before they have a single login attempt.
• When they get cleverer, they might add longer delays (unlikely).
• You are limited to one connection a minute too.
  • This can be mitigated by adding a knock-style random high port number that when syn'ed removes your IP from the temporary black-hole.
  • Or putting in a rule that bypasses any IPs coming from your ISP (or country).
• This does not work without a patch. ipt_recent doesn't handle jiffie overflow correctly, so it will block all incoming requests for the first five minutes after boot and after jiffie overflows. See https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=415 for more information and a patch.

Aftermath

After using this method, the next attack on a server of mine looked like this:

Jun  6 19:10:16 stella sshd[29357]: Did not receive identification string from 140.116.156.116
Jun  6 19:11:34 stella sshd[29358]: Illegal user aus from 140.116.156.116

That is one port-scan, and one incorrect log-in a little over a minute later.

Automated log monitoring

There are a variety of different options which will automatically monitor the logs for brute force attacks, and block any sites that cause repeated failures for some specified length of time.

Packages:

• fail2ban
• sshguard
• blocksshd
• Others?

Pros:

• Automatic logging and blocking of brute-force attempts
• Approach can easily be extended to cover other open services (ftpd, apache and so forth) (fail2ban has good support for this already)
• Minimal install effort - packages exist for most distributions, and default configurations are usually fairly good.

Cons:

• Rule based approach. Careful attackers can bypass the checks entirely.
• Can block legitimate users (mistyped usernames, mistyped passwords if password authentication is allowed)

Maintaining this page

Feel free to add any comments / methods / anything. These were the options I saw, there are more. Enjoy.

Comments

Not having all details at hand, but one should look into using fail2ban which is now in Debian unstable, I've installed the package on my Debian sarge and it works nicely. It adds rules to the firewall for events you want to block such as too many ssh login attempts. It will lift the ban after a specified time so you can't lock yourself interminably if you type the wrong password a couple of times.