How to make Linux servers more secure

Keep in mind that these seven points will make your Linux server more secure

Figure 1: The service in operation.

Services required for installation

If you're going to run a server, you might think, "I Have a 40GB SSD (SSD) storage System from Linode, so I can install any service I want to install." "Yes, you're on your turf: You can install any software on the server. But don't make mistakes that take for granted. Even the most impenetrable servers are hijacked by someone who has drilled any patches or vulnerable software components running on the server.

So the first rule is to keep your servers as concise as possible. Install only those packages that you really need. If there are unwanted packages, clear them. The smaller the number of packages, the less likely it is that the code will not be patched. Before installing any software and dependent packages (such as owncloud), you should read the documentation for the owncloud and install only those packages that it needs.

To run the required services

The second rule is to run only those services that are needed. Many distributions or packages may turn on some services to run on different ports. This can pose a security risk. So, open the terminal and run the following command: NETSTAT-NPL

The output results show which services are running on which ports. If you find any service that should not be running, stop it. You should also pay close attention to services that have been enabled and run when the system starts. You can check this as long as you run the following command on a system running SYSTEMD: Systemctl list-unit-files--type=service | grep enabled

Depending on the system, you will get the output shown in Figure 1 above. If you find any service you don't need, you can disable it with a powerful systemct1 command: Systemctl disable service_name

Restricting access to the server

It's like you don't give your keys to someone you know, and you don't give the right to access to the server to anyone who knows it casually. Once this rule is clarified, access to the server can be limited. Keep that in mind: it doesn't stop the idea of a bad person who is determined to destroy your server. However, its role is to add a layer of security for your server, prevention is just leackage check criminals.

Never log on as a root user

It is not a good idea to access the server via SSH as Superuser. We will later prohibit access to the server as a root user via SSH, but before doing so, it might be useful to create a user with sudo privileges so that you can get into the server via SSH and perform an admin task. Once you log in to the server, you can always switch the user to the root user, if necessary. If you already have users on the system, skip a few steps, or follow me.

Different distributions use different methods to add new users; Red Hat/centos uses Useradd,ubuntu/debian to use the user AddUser.

Create a new user on Fedora/centos: Useradd swapnil

Then, create a password for the user: passwd Swapnil

It will require you to provide it with the user's new password. Now, you need to grant sudo permissions to the user. Run the following command: Editor=nano Visudo

Look for the following line (see Figure 2): #%wheel all= (All)

Figure 2: Sudo permissions are granted to the user.

Remove the comment for the line (#符号意味着该行被注释; Remove the annotation as long as you remove the symbol) so it looks like this:%wheel all= (All)

Now, save and close the file. If the user does not belong to the wheel group, you can easily add it to the group by simply running the following command: # USERMOD-AG wheel Swapnil

On the Ubuntu system, you can add new users and run the following commands for this: AddUser Swapnil

Answer some of the questions raised by the system, including creating a password for the user. Once created, grant sudo permissions to the user: Gpasswd-a swapnil sudo

Open another terminal window, try to login to the server as the user you just created, and try to perform some administrator tasks with sudo privileges. If everything works, go to the next step.

Disable root user logon

We now disable the root user login, which means that no one can access the server as a root user via SSH or login. To do this, open the sshd configuration file: nano/etc/ssh/sshd_conf

Next, look for this comment line that shows the following: #PermitRootLogin No

Then save and close the file and restart the service: Services SSH restart or systemctl restart sshd

Important reminder: Don't quit the server at this point. You have to test if you can successfully access the server via SSH with the user you just created. Open another instance of the terminal to enter the server via SSH to the user you created earlier. You don't want to be completely locked out of the server. If everything is OK, you can safely log out of the server as the root user.

Change port

The second change we have to make to the sshd profile is to change the default port. This is mainly to add a layer of invisibility to make your server secure, rather than adding any real security to the server. This is like a security service company sending the same vehicles to transport important people, so that the attackers do not know which cars to attack.

Open the Sshd_config file (this time opens with sudo permission because you can no longer log on to the server as root): sudo nano/etc/ssh/sshd_conf

Then, find this comment line: #Port 22

Remove the line comment and select a port number. When choosing a port, make sure that it is not used by any other service on your system, I chose Port 1977:port 1977 for the server

Next, save and close the file and restart the sshd service. Once again, check the settings before you log out of the server, you can open another terminal window, and then log in using that mode: Ssh-p{port_number} @server_IP

Example:

ssh-p1977

swapnil@10.14.190.118

If you can successfully log in, it's done.

Login without password

You can easily access the server via SSH via a password-free login and completely disable password authentication to add another layer of security. It's important to keep in mind that you can only log in to your server from the machine that created the SSH key.

You may wish to create an SSH key on the local system using the following commands (see Figure 3): ssh-keygen-t RSA

Figure 3: Creating the SSH key.

It raises a few questions; you don't have to change the key location, keep its default value, and provide it with a hard to guess pass code. Next, you need to copy the keys to the server so that the two machines can connect to each other using the key.

Cat ~/.ssh/id_rsa.pub | Ssh-p 1977 Swapnil@remote-server "; Mkdir-p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Now try to access the server via SSH from another terminal, and if it's all right, it won't require you to enter a password.

This step is mainly for convenience, not to add some real security. But you can also add a little security, as long as you disable password authentication for the server. Just open the sshd configuration file and look for one line of this comment: #PasswordAuthentication Yes

Remove the line comment and change it from Yes to No. Save and close the file. Then, restart the sshd service. Once again, do not close the server connection from the current window. Open another window and log in to the server (make sure it doesn't require a password).

Another aspect of this setting is that you can now access the server via SSH from the same machine that created the SSH key. Do not use this method if you frequently log on to the server from different machines.

These are some basic aspects to consider for new users trying to run their own servers. Keep in mind that hackers are always a step ahead; they are constantly looking for any vulnerabilities that will break into your server. Thus, the best practice is to do a consistently up-to-date backup of your server. I recommend that you back up your site before and after any changes are made. That way, you can always recover from a previous set of backups in case your server is recruited.