Introduction to Linux Security & Hardening

Mattia Zignale
8 min readMay 26, 2021


In this article I will touch some points on Linux Security and Linux Hardening, I won’t go into much deep because I would like to do that in dedicated articles, so enjoy this reading!

General Security

What does make Linux a secure Operating System?

Linux is an open-source Operating System (technically Linux is the kernel), and beacuse of it is more difficult to insert any backdoor or malicious code into the source without anyone noticing. Windows often suffers for bugs that persist for months or years before being patched, and only Microsoft have access to the source code.

Multiuser system

Linux is a multiuser system and could segregate access to files or settings. There is a user called superuser whose username is root, and it has all privilege to do anything on the system, also if files and/or configurations are hidden somewhere from any user in the system.

Own root, own the system.

One of the advatage of Linux is that files and processes can be executed, edited or deleted only by his owner or by root.

Nothing is 100% secure, there is always a compromise between usability and security.

Service account

Some services, daemons or applications in Linux use their own user; for example the web servers use their user to protect exposed files (and the system), they are owner of the files and configurations.

Hackers are people, and therefore often lazy

Generally there are more Windows computers in the world than Linux, mostly on customer side, so this became the most coveted target. In fact who uses Linux is usually a technical user and for this he has a more pronounced security attitude than the normal user.

Windows has many malwares for this very reason; this does not mean that Linux systems are malware-free.

Centralized software management

In Linux systems all the software and applications are managed and installed through a package manager; various distributions have signed repository, this ensures that the software we install is really what it claims to be.

Most of the software on Linux are themself open-source and the benefits are as outlined above.

Security guidelines

If you don’t need a software or service, uninstall it. The risk is to “help” the attacker by increasing your attack surface.

If an attacker exploits your webserver and there is a file sharing service on the same system, it is very likely that they will be able to access that too.

By encrypting communications, man-in-the-middle (MITM) attacks are avoided. Use SFTP, SNMPv3, HTTPS, SSH. Avoid using protocols that communicate in clear text such as TELNET.

Each person who logs into the system should have their own account and this also applies to services. Furthermore, shared accounts decrease the overall security of a system and make auditing difficult.

Users should use their own accounts and when necessary use the sudo command to execute commands or programs with other privileges. Using sudo the actions are logged, improving auditing.

Unlike other, root account is often shared, so it is always necessary to use it with caution and only when strictly necessary.

Use strong passwords (> 12 alphanumeric characters) and change them regularly will increase the security posture of the system. Accounts no longer in use should be removed (or disabled, as needed).

For critical systems (for example military or governmental ones) the authentication must be based on two or more factors, usually a password and a temporary code (OTP) or fingerprint.

Do not start services with root user, they work with their own service accounts. Give to users enough privilege to do their job, nothing more.

Periodically review your system logs and send them to a centralized logging system (usually a SIEM), so in case of deletion you will have a local copy.

Linux has its own built-in firewall: netfilters + iptables. Using the “least privilege” principle, authorize only useful connections to your system and drop all the rest.

In addition to encrypting the connections, it is necessary to encrypt sensitive data even when they are stored on the systems, in order to prevent any reading or alteration by unauthorized parties. The information in the databases must also be encrypted.

Physical Security

Physical Security overview

Physical access to a system is a huge security threat, a malicious user could shut down the system and then start it in single user mode to install his software: authorize physical access only if strictly necessary.
Check physical access as you do for system login.

Only authorized personnel should access to datacenter, any visit to your datacenter should be accompained, and the presence of the datacenter should not be indicated outside.

Also for cloud systems physical security has an important role (your vms in cloud are somewhere in the world as physical machine). Any virtual device you rent or buy is on a physical machine and the vendor trust should be guaranteed. Moreover you have to remember that your vendor has access to your data, so if possible encrypt your cloud environment.

Single user mode security

One of the issue that physical security has, is that a malicious user could reboot physically your machine (for VM could happen through virtual console) and enter into single user mode (often with root without password).

It’s possible to ask for password also in single user mode changing the settings from /sbin/sushell to /sbin/sulogin.

# Set '/sbin/sulogin' to ask password also in single user mode
# Else set '/sbin/sushell' for no password
SINGLE=/sbin/sulogin <--- will ask for password

Generally the files to modify are in /boot/grub/grub.conf and /etc/sysconfig/init, these settings could be different for any distribution.

On Ubuntu systems is important to set a password for root because it generally comes without.

Secure the Boot Loader

To bypass authentication mechanism you can change the init configuration (kernel -> init -> system) with:


In GRUB configuration you can indicate a superuser and a password to protect the kernel and avoid use of parameters for start.

However, the system remains susceptible to attacks if the storage is readable (unencrypted).

Disk Encryption

The Operating System must have access to the decrypted files in order to work with them. In Linux dm-crypt (device mapper crypt) is used for disk encryption, it provides an encryption completely transparent to the user and the system: a new device is created in /dev/mapper and it is possible to use it as a normal disk, even using LVM.

LUKS (Linux Unified Key Setup) is a frontend for dm-crypt, it supports multiple passphrases and it’s also widely used for removable devices.

To more specific content on FDE with LUKS read this article:

Structure of Disk Encryption operation

Setup LUKS

Warning: This process removes all previous data

TIP: Before encrypting the disk it is useful to use shred command and fill the disk with random data. This will make very difficult for an attacker to figure out where the section with the real data begins and ends.

  1. Install cryptsetup
  2. Run:
sudo cryptsetup luksFormat /dev/sdb

The /dev/sdb indicates the disk to encrypt, be careful to select the right disk!

3. Access to the disk with:

sudo cryptsetup luksOpen /dev/sdb OPT

Substitute OPT with the path in /dev/mapper where you will mount the disk. If we want the automount we have to modify the configurations in /etc/fstab and /etc/crypttab.

4. Close the encrypted device:

sudo cryptsetup luksClose OPT

OPT will be our directory in /dev/mapper.

Introduction to PAM

Linux Account Security

An internal user has more access to the system than an external user, a common attack is to use any random user and perform privilege escalation.

One of the countermeasures to make a system more secure is to give users access only to what they need.

PAM (Pluggable Authentication Modules) allows you to manage authentication and, instead of leaving this delicate phase to each application, manage it with these modules.

You can add modules (e.g. biometric modules) to the PAM to change the access modes.
The configurations are in /etc/pam.d and the format of the directives is:

module_interface control_flag module_name module_arguments

The module_interface are:

  • AUTH — User Authentication
  • ACCOUNT — Check if the user is enabled
  • PASSWORD — Change user’s password
  • SESSION — Manage user session

The control_flags tell to PAM what to do with a given result:

  • REQUIRED — The result of the module must be positive to continue
  • REQUISITE — As above, but without invoking other modules
  • SUFFICIENT — Authenticate user if REQUIRED forms are not failed
  • OPTIONAL — The result of the module can be ignored unless it is the only module
  • INCLUDE — Includes configurations from other files

Linux Account Type

root —It can do anything on the system, it always has UID=0 (it is not the root name that gives it “power”)

system users —Have UID < 1000

normal users —Have UID ≥ 1000, are almost exclusively human users (interactive)

Password Security

Don’t leave the complexity of passwords up to users, use the PAM_PWQUALITY module (based on the PAM_CRACKLIB module).

Shadow Password

Initially the passwords were saved in the file /etc/passwd, by enabling shadow passwords are saved in /etc/shadow.

Format of the file /etc/shadow:

  1. username
  2. password hash (asterisk in case of users unable to login directly)
  3. last password change date (epoch format)
  4. days until change allowed
  5. days before change required
  6. days warning for expiration
  7. days after no logins before account is locked
  8. days since epoch when account expires
  9. reserved and unused

Each line represents a user, each field is separated by the “:” character, so the representation of a line in the file is as follows:


In order not to allow users to use their old password, it is necessary to use the PAM_PWHISTORY module.

Monitor the accesses

With these commands:

passwd -l   # Lockpasswd -u   # Unlock

you can lock and unlock an account, or you can edit the passwd file and set nologin instead of the default shell. The login can also be disabled from the PAM_NOLOGIN module.

With last, lastb, and lastlog commands you can review access logs.

In case we want to block remote connections that have repeatedly failed to login we can use fail2ban.

Login can be secured with multifactor authentication using OTP codes. There are PAM modules for Google Authenticator, Duo Security and RSA SecurID.

Security by Account Type

  • Use normal user (non-privileged)
  • Disable direct login with root
  • Use sudo command
  • Root password must be different for each system
  • Ensure root is the only user which has UID=0

Disable root login
Via PAM_SECURETTY: Within the configurations you can specify where root can log in (tty, console). If no terminal is specified, the only way to log in is single user mode.
Via SSH: Edit the configurations in /etc/sshd.

System account and service account
Use only one account per service or application, do not enable login for those accounts.

User account
Use only one account per person, remove unnecessary users, remove anything related to a user to be deleted.

Network Security

Services are also called network services, daemons, or servers, and they listen on specific ports.
They are always running (in the background) and the output is logged by the system, usually in /var/log unless otherwise specified in the configuration files or by the default application configuration. Each service performs a single task: serving web pages, serving databases, sniffing.

  • Using dedicated users for each service allows us to have the advantage of separation of duties
  • Ports under 1024 are privileged ports and require root to open.
  • Unused services should be stopped and uninstalled
  • Avoid using services that communicate in an insecure manner
  • Keep services and system up to date

A TCP Wrapper can be useful to further increase the security posture of our system.

Information Leakage
Avoid disclosing information about the software and version used unless necessary, edit or delete service banners.

xinetd services
These services are located in /etc/xinetd.d/SERVICE, the purpose of xinetd is to start the services in case it notices a connection to a specific port.

Originally published at