Effective and simple Web server security measures "Linux"

This is the final installment of "Effective and Easy Web Server Security Measures". The main character this time is Linux, that is, OS security measures.

To date, 70% of web services around the world use Linux. This means that Linux is already widely used. Increasing the number of users means that vulnerabilities in Linux will be discovered sooner.

Indeed, in the last five years or so, it's true that the Linux kernel has become commonplace to be exposed to serious CVE vulnerabilities.

But I don't think this is a bad thing. Since Linux itself is open source, any CVE vulnerabilities found will be fixed immediately. I think it is an embodiment of lively ecology.

To keep your Linux server safe, we must maintain good security habits ourselves.

Regular system updates

You can avoid the latest vulnerabilities by updating the Linux kernel and packages frequently.

I usually use a stable version of a Linux distro that assumes stability (Ubuntu LTS, Debian Stable, CentOS, etc.), the kernel only updates small versions, and there is no direct upgrade to the latest kernel, so the kernel You don't have to worry about problems such as bugs caused by updating the kernel or compatibility issues.

System or package update:

Debian/Ubuntu

  apt-get update && apt-get upgrade -y && apt-get autoremove -y && apt-get clean -y

Or:

  apt update && apt upgrade -y && apt autoremove -y && apt clean -y

CentOS

  yum update -y && yum upgrade -y

Of course, you can also take advantage of automatic updates on various Linux distributions.

SSH security

Ssh security is arguably one of the most important Linux security measures. Most cases of Linux server hacks are due to a cracked SSH password.

The first thing to do to ensure the security of your Linux server is to ensure SSH.

Usually, many people will say that they use Fail2ban for SSH protection to prevent the SSH password from being blasted. However, it turned out that an illegal intruder used a lot of proxy IPs to break into SSH roughly. As a result, Fail2ban can no longer be effectively protected.

Therefore, using Fail2ban to protect SSH is not particularly effective and is not recommended. Conversely, Fail2ban also occupies many iptables rules, which impacts iptables performance.

So how do you protect SSH? We recommend the following methods:

1. Set the SSH password to a strong password

Brute force cracking in Ssh is basically attempted using a weak cryptographic dictionary. Therefore, I had to change the SSH password to a stronger one.

Usually, passwords are changed to 12 characters or more, with uppercase and lowercase letters and numbers with special symbols. This greatly prevents the password from being cracked roughly.

How to change your password:

  passwd root

2. Change the default port for SSH

Malicious scanners against Ssh usually scan only port 22.

So you can prevent this part of the malicious scanner by simply changing the default port of SSH to another port.

How to change the default port:

1. Open SSH config file:

    vim /etc/ssh/sshd_config

2. Change the following parameters:

Port 22322 # <---- Please select your favorite port

3. If iptables is enabled, you need to whitelist the modified SSH ports:

    iptables -A INPUT -p tcp --dport 22322 -j ACCEPT

4. Restart the SSH service:

    /etc/init.d/ssh restart

3. Log in using your SSH certificate

You can use an SSH certificate to log in to prevent brute force cracking of your SSH password. Because there is no password at all. How do you crack without a password?

1. Generate an SSH certificate

Here, PuTTY's certificate generator is used to generate the public and private keys and store them after generation.

2. Upload the public key to the server

Here, it is assumed that the public key is uploaded to "/etc/ssh/key/public.key".

Then set the public key to the correct system privileges:

chmod 700 /etc/ssh/key
chmod 600 /etc/ssh/key/public.key

3. Change the following parameters in the SSH config file for the SSH certificate to log in:

Open SSH config file:

    vim /etc/ssh/sshd_config

Change the following parameters:

    ......
    RSAAuthentication yes
    PubkeyAuthentication yes
    AuthorizedKeysFile /etc/ssh/key/public.key
    PermitEmptyPasswords no
    AllowTcpForwarding no
    X11Forwarding no
    PasswordAuthentication no
    ......

4. Restart the SSH service:

    /etc/init.d/ssh restart

4. Allows only the specified IP address to connect to the SSH port

This is the most secure SSH login. It's even more secure than an SSH certificate login.

The SSH certificate can be compromised, but the way only the specified IP can log in to SSH is virtually unbreakable.

However, only if you have a fixed proxy server and the security measures of the proxy server are strong.

Personally, I use wire guards to connect to my network before accessing the Internet. So my export IP is fixed.

So all my servers are restricted to my exit IP for SSH connections.

We recommend that you whitelist the two IPs of the proxy server. One of the proxy servers as a backup. We also recommend that both proxy servers be in different regions.

Set whitelist:

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -j ACCEPT
    iptables -A INPUT -s xxx.xxx.xxx.xxx -p TCP --dport 22322 -j ACCEPT
    iptables -A INPUT -p tcp --dport 22322 -j DROP

Save iptables settings (Debian / Ubuntu):

    /etc/init.d/netfilter-persistent save
    /etc/init.d/netfilter-persistent reload

5. Download the SSH client from the official website

Even with PuTTY, PuTTY files downloaded to many unofficial websites have backdoors that can illegally steal a user's SSH password.

PuTTY official website

Allow only the specified receiving port

Normally, the port used by the web server is fixed. For example, HTTP port 80 or HTTPS port 443. Allowing only connections to these ports prevents the occurrence of unknown attacks.

Of particular note here is the DNS port. Everyone knows that DNS uses the UDP protocol, but UDP does not have the connectivity retention capabilities of the TCP protocol. Therefore, open port 53 for proper DNS resolution.

However, other than DNS resolution, a typical web server does not require the UDP protocol. So, to prevent DDoS attacks, I generally block all UDP protocols. However, it does not protect against all DDoS attacks. We will discuss how to protect against DDoS attacks in a later article.

Use iptables to limit ports:

iptables -A INPUT -i lo -j ACCEPT # <-Allow local loopback interface (ie perform local access to local machine) iptables -A INPUT -m state --state ESTABLISHED, RELATED -j ACCEPT # <-Allow the passage of established or related connections iptables -A OUTPUT -j ACCEPT # <-Allow all local outbound access iptables -A INPUT -s xxx.xxx.xxx.xxx -p TCP --dport 22322 -j ACCEPT # <-Allows only the specified IP address to connect to the SSH port iptables -A INPUT -p tcp --dport 80 -j ACCEPT #<-- HTTP iptables -A INPUT -p tcp --dport 443 -j ACCEPT #<-- HTTPS iptables -A INPUT -p udp --dport 53 -j ACCEPT #<-- DNS iptables -A INPUT -j REJECT # <-Prohibit access to other unauthorized rules iptables -A FORWARD -j REJECT # <-Prohibit access to other unauthorized rules

Conclusion

This concludes the tutorial in the "Effective and Easy Web Server Security Measures" series.

Basically, you can keep your web server safe by following the security measures I have introduced.

However, to ensure 100% server security, it is also necessary to raise awareness of personal server security. You must always be prepared to face future security threats.

that's all.