Linux security: 8 more system lockdown controls

System lockdown doesn't have to be a big or a horrible task that strikes dread into the most jaded of sysadmin hearts. No, it's not intuitive or necessarily trivial to properly lock down a Linux server, but it's also not quantum physics either. In my previous article, Sysadmin security: 8 Linux lockdown controls, I covered eight essential changes that you need to make to every Linux system regardless of function. In this article, I cover more system controls that you can implement quickly and at no cost.

These controls originate from a variety of sources, such as my own experience, DISA STIGs, and other sysadmins. The controls listed here are in no particular order of importance or severity.

Banner

Whether your system has a graphical user interface or not, you need to create a banner that displays to the user at logon. The banner needs to warn the user that the system is protected by <Your country's laws and regulations> and that misuse of the system is a criminal offense. The banner needs to display for users at the console as well as for those who log in over the network.

Edit the /etc/issue for console users and the /etc/issue.net for network users. Be sure to provide the full path to the file you're using for the banner in the /etc/ssh/sshd_config file as follows:

Banner /etc/issue.net

You may use any file you want, but you must edit the Banner path and point it to the file that contains your message.

No, setting up a banner will definitely not prevent an attacker from successfully compromising your system. Still, it destroys the defense argument that the attacker had no awareness that the system was a private, protected system.

Password complexity enforcement

Enforce password complexity, for those systems that still use passwords, by modifying the parameters in the /etc/security/pwquality.con file (shown below). This file contains a list of editable parameters to enforce strong passwords for your systems.

# Configuration for systemwide password quality limits
# Defaults:
#
# Number of characters in the new password that must not be present in the
# old password.
# difok = 5
#
# Minimum acceptable size for the new password (plus one if
# credits are not disabled which is the default). (See pam_cracklib manual.)
# Cannot be set to lower value than 6.
# minlen = 9
#
# The maximum credit for having digits in the new password. If less than 0
# it is the minimum number of digits in the new password.
# dcredit = 1
#
# The maximum credit for having uppercase characters in the new password.
# If less than 0 it is the minimum number of uppercase characters in the new
# password.
# ucredit = 1
#
# The maximum credit for having lowercase characters in the new password.
# If less than 0 it is the minimum number of lowercase characters in the new
# password.
# lcredit = 1
#
# The maximum credit for having other characters in the new password.
# If less than 0 it is the minimum number of other characters in the new
# password.
# ocredit = 1
#
# The minimum number of required classes of characters for the new
# password (digits, uppercase, lowercase, others).
# minclass = 0
#
# The maximum number of allowed consecutive same characters in the new password.
# The check is disabled if the value is 0.
# maxrepeat = 0

The following are the recommended values. Note: Be sure to uncomment the parameter line to enable the enforced value.

difok = 8

minlen = 15

dcredit = -1

ucredit = -1

lcredit = -1

ocredit = -1

minclass = 4

maxrepeat = 3

maxclassrepeat = 4

These parameters help to ensure that system passwords are far more secure than the default settings. It is recommended to use multi-factor authentication rather than passwords for enhanced system access security.

Note: The minlen (minimum length) parameter should be set to a value of 15 or greater. Teach users to use passphrases rather than attempting to find a single word that meets the criteria.

Minimum password lifetime

Some clever users change their passwords multiple times to circumvent system security. When forced to update their passwords, they change their passwords enough times to beat system security to eventually set their password back to the original. The PASS_MIN_DAYS parameter in the /etc/login.defs file can prevent this activity. Set the value to 1 or greater. The default is 0, which is what causes the security problem.

PASS_MIN_DAYS 1

Setting this parameter means that the user must keep the new password for a minimum of one day before changing it again. You may set the value to any number you want, but preventing the user from immediately changing multiple times seems to resolve the issue.

Maximum password lifetime

Perhaps even more dangerous than minimum password lifetime is the maximum password lifetime setting. The default is 99999, which means that the user would never have to change their passwords. This is a serious security violation.

Depending on your company's policies and security needs, you should enforce password changes in the 60 to 90-day range. To enforce such a system-wide change, edit the PASS_MAX_DAYS setting in the /etc/login.defs file.

PASS_MAX_DAYS 60

This setting forces users to change their passwords every 60 days. Yes, you will hear grumbling, especially when coupled with the PASS_MIN_DAYS restriction. Security wins over user complaints.

Sudoer security

Often, sysadmins configure their user accounts to use the sudo command with no password. This is a serious security violation and one that should not be allowed under any circumstances on any system, regardless of function.

Edit the /etc/sudoers file with visudo and remove all instances of NOPASSWD in the file.

Additionally, check for instances of "!authentication" in the /etc/sudoers file. This entry allows a user who has sudo access to continue to use sudo without re-authentication. This is a security violation. Remove all instances of "!authentication" from the /etc/sudoers file.

Failed login delay

To help thwart brute-force attacks on user accounts, you should set the login fail delay to at least 4 seconds. This deters brute-force attacks but may also help users to enter the correct password, which does become more difficult for longer passwords and passphrases.

This parameter is set in the /etc/login.defs file. The number is the number of seconds the system pauses before presenting a new login prompt after a failed login attempt.

FAIL_DELAY 4

Four seconds is short enough not to frustrate users who might have hit the wrong key by accident but long enough to prevent repeated login attempts by bots.

Disable device automounting

Automounting of filesystems introduces security risks from unknown devices that might be plugged into a system. In other words, an attacker could plug in a USB device to deliver a payload when the device automounts. Disable automounting by stopping and disabling the autofs service.

$ sudo systemctl stop autofs

$ sudo systemctl disable autofs

It might be a little less convenient to have to manually mount filesystems after a new device is plugged into the system, but the increase in security offsets the extra three seconds of labor required to mount a device. This allows the system administrator the opportunity to disable, wipe, or eject an unauthorized device.

Restrict file creation permissions

We're going back to the /etc/login.defs file to make a system-wide change. When users create new files, they typically receive permissions of 644 resulting from the umask filter setting of 022. To enhance security, all new files should be created with a umask of 077, which results in new files having 600 as their default permissions.

UMASK 077

For most users, it might matter less, but for files created by root, this setting is mandatory. Setting it system-wide ensures consistency.

Wrap up

Enhancing system security is one of the system administrator's primary tasks. New systems, inherited systems, and systems that serve niche functions are the most vulnerable on your network. Special care must be taken to protect every network system. Often the compromise of one system allows the compromise of more because now the attacker is on the inside of the network and has control of one or more systems.

Some of these security controls might seem heavy-handed, but compared to recovering after a breach, it's just part of today's "normal."

[ Want to learn more about security? Check out the IT security and compliance checklist. ]