Although Linux may not be such a popular target for cybercriminals as Windows, the standard is not entirely secure either. In this article, we list the most important dangers for you, obviously with a solution. Protecting Linux is something you do.

First, make sure that your system is not physically accessible. After all, a physically reachable system can be hacked. So provide Grub with a password to access the boot prompt. But even then you can still hack into the server by booting a boot image, such as a DVD or USB stick. You can do this by first defining the internal hard drive in the boot sequence in the system’s system.

Finally, provide your BIOS(EFI) with a password and put the Linux machine under lock and key. With these measures, you have made it virtually impossible to unauthorized reset the root password.

Rootkits and software packages:

To be able to install software, you must install software packages with root permissions. However, few people check the packages first to see if they do not happen to contain malicious code (such as rootkits). And maybe you yourself have been unsuccessfully looking for a driver or program via apt, zypper, dnf or yum. Luckily you came across a package somewhere on the internet with a promising description. The problem with packages from the internet, however, is that you have no idea what you are installing.

important that you are sure of your case. There is a fairly simple solution for this: use only the repositories that are made available by your distribution. The chance that something goes wrong is very small. The risk also increases when you look further than the software that is made available by your Linux distribution.

This already applies to seemingly reliable external parties, but especially to packages that you yourself have found on the internet. If you do download and install software from the internet, it is wise to analyze what you are going to do exactly. If it concerns rpm packages, use the command

rpm -qp scripts

before you install it.

Scripts

Perhaps the biggest problem of Linux is untrustworthy or just badly written scripts. Many applications, especially web servers, make extensive use of scripts. These scripts can, for instance, be included in web pages and can ensure that tasks are carried out automatically when selecting a specific function.

We once saw that problem live on a server that ran multiple Apache virtual hosts for a number of websites that were maintained by different people. The result was a proliferation of PHP, Python and Perl scripts, one of which had the option to open a shell from the script.

Perhaps the biggest problem of Linux is untrustworthy or just badly written scripts.

In this specific case, the damage was still somewhat limited because the Apache server concerned used a specific account created for this service. In this account, however, it was possible to open a shell, with the result that a hacker from the script had written numerous other scripts in the / var / tmp / directory. These scripts were jointly carrying out a DDoS attack on a number of leading websites.

Mandatory Access Control

Of course, it should never have happened to open a shell with the httpd account. This problem is easily prevented by specifying a program like / sbin / nologin or / bin / false as a shell instead of / bin / bash (and fortunately almost every modern Linux distribution does that for service accounts). However, depriving a login shell for service accounts does not offer a comprehensive solution for any security problems. A system for Mandatory Access Control like SELinux does.

On a system where SELinux or AppArmor is active, only actions that have a specific rule in the policy are allowed. This means that an Apache process can, for example, read files in the Apache DocumentRoot or run scripts from the default directory for scripts. An action that is not specifically allowed, however, will be stopped. An example of this is a script that wants to create files in / var / tmp / – and then executes them. Unfortunately, there are still many administrators who switch SELinux off immediately because they can not handle it properly.

Ssh-brute-force

Another popular candidate for a successful hack on Linux is ssh. Secure Shell is a handy service that allows administrators to log in remotely on Linux. At the same time, you activate with ssh a service that makes it possible for everyone to log in. Especially when sshd runs on the standard port 22 and your system is connected directly to the internet.

Several tests show that such a system is found within fifteen minutes and is subjected to the first ssh brute force attack. In an ssh brute force attack, the attacker attempts to gain access by automatically trying obvious usernames and trying out frequently used passwords to break into. If the attacker only sustains this long enough, that will eventually succeed.

However, the ability to access via ssh is fairly easy to stop by providing the ssh service itself with a number of non-standard parameters. To begin with, it is advisable not to offer any ssh services on the standard port 22; automated scripts usually only scan on that port.

Next, it is a good idea to use the AllowUsers option, which lets you specify which users can log in via ssh and deny all other users access. You can also consider using ssh logins with passwords and only grant access to users who use a ssh-public / private-keypaar. With these measures you make sure that ssh becomes virtually impregnable.
Zero-day exploits

Finally, there is another category in Linux (and any other operating system) that needs attention: the zero-day exploit. These are vulnerabilities in software that are not yet (generally) known and therefore have yet to be discovered. This makes it extremely difficult to arm yourself against this. Yet there are measures that you can take.

For starters, it is necessary to regularly install patches and updates. Perhaps the unknown exploit for your distribution has already been found and the solution is ready in the form of a patch. The days of ‘If it is not broke, do not fix it’ are far behind us and every modern computer system that is connected to the Internet should regularly be provided with the very latest patches.

Do you really want to be on top of the facts and keep up to date with new problems, even before patches have been released? Then it is worthwhile to keep an eye on this site. This is where all security problems are published when they are known. This allows you to take immediate action if the problems apply to your environment.

In addition, you can prevent unknown problems to a certain extent by using Mandatory Access Control, which stops your actions that an application does not have to do, and that limits the risk that zero-day exploits will cause damage.

Conclusion

Like any operating system, Linux has a number of weak spots. In addition, however, Linux offers everything that is needed to protect your system against those weak spots. If you want to minimize the risks of hacking your Linux system, it is sufficient to take a few measures. To begin with, every Linux system would have to use SELinux or AppArmor. This prevents applications from performing unwanted actions – for example, the script on the web server that wants to open a shell, but also unknown risks (zero-day exploits).

In addition, a consistent update strategy also helps. If you do not want to check for yourself which new exploits have been published, make sure that any unknown problems can be prevented by installing updates.

A third measure that is quite efficient is offering sshd services on a non-standard port, so dictionary-attacks have little chance. Combine that with the AllowUsers parameter in sshd_config and ensure that remote log-in is only allowed by one account with an unusual name.

Finally, if it is possible to physically secure the server by placing it in a confined space, it also makes it difficult to change the root password unauthorized, resulting in a Linux system that is almost impossible to hack.