A Linux system, even one known for its robustness, is not immune by default to attacks. Linux security relies on a set of configurations, access rules, and monitoring mechanisms that must be activated and maintained manually. Without intervention, a freshly installed server or workstation exposes unnecessary services, open ports, and accounts with overly broad permissions.
Prioritizing kernel patches: the real challenge of Linux security
Competitors all repeat that one must update their system. The advice remains valid, but the reality has changed. In 2024, the Linux kernel recorded 3,108 CVEs, an increase of about 79% compared to the 1,736 CVEs in 2023, according to the NIST’s NVD database.
This explosion does not indicate a degradation of the code. It results from the improvement of automated analysis tools, some of which leverage artificial intelligence to scan the approximately 40 million lines of the kernel. Since February 2024, the Linux kernel has become its own CVE Numbering Authority (CNA), which accelerates the reporting of each detected vulnerability.
For an administrator, blindly applying every patch released amounts to chasing an almost continuous stream of updates. The right approach is to sort CVEs by CVSS score and by the actual exposure of the system. A critical vulnerability on a network module loaded in production deserves an immediate patch. A vulnerability on a hardware driver absent from the machine can wait for the next maintenance cycle.
To track these developments and understand their concrete impact, security information on Hebdo Linux regularly details kernel patches and alerts associated with major distributions.
Reducing the attack surface on a Linux server
System hardening aims to remove anything that has no reason to exist on the machine. Each active service, each open port, and each installed package represents a potential entry point for an attacker.
Unnecessary services and packages
After a standard installation, several services run without anyone having requested them: print server (CUPS), Avahi for local network discovery, or even a mail agent (Postfix, Exim). On a production server, these components are useless and expand the attack surface. The command systemctl list-unit-files –state=enabled allows for precise identification of what starts automatically.
Disabling a service is not always enough. If the package remains installed, accidental reactivation or local exploitation remains possible. Completely removing the package is the most reliable method.
Network configuration and firewall
A properly configured firewall serves as the first barrier between the network and internal services. On recent distributions, nftables is gradually replacing iptables. The logic remains the same: block all incoming traffic by default, then open only the necessary ports.
- Allow port 22 (SSH) only from known IP addresses, never from the entire internet.
- Close database-related ports (3306 for MySQL, 5432 for PostgreSQL) on the public interface and expose them only on the local interface or a private network.
- Enable logging of rejected packets to detect scanning attempts.
User control and privilege escalation
User account management determines who can do what on the system. Using a root account on a daily basis remains one of the most common mistakes, even on machines managed by technical profiles.
Sudo should replace any direct root login. Every command executed via sudo is logged with the user’s identity, creating an audit trail that can be exploited in case of an incident. The /etc/sudoers file allows for restricting commands authorized by user or group.
Beyond sudo, mandatory access control modules like SELinux (Red Hat, Fedora distributions) or AppArmor (Ubuntu, Debian) add a layer of restriction by process. Even if an attacker compromises a service, the module prevents access to files or directories outside the scope defined by the security policy.
- Apply the principle of least privilege: each user has only the rights necessary for their task.
- Disable unused accounts rather than leaving them dormant with a weak password.
- Configure automatic password expiration via chage to enforce periodic renewal.
- Regularly check the /etc/passwd and /etc/group files to spot unexpected accounts or groups.
Logging and detecting abnormal behavior on Linux
A system can be compromised for weeks without anyone noticing if the logs are neither centralized nor monitored. Logging is not only useful for post-incident analysis: when well utilized, it allows for detecting an ongoing intrusion.
The systemd journal (journalctl) centralizes system events, but its default rotation can erase traces before they are analyzed. Exporting logs to a remote server (via rsyslog or syslog-ng) ensures that an attacker who gains root access cannot delete their own traces locally.
To go further, tools like auditd allow monitoring specific events: modification of a sensitive configuration file, addition of a user, change of permissions on a critical directory. Each audit rule generates a timestamped entry that can be exploited to reconstruct the timeline of an incident.
The combination of a strict firewall, granular access control, and exported logging covers the three axes of Linux security: prevention, restriction, and detection. Neglecting any of these axes is akin to leaving a door open, even if the other two are locked.
