📜 ⬆️ ⬇️

Protecting the web server on Linux

Hi, Habr!

We haven't had any new books on Linux for beginners for a long time - and now we take on the translation of a novelty of just such a plan. The book " Linux in Action " by David Clinton was published by Manning and tells not only about the internal structure of Linux , but also about the most common problems, and how to eliminate them.


The author published on the Hackernoon website an excerpt from the ninth chapter, which we invite you to evaluate.

Assembling a LAMP server, how to configure it, ensure reliable data processing, set up a subject area, and attend to a TLS certificate is only half the journey to victory. You also need to make sure that your infrastructure is protected from the many daunting threats of the Internet.
')
In this article, we explore the security of a website, learning how to work with system groups, ensure process isolation and regular audit of system resources. Of course, this story is not complete (other topics are discussed in the Linux book, for example, installing TLS certificates and working with SELinux), but this will be quite enough for a start.

System groups and the principle of minimum privileges


Developers whose support you are engaged in (finally) are beginning to realize that it is necessary to limit the general access to data and configuration files located on the application server, but at the same time, keep such access open for various programming and other IT commands.

The first part of the solution is the groups . A group is an object in the system (approximately like a user) with the proviso that no user will ever log in as a group. The power of groups lies in the fact that they, like users, can be “assigned” to files or directories, allowing each member of the group to use the powers provided for it. This is illustrated below.

Developers who are part of the Developers group can access a specific directory, and for non-users, the directory will be closed.
Try it yourself: create a new file in a text editor. Write simple text in it, for example, “Hello World”, so that you can immediately see when the file was successfully accessed. Then edit the permissions using chmod 770 so that the owner of the file and the members of the group to which he belongs have full rights to work with the file, while others cannot read it.

 $ nano datafile.txt $ chmod 770 datafile.txt 

If there are no other user accounts on your system except your own - create such an account either with adduser - this is done in Debian / Ubuntu - or with the help of useradd , as it is in CentOS. The useradd command will work in Ubuntu.

The useradd command, unlike the Debian adduser requires that a user password be generated separately:

 # useradd otheruser # passwd otheruser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully 

Using the su command, we switch to a new user. After we enter his password, all of the following commands will be executed on behalf of this user. You will work on behalf of this particular user; no more, no less. If you try to read the datafile.txt data file (using cat ), then nothing will come of it anymore; as you remember, only members of the group have read permissions. When done, enter exit to exit the shell of the new user, and return to your original shell.

 $ su otheruser Password: $ cat /home/ubuntu/datafile.txt cat: /home/ubuntu/datafile.txt: Permission denied $ exit 

All this is expected and quite understandable. As you can see, when you can’t read a file belonging to another user, this is sometimes a problem. Let's see what can be done by associating a file with a group, and then properly configuring file permissions.

Create a new group with which we can manage the data of our application, and then edit the properties of our data file with the help of the command chown . The ubuntu: app-data-group argument leaves the Ubuntu user the right to own the file, but its group changes to a new one: app-data-group.

 # groupadd app-data-group # chown ubuntu:app-data-group datafile.txt 

Run ls to get a “expanded” output of this file and view its new access rights and status. Note that as expected, the file is owned by the user ubuntu , belonging to the app-data-group .

 $ ls -l | grep datafile.txt -rwxrwx — — 1 ubuntu app-data-group 6 Aug 9 22:43 datafile.txt 

You can use usermod to add your user to the app-data-group , and then the su command to switch to the shell in which the other user’s account is deployed. Now, even though the file permissions close it from all “others” - and you are definitely a “different” user at the moment - you should read this file freely, as you belong to the right group.

 # usermod -aG app-data-group otheruser $ su otheruser $ cat datafile.txt Hello World 

Using the su command, we switch between user accounts. They are recorded in my datafile.txt file. Such an organization is the right and effective way to eliminate various complex problems with access rights that may arise in a multi-user system.

In fact, it is used not only to provide the necessary access rights to individual users - many system processes would also not be able to perform their tasks if they were not assigned to belong to the necessary groups. You can view the file / etc / group diagonally - note how many system processes belong to their own groups ...

An abbreviated listing of the contents of / etc / group file:

 $ cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:syslog tty:x:5: disk:x:6: lp:x:7: mail:x:8: news:x:9: uucp:x:10: man:x:12: proxy:x:13: […] 

Isolation of processes in containers


Perhaps you are worried that many services running on one server for you will be at risk if at least one of these services is hacked? One option to smooth out such damage that careless or malicious users can cause is to isolate system resources and processes. Thus, even if someone wishes to expand his authority beyond the established limits, he will not receive physical access to the data.

Previously, this problem was decided to solve as follows: for each service, they allocated their own physical machine. However, thanks to virtualization, it becomes much easier and cheaper to build a “mesh” architecture. Today, this architecture is often referred to as microservice and allows you to run multiple containers at once, in one of which the database can work, for example, in the other - Apache, and in the third - the media files that can be embedded in your web pages. Microservice architecture allows not only to significantly improve performance and efficiency, but also significantly reduces the risk of hacking of each individual component.

The “containers” I’m talking about do not have to be convincing LXC. Today, other container technologies, such as Docker, are becoming much more popular.

Check for dangerous user ID values


Of course, any user with administrator privileges can temporarily provide root access with the sudo , but only the admin is a genuine admin. As you already know, it is unsafe to perform regular functions under root access. However, it may happen - either purely by accident, or because of malicious fraud - that a regular user will have administrative rights without any interruptions.

In this case, it is good that it is easy to identify such impostors: their user and / or group IDs, like the admin, will have a “0”. Take a look at the passwd file in the / etc / directory. This file contains an entry for each normal and system user account that already exists in the system. The first field contains the account name (in this case, root and ubuntu), and the second field can contain x instead of the password (if the password exists, it will be in the encrypted form in the / etc / shadow file). But the next two fields contain the user and group IDs. In the case of ubuntu in this example, both IDs are equal to 1000. And the administrator, as you can see, has zeros here.

 $ cat /etc/passwd root:x:0:0:root:/root:/bin/bash […] ubuntu:x:1000:1000::/home/ubuntu:/bin/bash 

If you ever meet a regular user with a user or group ID = 0, then you can be sure that this is unclean, and the situation needs to be rectified. A quick and easy way to detect such a problem is to check the passwd with the awk command, which will print all the lines in the third field of which there is nothing but 0. In my case (you can breathe out) only one such line was found - the root. You can run it again, replacing $ 4 with $ 3 - so you check the group ID field.

 $ awk -F: '($3 == “0”) {print}' /etc/passwd root:x:0:0:root:/root:/bin/bash 

System Resource Audit


The more all sorts of things you have in the system, the higher the likelihood that something in it will break. Therefore, it is reasonable to keep track of what works. Speech in this case is about network ports (if the port is “open”, then by definition there should be an input), services (if the service is active, then it should be able to use it) and about installed programs (if the program is installed, then it should be the ability to perform it).

For an audit to be beneficial, it must be more or less regular. Since we are all forgetful, it is much better to write the audit tools in a special script that will not only run regularly but also ideally parse the results so that they are more readable.

Here, however, I will introduce you to three key audit tools that will help you view open ports, active services, and unnecessary software packages. Your task is to automate all this.

Port scan


A port is considered “open” if a process is running on the host that listens for requests on that port. Watching over your open ports, you will better understand what is happening on your server.

You already know that HTTP (80) and SSH (22) ports should probably be open on a regular web server, so they won't surprise you. But it is much more important to pay attention to other, unexpected results. The netstat command displays all open ports, as well as a wealth of information about exactly how they are used.

In this example, we check a completely typical multipurpose server, and the -n command tells netstat to turn on all numeric ports and addresses. -l includes only listening sockets, and -p adds the process ID of the listening program. Naturally, if you see something - act.

 # netstat -npl Active Internet connections (only servers) Proto Local Address Foreign Address State PID/Program name tcp 127.0.0.1:3306 0.0.0.0:* LISTEN 403/mysqld tcp 0.0.0.0:139 0.0.0.0:* LISTEN 270/smbd tcp 0.0.0.0:22 0.0.0.0:* LISTEN 333/sshd tcp 0.0.0.0:445 0.0.0.0:* LISTEN 270/smbd tcp6 :::80 :::* LISTEN 417/apache2 […] 

In recent years, ss increasingly used in place of netstat . Just to be on the safe side: if you find yourself in the company sometime in the evening, and someone asks you about ss, then this example (which lists all the established SSH connections) should be informative enough so that you can’t lose face.

 $ ss -o state established '( dport = :ssh or sport = :ssh )' Netid Recv-Q Send-Q Local Address:Port Peer Address:Port tcp 0 0 10.0.3.1:39874 10.0.3.96:ssh timer:(keepalive,18min,0) 

We check active services


If you take a quick, snapshot of the services managed by the system and currently active on your computer, the machine will help identify any unwanted activity. The systemctl command can list all existing services, and then you can narrow down the list to those that contain enabled in the description. Only active services will be returned this way.

 # systemctl list-unit-files — type=service — state=enabled autovt@.service enabled bind9.service enabled cron.service enabled dbus-org.freedesktop.thermald.service enabled docker.service enabled getty@.service enabled haveged.service enabled mysql.service enabled networking.service enabled resolvconf.service enabled rsyslog.service enabled ssh.service enabled sshd.service enabled syslog.service enabled systemd-timesyncd.service enabled thermald.service enabled unattended-upgrades.service enabled ureadahead.service enabled 

If you find something that is clearly not the place, you can use the systemctl command to stop the service and make sure that it does not restart on the next boot.

 # systemctl stop haveged # systemctl disable haveged 

In fact, there is nothing dark and gloomy in the haveged service, which I stop in this example: these are the tools that I often run to create random background system activity when I create encryption keys.
Search for installed programs

Could someone install software on your system without your knowledge? Well, to find out - you need to look. The yum list installed command is yum list installed or, in the case of Debian / Ubuntu, the dpkg — list will give you a detailed summary, and the remove command should remove all packages that we do not need.

 # yum list installed # yum remove packageName 

Here's how the same thing is done in Ubuntu:

 # dpkg --list # apt-get remove packageName 

It is also useful to keep track of the changes that are made to your system configuration files — we'll talk about this in Chapter 11.

Source: https://habr.com/ru/post/425571/


All Articles