Server Security (3) SSH Defense

0, Preface

A few days ago @SCH's server was blasted by SSH, and there were 90,000 more error logs in just a few days. Only then did he realize that SSH password login is very insecure.

No matter what purpose the server is used for, SSH must be "the place where the dream begins", but with long-term use, SSH is very likely to become a breakthrough for the server to be invaded.

As we all know, SSH login first needs the IP and port of the target server, and then needs to provide login information, namely account and password, or account and key.
Many people only notice that the password login is not safe, but ignore the problem of the default SSH account. Similarly, many people only know how to modify the SSH port, but they don't know how to prevent the SSH port from being scanned at all.

Therefore, this article will talk about the best practices of SSH security from the four aspects mentioned above.

1. Hide source IP

Seeing this title, you may be at a loss. The domain name must be resolved to the IP to take effect. How can the IP not be exposed?

In fact, you only need to resolve the domain name to an IP other than the source server, and the transit server will pass the traffic back to the source server, so it can be realized. This is the CDN that many people use.

If there is a record, you can directly access the global CDN of the cloud vendor, if not, you can refer to

Server security (2) internal and external network defense
https://blog.tsinbei.com/archives/140/

Use the reverse proxy method to make a self-made CDN with only a single IP.

However, this method has a flaw. The IP of the server that exposes the external network port cannot be hidden, and it also needs to use SSH connection. Isn’t it easy to expose the SSH port?

Therefore, a springboard machine can be used.

2, springboard machine

As the name suggests, the springboard machine is a transit server, through which the SSH connection is first transmitted to the source server. Is it a bit like the reverse proxy mentioned earlier?

First, you need to configure the firewall on the source server to only allow the springboard machine to access the SSH port of the source server:

The same is true for cloud server security group settings.

Then, set up port forwarding on the springboard:

The custom port here must be safe enough, for example, 22 cannot be used, and it is best if it is a five-digit port.

After that, you can only access the source server SSH through springboard machine IP: custom port. The springboard machine can be the previous source server, so that the IP will not be exposed. In this way, if the port scan is performed on the website, only ports 80 and 443 can be scanned.

Pagoda panels can also use this method. However, when port forwarding, you need to pay attention not to conflict with existing ports, otherwise the original port will not be able to connect.

3. Change port

I highly recommend changing the default SSH port in the first place. Moreover, the larger the port number, the lower the probability of being scanned. Others are commonplace, so I won't repeat them here.

4. Change user

The default user of most Linux distributions is root, Ubuntu is ubuntu, and the server purchased in Azure is azure, do you think that if you don’t use root, you will be safe? Big mistake, the usernames listed above are the hardest hit areas to be scanned and should be avoided as much as possible.

Here we take root as an example:

The default is yes, that is, no limit;
The best suggestion is to directly change it to no, which means that login is prohibited;
If you have to use root to log in, be sure to change it to without-password, that is, you can only log in with the key;
If there is software (such as rsyncd) that needs to be connected through SSH, it can be changed to forced-commands-only, that is, only these software are allowed to connect to SSH and perform operations, and the connection using the SSH client will be directly rejected.

My suggestion is to use a custom account, such as the pinyin of your own name, and then develop the habit of permission isolation, and add sudo if necessary, so that 90% of misoperations can be eliminated.

If you must use root to operate, why not execute sudo -i after logging in to your own account.

5. Password

Passwords are actually commonplace, but there are some issues that need to be emphasized.

The principle of passwords is that short passwords are better than meaningless long passwords, passwords are some characters or words with practical meaning, such as This-is-my-password!, and meaningless long passwords are generally random characters String, such as m7Hnl0Hwb5McKxiem1dLxjlw1, it seems that the latter is more secure, because it is more complicated, and then it is so complicated that we cannot remember it with our heads, and we must record it on something. In case this thing is leaked, this "safe" password will also It is no longer safe.

Therefore, it is recommended that you choose an easy-to-use password, which is meaningful to you, so that it is easy to remember; complex, so that it is safe. For example, "Zhang San" can be called:

My-teacher-is-Bilibili@Luo-Xiang~