Port 22 SSH port or not
I stumbled upon a discussion three months ago about the need to transfer the SSH port. A lot of participants in the discussion are convinced that there is no need to transfer the port to a non-standard port.
It is enough to switch to key authorization and deliver Fail2ban and this will already be a guarantee of security. Unfortunately, we live in the real and the world, which is constantly changing and the proposed security measures are no longer always sufficient.
Let's take a look - key authorization has left two relatively secure ssh keys, these are RSA-4096 and ED25519, DSA keys are no longer included in recent versions of OpenSSH. It should take into account the presence on the Internet of some doubts about the reliability of ED25519, Google to help, if you are interested.
In addition to keys, a sufficiently long passphrase for your keys from random characters in different case and numbers, as a minimum, is recommended.
Brute force attacks - let's briefly see what happens if your host is attacked purposefully.
This collection of information is not always reflected in your logs, for example, port scanning can go without a connection. Fail2ban is useless here, it works only on the records in the logs. At the first stage, the installed protection systems can also be monitored. For example, the number of authorization attempts before blocking is determined, the blocking time.
For hacking, botnets with thousands of addresses are used and scanning in a simple case goes to bypass the default Fail2ban settings from hundreds and thousands of addresses, with a serious scan taking into account the settings of the victim protection system. Fail2Ban is also useless here, especially if SSH is on port 22 and the Fail2Ban settings are defaulted.
I have all ports closed on the outer perimeter of one of the servers, but in a couple of days up to several thousand hosts are dialing up that are trying to establish a connection to standard ports. Moreover, the scan is taking into account the possible protection, packets from one address are, as a rule, with an interval of several minutes.
Of course, Fail2ban can be effective to protect some other services with non-standard settings for your hosts and services.
For some reason, it always seems that the second stage is the most dangerous, in fact, at the first stage, possible vulnerabilities on the host are looked for; they can be much more dangerous than a simple Brute force SSH. Why break SSH when there is an open door with a vulnerability nearby.
Regarding the change of the standard port, there is a fresh overview of BestPractic security for SSH , there the change of the standard port is 8 points, authorization by keys is the first point and the installation of Fail2ban or analogs 10 points. Top 20 OpenSSH Server Best Security Practices .
Switching the SSH port to non-standard allows you to use standard ports as a trap to track scanning attempts, and block the received IP addresses for a long time and on all ports, this is item 11, in the BestPractic article. Naturally, you need to specify white addresses in order not to get a random blocking - these are 7 and 8 points in the BestPractic article.
In this way, we increase the cost of collecting information about our system. Information on open ports will cost several thousand IP addresses or months to scan our system. If my SSH port is unknown to a potential hacker, even if a vulnerability appears, it will not be able to use it.
It is enough to switch to key authorization and deliver Fail2ban and this will already be a guarantee of security. Unfortunately, we live in the real and the world, which is constantly changing and the proposed security measures are no longer always sufficient.
Let's take a look - key authorization has left two relatively secure ssh keys, these are RSA-4096 and ED25519, DSA keys are no longer included in recent versions of OpenSSH. It should take into account the presence on the Internet of some doubts about the reliability of ED25519, Google to help, if you are interested.
In addition to keys, a sufficiently long passphrase for your keys from random characters in different case and numbers, as a minimum, is recommended.
Brute force attacks - let's briefly see what happens if your host is attacked purposefully.
Stage 1 - collecting information about the host, including open ports
This collection of information is not always reflected in your logs, for example, port scanning can go without a connection. Fail2ban is useless here, it works only on the records in the logs. At the first stage, the installed protection systems can also be monitored. For example, the number of authorization attempts before blocking is determined, the blocking time.
Stage 2 - attempts to access the system through SSH hacking
For hacking, botnets with thousands of addresses are used and scanning in a simple case goes to bypass the default Fail2ban settings from hundreds and thousands of addresses, with a serious scan taking into account the settings of the victim protection system. Fail2Ban is also useless here, especially if SSH is on port 22 and the Fail2Ban settings are defaulted.
I have all ports closed on the outer perimeter of one of the servers, but in a couple of days up to several thousand hosts are dialing up that are trying to establish a connection to standard ports. Moreover, the scan is taking into account the possible protection, packets from one address are, as a rule, with an interval of several minutes.
Of course, Fail2ban can be effective to protect some other services with non-standard settings for your hosts and services.
For some reason, it always seems that the second stage is the most dangerous, in fact, at the first stage, possible vulnerabilities on the host are looked for; they can be much more dangerous than a simple Brute force SSH. Why break SSH when there is an open door with a vulnerability nearby.
Regarding the change of the standard port, there is a fresh overview of BestPractic security for SSH , there the change of the standard port is 8 points, authorization by keys is the first point and the installation of Fail2ban or analogs 10 points. Top 20 OpenSSH Server Best Security Practices .
Switching the SSH port to non-standard allows you to use standard ports as a trap to track scanning attempts, and block the received IP addresses for a long time and on all ports, this is item 11, in the BestPractic article. Naturally, you need to specify white addresses in order not to get a random blocking - these are 7 and 8 points in the BestPractic article.
In this way, we increase the cost of collecting information about our system. Information on open ports will cost several thousand IP addresses or months to scan our system. If my SSH port is unknown to a potential hacker, even if a vulnerability appears, it will not be able to use it.