Safety First

Security is a problem for any computer that faces the Internet, and the solution can be as big and comprehensive as you want to make it. Firewalls, penetration testing, and Intrusion Prevention Systems (IPS) are all important, but you can do a lot for securing your system before you even start adding these critical security layers. This article highlights some basic security steps that are so easy they are often overlooked.

If you are administering a Linux system that you can install from scratch, keep in mind that fewer services on the system means fewer avenues for attack, so one worthy approach is to leave out everything you don't really need. Many distributors offer specially designed minimal versions for reducing the attack footprint. You can then set up a miniature Linux and import only the packages you genuinely need.

Once the system is running, keep it up to date. Security updates, in particular, need to be checked daily and installed immediately. Many distributions have automated processes for installing security updates. On Debian and Ubuntu, for instance, the buzzword is "unattended upgrades " [1].

In addition to time-honored chestnuts like installing updates and only using the services you need, a few additional actions can really help to reduce your exposure to attack. Read on for some easy steps you can take right now.

Disable Root Login

The password for the root account, which belongs to the user with the most far-reaching privileges, is a particularly valuable target for an attacker. Some contemporary Linux alternatives, such as Ubuntu, disable root login by default, but other Linux distros still allow it. If the system can be accessed via SSH over the Internet, you will find numerous login attempts by automated bots in the log file /var/log/auth.log (Listing 1, lines 1 to 4) or in the systemd log (from line 5), in which the attackers try to gain access to the system by simply guessing the root password.

In Listing 1, someone has tried to log in as root from a system with the IP address 222.186.180.223. If you want to know where the login attempt came from, enter whois IP_address. The output is shown in a slightly curtailed form in Figure 1.

Figure 1: The whois command lets you determine who is behind an IP address.

In this case, the attacker guessed wrong (Failed password for root). However, if you had chosen a weak password, or if the attacker got lucky, you could lose control over the system. For this reason, you should completely disable logging in as root if it isn't already disabled on your system. An active root account is usually not needed anyway, since a properly configured account can assume administrative rights with sudo.

In the first step, create a user named, say, bob and assign a password for the account (Figure 2). To allow Bob to execute commands with a prefix sudo as root, you have to add them to the Sudo user group with the usermod -a -G sudo bob command. (Check the documentation for your distro: Ubuntu, and some others automatically add the first user account created at installation to the Sudo group.)

Figure 2: Most distributions do not impose requirements for new passwords.

To test if everything works, log out and then log in again as bob. Then execute the command sudo ls /root. If you do not receive an error message, everything is fine. You might not see any output: On a freshly installed system, the /root directory is usually empty.

To disable the login for root, edit the configuration file of the SSH server, /etc/sshd/sshd_config. In the PermitRootLogin yes line, change the yes to a no and save the file. Then run the sudo usermod -p '!' root command to deactivate the root user. Finally, restart the SSH service by typing systemctl restart ssh.

From now on, the system will no longer accept login attempts by the root user. You have thus successfully taken the root account out of the line of fire and noticeably reduced the system's attack surface.

Enforce Stronger Passwords

According to analysis [2] by the security company SplashData, the five most frequently used passwords last year were 12345, 123456789, querty, password, and 1234567. Similar studies by other companies and institutions come to almost identical conclusions.

As a maintainer of a Linux system, you should not rely on your users deciding to choose sensible and sufficiently complex passwords by themselves. You have to give them a little help. The Pwquality PAM module can help you enforce stronger passwords. You install Pwquality on a Debian or Ubuntu system with the command from Listing 2.

The cracklib-runtime package contains a dictionary with which the module detects frequently used and overly simple passwords and warns not to use them. Give it a try: Use the command passwd to change the password for the bob account to 12345678. You will see an unequivocal BAD PASSWORD warning, but you can still change the password to 12345678 (Figure 3).

Figure 3: The Pwquality PAM module warns users when they try to set weak passwords.

To enforce more complex passwords, you have to make another adjustment to the /etc/pam.d/common-password file. Look for the line that reads password requisite pam_pwquality.so retry=3. By attaching various parameters, you can harden the rules for new passwords (Listing 3). The individual parameters give you an easy option for controlling the password requirements (see Table 1).

After a reboot, the new password controls are active. If you now try to change Bob's password to 12345678, the system will force you to follow the rules in /etc/pam.d/common-password. It rejects your attempt to input 12345678 (Figure 4).

Figure 4: With the right settings, Pwquality does not allow weak passwords.

Now try a "real" password, like Iwbity1,itcoY. These are the first letters of the first words in Robinson Crusoe by Daniel Defoe ("I was born in the year 1632, in the city of York"). It fulfills all requirements for upper- and lowercase letters – a number and a non-standard character are also included – and is therefore accepted.

Log In by Key Only

What could be better than the strongest password? No password at all. SSH lets you prove your identity with a cryptographic key instead of the password. To do this, you first create a key pair consisting of a secret and a public key on the system from which you want to log in. In this example, I use an RSA key type with a length of 4096 bits:

$ ssh-keygen -t rsa -b 4096

The command now wants to know where to store the keys. The recommendation is to keep the default settings and simply press Enter. Then you decide whether you want to protect the key with a passphrase – giving you additional protection should the key ever fall into the wrong hands. If you simply press Enter, the key can be used without a passphrase (Figure 5).

Figure 5: SSH keys offer a convenient option for logging in on remote computers without a password.

You now need to upload the public part of the key pair you have generated to the server where you want to log in with this key:

$ ssh-copy-id bob@IP_address

All done. You can log in on the remote server using ssh bob@IP_address without entering a password.

As long as you practice this process for all users who log in on the remote system, you can also completely disable password-based logins. To disable password logins, change the PasswordAuthentication line to PasswordAuthentication_no in the SSH server configuration in /etc/ssh/sshd_config. After restarting the SSH service, login by password won't be possible – access is key-based only.