Linux Server Security Hardening

Write in front:

When you get a server, don't worry about deploying apps, security is a top priority. If you sort the order, the Linux system can be secured by following several steps. This article is mainly for the enterprise common CentOS system, Ubuntu system slightly different can be Baidu query.

1. System User Optimization

2. System service Optimization

3.SSH Access Policy

4. Firewall configuration

1. System User Optimization

Note: When we perform system user optimization, every step of the operation needs to be communicated with the development and management personnel of this server to ensure that there is no mis-operation.

The user is the first level of security hardening in Linux, if there is a security risk in the system itself, then the security policy will not be able to strengthen the effect.

In a Linux system, you can use the following command to view user information in the system

cat/etc/passwd

Such a display does not allow us to visually see the security implications of the system, so we can use the following command to target the view:

cat/etc/passwd | Awk-f: ' $3==0 '//List of users with super privileges CAT/ETC/PASSWD | grep '/bin/bash '//List of users with login shell

If there are other super users besides Root, then be very careful. In general, the new system is not the case, but careful to sail the ship, if not the special requirements of system management, the system of super-users can only be root.

In the list of users who have logged in to the shell, these users can use the terminal to log on to the system and operate, even though these users may have only normal permissions, but still have to be careful. Delete outdated or useless users.

2. System service Optimization

Note: Again, each step of the operation requires communication with the development and management staff using the server to ensure that no misoperation occurs.

In general, the system may automatically run some unnecessary services, we can use the following command to view the current default open System services:

Chkconfig--list | grep "3:on"

If we only provide Web services, then for SendMail, NFS, Postfix, FTP and other unnecessary services can be closed, the command to close is:

Chkconfig <servername> off

For the key services, we need to ensure that they operate, such as: Iptables, sshd, Syslog, httpd, Nginx, MySQL, php-fpm and so on.

3.SSH Access Policy

SSH access is a means of almost the only control system in our daily work, whether it be operations or developers. So the security of SSH is very important, generally high SSH security policy adhering to the following several principles.

A. Disable root user ssh login.

B. The way to disallow passwords is verified.

C. Allow only one user to have full Sodu permissions.

D. The private key file is not allowed in the system unless it is a bastion machine.

E. Use a random port instead of Port 22.

But what we have to do before we do these security reinforcements is:

Create a new normal user that allows the user to log into the system through a certificate and give sudo full access.

Certificate Verification Method Please refer to: Http://bbs.aliyun.com/read/252222.html?spm=5176.7189909.0.0.gKfLSI

To add sudo permissions, do the following (root permission required):

To edit the Vim/etc/sudoers, add an article:

Test all= (All) Nopasswd:all

The example here shows that the test gives full sudo permission and does not require a password to be validated when Sudo is raised.

Remember: When you are guaranteed to be able to log in to the system by using the test user's certificate, you can use sudo su to extract the power to root, and then do the following.

A. Disable root user ssh login. (Requires root access)

Edit/etc/ssh/sshd_config file, change Permitrootlogin Yes to

Permitrootlogin No

If you are lazy, execute the following command directly:

Sed-i ' s/\ (permitrootlogin\) yes/\1 no/'/etc/ssh/sshd_config

B. Prohibit passwords, use certificates

Edit/etc/ssh/sshd_config file, change passwordauthentication Yes to

Passwordauthentication No

Of course there are lazy people dedicated methods:

Sed-i ' s/\ (passwordauthentication\) yes/\1 no/'/etc/ssh/sshd_config

C.sudo can have many permissions, but it is recommended to give full permissions only to a dedicated OPS user. And you should be accustomed to using sudo under normal users for temporary power.

D. Only the pub public key file can be stored on the server, but the private key file is absolutely not allowed unless the server is a bastion machine.

E. Modifying the monitor port of sshd

Edit the/etc/ssh/sshd_config file to

#Port 22

Revision changed to

Port 28536

Of course you can specify any custom port that is not occupied.

Remember to restart the SSHD service after completing the relevant configuration of sshd

Service sshd Restart

In the future, we will use SSH to specify a port of 28536.

Now let's look at the effect of SSH access:

(1) All users cannot login with password authentication.

(2) The root user is not allowed to log in directly, even if they have the root password, the only way to get root is to use the test user to raise the power.

(3) test user can only log on with a certificate.

(4) SSH no longer uses the default 22 port

4. Firewall Policy

Linux firewall that must be iptables.

The highest firewall policy is to shut down all and turn them on.

But this is too complicated for most people, so in general we just need to focus on the input chain.

(1) First, clear the original iptables rules.

Under guarantee that the default rule for all iptables chains is accept, use the following command:

Iptables-fiptables-xiptabels-z

(2) Configuring the input chain rule

Iptables-a input-p tcp-m TCP--dport 28536-j accept//allow SSH ports via iptables-a input-m State--state related,established -j accept//allow established and server-initiated packets to drop//drop all packets not allowed through Iptables-p INPUT

Effect: Any packet that accesses the server will be rejected except for 28536, which is ssh.

Attention:

After you configure the above 3 commands, try to log on to the server from a new SSH connection if the login succeeds. You can save Iptables rules:

Service Iptables Save

If anything happens, you can also return to the original state of Iptables by restarting the server, so it is a good practice to save after the test iptables can properly meet the requirements.

Finally: Ensure that all necessary servers are powered on

Chkconfig sshd onchkconfig iptables on

This article is from the "Thinking Can Progress" blog, please be sure to keep this source http://mislost.blog.51cto.com/10256994/1679560

Linux Server Security Hardening