7.1 Hardening a Linux System

Understanding Linux Hardening

Hardening is the process of making a system significantly more resistant to compromise, abuse, and accidental damage. It is not a product or a one‑time task, but an ongoing process of:

• Reducing attack surface (removing what you don’t need)
• Enforcing least privilege (tightening what must remain)
• Adding defense in depth (multiple layers of protection)
• Continuously monitoring and adjusting

Hardening also has trade‑offs: security vs. convenience, security vs. performance, and security vs. flexibility. As you read, always ask: “What risk am I reducing?” and “What cost am I accepting?”

This chapter gives you a structured, system‑wide approach. Later subchapters (kernel hardening, FIM, vulnerability scanning) dive deeper into specific tools and mechanisms.

Threat Modeling for Linux Systems

Before changing anything, define what you are defending and against whom.

Identify Assets

Typical assets on a Linux system:

• Credentials: SSH keys, API tokens, password hashes, Kerberos tickets
• Data: databases, configuration files, logs, intellectual property
• Services: web server, SSH access, container runtime, databases
• Availability: uptime for production services, build pipelines, etc.

Identify Adversaries and Capabilities

Examples:

• Opportunistic internet bots: port scans, exploiting known CVEs
• Malicious insiders: already have some level of access
• Targeted attackers: willing to invest time, use zero‑days, social engineering
• Ransomware groups: focused on encryption, lateral movement, backups

Knowing this informs how strict you must be with:

• Exposure (public ports, open services)
• Authentication strength (MFA, SSH keys)
• Monitoring and logging requirements
• Backup and recovery strategies

Define Security Objectives

Common objectives:

• Prevent remote compromise: strong network boundaries, patching, service reduction
• Contain compromise: strong user separation, file permissions, MAC systems
• Detect compromise: logging, alerting, FIM, vulnerability scanning
• Recover quickly: backups, configuration management, reproducible builds

Write down a small, concrete policy for a system (e.g., “Public web server: only ports 80/443, SSH from VPN, automatic security updates nightly, logs shipped off‑host”).

Principles of System Hardening

Least Privilege

Each component (users, processes, services) should have only the permissions it needs:

• Non‑root services (use system users)
• Fine‑grained sudo rules instead of blanket ALL=(ALL) ALL
• File ownership that restricts sensitive configs and secrets

This reduces blast radius when something is compromised.

Attack Surface Reduction

Every component is a potential entry point.

Typical measures:

• Uninstall or disable unused packages and services
• Remove unused network listeners
• Avoid unnecessary language runtimes and frameworks on critical hosts
• Reduce kernel attack surface (modules, syscalls, etc.—covered in “Kernel hardening”)

Defense in Depth

Assume individual controls will fail:

• Network firewall + host firewall + service configuration
• File permissions + MAC (SELinux/AppArmor) + container boundaries
• Local logs + central logging + FIM + vulnerability scanning

You want multiple, independent obstacles for an attacker.

Secure by Default and Immutability

Strive for:

• Secure defaults: services ship with restrictive configs, not permissive ones
• Configuration as code: manage configs and hardening policies via tools (Ansible, etc.)
• Immutable/ephemeral infrastructure where possible: rebuild instead of patching in place

---

Baseline Hardening Checklist

This section outlines a high‑level baseline for a generic Linux server. Later sections dig into each category more deeply.

1. Inventory & exposure
• Document what services run and why
• Restrict exposed ports; block everything else
• Place public services behind load balancers or reverse proxies when possible
2. Users & authentication
• Unique user accounts (no shared logins)
• Strong password policies or, preferably, SSH keys
• Disable password SSH logins when feasible
• Remove or lock unused accounts
3. Software & updates
• Minimal package set
• Enable security repositories/updates
• Define and use a patching schedule; emergency path for critical CVEs
4. Network security
• Host firewall with default‑deny inbound
• Restrict admin services (SSH, web admin) to trusted networks/VPN
• Disable legacy/protocols (e.g., old TLS, weak ciphers) in services
5. File permissions & data protection
• Tighten permissions of sensitive files (/etc/shadow, private keys, secrets)
• Separate data across appropriate mount points
• Consider encryption (LUKS, encrypted home) for sensitive data
6. Services & daemons
• Run as dedicated, least‑privileged users
• Use sandboxing/isolation where possible (systemd protections, containers)
• Disable or restrict remote administration interfaces
7. Logging, monitoring & alerting
• Enable and centralize logs
• Monitor log integrity (FIM)
• Watch for failed logins, privilege escalations, configuration changes
8. Backups & recovery
• Regular, tested backups
• Store off‑host and, ideally, off‑site
• Protect backup credentials and infrastructure
9. Policies & processes
• Document hardening standards
• Use baselines (e.g., CIS Benchmarks) as references
• Periodically reassess and test (vulnerability scanning, audits, red‑teaming)

---

Access and Authentication Hardening

Account Lifecycle Management

• Enforce a formal process for creating, modifying, and deleting users.
• Immediately disable accounts when people leave a team or company.
• Avoid using root interactively; use sudo with named users.

Automate this via directory services (LDAP, Active Directory, SSO) where appropriate.

Password Policies

Use PAM to enforce:

• Minimum length
• Complexity (or, better, passphrase support)
• Reuse limits
• Lockouts or progressive delays on failed attempts

Balance usability with risk: too strict policies can cause unsafe workarounds (password reuse, notes on desks).

SSH Hardening

Typical steps:

• Prefer key‑based authentication
• Disable PermitRootLogin or restrict it to forced commands
• Optionally set PasswordAuthentication no after keys are deployed
• Restrict which users or groups can SSH (AllowUsers, AllowGroups)
• Change default port only as a noise‑reduction measure (not security by itself)
• Use modern ciphers and MACs; disable legacy algorithms

Combine network restrictions (firewall, VPN) with SSH configuration for layered protection.

Multi‑Factor Authentication (MFA)

Where feasible:

• PAM‑based OTP (e.g., TOTP) or hardware tokens (U2F/FIDO2)
• SSH with MFA via SSO/gateway solutions
• Web admin interfaces protected by MFA at the application or SSO layer

MFA significantly raises the bar against credential theft.

Service and Application Hardening

Principle of “Service Isolation”

For each service:

• Dedicated system user with minimal privileges
• Separate configuration and data directories
• Restrictive file permissions on configs, keys, and data
• Avoid running as root unless absolutely necessary

Use containers or chroot‑like isolation if the risk justifies it.

Minimizing Public Interfaces

For every networked program:

• Decide: should it be accessible from the internet, internal LAN, or localhost only?
• Bind services to specific interfaces or localhost where possible
• Use reverse proxies (e.g., Nginx) to terminate TLS and centralize security policies

Close or remove admin/debug endpoints not intended for general use.

Secure Configuration Defaults

Adjust application configs to address:

• Authentication and authorization
• TLS requirements (protocols, ciphers)
• Logging levels (enough to detect issues, not so much to leak secrets)
• Request size limits and rate limits where available
• Safe defaults for file uploads, eval/exec features, plugin systems

Document any deviations from secure defaults for auditability.

Filesystem and Data Hardening

Partitioning Strategy and Mount Options

Plan mount points and options to constrain damage if processes are compromised:

Commonly hardened options:

• noexec: disallow executing binaries on the filesystem
• nosuid: ignore setuid and setgid bits
• nodev: disallow device files on the filesystem
• ro: read‑only where data should never change

Typical use patterns:

• /tmp and other temporary dirs:
• Mount as separate filesystem with nosuid,nodev and often noexec
• Application data dirs:
• Use nosuid,nodev as appropriate
• Configuration or static content:
• Consider ro mount for immutable systems

Ensure that noexec and similar options do not break legitimate workflows before enforcing them widely.

Protecting Sensitive Files

Identify sensitive paths:

• Authentication: /etc/shadow, /etc/ssh/key
• Secrets: API keys, TLS private keys, database passwords
• Configuration: database configs, web server configs
• Business data: customer records, IP

For these:

• Strict permissions (usually 600 or more restrictive)
• Limited group memberships
• Avoid storing secrets in world‑readable logs or configs
• Consider secret management systems (Vault, cloud KMS) instead of flat files

Data Encryption

Encryption is mainly about confidentiality at rest:

• Full disk encryption (LUKS) for laptops and portable devices
• Separate encrypted volumes for especially sensitive data on servers
• Protect keys: physical access to key material undermines encryption benefits

Complement encryption with access controls; encryption alone does not prevent misuse by authorized but compromised accounts.

Network Hardening

Host Firewall Strategy

Treat host firewalls as a last mile of defense, even if you have network firewalls.

Basic model:

• Default‑deny inbound
• Explicitly allow:
• SSH (restricted to admin/VPN addresses)
• Application ports (e.g., 80/443 for web frontends)
• Monitoring and management ports (if used and restricted)

For outbound traffic:

• Optionally restrict to required destinations (e.g., for high‑security environments)
• At least log suspicious outbound attempts that fail

Integrate firewall rule management into configuration management tools.

Service Segmentation and Zones

Define trust zones:

• Public zone: exposed to internet
• Internal zone: accessible only from internal networks
• Management zone: used for admin interfaces, monitoring, backups

Segment services accordingly:

• Database servers typically internal/management only
• Admin panels only in management/VPN zone
• Public HTTP/HTTPS in public zone, but with strict boundaries to backend systems

Protocol and Cipher Hardening

For network services that use TLS or other crypto:

• Disable deprecated TLS versions (e.g., TLS 1.0, 1.1)
• Prefer modern ciphers and key exchange methods
• Enable perfect forward secrecy when possible
• Use strong keys (e.g., 2048‑bit+ RSA or modern elliptic curves)

Use testing tools (like nmap scripts or SSL scanners) to validate configuration.

Logging, Monitoring, and Detection

Hardening must include the ability to detect and understand attacks.

What to Log

Ensure logging for:

• Authentication events:
• Successful and failed logins
• sudo usage
• Key additions/removals
• Service access:
• Web server access and error logs
• Application logs for authentication and authorization
• System security events:
• Kernel messages related to security (e.g., MAC denials)
• Configuration changes (via FIM and/or package manager logs)
• Administrative actions:
• Changes to users, groups, firewall, systemd units
• Package installation/removal and updates

Where to Store Logs

• Local logs:
• Short‑term, immediate debugging, and forensics
• Central logging:
• Protects against log tampering on a compromised host
• Enables correlation across multiple hosts

Harden log storage:

• Access control to log servers
• Integrity checks (FIM on logs themselves)
• Retention policies and archival methods

Alerting and Baselines

Define which events require alerts:

• Multiple failed logins or sudden spike in failures
• New privileged user creation
• Changes to critical configuration files
• Unexpected service starts/stops or crashes
• Kernel or MAC system denials that indicate misconfiguration or probing

Build baselines for “normal” behavior (CPU, memory, network, login patterns) to better detect anomalies.

Configuration Management and Compliance

Manual hardening does not scale and is hard to reproduce.

Configuration as Code

Use tools (Ansible, Puppet, Chef, etc.) to:

• Define hardening baselines in version‑controlled code
• Apply them consistently across environments
• Review and audit changes
• Roll back if necessary

Treat:

• /etc contents
• Firewall rules
• Systemd unit overrides
• User and sudo policy
• Application configs

as code‑managed assets, not ad‑hoc manual changes.

Baseline Benchmarks and Policies

Use external benchmarks as references, not gospel:

• CIS Benchmarks
• Vendor hardening guides
• Industry‑specific standards (PCI‑DSS, HIPAA, etc.)

When adopting a control:

• Understand the risk it addresses
• Test for side effects
• Document exceptions with justification

Automate compliance checks where possible to detect drift.

Backup, Recovery, and Resilience

Hardening is incomplete without resilience. Attackers often aim to:

• Encrypt or destroy data (ransomware)
• Corrupt configurations
• Destroy or corrupt backups

Backup Design Considerations

• Regular, automated backups of:
• Configurations (/etc, application configs)
• Critical data (databases, file storage)
• Logs and audit trails
• Off‑host copies:
• Another server, storage system, or cloud location
• Off‑line or immutable copies:
• Prevent attackers from deleting or encrypting backups

Testing and Documentation

• Regularly test restore procedures:
• Time to restore
• Completeness and integrity
• Document:
• What is backed up
• Where it lives
• How to restore different components

Treat backup credentials and infrastructures as high‑value assets and harden them accordingly.

Process and Culture of Hardening

Technical measures alone are not enough; you need ongoing practices.

Change Management

• Review proposed changes for security impact
• Track changes to hardening baselines
• Require approvals for risky operations (firewall changes, new services, privilege changes)

Continuous Improvement

• Feed lessons from incidents, near‑misses, and audits back into hardening policies
• Keep track of new threats and techniques relevant to your stack
• Periodically re‑do threat modeling as systems evolve

Training and Awareness

• Ensure admins and developers understand:
• Basic secure coding and deployment practices
• How to use hardened systems effectively
• Why certain restrictions exist

Poor communication can lead to people intentionally or unintentionally bypassing security controls.

Putting It All Together

In practice, hardening a Linux system is:

1. Understand what the system does, who uses it, and what can go wrong.
2. Reduce attack surface: remove unneeded services, packages, and access paths.
3. Restrict what remains using least privilege, isolation, and tight network controls.
4. Observe the system with logs, monitoring, and integrity checks.
5. Prepare for failure with backups and clear recovery procedures.
6. Automate and codify policies so they are applied consistently and can evolve safely.

Subsequent chapters in this section (kernel hardening, file integrity monitoring, vulnerability scanning) focus on specific mechanisms to deepen and operationalize this overall strategy.