A freshly installed Linux system is not a secure system. Mainstream distributions ship with configurations designed to work out of the box, not to withstand an intrusion attempt. Strengthening your Linux system’s security day to day comes down to a few specific steps, repeated regularly, that reduce the attack surface without turning your machine into an unusable fortress.
systemd sandboxing: confine each Linux service individually
Most Linux security guides cover user accounts and file permissions. Less often discussed is confining the services themselves. A web server or database manager often runs with far broader permissions than it needs.
Have you ever noticed that a compromised service can read files unrelated to its function? That’s exactly what systemd sandboxing addresses. Three directives make a big difference:
- ProtectSystem=strict mounts the root file system as read-only for the service in question, preventing changes outside explicitly permitted directories.
- PrivateTmp=true gives the service an isolated temporary directory that other processes cannot see. An attacker who gains access to the service’s /tmp cannot see the system’s /tmp.
- NoNewPrivileges=true prevents privilege escalation after the service starts, even if a setuid binary is present in the execution path.
Configure these options in the service’s unit file, under the [Service] section. After each change, restart the service and check that it works as expected. A directive that is too restrictive can block legitimate access to a socket or configuration file.
To explore this approach and other hardening methods, Hebdo Linux’s security advice covers several scenarios for both workstations and servers.
Check the actual status of SELinux and AppArmor on your system
Having SELinux or AppArmor installed does not mean these mechanisms are protecting anything. Why is this so often overlooked? Because the presence of a security module in the kernel creates a false sense of protection.
An inactive security module does not protect any processes. On a distribution such as Ubuntu, AppArmor is installed by default, but not all profiles are in “enforce” mode. Some run in “complain” mode, which only logs violations without blocking them.
Practical verification commands
For AppArmor, the aa-status command lists the loaded profiles and their modes. Every profile in “complain” mode is an open door. For SELinux, sestatus shows whether the mode is “enforcing”, “permissive” or “disabled”.
Checking these statuses is a useful part of your daily checks. A script run by cron or a systemd timer can send an alert if the mode switches to permissive after a reboot or kernel update. This kind of silent regression is common during version upgrades.
Linux patches: make sure the update is actually in effect
Installing a patch is not enough. After a kernel update, your machine may keep running the old kernel until it reboots. The package manager says “up to date”, but the system remains vulnerable.
Check the active kernel after every critical update. The uname -r command displays the version of the kernel currently running. Compare it with the latest installed version, shown by your package manager. If they differ, a reboot is required.
Managing patches on a production server
On a server, an immediate reboot is not always possible. Document the difference between the installed kernel and the active kernel. Some distributions offer a “live patching” mechanism that applies kernel patches without a reboot, but it does not cover every type of vulnerability.
One often-overlooked detail is alternative boot entries. If your bootloader keeps old kernels, an accidental reboot into an outdated entry can reintroduce patched vulnerabilities. Regularly remove old kernels from your boot menu once you have confirmed the new one is stable.
Reduce your exposed network attack surface day to day
Every open port is a potential entry point. On a Linux workstation, services such as CUPS (printing), Avahi (network discovery) or an SSH server may be listening without your knowledge.
The ss -tlnp command lists all listening ports and their associated processes. Review the list:
- Disable any service you do not use (Avahi on a machine without a network printer, for example) with
systemctl disable --nowfollowed by the service name. - An SSH server exposed on the standard port (22) is more secure with public-key authentication than with passwords. Disable password authentication in
/etc/ssh/sshd_configby settingPasswordAuthentication no. - The nftables firewall (or iptables, depending on your distribution) should have a default policy that rejects incoming traffic, with explicit exceptions only for the services you need.
Fewer listening services mean less attack surface to monitor. This review takes just a few minutes and significantly reduces the risk of remote exploitation.
Securing a Linux system is not a one-off task. Confining services, checking that security modules are active, confirming that patches are actually running and closing unnecessary ports form a short cycle. Repeated every week, this cycle covers most common attack vectors on a Linux workstation or server.
