How to make Linux servers more secure and linux servers more secure

How to make Linux servers more secure and linux servers more secure
I run several Linux servers. I have one at home, serving as a file server, and three active servers used as my Site Server, email server, and cloud storage server. Although I am not worried about the server in my house, it is not in contact with the outside world, but the other three servers need to be carefully maintained and always need to be carefully maintained.

Keep in mind that the following seven points will make your Linux server more secure.

Figure 1: running services.

Install required services

If you want to run a server, you may think, "I have a 40 gb ssd storage system from Linode, so I can install any services I want to install ." Yes, you are the master of your website: you can install any software on the server. However, do not take it for granted. Even the most solid server will be hijacked by someone exploiting the loopholes of any unpatched or Vulnerable Software Component running on the server.

Therefore, the first rule is to streamline your server as much as possible. Only install the packages you actually need. If there are unnecessary packages, clear them. The fewer packages, the less likely the code is to be patched. Before installing any software and dependency packages (such as ownCloud), you should read the ownCloud instructions and install only the packages required by it.

Run the required services

The second rule is to run only the services needed. Many distributions or packages may enable certain services and run on different ports. This may bring security risks. Open the terminal and run the following command: netstat-npl

The output result shows which services are running on which ports. If you find any service that should not run, stop it. You should also pay close attention to the services that have been enabled and run when the system is started. Run the following command on the system that runs systemd to check whether systemctl list-unit-files -- type = service | grep enabled

Depending on the system, you will get the output result shown in 1. If you find any unnecessary service, you can use the powerful systemct1 command to disable it: systemctl disable service_name

Restrict access to the server

Just like you don't give your keys to people you know, or give the server access permissions to people you know. Once this rule is clarified, access to the server can be restricted. Keep this in mind: this will not eliminate the idea of destroying the bad guys on your server. However, its role is to add more layers of security to your server. Prevention is just a hacker.

Do not log on as the root user

It is not a good practice to access the server through ssh as a Super User. We will disable ssh access to the server as the root user. Before doing so, create a user with sudo permissions so that you can access the server through ssh, the Administrator task has been executed. Once you log on to the server, you can always switch the user to the root user, if necessary. If you already have a user on the system, skip a few steps. Otherwise, follow me.

Different releases use different methods to add new users. Red Hat/CentOS uses useradd and Ubuntu/Debian uses user adduser.

Create a user in Fedora/CentOS: useradd swapnil

Then, create the password passwd swapnil for the user.

It requires you to provide a new password for the user. Now you need to grant sudo permission to this user. Run the following command: EDITOR = nano just do
Find the following line (see Figure 2): # % wheel ALL = (ALL) ALL

Figure 2: grant sudo permissions to users.

Remove the comment of the row (# The symbol means that the row is commented; remove the comment as long as this symbol is removed), it looks like this: % wheel ALL = (ALL) ALL

Now, save and close the file. If the user does not belong to the wheel group, you only need to run the following command to easily add it to the group: # usermod-aG wheel swapnil

On Ubuntu, you can add new users and run the following command: adduser swapnil

Answer some questions raised by the system, including creating a password for the user. Once the creation is complete, grant the sudo permission to the user: gpasswd-a swapnil sudo

Open another terminal window, try to log on to the server as the user you just created, and execute some administrator tasks with sudo permissions. If everything is normal, go to the next step.

Disable Root User Logon

We want to disable root user logon, which means no one can log on to the server through ssh or as the root user. To this end, open the sshd configuration file: nano/etc/ssh/sshd_conf

Next, find the comment line that displays the following: # PermitRootLogin no

Then save and close the file and restart the service: service ssh restart or systemctl restart sshd.

Important: do not quit the server. You need to test whether the user you just created can successfully access the server through ssh. Open another instance of the terminal and use ssh to access the server as the user created previously. You do not want to be completely locked out of the server. If everything works properly, you can log out of the server as the root user.

Change Port

The second change we need to make to the sshd configuration file is to change the default port. This mainly adds a layer of concealment to ensure the security of your server, rather than adding any actual security mechanisms to the server. This is like a security service company dispatching vehicles to transport important people, so that attackers do not know which vehicles should be attacked.

Open the sshd_config file (this time it is opened with the sudo permission, because you can no longer log on to the server as the root user): sudo nano/etc/ssh/sshd_conf
Then find the comment line: # Port 22
Remove the line comment and select a port number. When selecting a Port, make sure it is not used by any other service on your system. I have selected Port 1977: Port 1977 for the server.
Next, save and close the file and restart the sshd service. Once again, check the settings before logging out of the server. To do this, open another terminal window and use this mode to log in: ssh-p {port_number} @ server_IP
Example:

Ssh-p1977
Swapnil@10.14.190.118

If you can log in successfully, it will be done.

Logon without a password

You can easily log on to the server through ssh without a password, and Disable password verification completely to add another layer of security. Remember: you can only log on to your server from the machine that created the ssh key.

Use the following command to create an ssh key on the local system (see figure 3): ssh-keygen-t rsa

Figure 3: Create an ssh key.

It raises some questions; you don't need to change the key location, keep its default value, and provide it with a difficult to guess. Next, you need to copy these keys to the server so that the two machines can use the keys to contact the other party.

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

Now, try to access the server through ssh from another terminal. If everything works, it will not require you to enter the password.

This step is mainly for convenience, rather than adding some real security. However, you can also add a bit of security, as long as the server password verification is disabled. You only need to open the sshd configuration file and find the line with this comment: # PasswordAuthentication yes
Remove the line comment and change it from yes to no. Save and close the file. Restart the sshd service. Once again, do not close the server connection from the current window. Open another window and log on to the server (make sure it does not require a password ).

Another aspect of this setting is that you can only access the server from the machine that created the ssh key through ssh. If you often log on from different machines to the server, do not use this method.

These are some basic considerations for new users trying to run their own servers. Keep in mind that hackers always take the first step; they constantly seek to break into any vulnerabilities on your server. Therefore, the best practice is to keep the latest backup for your server. I suggest you back up your site before and after any changes. In this case, your server will always be able to recover from the previous backup.