DEV Community

Marek „Netbe” Lampart
Marek „Netbe” Lampart

Posted on

Linux Hardening: Building a Secure Server from the Kernel to the Application Layer

Practical security checklist for production Linux environments

Linux is everywhere.

It powers:

  • cloud infrastructure,
  • web servers,
  • Kubernetes nodes,
  • databases,
  • network appliances,
  • security platforms.

Many administrators believe that Linux is secure by default.

The reality is different.

Linux provides powerful security mechanisms, but they must be correctly configured.

A fresh installation is only the beginning.

A production server should go through a hardening process:

Fresh Linux Installation

        ↓

System Updates

        ↓

Kernel Security

        ↓

User Management

        ↓

Network Protection

        ↓

Service Hardening

        ↓

Monitoring

        ↓

Continuous Auditing
Enter fullscreen mode Exit fullscreen mode

What is Linux Hardening?

Linux hardening is the process of reducing the attack surface of a Linux system.

The goal is simple:

Allow only required functionality and block everything unnecessary.

A hardened server should follow:

Principle of Least Privilege

Every user, process and service receives only the permissions it needs.

Example:

Bad:

Web Application

↓

root privileges

↓

Entire system access
Enter fullscreen mode Exit fullscreen mode

Better:

Web Application

↓

Dedicated user

↓

Limited permissions
Enter fullscreen mode Exit fullscreen mode

1. Keep the System Updated

The first security layer is patch management.

Check available updates:

Debian/Ubuntu:

apt update

apt upgrade
Enter fullscreen mode Exit fullscreen mode

RHEL/Fedora:

dnf update
Enter fullscreen mode Exit fullscreen mode

For production environments:

Do not update randomly.

Use:

Testing

↓

Staging

↓

Production
Enter fullscreen mode Exit fullscreen mode

A security update should improve protection without breaking applications.


2. Remove Unnecessary Services

Every running service is a potential entry point.

Check running services:

systemctl list-units --type=service
Enter fullscreen mode Exit fullscreen mode

Example:

A server hosting a website probably does not need:

Bluetooth

Printing service

Avahi discovery

Unused databases
Enter fullscreen mode Exit fullscreen mode

Disable unnecessary services:

systemctl disable service_name

systemctl stop service_name
Enter fullscreen mode Exit fullscreen mode

Security rule:

If a service is not required, remove it.


3. Secure SSH Access

SSH is one of the most attacked services on Linux servers.

Basic hardening:

Edit:

/etc/ssh/sshd_config
Enter fullscreen mode Exit fullscreen mode

Disable root login:

PermitRootLogin no
Enter fullscreen mode Exit fullscreen mode

Disable password authentication:

PasswordAuthentication no
Enter fullscreen mode Exit fullscreen mode

Use keys:

Public Key Authentication
Enter fullscreen mode Exit fullscreen mode

Example:

ssh-keygen -t ed25519
Enter fullscreen mode Exit fullscreen mode

Modern SSH authentication should look like:

User

↓

SSH Key

↓

Server Verification

↓

Access Granted
Enter fullscreen mode Exit fullscreen mode

4. Protect SSH Against Brute Force

Install:

fail2ban
Enter fullscreen mode Exit fullscreen mode

Example:

apt install fail2ban
Enter fullscreen mode Exit fullscreen mode

Architecture:

Failed Login Attempts

        ↓

Fail2ban

        ↓

Firewall Rule

        ↓

IP Block
Enter fullscreen mode Exit fullscreen mode

However, blocking attackers is only one layer.

The better approach:

  • disable passwords,
  • use MFA,
  • restrict access by firewall.

5. Configure Firewall Rules

A server should not expose unnecessary ports.

Check listening services:

ss -tulpn
Enter fullscreen mode Exit fullscreen mode

Example output:

22/tcp    SSH

80/tcp    HTTP

443/tcp   HTTPS
Enter fullscreen mode Exit fullscreen mode

Everything else should be reviewed.


Example using nftables:

nft list ruleset
Enter fullscreen mode Exit fullscreen mode

Security model:

Internet

↓

Firewall

↓

Allowed Services Only

↓

Application
Enter fullscreen mode Exit fullscreen mode

6. Use Mandatory Access Control

Traditional permissions:

User

↓

Group

↓

File permissions
Enter fullscreen mode Exit fullscreen mode

are not always enough.

Linux provides:

SELinux

Common in:

  • Red Hat Enterprise Linux,
  • CentOS,
  • Fedora.

Example:

getenforce
Enter fullscreen mode Exit fullscreen mode

AppArmor

Common in:

  • Ubuntu,
  • Debian.

Check profiles:

aa-status
Enter fullscreen mode Exit fullscreen mode

These systems answer:

What is a process allowed to do, even if it is compromised?


7. Kernel Hardening

The Linux kernel is the foundation.

Check kernel version:

uname -r
Enter fullscreen mode Exit fullscreen mode

Important mechanisms:

Kernel parameters

Example:

/etc/sysctl.conf
Enter fullscreen mode Exit fullscreen mode

Disable IP forwarding:

net.ipv4.ip_forward=0
Enter fullscreen mode Exit fullscreen mode

Protect against SYN attacks:

net.ipv4.tcp_syncookies=1
Enter fullscreen mode Exit fullscreen mode

Apply:

sysctl -p
Enter fullscreen mode Exit fullscreen mode

8. Secure User Accounts

Review users:

cat /etc/passwd
Enter fullscreen mode Exit fullscreen mode

Find accounts with shells:

cat /etc/passwd | grep bash
Enter fullscreen mode Exit fullscreen mode

Remove unused accounts:

userdel username
Enter fullscreen mode Exit fullscreen mode

Check sudo privileges:

cat /etc/sudoers
Enter fullscreen mode Exit fullscreen mode

Avoid:

ALL=(ALL) ALL
Enter fullscreen mode Exit fullscreen mode

for unnecessary users.


9. Filesystem Security

Important directories:

/etc

/bin

/usr

/var

/home
Enter fullscreen mode Exit fullscreen mode

Check permissions:

ls -la
Enter fullscreen mode Exit fullscreen mode

Sensitive files:

/etc/shadow
Enter fullscreen mode Exit fullscreen mode

should be:

-rw-r-----
Enter fullscreen mode Exit fullscreen mode

not:

-rw-rw-rw-
Enter fullscreen mode Exit fullscreen mode

10. Use Secure Mount Options

Example:

Temporary filesystem:

/tmp
Enter fullscreen mode Exit fullscreen mode

can use:

nodev

nosuid

noexec
Enter fullscreen mode Exit fullscreen mode

Meaning:

nodev

No device files.

nosuid

Ignore SUID bits.

noexec

Prevent execution.


Example:

/dev/sdb1 /tmp ext4 defaults,nodev,nosuid,noexec
Enter fullscreen mode Exit fullscreen mode

11. Audit System Activity

Security without visibility is impossible.

Linux provides:

auditd

Install:

apt install auditd
Enter fullscreen mode Exit fullscreen mode

Check status:

systemctl status auditd
Enter fullscreen mode Exit fullscreen mode

Example events:

User login

↓

File modification

↓

Privilege change

↓

Audit record
Enter fullscreen mode Exit fullscreen mode

12. Centralize Logs

System logs are critical.

Modern Linux uses:

systemd-journald
Enter fullscreen mode Exit fullscreen mode

Check logs:

journalctl
Enter fullscreen mode Exit fullscreen mode

Examples:

SSH logs:

journalctl -u ssh
Enter fullscreen mode Exit fullscreen mode

Kernel messages:

journalctl -k
Enter fullscreen mode Exit fullscreen mode

Production environments usually forward logs to:

  • SIEM,
  • Elasticsearch,
  • Graylog,
  • Splunk.

13. Container Security on Linux Hosts

Modern Linux servers often run containers.

Docker security should include:

Rootless containers

Instead of:

root

↓

Docker daemon

↓

Container
Enter fullscreen mode Exit fullscreen mode

Use:

User

↓

Rootless Docker

↓

Container
Enter fullscreen mode Exit fullscreen mode

Seccomp

Limit system calls:

Allowed:

read()

write()

open()


Blocked:

mount()

ptrace()
Enter fullscreen mode Exit fullscreen mode

cgroups v2

Control:

  • CPU,
  • RAM,
  • processes.

Example:

Container

↓

Memory limit

↓

Host protection
Enter fullscreen mode Exit fullscreen mode

14. Backup and Recovery

Security is incomplete without recovery.

A ransomware attack changes the question:

Not:

Can we prevent every attack?

But:

How quickly can we recover?

Backup strategy:

Production

↓

Backup

↓

Offline Copy

↓

Recovery Test
Enter fullscreen mode Exit fullscreen mode

15. Automated Security Auditing

Manual checks are not enough.

Useful tools:

Lynis

Linux security auditing:

lynis audit system
Enter fullscreen mode Exit fullscreen mode

OpenSCAP

Compliance scanning:

  • CIS Benchmarks,
  • security policies.

Docker Bench Security

Container security auditing.


Linux Hardening Checklist

System

✅ Updates enabled
✅ Unused packages removed
✅ Services reviewed
✅ Time synchronization configured


Authentication

✅ SSH keys
✅ Root login disabled
✅ MFA where possible
✅ Password policies


Network

✅ Firewall enabled
✅ Minimal open ports
✅ Network monitoring


Kernel

✅ sysctl hardening
✅ Secure parameters
✅ Updated kernel


Filesystem

✅ Correct permissions
✅ Secure mounts
✅ Encryption where required


Monitoring

✅ auditd
✅ journald
✅ Central logging
✅ Alerts


Final Thoughts

Linux is not secure because it is Linux.

Linux is secure because it provides the tools required to build a secure system.

The difference between a normal Linux server and a production security-grade server is configuration.

A mature security approach combines:

Linux Hardening

+

Firewall

+

SELinux/AppArmor

+

Audit Logging

+

Container Security

+

Monitoring

+

Regular Testing
Enter fullscreen mode Exit fullscreen mode

Security is not a single command.

It is a continuous process of reducing risk, monitoring changes and improving the system over time.


Tags:

#Linux
#CyberSecurity
#DevSecOps
#LinuxSecurity
#SystemAdministration
#Hardening
#InfrastructureSecurity
#CloudSecurity

Top comments (1)

Collapse
 
circuit profile image
Rahul S

Solid checklist. The one thing I'd promote from "item #11" to load-bearing: auditd and local logs are only worth anything if they're immutable and already off the box before you need them. A checklist quietly assumes the attacker isn't root yet, but auditd, local log files, and filesystem perms are exactly the controls you lean on after a compromise — and a local auditd that root can turn off with auditctl -e 0, or whose logs they can truncate, is theater. Set the audit config immutable (-e 2, so rules can't change until reboot) and ship logs push-only to a separate trust domain, so root-on-the-host doesn't also mean root-on-the-evidence. Same reasoning is why the key-only SSH line matters more than fail2ban — one actually closes the door, the other just trims the noise from people rattling it.