Preventive Measures to Block SSH Attacks - Preventive Measures
(Page 2 of 4 )
In order to keep things simple, we’re forced to make the assumption that you are running some sort of Linux distribution. Chances are, this is your operating system on which the SSH daemon is up and running. Throughout this article we will focus on solutions that are compatible with Linux, but if you’re running Windows, then you will also find some gems that you can implement to block attacks.
We will skip introductions; no one is interested in how the secure shell (SSH) protocol became the standard secured protocol for communicating between devices. However, what is truly important is that the de facto standard port of SSH is 22. Everyone knows this. That is why it is not good. For starters, it is more than recommended to set your SSH port to a proprietary custom port. This trick will eliminate ~50% of attacks!
Most brute-forcing tools are specifically programmed to target SSH daemons on port 22. Implementing this tiny trick will eliminate almost half of your attacks. Why? To find the exact port number on which the SSH daemon responds, the attacker must port-scan your server first, and this adds a lot to the complexity.
It is often advised to use ports that are “popular” for other services, especially when they are not required on the particular server. For example, port 110 is a rather ignored port number, since everyone knows POP3 is served through it. Some of the most renowned port-scan utilities can be fooled by this. Like I said earlier, this really makes the job tougher, and it’s just one of the tricks that you can use.
Another often-neglected configuration is forcing SSEv2 protocol type. The first one was really vulnerable. This second “revision” is much more secure, newer, and sports lots of new functions. But due to backward compatibility, lots of SSH daemons are able to serve both types. Chances are no one ever really needs SSEv1 nowadays. You can remove the support for SSEv1. Find your config file: /etc/ssh/sshd_config
Try searching for the line “Protocol 2,1” within that configuration file. It means the main protocol type is SSEv2, but it is able to “fall back” and be compatible with SSEv1. In order to eliminate this, just delete the “,1” part. Leave “Protocol 2." It’s much safer.
Moving on, this next trick is short but effective. You do not need to allow root logins via SSH. This is pointless. Should you be required to administer the server and really need the root permissions, you can log in with your normal user account and become a super-user right away (using the command “su”). In your SSH daemon configuration file, please edit the following line accordingly:
PermitRootLogin yes
It is also worth mentioning the obvious. Please use strong passwords. Most brute-force SSH attacks are dictionary-based at first, and if these fail, that’s when they become pretty random, using proprietary strategies (such as generating every possible combination using just letters, then numbers, and then capitalized letters as well, and finally special characters).
You can also specify just a group of users that are authorized to access SSH.
AllowUsers administrator
Nevertheless, it would be much more sophisticated if you opt for the RSA type of authorization. Instead of passwords, you will use public and private keys. Its main drawback is that you do need to carry your key with you whenever you need to log in from a different host. You can use the following command to generate an RSA key-pair.
ssh-keygen -t rsa
Two kinds of keys are going to be created. The private key will be called id_rsa, while the public key is id_rsa.pub and their locations are specified during the execution of the above command. The public key is used for decryption, and it must be placed on the servers on which this kind of authentication will be used. The private keys are required on the client machines—from which you will try to log in.
And finally, if you opt for this kind of login authorization mechanism, then you also need to edit the SSHd configuration file appropriately. This makes the SSH daemon quite immune to brute-force attacks because generating passwords won’t yield a result. In the following snippet the /authorized_keys is the location of private keys on client PCs.
PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
We’ve presented some basic configuration tips and tricks that are often neglected. Their efficiency is mind-blowing; they just work. These would suffice for every run-of-the-mill server. However, we can go even further. On the next page we will look into scripts that can monitor the logs for “miscellaneous” login attempts and take action.
