Despite the fact that Linux is considered to be a more secure system than MS Windows, this fact is not enough.

Therefore, I want to tell you about the basic security configuration in the Linux family. The article is aimed at beginners Linux-administrators, but it is possible and experienced experts will learn something interesting for themselves. The text will not be step by step instructions - only a basic description of the technologies and methods, as well as a few personal recommendations.

Where to start to tighten the screws

The first and most important recommendation - be careful about the instructions on the Internet. Unfortunately, often these instructions contain irrelevant or even harmful information and do not explain why it is done this way and not otherwise. You should always understand what you are doing. Copying commands to the console is dangerous at all.

As a rule, most products are fairly well documented, and information is better to draw from official sources.

There are often recommendations in the network not to work under the root user - a superuser with full rights to everything. Partly the recommendation is correct: working under root is not safe in terms of the fatality of possible errors and the risk of intercepting a password.

Since you actually work on the server a couple of times a year, and at the same time you are mainly engaged in updating or minor editing of configs, working with root-rights is just like a temporary privilege escalation using sudo . But a series of reasonable precautions still does not hurt:

• ideally, configure server logon by keys ;

  
  

• do not enter the password from the superuser on unreliable machines;

  
  
• Do not use simple or vocabulary passwords. You can rename the root user altogether, but first it is better to check the consequences in a test environment.

Installing updates is definitely needed and useful. Only now, not just once the update of both individual packages and the operating system led to a crash. Therefore, always before the updates should check their installation on a copy of the working server.

Protecting the file system

If the server has more than one user or a couple of services running under different accounts, then it will be a good idea to separate the access rights to the file system and narrow the area of ​​damage in case of anything.

Each distribution uses the so-called selective access system. For example, the ability of a user to open a file is checked against an access control list (Access Control List, ACL) - which “ticks” for this user are included.

A good safety principle is to provide only the rights that are really necessary for work.

In particular, on Linux systems, the following access mechanism is used for files:

• each object has three access parameters - for the owner, for the group of users where the owner belongs and for all the others;

  
  
• Each parameter can take a combination of three values ​​- you can read, you can change, you can run.

The right of access is conveniently presented in numerical form. The number will be a three-digit, calculated according to a simple scheme:

Thus, the right to full rights for all to an object will look like: (400 + 200 + 100) + (40 + 20 + 10) + (4 + 2 + 1) = 777. Such rights, as a rule, are never needed and no one, it is permissible to expose them only in the process of debugging.

This access mechanism is sometimes called UGO (User-Group-Others).

More information about access rights and working with them can be read in the relevant materials .

Of course, such an access mechanism is not always convenient. For example, if you need to give user rights to a specific object, you will have to add it to the group, or even create a new one. Therefore, on UNIX systems, a slightly complicated access mechanism has been added, called an ACL. It supports already more flexible and complex access lists.

By default, this system is disabled. To enable it, you need to mount a hard disk with the acl option. For example, enable acl for the root partition by adding the mount option to / etc / fstab:

Now the system boots with extended ACL support.

You can now manage access lists with the setfacl command . View current permissions - getfacl .

More information can be found in the documentation , but for an example I will give full access rights for the user user to the test.txt file:

Granting full user rights to user.

The protection mechanism is quite simple, effective ... and resembles the NTL file system ACL.

Fire wall on the autobahn

The main mechanism for protecting access to the server is traditionally firewall. On GNU \ Linux systems, the netfilter built into the kernel is used for this .

For managing the firewall, iptables is most often used. There is enough material on it, so I will confine myself to the general recommendation - we block everything that is not allowed. And what is allowed - as much as possible we limit.

For example, if SSH access to the server is required only from certain external addresses, allow access only from them.

But working with iptables is not always convenient, because it requires a deep understanding of the path of the packets. Alternatively, other utilities are often used, such as ufw on Ubuntu systems.

For example, to provide access via ssh using ufw, just run the command:

ufw allow from 1.2.3.4 to any port 22 

The same with iptables would look more cumbersome. Allow incoming traffic:

 iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT 

Then allow the return traffic:

 iptables -A OUTPUT -p tcp --sport 22 -d 1.2.3.4 -j ACCEPT 

I must say that more often, instead of making two explicit rules for incoming and return traffic, they simply allow the traffic of established connections (ESTABLISHED) and those associated with established connections (RELATED). To do this, it is enough to allow all ESTABLISHED and RELATED connections by the following commands:

 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 

In modern RPM distributions like CentOS, Fedora and Red Hat, the firewalld daemon is used as a replacement for iptables. It differs from the usual mechanism in that it can apply the rules on the go without reloading the list, as well as working with zones - levels of trust in network connections. A bit like the built-in Windows firewall. However, it is a bit unusual to use it after iptables, and often system administrators prefer to return complex but familiar iptables.

In conjunction with the firewall, a mechanism such as fail2ban works closely, which does the following:

• monitors the log of any service, for example ssh or ftp;

  
  
• if there are too many connections from the same IP address with incorrect usernames and passwords, block this IP using a firewall for some time. Suddenly it is brute force.

More details on the fail2ban setting can be found in the official Wiki .

NSA on guard

SELinux is an additional mechanism for enforcing access control. Unlike classical selective, access is based on special policies, not ACLs.

Disadvantages of an ACL-based access system:

• server user can provide access to their files - for example, to private keys;

  
  
• processes inherit user rights and can change file permissions — for example, a compromised browser can access mail correspondence.

SELinux, created by the NSA (US National Security Agency) and Red Hat in 1998, can eliminate these shortcomings. In the Linux kernel, this technology has been around for a long time. However, in some instructions, it is still often the recommendation to turn it off, which is not always true. More information about SELinux can be read in the profile article on Habré , so I will limit myself to a small educational program.

SELinux has three modes of operation:

• enforcing. The default mode of operation, all unresolved actions are blocked;

  
  

• permissive. All unresolved actions are performed, but recorded in the log;

  
  
• disabled. SELinux is disabled.

You can find out the current mode of operation with the getenforce command, you can switch between enforcing and permissive modes with the setenforce command. Turning off SELinux requires a system reboot.

The protection mechanism is applied after the classic, and is based on a special marking of objects. You can view the current marking with the command:

 ls -Z 

We look at the label of the newly created file.

As an example of configuration, I will analyze the situation when we want to place the site in a non-default folder and “hang” the web server on another port. One change of values ​​in the httpd.conf configuration file will not be enough; you must tell SELinux that the web server should be granted access to the folder and port. For this you need:

• install the policy package of policycoreutils-python;

  
  

• tell the system about the folder labeling commands:

  
  

   semanage fcontext -a -t httpd_sys_content_t "/path/to/www(/.*)?" semanage fcontext -a -t httpd_sys_rw_content_t "/path/to/www(/.*)?" 

  
  

• restore markings with the command:

  
  

   restorecon -R /path/to/www 

  
  
• provide access to the port:

 semanage port -a -t http_port_t -p tcp 81 

Of course, before doing all this, I recommend to get acquainted with the work of SELinux in detail.

SELinux as a solution is not unique. The second most popular defense mechanism is AppArmor. Its development was initially supervised by Novell, but after the tool was abandoned as unpromising. However, Canonical is now working on AppArmor, and the product is closely related to the Ubuntu system. As for the differences, AppArmor is more convenient than SELinux due to the many ready-made policies.

There is also a learning mechanism in which user actions are recorded in the log, but not blocked — this is how you can launch a new defense as a “pilot” and immediately eliminate flaws. If in SELinux this mode is enabled for the entire system, then with AppArmor it can be activated for a specific application. An example of such an appointment:

 aa-complain /path/to/bin 

The key difference between AppArmor and SELinux is that AppArmor binds the policy to the path, and SELinux relies on the file descriptor. If you block the execution of the file and then move it, then AppArmor will allow the file to start, but SELinux will not.

If the file is overwritten by the original path, then AppArmor will block it, and SELinux will allow execution. You can avoid these misunderstandings by turning on the “block everything except explicitly allowed” policy.

If we describe the differences briefly, the SELinux developers did not focus on ease of use, but on security. With AppArmor, everything is exactly the opposite. You can read more about AppArmor in the documentation from the manufacturer , or in the Ubuntu library.

Alas, I can not give unequivocal advice that you choose, because it is a matter of priorities and preferences for the OS distribution. Centos and Red Hat fans choose SELinux more often, and Ubuntu fans choose AppArmor.

By the way, write in the comments, what mechanism do you prefer?

A set of master keys just in case

In this section, I will discuss some useful, but not must-have, mechanisms for protecting a server.

Barring root connections to the terminal

On GNU \ Linux systems, you can limit the list of terminals to which the root user can connect. This can be done by modifying the / etc / securetty file. If the file is empty, then root will not be able to directly connect at all, and you will need su or sudo to get full permissions .

Password policy

It may also be useful to set the password expiration with the following command:

 chage -M 20 username 

Where 20 is the password expiration date in days. Another option would be to change the overall password policy in the /etc/login.defs file. Suppose we want the password to be changed every 20 days, and that the user receives a reminder about this in 5 days. Then the contents of the file will be as follows:

 PASS_MAX_DAYS 20 PASS_MIN_DAYS 0 PASS_WARN_AGE 5 

Another useful feature is the password complexity policy. For this, the pam_cracklib module is used. For example, if we want the password to contain at least one large letter, at least one small, at least one digit, and the password itself is at least 8 characters in length, adding a string will help:

 password required pam_cracklib.so minlen=8 lcredit=1 ucredit=1 dcredit=1 

in the /etc/pam.d/system-auth file.

Notifications of elevation cases

Another option you need is a notification of every sudo entry to control access to superuser rights. To do this, simply add the following lines to the / etc / sudoers file:

 mailto [admin@domain.com](mailto:admin@domain.com) mail_always on 

Of course, the sending agent must be configured in the system. A good option for replacing the standard sendmail is ssmtp , which will easily make friends with sending emails even through free email services.

Deactivating Compilers

In order to avoid compiling and running malicious software, it is useful to disable compilers on the server for use by users.

 rpm -q --filesbypkg gcc | grep 'bin' 

 groupadd compilerGroup 

 chown root:compilerGroup /usr/bin/gcc 

 chmod 0750 /usr/bin/gcc 

Immunity for configuration files

A good way to protect system files and configurations even from the superuser is an attribute of immunity. To use it, use the chattr + i filename command .

Even root cannot delete an immune file.

To remove this attribute, just run the command chattr -i filename.

I think every administrator has his own best-practices on server security. I propose to share them with colleagues in the comments.