Runbook 03 — Linux Server Hardening

A security assessment identifies:

What Is Weak?

Server hardening answers:

How Do We Reduce the Risk?

Linux hardening is not simply:

Disable Everything

Block Everything

Remove Everything

A production server still needs to perform its business function.

The objective is to create:

Secure
+
Stable
+
Supportable
+
Observable
+
Recoverable

Linux infrastructure.

Runbook Information

Runbook: Linux Server Hardening
Level: Intermediate → Advanced
Primary Role: Linux Security Engineer
Supporting Roles: System Administrator, Cloud Security Engineer, DevSecOps Engineer, Security Consultant, Platform Engineer
Environment: Authorized Linux servers
Objective: Reduce Linux attack surface while preserving required business functionality.

Mission Scenario

A Linux server has completed its security assessment.

The assessment identified several weaknesses:

Pending Security Updates

Dormant User Accounts

Excessive sudo Access

Broad SSH Exposure

Unnecessary Services

Weak File Permissions

Overly Permissive Firewall Rules

Incomplete Security Logging

Inconsistent Hardening

The server is scheduled for production deployment.

You have been assigned to create and execute the approved hardening plan.

Your job is to move the system from:

Functional Linux Server

to:

Hardened Production Linux Server

without unnecessarily disrupting the application.

Hardening Philosophy

Use:

UNDERSTAND
    ↓
BASELINE
    ↓
BACK UP
    ↓
HARDEN
    ↓
TEST
    ↓
VALIDATE
    ↓
MONITOR
    ↓
DOCUMENT

Golden Rule

Never harden production systems blindly.

Do not:

Copy Random Internet Commands

Apply Every Benchmark Setting

Disable Services Without Validation

Change SSH Without Recovery Access

Modify Firewall Rules Without Testing

Disable SELinux to Fix Problems

Delete Accounts Without Ownership Review

Instead:

Requirement
    ↓
Risk
    ↓
Approved Change
    ↓
Controlled Implementation
    ↓
Validation
    ↓
Rollback if Required

Hardening Mental Model

Think in layers:

              APPLICATION
                   ↓
                DATA
                   ↓
               PROCESS
                   ↓
               SERVICE
                   ↓
              FILESYSTEM
                   ↓
               IDENTITY
                   ↓
              PRIVILEGE
                   ↓
               NETWORK
                   ↓
            LINUX KERNEL
                   ↓
             INFRASTRUCTURE

Security should exist at every layer.

Phase 01 — Confirm Authorization

Before making changes confirm:

Server Is In Scope

Hardening Is Approved

Change Window Is Approved

Application Owner Is Available

Rollback Plan Exists

Backup Exists

Recovery Access Exists

Monitoring Team Is Informed

Change Record

Document:

Change ID:

Server:

Business Owner:

Technical Owner:

Change Window:

Hardening Engineer:

Approved By:

Rollback Owner:

Validation Owner:

Phase 02 — Understand the Server Role

Do not harden before understanding:

What Does the Server Do?

Which Applications Run?

Which Ports Are Required?

Which Users Need Access?

Which Services Are Required?

Which External Systems Are Required?

Which Data Is Processed?

What Availability Is Required?

Example

A web server may legitimately require:

TCP 443

A database server may require:

Database Port

but only from:

Approved Application Servers

Hardening should reduce unnecessary access without breaking required access.

Phase 03 — Establish the Approved Baseline

Possible references include:

Organizational Linux Standard

Vendor Hardening Guidance

CIS Benchmark

Cloud Security Standard

Application Requirements

Regulatory Requirements

Important

A benchmark is:

Security Guidance

not:

Blind Configuration Script

Evaluate every control against:

Linux Distribution

Version

Server Role

Application Compatibility

Operational Requirements

Threat Model

Phase 04 — Capture the Pre-Hardening Baseline

Before changing anything, capture the current state.

Useful information includes:

hostnamectl

cat /etc/os-release

uname -r

uptime

ip -brief address

ip route

sudo ss -lntup

systemctl --type=service --state=running

systemctl list-unit-files --type=service --state=enabled

Capture Security State

Also record:

Users

Groups

sudo Access

SSH Configuration

Firewall

SELinux/AppArmor

Installed Packages

Logging

Audit Configuration

Scheduled Tasks

Why Baseline First?

You need to know:

BEFORE

so that you can prove:

AFTER

Phase 05 — Prepare Rollback

Before high-impact changes, determine:

How Will We Recover?

Possible mechanisms include:

VM Snapshot

Cloud Snapshot

Configuration Backup

Infrastructure as Code

Configuration Management

System Backup

Known-Good Image

Important

A snapshot is not always a complete backup strategy.

Understand:

Application Consistency

Database State

Encryption

Dependencies

Recovery Procedure

Phase 06 — Preserve Configuration

Before modifying important files, follow your organization’s configuration-management procedure.

Important configuration may include:

SSH

sudo

Firewall

Network

Authentication

Application Services

SELinux/AppArmor

Logging

Audit

Change Principle

Every important change should have:

Original State

New State

Reason

Owner

Validation

Rollback

Phase 07 — Patch the Operating System

Patching is one of the highest-value hardening activities.

Use the supported package-management process for the distribution.

Debian-family environments commonly use:

APT

RHEL-family environments commonly use:

DNF / RPM

Patch Workflow

Inventory
   ↓
Identify Updates
   ↓
Review Security Relevance
   ↓
Test
   ↓
Approve
   ↓
Deploy
   ↓
Reboot if Required
   ↓
Validate

Do Not Blindly Patch Production

Consider:

Application Compatibility

Kernel Changes

Library Dependencies

Maintenance Window

Cluster Redundancy

Rollback

Phase 08 — Review Repository Trust

Software should come from approved sources.

Review:

Configured Repositories

Repository Ownership

Signing

Third-Party Sources

Unsupported Repositories

Supply Chain Model

Trusted Source
     ↓
Verified Package
     ↓
Approved Version
     ↓
Controlled Deployment

Finding to Hardening Action

Finding:
Unapproved Repository

Hardening:
Remove or disable unapproved source
after validating application dependency.

Phase 09 — Remove Unnecessary Software

Every unnecessary package can add:

Code

Dependencies

Potential Vulnerabilities

Maintenance Burden

But do not remove packages simply because you do not recognize them.

Use:

Package
   ↓
Purpose
   ↓
Dependency
   ↓
Business Requirement
   ↓
Decision

Phase 10 — Review User Accounts

Inventory:

getent passwd

Classify accounts:

Human

Administrator

Service

System

Account Hardening Questions

Is the Account Required?

Who Owns It?

Can It Log In?

Should It Log In?

What Groups Does It Belong To?

Does It Have Administrative Access?

Phase 11 — Remove Dormant Access

For accounts no longer required:

Validate Owner
    ↓
Disable Access
    ↓
Preserve Required Data
    ↓
Remove According to Policy

Never delete accounts simply because they appear inactive.

Validate:

Application Dependencies

File Ownership

Scheduled Jobs

Service Ownership

first.

Phase 12 — Review UID 0

Run:

awk -F: '$3 == 0 {print $1 ":" $3 ":" $7}' /etc/passwd

Unexpected UID 0 identities should be investigated and remediated.

Desired Model

Individual Administrator
        ↓
sudo
        ↓
Controlled Root Privilege

instead of multiple root-equivalent accounts.

Phase 13 — Harden Service Accounts

Service accounts should normally receive only the capabilities their workload requires.

Review:

Interactive Shell

Password Authentication

Home Directory

Group Membership

sudo

File Ownership

Network Access

Service Account Model

Application
    ↓
Dedicated Identity
    ↓
Required Files
    ↓
Required Process
    ↓
Minimum Privilege

Phase 14 — Review Password Controls

Where password authentication is used, align controls with organizational policy.

Consider:

Password Quality

Password Reuse

Account Locking

Password Aging

Compromised Credential Detection

Do not apply arbitrary password expiration values simply because a generic benchmark suggests them.

Phase 15 — Review PAM

Pluggable Authentication Modules can influence:

Authentication

Password Quality

Account Restrictions

Session Controls

Changes to PAM can lock users out.

Therefore:

Understand
   ↓
Test
   ↓
Maintain Recovery Access
   ↓
Implement
   ↓
Validate

Phase 16 — Harden Privileged Access

Review:

sudo -l

Review approved sudo configuration.

Use:

visudo

for safe sudo configuration editing where appropriate.

Avoid

ALL=(ALL) ALL

for every administrator unless genuinely required.

Also review overly broad:

NOPASSWD

Wildcards

Shell Execution

Editable Scripts

Unrestricted Administrative Groups

Privilege Principle

User
 ↓
Role
 ↓
Required Administrative Task
 ↓
Minimum Privilege

Phase 17 — Separate Administrative Identities

Where organizational architecture requires it, administrators may use separate identities for:

Normal Work

and:

Privileged Administration

This reduces exposure of privileged credentials.

Phase 18 — Harden SSH

SSH is often one of the most important Linux administrative controls.

Start by reviewing the effective configuration where supported:

sudo sshd -T

Do not change SSH before confirming:

Console Access

Second Administrative Session

Recovery Method

Phase 19 — Validate SSH Configuration Before Reload

After approved changes:

sudo sshd -t

Only proceed when configuration validation succeeds.

SSH Hardening Areas

Review:

Root Login

Password Authentication

Public-Key Authentication

Empty Passwords

Allowed Users / Groups

Idle Sessions

Logging

Cryptographic Configuration

Network Exposure

Exact settings should follow the supported SSH version and organizational standard.

Phase 20 — Root SSH Access

Where direct root SSH is not required, prefer:

Administrator
      ↓
Individual Account
      ↓
sudo

This improves:

Accountability

Auditability

Access Control

Phase 21 — SSH Authentication

Where architecture supports it:

Managed Public-Key Authentication

may be preferable to reusable passwords.

But keys require lifecycle management:

Issue

Protect

Inventory

Rotate

Revoke

Phase 22 — Protect SSH Key Files

Common user-side permission expectations include:

~/.ssh

restricted to the user and:

authorized_keys

protected from unauthorized modification.

For example, where appropriate:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

Validate ownership as well.

Phase 23 — Restrict SSH Users

Where required, restrict remote administration to approved identities or groups.

The architecture should resemble:

Approved Admin Group
        ↓
SSH
        ↓
Linux Server

rather than every local identity automatically receiving remote access.

Phase 24 — Restrict SSH Network Exposure

Host configuration is only one layer.

Use:

Management Network
      ↓
Network Firewall
      ↓
Host Firewall
      ↓
SSH

where architecture permits.

Phase 25 — Filesystem Hardening

Review:

Ownership

Permissions

ACLs

Special Permissions

Mount Options

Sensitive Data

Filesystem Principle

User
 ↓
Only Required Files
 ↓
Only Required Permissions

Phase 26 — Review Sensitive System Files

Important examples include:

/etc/passwd

/etc/shadow

/etc/group

sudo Configuration

SSH Configuration

Private Keys

Application Secrets

Assess metadata without unnecessarily exposing contents.

Phase 27 — Remove Excessive Permissions

Avoid:

chmod 777

as a generic troubleshooting technique.

Instead determine:

Which Identity Needs Access?

Read?

Write?

Execute?

Then grant only those permissions.

Phase 28 — Review World-Writable Files

In an authorized environment:

sudo find / -xdev -type f -perm -0002 -print 2>/dev/null

For each result:

Purpose

Owner

Business Need

Security Impact

Do not automatically change every result.

Phase 29 — Review Shared Directories

For locations such as:

/tmp

review:

Ownership

Permissions

Sticky Bit

Mount Configuration

Usage

Phase 30 — Review SUID

Inventory:

sudo find / -xdev -type f -perm -4000 -print 2>/dev/null

For every result ask:

Expected?

Required?

Which Package?

Approved Baseline?

Known Security Risk?

Do not blindly remove SUID permissions from operating-system files.

Phase 31 — Review SGID

Inventory:

sudo find / -xdev -type f -perm -2000 -print 2>/dev/null

Apply the same validation process.

Phase 32 — Review ACLs

ACLs can grant access beyond traditional:

Owner

Group

Other

Ensure ACLs do not create unexpected access to sensitive data.

Phase 33 — Harden Home Directories

Review:

ls -ld /home/*

Ensure permissions align with:

Privacy Requirements

Application Requirements

Collaboration Requirements

Phase 34 — Review umask

umask influences default permissions for newly created files and directories.

Review the organizational standard rather than applying arbitrary values globally.

Consider:

Users

Administrators

Service Accounts

Applications

because different workloads may have different requirements.

Phase 35 — Review Mount Security

Depending on workload, mount options may include controls such as:

nodev

nosuid

noexec

These are not universally appropriate.

For example:

noexec

may break applications that legitimately execute from the filesystem.

Use:

Threat Model
+
Workload Requirement

before applying.

Phase 36 — Review `/etc/fstab`

Incorrect changes can prevent a system from booting.

Before modifying:

Back Up Configuration

Validate Syntax

Confirm Recovery Access

Test Mount Behavior

Phase 37 — Reduce Service Attack Surface

Inventory:

systemctl --type=service --state=running

and:

systemctl list-unit-files --type=service --state=enabled

For each service:

Required?

Owner?

Network Exposure?

Privilege?

Startup Required?

Phase 38 — Disable Unnecessary Services

For approved unnecessary services:

Validate Dependency
      ↓
Stop
      ↓
Disable
      ↓
Validate Application
      ↓
Confirm Port Closed

Do not disable unfamiliar services without understanding them.

Phase 39 — Verify Listener Reduction

Before:

sudo ss -lntup

After:

sudo ss -lntup

Compare:

BEFORE
   ↓
HARDEN
   ↓
AFTER

This proves attack-surface reduction.

Phase 40 — Network Hardening

Review:

Interfaces

Routes

Listening Ports

Inbound Access

Outbound Access

IPv4

IPv6

Network Principle

Only Required Communication
Should Be Allowed

Phase 41 — Review IP Forwarding

A standard application server usually does not need to operate as a router.

Review:

sysctl net.ipv4.ip_forward

Do not disable forwarding if the system legitimately functions as:

Router

Gateway

VPN Server

Container Networking Host

without understanding the impact.

Phase 42 — Review Network Kernel Parameters

Depending on server role and approved baseline, review settings related to:

Forwarding

Redirects

Source Routing

Reverse Path Validation

Network Logging

Do not paste generic sysctl hardening configurations across every server.

Phase 43 — Persist Approved sysctl Settings

Persistent custom settings are commonly managed under:

/etc/sysctl.d/

Use organization-controlled configuration files and configuration management where possible.

Phase 44 — Harden the Host Firewall

Identify the active firewall technology:

firewalld

nftables

ufw

Firewall Design

Start from:

What Must Be Reachable?

not:

What Can We Block?

Phase 45 — firewalld Review

On applicable systems:

sudo firewall-cmd --get-active-zones

Then:

sudo firewall-cmd --list-all

Review:

Zone

Interfaces

Services

Ports

Sources

Forwarding

Phase 46 — UFW Review

On applicable systems:

sudo ufw status verbose

Review allowed services and source ranges.

Phase 47 — nftables Review

Where used:

sudo nft list ruleset

Review the active ruleset against the approved network design.

Phase 48 — Firewall Hardening Principle

Prefer:

DENY UNNECESSARY
      +
ALLOW REQUIRED

For example:

Internet
   ↓
HTTPS 443
   ↓
Web Server

while administration follows:

Management Network
       ↓
SSH 22
       ↓
Web Server

Phase 49 — Protect Yourself from Lockout

Before tightening remote firewall access:

Confirm Current Source IP

Allow Required Management Path

Maintain Secondary Session

Maintain Console Access

Apply Change

Test New Session

Only Then Close Recovery Session

Phase 50 — Review Outbound Access

Inbound controls are not enough.

Ask:

Does the Server Need
Unrestricted Internet Access?

Required outbound destinations may include:

Package Repositories

DNS

NTP

Monitoring

Backup

Application APIs

Consider restricting unnecessary egress where architecture supports it.

Phase 51 — SELinux Hardening

On SELinux systems:

getenforce

and:

sestatus

A security-focused production baseline will often expect:

Enforcing

where supported and required.

Never Use

Disable SELinux

as the default troubleshooting strategy.

Correct SELinux Troubleshooting

Application Fails
      ↓
Check Normal Permissions
      ↓
Check Logs
      ↓
Check SELinux Denial
      ↓
Check Context
      ↓
Check Boolean
      ↓
Correct Configuration

Phase 52 — Review SELinux Contexts

Use:

ls -Z <path>

where appropriate.

Incorrect labels should normally be corrected using supported policy-aware mechanisms rather than arbitrary permanent changes.

Phase 53 — SELinux Booleans

SELinux booleans can enable specific policy capabilities.

The process should be:

Application Requirement
      ↓
Relevant Boolean
      ↓
Security Impact
      ↓
Approved Change
      ↓
Validation

Do not enable unrelated booleans simply to make an application work.

Phase 54 — AppArmor Hardening

On AppArmor systems review:

Loaded Profiles

Enforcing Profiles

Complain Profiles

Unconfined Applications

The goal is:

Application
      ↓
Approved Behavior
      ↓
Enforced Policy

Phase 55 — Logging Hardening

A hardened system must be observable.

Review:

System Logs

Authentication Logs

sudo Activity

Application Logs

Firewall Logs

Security Control Events

Logging Model

EVENT
  ↓
LOCAL LOG
  ↓
CENTRAL COLLECTOR
  ↓
SIEM
  ↓
DETECTION
  ↓
INVESTIGATION

Phase 56 — Protect Logs

Consider:

Ownership

Permissions

Retention

Rotation

Disk Capacity

Remote Forwarding

Tamper Resistance

Logs should not become:

Disk Exhaustion Risk

or be easily altered by inappropriate identities.

Phase 57 — Centralize Logs

Where architecture supports it, forward important events to a centralized platform.

Benefits:

Cross-System Correlation

Longer Retention

Incident Investigation

Detection

Reduced Local Tampering Risk

Phase 58 — Harden Auditing

Where Linux audit is required:

systemctl status auditd

Review rules where authorized:

sudo auditctl -l

Audit important events according to organizational requirements.

Potential categories include:

Identity Changes

Privilege Changes

Security Configuration

Sensitive File Changes

Administrative Actions

Audit Principle

Do not collect:

Everything

without planning.

Excessive auditing can create:

Noise

Storage Consumption

Performance Impact

Investigation Difficulty

Phase 59 — Time Synchronization

Review:

timedatectl

A hardened server should have reliable time synchronization.

This supports:

Authentication

Logging

Incident Response

Certificate Validation

Distributed Systems

Phase 60 — Scheduled Task Hardening

Review:

crontab -l

and:

systemctl list-timers --all

For each scheduled task:

Owner

Purpose

Command

Script Ownership

Script Permissions

Schedule

Important

A root-owned scheduled task that executes a script writable by a lower-privileged user creates a serious privilege boundary problem.

Phase 61 — systemd Hardening

Review custom service units for:

User

Group

Executable

Working Directory

Environment

Restart Behavior

Dependencies

File Permissions

Where supported by the workload, systemd can provide additional service restrictions.

Apply them only after compatibility testing.

Phase 62 — Protect Secrets

Never store secrets casually in:

Shell Scripts

World-Readable Files

Source Code

Shell History

Shared Home Directories

Better Model

Application
      ↓
Approved Secret Manager
      ↓
Authorized Identity
      ↓
Required Secret

Phase 63 — Review Configuration Files for Secrets

Do not indiscriminately copy application configuration into assessment evidence.

Instead determine:

Where Are Secrets Stored?

Who Can Read Them?

Are They Encrypted?

Can They Be Rotated?

Are They Shared?

Phase 64 — Protect Private Keys

Private keys require:

Restricted Access

Controlled Storage

Lifecycle Management

Rotation

Revocation

Never place private key material into tickets, screenshots, or routine hardening reports.

Phase 65 — Backup Hardening

A hardened server should be recoverable.

Review:

Backup Scope

Frequency

Encryption

Access Control

Retention

Isolation

Restore Testing

Backup Threat Model

An attacker with administrative access may attempt to:

Encrypt Backups

Delete Backups

Corrupt Backups

Steal Backups

Therefore backups require their own security controls.

Phase 66 — Separate Backup Privilege

Where architecture permits:

Production Administrator

should not automatically have unrestricted destructive control over every backup copy.

Consider:

Separate Credentials

Immutable Storage

Offline Copies

Restricted Deletion

according to business requirements.

Phase 67 — Validate Restore

A backup is not proven until:

Restore Works

Periodically test:

Configuration Recovery

File Recovery

Application Recovery

Full Server Recovery

Phase 68 — Install Security Monitoring Where Required

Depending on the environment, controls may include:

EDR

File Integrity Monitoring

Vulnerability Agent

Runtime Security

Security Logging

Configuration Monitoring

The correct controls depend on:

Threat Model

Server Role

Performance

Compliance

Architecture

Phase 69 — File Integrity Monitoring

Important security-sensitive locations may include:

SSH Configuration

sudo Configuration

Authentication Configuration

Service Units

Application Configuration

The objective is to detect:

Unexpected Change

not to generate alerts for every legitimate deployment.

Phase 70 — Vulnerability Management

A hardened system should participate in a recurring vulnerability-management process:

Discover
   ↓
Assess
   ↓
Prioritize
   ↓
Remediate
   ↓
Retest

Prioritize Using Context

Consider:

Known Exploitation

Network Exposure

Privilege

Asset Criticality

Data Sensitivity

Compensating Controls

not just a numeric vulnerability score.

Phase 71 — Configuration Management

Manual hardening does not scale well.

A mature environment moves toward:

Approved Baseline
      ↓
Ansible / Configuration Management
      ↓
Server Fleet
      ↓
Validation
      ↓
Drift Detection

RHCE Connection

This connects directly to the RHCE skills you studied earlier.

Instead of manually configuring:

100 Servers

you define:

Desired Secure State

and apply it consistently.

Phase 72 — Version Control

Security configurations should be version controlled where appropriate.

Benefits:

Change History

Peer Review

Rollback

Auditability

Consistency

Never commit:

Passwords

Private Keys

Tokens

Unencrypted Secrets

to source control.

Phase 73 — Golden Images

Cloud and enterprise environments may create:

Hardened Base Image

containing:

Approved OS

Security Baseline

Logging

Monitoring

Required Agents

Minimal Packages

New servers inherit a known baseline.

Phase 74 — Immutable Infrastructure

A mature model may move from:

Repair Server Manually

toward:

Update Image
      ↓
Deploy Replacement
      ↓
Remove Old Instance

This reduces configuration drift.

Phase 75 — Cloud Linux Hardening

Cloud-hosted Linux requires two layers.

Cloud Security
      +
Linux Security

AWS

Consider:

IAM Role

Security Groups

VPC

EBS Encryption

CloudTrail

CloudWatch

Systems Manager

Instance Metadata Security

Azure

Consider:

Managed Identity

Azure RBAC

NSGs

Disk Encryption

Defender for Cloud

Azure Monitor

Google Cloud

Consider:

Service Accounts

IAM

VPC Firewall

OS Login

Cloud Logging

Cloud Monitoring

Cloud Hardening Model

IDENTITY
   ↓
CLOUD CONTROL PLANE
   ↓
NETWORK
   ↓
LINUX
   ↓
APPLICATION
   ↓
DATA

Phase 76 — Container Host Hardening

If Linux hosts containers, additionally assess:

Container Runtime

Registry Trust

Image Sources

Privileged Containers

Capabilities

Mounts

Host Networking

Secrets

Runtime Monitoring

Phase 77 — Kubernetes Node Hardening

For Kubernetes Linux nodes consider:

Node Access

Kubelet

Container Runtime

Host Firewall

Kernel

Logging

Cloud IAM

Runtime Security

Avoid treating Kubernetes nodes exactly like general-purpose user servers.

Phase 78 — Validate Hardening

After implementing approved changes, repeat the baseline.

Review:

sudo ss -lntup

systemctl --type=service --state=running

systemctl list-unit-files --type=service --state=enabled

Then validate:

SSH

Firewall

Application

Logging

Security Controls

Scheduled Tasks

Monitoring

Phase 79 — Functional Testing

Security controls are successful only if:

Security Improved

and:

Required Business Function
Still Works

Test:

Application Access

Administrative Access

Monitoring

Backups

Scheduled Jobs

Dependencies

Phase 80 — Negative Security Testing

Also test what should no longer work.

Examples:

Unauthorized User
Cannot Read Sensitive Data

Unapproved Source
Cannot Reach SSH

Removed Service
No Longer Listens

Standard User
Cannot Perform Admin Action

Phase 81 — Reboot Validation

Some changes appear correct until reboot.

Where approved and operationally safe, validate persistence after restart.

Check:

Services

Mounts

Firewall

Network

SELinux/AppArmor

Logging

Application

Monitoring

Phase 82 — Compare Before and After

Build a hardening matrix:

Control	Before	After	Status
Unsupported accounts	Present	Removed/disabled	Improved
SSH exposure	Broad	Restricted	Improved
Unnecessary service	Running	Disabled	Improved
Firewall	Permissive	Restricted	Improved
MAC	Review	Enforcing	Improved
Logging	Local	Centralized	Improved

Phase 83 — Record Exceptions

Not every baseline control can always be implemented.

Document:

Control

Reason

Business Owner

Security Risk

Compensating Control

Approval

Expiration

Review Date

Phase 84 — Compensating Controls

Suppose an application cannot support a particular host hardening requirement.

Possible compensating controls might include:

Network Restriction

Additional Monitoring

Application Firewall

Stronger IAM

Dedicated Host

Increased Logging

The compensating control should address the actual risk.

Phase 85 — Hardening Finding Closure

A finding should move through:

OPEN
 ↓
REMEDIATION PLANNED
 ↓
IMPLEMENTED
 ↓
RETESTED
 ↓
CLOSED

Not:

OPEN
 ↓
Engineer Says Fixed
 ↓
CLOSED

Phase 86 — Hardening Report

Create:

Linux Server Hardening Report

Include the following sections.

1. Executive Summary

Document:

Server

Business Role

Hardening Objective

Overall Result

Residual Risk

2. Scope

Document:

Operating System

Applications

Security Controls

Excluded Components

3. Baseline

Identify:

Organizational Standard

Vendor Guidance

Applicable Benchmark

4. Pre-Hardening State

Summarize major weaknesses.

5. Changes Implemented

For every change:

Control

Original State

New State

Reason

Validation

6. Security Improvements

Examples:

Reduced Attack Surface

Reduced Privilege

Restricted SSH

Improved Firewall

Improved Logging

Improved Recovery

7. Exceptions

Document approved deviations.

8. Residual Risk

Explain risks that remain after hardening.

9. Validation

Document:

Functional Testing

Security Testing

Reboot Testing

Monitoring Validation

10. Recommendations

Include:

Immediate

Operational

Long-Term

Phase 87 — Hardening Checklist

Preparation

System

Identity

Privilege

SSH

Filesystem

Services

Running services inventoried
Enabled services inventoried
Unnecessary services addressed
Service ownership established
Service dependencies validated

Network

Firewall

Mandatory Access Control

SELinux/AppArmor state reviewed
Required policies enforcing
Exceptions documented
Application compatibility validated

Logging

Auditing

Time

Timezone correct
Time synchronization active
Central systems use compatible time

Persistence

Secrets

Plaintext secrets reviewed
Secret permissions reviewed
Private keys protected
Approved secret-management process used
Secret rotation available

Recovery

Monitoring

Security telemetry enabled
Vulnerability management active
File integrity monitoring considered
Endpoint/runtime monitoring considered
Alerts validated

Validation

Documentation

Common Hardening Mistakes

Avoid:

Blindly Applying CIS Settings

Changing SSH Without Console Access

Applying Firewall Rules Before Allowing Management

Using chmod 777 to Fix Applications

Disabling SELinux

Disabling AppArmor

Removing Unknown Services Without Investigation

Deleting Service Accounts Without Dependency Review

Ignoring IPv6

Ignoring Egress

Ignoring Secrets

Ignoring Backups

Hardening Without Application Testing

Hardening Without Rollback

Hardening Once and Never Checking Again

Hardening Is Continuous

A hardened server today may drift tomorrow.

Why?

New Package

New Administrator

Application Change

Emergency Fix

New Firewall Rule

New Service

Configuration Change

Therefore:

HARDEN
   ↓
MONITOR
   ↓
DETECT DRIFT
   ↓
REMEDIATE
   ↓
VALIDATE

Configuration Drift

Example:

Approved State

SSH:
Management Network Only

Later:

Temporary Troubleshooting Change

SSH:
Any Source

Then the temporary change is forgotten.

That is:

Configuration Drift

Continuous Compliance

Mature environments automate:

Baseline
   ↓
Configuration Assessment
   ↓
Drift Detection
   ↓
Alert
   ↓
Remediation

Security Automation

As environments grow:

1 Server

may be manageable manually.

But:

10 Servers

100 Servers

1,000 Servers

require automation.

Tools and approaches may include:

Ansible

Configuration Management

Policy as Code

Infrastructure as Code

Compliance Automation

Zero Trust Connection

Linux hardening supports Zero Trust principles:

Verify Identity

Least Privilege

Minimize Access

Segment Networks

Monitor Activity

Assume Breach

Defense in Depth

No single Linux control should carry the entire security burden.

Use:

PATCHING
   +
IAM
   +
sudo
   +
SSH
   +
PERMISSIONS
   +
FIREWALL
   +
SELINUX / APPARMOR
   +
LOGGING
   +
MONITORING
   +
BACKUPS

Interview Scenario 01

How would you harden a new Linux production server?

Use:

Understand Role
      ↓
Baseline
      ↓
Backup
      ↓
Patch
      ↓
Identity
      ↓
Privilege
      ↓
SSH
      ↓
Filesystem
      ↓
Services
      ↓
Network
      ↓
Firewall
      ↓
MAC
      ↓
Logging
      ↓
Monitoring
      ↓
Backup
      ↓
Validate

Interview Scenario 02

Why shouldn’t you blindly apply CIS controls?

Because a security control may affect:

Application Compatibility

Availability

Operations

Performance

Controls must be evaluated against the actual workload.

Interview Scenario 03

How do you safely harden SSH remotely?

Maintain:

Existing Session
      +
Console/Recovery Access

Then:

Modify
  ↓
Validate sshd Configuration
  ↓
Reload
  ↓
Open New Session
  ↓
Verify
  ↓
Close Old Session

Interview Scenario 04

Why shouldn’t SELinux simply be disabled when an application fails?

Because SELinux may be correctly preventing behavior outside the intended policy.

Investigate:

Permissions

Context

Logs

Policy

Boolean

Application Behavior

and correct the underlying issue.

Interview Scenario 05

How do you know hardening worked?

By comparing:

BEFORE

and:

AFTER

and performing:

Configuration Validation

Functional Testing

Negative Security Testing

Monitoring Validation

Persistence Testing

40 Linux Server Hardening Interview Questions

What is Linux server hardening?
What is attack-surface reduction?
Why must server role be understood first?
What is a hardening baseline?
Why should benchmarks not be applied blindly?
Why is rollback important?
Why should a pre-hardening baseline be captured?
How does patching improve security?
Why should repositories be reviewed?
Why remove unnecessary packages?
How do you harden user accounts?
What is a dormant account?
Why are UID 0 accounts important?
How should service accounts be hardened?
What is least privilege?
How do you safely modify sudo?
Why is visudo useful?
How would you harden SSH?
Why should SSH root login be reviewed?
Why are SSH keys security-sensitive?
Why should SSH network exposure be restricted?
Why is chmod 777 dangerous?
What are SUID and SGID?
What is umask?
What do nodev, nosuid, and noexec conceptually provide?
How do you reduce service attack surface?
How do you identify listening ports?
Why should IP forwarding be reviewed?
How do you harden a host firewall?
Why should outbound access be reviewed?
What is SELinux?
Why should SELinux remain enforcing where required?
What is AppArmor?
Why is centralized logging important?
What is Linux auditing?
Why is time synchronization important?
How should secrets be protected?
Why are secure backups part of hardening?
What is configuration drift?
How would you validate Linux hardening?

Runbook Completion Criteria

Linux hardening is complete only when you can demonstrate:

Supported Operating System

Security Updates Managed

Accounts Controlled

Privilege Minimized

SSH Restricted

Sensitive Files Protected

Unnecessary Services Reduced

Network Exposure Restricted

Firewall Enforced

Mandatory Access Control Operating

Security Events Logged

Auditing Appropriate

Secrets Protected

Backups Recoverable

Monitoring Active

Configuration Validated

Exceptions Documented

Final Linux Hardening Mental Model

Memorize:

KNOW THE SERVER
      ↓
REDUCE SOFTWARE
      ↓
REDUCE USERS
      ↓
REDUCE PRIVILEGE
      ↓
REDUCE SERVICES
      ↓
REDUCE PORTS
      ↓
RESTRICT NETWORK
      ↓
PROTECT FILES
      ↓
ENFORCE SECURITY CONTROLS
      ↓
LOG IMPORTANT ACTIVITY
      ↓
MONITOR CHANGE
      ↓
PROTECT RECOVERY
      ↓
VALIDATE EVERYTHING

Runbook Success Criteria

A successful Linux hardening engagement produces:

Approved Baseline

Pre-Hardening Evidence

Change Plan

Rollback Plan

Patched System

Hardened IAM

Hardened SSH

Protected Filesystem

Reduced Services

Restricted Network

Host Firewall

SELinux/AppArmor Enforcement

Logging and Auditing

Protected Secrets

Secure Backups

Monitoring

Post-Hardening Validation

Exception Register

Hardening Report

Linux Security Operations Lifecycle

Your three runbooks now form a complete operational lifecycle:

Runbook 01
Linux Incident Investigation
        ↓
"What Happened?"

Runbook 02
Linux Security Assessment
        ↓
"What Is Weak?"

Runbook 03
Linux Server Hardening
        ↓
"How Do We Secure It?"

Together:

ASSESS
   ↓
HARDEN
   ↓
MONITOR
   ↓
DETECT
   ↓
INVESTIGATE
   ↓
REMEDIATE
   ↓
VALIDATE
   ↓
IMPROVE

Linux Learning Path Complete

You have now completed the Linux certification, lab, and operational runbook sequence.

LINUX CERTIFICATION ROADMAP
        ↓
Linux Essentials
        ↓
LPIC-1
        ↓
CompTIA Linux+
        ↓
RHCSA
        ↓
RHCE
        ↓
LINUX LABS
        ↓
Linux Administration
        ↓
Linux Hardening
        ↓
Linux IAM
        ↓
Linux Networking
        ↓
Linux Security
        ↓
LINUX RUNBOOKS
        ↓
Linux Incident Investigation
        ↓
Linux Security Assessment
        ↓
Linux Server Hardening

You have progressed from:

Linux Fundamentals

through:

Linux Administration

into:

Enterprise Linux
        ↓
Automation
        ↓
Security
        ↓
Assessment
        ↓
Incident Response
        ↓
Hardening

What’s Next?

➡️ Linux Security Path Complete

You now have a Linux foundation that directly supports the broader GoHackersCloud career paths:

Linux
  ├── Cybersecurity
  ├── SOC Operations
  ├── Ethical Hacking
  ├── Cloud Security
  ├── DevSecOps
  ├── Container Security
  ├── Kubernetes Security
  ├── Incident Response
  └── Security Engineering

The most important outcome is not memorizing commands.

It is developing the ability to look at a Linux system and systematically ask:

What Should Be Here?

What Is Actually Here?

What Is Exposed?

Who Has Access?

What Is Over-Privileged?

What Can Be Removed?

What Must Be Protected?

What Can We Detect?

Can We Investigate?

Can We Recover?

Can We Prove the System Is Secure?

That is the mindset of a professional Linux security engineer.

Runbook 03 — Linux Server Hardening

Runbook Information

Mission Scenario

Hardening Philosophy

Golden Rule

Hardening Mental Model

Phase 01 — Confirm Authorization

Change Record

Phase 02 — Understand the Server Role

Example

Phase 03 — Establish the Approved Baseline

Important

Phase 04 — Capture the Pre-Hardening Baseline

Capture Security State

Why Baseline First?

Phase 05 — Prepare Rollback

Important

Phase 06 — Preserve Configuration

Change Principle

Phase 07 — Patch the Operating System

Patch Workflow

Do Not Blindly Patch Production

Phase 08 — Review Repository Trust

Supply Chain Model

Finding to Hardening Action

Phase 09 — Remove Unnecessary Software

Phase 10 — Review User Accounts

Account Hardening Questions

Phase 11 — Remove Dormant Access

Phase 12 — Review UID 0

Desired Model

Phase 13 — Harden Service Accounts

Service Account Model

Phase 14 — Review Password Controls

Phase 15 — Review PAM

Phase 16 — Harden Privileged Access

Avoid

Privilege Principle

Phase 17 — Separate Administrative Identities

Phase 18 — Harden SSH

Phase 19 — Validate SSH Configuration Before Reload

SSH Hardening Areas

Phase 20 — Root SSH Access

Phase 21 — SSH Authentication

Phase 22 — Protect SSH Key Files

Phase 23 — Restrict SSH Users

Phase 24 — Restrict SSH Network Exposure

Phase 25 — Filesystem Hardening

Filesystem Principle

Phase 26 — Review Sensitive System Files

Phase 27 — Remove Excessive Permissions

Phase 28 — Review World-Writable Files

Phase 29 — Review Shared Directories

Phase 30 — Review SUID

Phase 31 — Review SGID

Phase 32 — Review ACLs

Phase 33 — Harden Home Directories

Phase 34 — Review umask

Phase 35 — Review Mount Security

Phase 36 — Review /etc/fstab

Phase 37 — Reduce Service Attack Surface

Phase 38 — Disable Unnecessary Services

Phase 39 — Verify Listener Reduction

Phase 40 — Network Hardening

Network Principle

Phase 41 — Review IP Forwarding

Phase 42 — Review Network Kernel Parameters

Phase 43 — Persist Approved sysctl Settings

Phase 44 — Harden the Host Firewall

Firewall Design

Phase 45 — firewalld Review

Phase 46 — UFW Review

Phase 47 — nftables Review

Phase 48 — Firewall Hardening Principle

Phase 49 — Protect Yourself from Lockout

Phase 50 — Review Outbound Access

Phase 51 — SELinux Hardening

Never Use

Correct SELinux Troubleshooting

Phase 52 — Review SELinux Contexts

Phase 36 — Review `/etc/fstab`