Interesting article from SecurityFocus
Malicious SSH login attempts have been appearing in some administrators’ logs for several years. This article revisits the use of honeypots to analyze malicious SSH login attempts and see what can be learned about this activity. The article then offers recommendations on how to secure one’s system against these attacks.
Some raccomandations are given:
There are a number of simple methods to protect against these attacks. The most obvious way is to turn off the daemon service, which on many systems is installed by default. If the computer system runs as a desktop machine, there is likely no need for remote access via SSH to log into the machine. If this is not an option, there are numerous other options.
- Use the /etc/hosts.allow and /etc/hosts.deny files found on most Unix and Linux system to restrict daemon access to specific hosts.
- Install a firewall to restrict access to the SSH server from only designated machines and networks. This works particularly well if administration of a machine from an internal network necessitates remote access to that machine.
- Restrict the SSH server to only authenticate particular users or groups.
- Move the listening port of the SSH server from 22 to some other unused port. While this would not prevent attackers from connecting to the server and start guessing password, it will significantly reduce the likelihood of finding your SSH daemon, as attackers use standard SSH clients and attack tools that assume the SSH server is running on its standard port 22.
- Use an alternate authentication method besides simple passwords. More on this below. If this is not an option, ensure that a strong, complex password or passphrase is used.
SSH provides an alternate authentication method which successfully mitigates password guessing attacks. This authentication method is based on cryptographic keys, or so-called private key and public key. The public key is placed onto the server and acts as a custom lock for access to your account. This lock can only be opened with the corresponding private key. Once you provide this key, you gain access. Password guessing attacks would fail as attackers cannot guess or generate such a private key. All modern SSH servers are configured by default to support this authentication method. However, they usually fail back to password-based authentication in case the incorrect private key is provided, opening the door for password guessing attacks once again. The server needs to instead be configured to accept key-based authentication only for this mitigation strategy to be successful.