I read the logs from my servers. The amount of time I spend reading log summaries is determined by how important the server is. On the machines that are most important to me I carefully read log summaries and periodically scan the logs for anything that looks unusual.
The amount of time taken is obviously determined by the amount of data in the logs, so it is a benefit to me (in terms of spending less time) to have smaller logs. It’s also a benefit for me (and the other people who depend on those servers) that I spend my time on things that might be important instead of mindless failed attacks.
One thing that I do to reduce the size of my logs is to run sshd on a non-standard port. This requires using a Port directive in the file /etc/ssh/sshd_config and on the client machines I edit /etc/ssh/ssh_config to include a section such as the following to avoid the need to use the “-p” option for ssh (or the “-P” option for scp):
Host some_server
ForwardX11 no
Protocol 2
HostKeyAlgorithms ssh-rsa
Port 1234
Incidentally I disable X11 forwarding explicitly because it’s a dangerous option which usually isn’t needed, and I specify the ssh-rsa algorithm not because it’s any better than the other option of ssh-dsa but because the possibility of having a secondary option that is normally used adds the possibility that a MITM [1] attack can be performed by an attacker who forces the client to use the non-default protocol (thus giving an unknown host key message instead of a message about an invalid key).
Note that these settings can go in /etc/ssh/ssh_config to apply to all users or in ~/.ssh/config to apply to only one user (IE if you aren’t root on the machine in question).
The practice of avoiding attacks by using non-standard ports is not Security by Obscurity in that the security of my systems does not rely on attackers not knowing the port. Attackers can easily scan all ports and discover which one I use. The fact is that any attacker who does so is a more serious threat than all the attackers who scan port 22 and bother someone else when they discover that nothing is listening, such an attacker deserves to have some of my time used to read the log files related to their attempt.
I’m the author of the SSH brute forcer known as SSHatter. It may be evil, but it’s also useful as part of my day job as a security researcher. Your timing is funny as I’ve just (today) been adding arbitrary port support to SSHatter. Your suggestions are very much in line with best practice recommendations.
May I also suggest using AllowUsers to limit access to only legitimate user names. This threw older versions of SSHatter off the scent regarding the success or otherwise of any brute force attempt and might well be effective against other SSH brute forcers.
More importantly, I’d also recommend that where possible, access is restricted by public key. You can actually disable password based authentication entirely with “PasswordAuthentication no” in /etc/ssh/sshd_config. Doing so is the most effective way to prevent a brute force attack.
Hi,
If you use a privileged port (<1024), you eliminate the risk of connecting to a daemon launched by a regular user. This is probably only a concern on shell servers, but perhaps worthwhile nonetheless.
What about active blocking of systems trying to attack. I know this significantly reduced my ssh logs across the board. There are plenty of methods to do this such as iptables rules and script based approaches.
In the end I wrote my own utility because I wanted it to do everything automatically for me. i.e. manage IP tables ban list, white list, auto-expire bans, and synchronise banned IPs across all my hosts running the util. It’s also a bit generic in that you can use modules to monitor any log and ban from those too – I have a module to watch apache logs and used to ban IPs from that as well. It’s GPL’d and at http://jason.mindsocket.com.au/pages/linux/ipb-monitor/
Prior to putting this in place I’d see attacks happen across multiple hosts occur in close proximity or simultaneous (they were all on the same subnet). After implementing this as soon as an IP is banned it’s banned on all.
Non-standard port is a good move too although sometimes that restricts access. We had a requirement that we’d need to access the systems from customer networks with restricted firewalls (perhaps SSH outbound, but not all ports) and from other people’s systems (i.e. key auth not an option).
http://freshmeat.net/projects/sshatter/
Tim: Interesting, I’ll have to try SSHatter out some time. For the benefit of other readers above is the freshmeat URL for SSHatter. Also Tim’s home page is interesting and I suggest you check it out.
Graham: Good point, preventing a non-root user from binding to the port is good practice. But if you rely on it you are doomed. The only safe way to do it is to rely on the public-key authentication built into the ssh protocol (which is why I recommend locking to a single protocol version and encryption algorithm).
Jason: Good idea, that looks like a good tool.