This page is meant to be a living document for settings, processes, etc. used to harden systems running any flavor of Linux. This page can be used as a guide for implementing security best practices.
When possible a minimal install of any given distribution should be used in order to avoid any unneccary processes running. If this is not feasible then an audit should be performed to determine all the absolutely necessary services. Any service deemed extraneous should be disabled using systemctl or similar. Depending on how packages are installed on the distribution it may be useful to pin or version lock related packages.
A periodic audit of package updates should be performed to evaluate the changes to required software to ensure both security and functionality are not broken by patching. Unless patching impairs the production service then security patches should always be applied. A patching policy using the below guidelines should created.
Patching Policy
The following should be covered in policy:
In a production environment the goal is to limit user access as much as possible. Tooling to gather information about the status of systems and services should be implemented in such a manner where if troubleshooting needs to occur it is not necessary to access a production service or system directly.
With this in mind when users are created it is best to use some sort of centralized software for managing users/groups and security auditing along. This can be achieved implementing services like OpenLDAP, ActiveDirectory, Free IPA, NIS, etc. which can be a part of identity and access management (IAM).
Additionally, MFA should be used in conjunction with a strong password policy when necessary. If using keybased authentication a policy for managing keys should be established as well.
ssh
If running an ssh server, /etc/ssh/sshd_config should be audited and configured to allow only the necessary users/services access. Details: https://man.openbsd.org/sshd
sudo
From the manual page:
sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. The invoking user's real (not effective) user ID is used to determine the user name with which to query the security policy. The main configuration files for this command are /etc/sudoers and any file in /etc/sudoers.d/.
access.conf
From the manual page:
The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask) or (user/group, tty) combinations for which a login will be either accepted or refused.
The configuration of PAM to use access file supplements the sudoers and SSH access. The goal of the configuration is to ensure that root is never accessed via any means other than by privileged users.
Service Accounts
It is best to create a service account for any critical recurring automation that occurs on a system. A service account ensures that the entity running the automation only has access to necessary resources. A service account is usually created without a password, shell, and home directory. It can be allowed to run some subset of
The goal of enabling the firewall is to allow access to only the needed services running on a server. IPTables is commonly used on most distributions with the adoption of nftables becoming more prevalent. Some distributions provide commands on top of those to make firewall management easier. Such as:
AppArmor uses profiles to manage a program's access to system resources. Documentation can be found here.
SELinux defines access controls for applications, processes and files with security policies. Documentation can be found here.