Lab 02 — Linux Hardening

In the previous lab, you learned how to administer a Linux server.

Now you will move from:

Functional Linux Server

to:

Hardened Linux Server

Linux hardening is the process of reducing unnecessary attack surface while preserving the business functions the system is expected to provide.

Your objective is not:

Disable Everything

Your objective is:

Understand the Server
        ↓
Identify Required Functions
        ↓
Remove Unnecessary Exposure
        ↓
Apply Security Controls
        ↓
Validate Business Function
        ↓
Document the Result

Mission Information

Lab: Linux Hardening
Level: Intermediate
Estimated Time: 120–180 minutes
Environment: Authorized disposable Linux VM
Primary Role: Linux Security Engineer
Secondary Roles: Cloud Security Engineer, System Administrator, SOC Analyst, DevSecOps Engineer

Mission Scenario

Your organization has deployed a new Linux server that will soon host an internal application.

Before the server can be approved for production use, the security team has asked you to perform a hardening review.

You must evaluate and improve:

System Baseline

Accounts

Administrative Privilege

Authentication

SSH

Filesystem Permissions

Temporary Directories

Installed Software

Running Services

Network Exposure

Host Firewall

Patching

Logging

Auditing

Time Synchronization

Security Controls

You must also ensure that your changes do not unnecessarily break the server.

Mission Objectives

By completing this lab, you should be able to:

Establish a Linux security baseline
Review local users and groups
Identify unnecessary or privileged accounts
Review administrative access
Evaluate password and account settings
Harden SSH safely
Identify unnecessary software
Review running services
Reduce network attack surface
Configure basic firewall restrictions
Review sensitive filesystem permissions
Identify world-writable locations
Review SUID and SGID files
Validate package and patch status
Review SELinux or AppArmor
Validate system logging
Review auditing capabilities
Verify time synchronization
Produce professional security findings
Create before-and-after hardening evidence

Lab Architecture

+----------------------------+
|       Administrator        |
|      Security Engineer     |
+-------------+--------------+
              |
              | SSH / Console
              |
              v
+----------------------------+
|      Linux Lab Server      |
|                            |
|  Users & Groups            |
|  sudo                      |
|  SSH                       |
|  Services                  |
|  Firewall                  |
|  Packages                  |
|  Filesystem                |
|  Logging                   |
|  Security Controls         |
+----------------------------+

Important Safety Principle

Hardening can break systems if performed without understanding application requirements.

For every proposed change ask:

What Does This Control Protect?

What Depends on This Setting?

What Could Break?

How Will I Validate It?

How Will I Roll Back?

Recommended Lab Environment

Use your own authorized disposable Linux VM.

Suitable examples include:

Ubuntu

Debian

Rocky Linux

AlmaLinux

Red Hat Enterprise Linux

Some commands and configuration locations vary between distributions.

Where appropriate, this lab provides both Debian-family and Red Hat-family concepts.

Before You Begin

Take a VM snapshot if your virtualization platform supports it.

Record:

Snapshot Name:
Pre-Linux-Hardening

This gives you a safe recovery point.

Hardening Workflow

Use this throughout the lab:

BASELINE
   ↓
REVIEW
   ↓
PRIORITIZE
   ↓
CHANGE
   ↓
VALIDATE
   ↓
DOCUMENT

Part 01 — Establish the Baseline

Do not begin changing settings immediately.

First understand the current system.

Step 01 — Confirm Identity

Run:

whoami

Then:

id

Record:

Current User:

UID:

Groups:

Administrative Access:

Step 02 — Identify the System

Run:

hostname

cat /etc/os-release

uname -r

uptime

Record:

Hostname:

Distribution:

Version:

Kernel:

Uptime:

Step 03 — Create a Hardening Workspace

Create:

mkdir -p ~/linux-hardening-lab

Enter it:

cd ~/linux-hardening-lab

Create folders:

mkdir baseline findings evidence

Step 04 — Capture System Information

Create:

{
  echo "Linux Hardening Baseline"
  echo "========================"
  echo "Date: $(date)"
  echo "Hostname: $(hostname)"
  echo "Kernel: $(uname -r)"
  echo "Current User: $(whoami)"
} > baseline/system-info.txt

Review:

cat baseline/system-info.txt

Baseline Principle

A professional hardening exercise should preserve:

Before State

and:

After State

This helps demonstrate:

What Changed?

Why?

Did It Work?

Part 02 — Review Local Accounts

Identity is one of the most important Linux security areas.

Start with:

getent passwd

Step 05 — Understand Account Types

Linux systems commonly contain:

Human Users

Administrative Users

Service Accounts

System Accounts

Do not assume every unfamiliar account is malicious.

Many are required by installed software.

Step 06 — Identify Interactive Shell Accounts

Review:

getent passwd | grep -E '/bin/(bash|sh|zsh|fish)$'

The exact shells present depend on the system.

Ask:

Which Accounts Can Log In Interactively?

Step 07 — Review UID 0 Accounts

Run:

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

Normally, highly privileged UID 0 accounts require strict review.

Document any unexpected results.

Security Question

Ask:

Should Any Account
Besides the Approved
Administrative Identity
Have UID 0?

Accounts that do not require interactive login may use shells such as:

/usr/sbin/nologin

or:

/sbin/nologin

depending on the distribution.

The principle is:

No Interactive Requirement
        ↓
No Interactive Shell

where operationally appropriate.

Step 09 — Review Account Ownership

For every human account ask:

Who Owns It?

Why Does It Exist?

Is the User Still Active?

Which Groups Does It Belong To?

Does It Need Administrative Access?

Account Review Table

Create documentation like:

Account	Type	Interactive Login	Privileged	Required
user1	Human	Yes	No	Yes
service1	Service	No	No	Yes
olduser	Human	Yes	Unknown	Review

Do not remove real accounts without authorization.

Part 03 — Review Groups

Run:

getent group

Look especially for groups that may grant elevated capabilities.

Examples depend on distribution, but may include administrative groups.

Step 10 — Review Your Administrative Group

Run:

id

Then review the relevant administrative group using:

getent group <group-name>

Security Principle

Group Membership
      ↓
Privilege

Therefore group membership is security-sensitive.

Part 04 — Review sudo Access

Administrative privilege should follow:

Least Privilege

Use:

sudo -l

to review the privileges of your current account.

Step 11 — Review sudo Configuration

Where authorized, inspect configuration carefully.

Main locations may include:

/etc/sudoers

/etc/sudoers.d/

Use safe inspection methods.

Do not edit /etc/sudoers directly with an ordinary text editor.

Use the approved validation workflow such as:

sudo visudo

when legitimate changes are required.

Security Questions

Ask:

Who Can Use sudo?

What Can They Run?

Can They Run Everything?

Is That Required?

Is Access Documented?

Finding Example

Finding:
Excessive Administrative Privilege

Observation:
A user has broad sudo access without
a documented administrative requirement.

Risk:
Compromise of the account could provide
full control of the Linux server.

Recommendation:
Restrict privileged access to the
minimum administrative functions
required for the user's role.

Part 05 — Review Password and Account Controls

Password-related configuration differs by distribution and enterprise authentication model.

Review relevant account-aging information using:

chage -l <authorized-test-user>

Step 12 — Review Password Aging Concepts

Understand:

Minimum Password Age

Maximum Password Age

Expiration Warning

Account Expiration

Do not blindly apply arbitrary expiry settings.

Align with:

Organization Policy

Authentication Architecture

Regulatory Requirements

Step 13 — Review Locked Accounts

For training identities you control, understand the difference between:

Disable Interactive Access

Lock Password Authentication

Delete Account

Deletion is not always the correct security response.

During investigations, preserving the account may be necessary.

Part 06 — Review SSH Configuration

SSH is one of the most important Linux remote-access services.

First determine whether SSH is running.

Possible service names include:

ssh

sshd

Check the correct service for your distribution.

Example:

systemctl status sshd

or:

systemctl status ssh

Step 14 — Locate SSH Configuration

The primary server configuration is commonly:

/etc/ssh/sshd_config

Additional configuration fragments may exist depending on the distribution.

Before changing anything, create an authorized backup:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.lab-backup

Step 15 — Review Effective SSH Configuration

Where supported:

sudo sshd -T

This is often more useful than reading only one configuration file because it can show effective settings.

SSH Hardening Questions

Review:

Is Direct Root Login Required?

Which Authentication Methods Are Allowed?

Are Empty Passwords Allowed?

Which Users/Groups Can Connect?

Is SSH Exposed to the Correct Networks?

Are Logs Available?

A common security objective is:

Prevent Direct Remote Root Login

where administrative workflows permit it.

A common configuration consideration is:

PermitRootLogin

Do not change it blindly.

First ensure:

A Working Administrative Account Exists

sudo Works

Your Current Session Remains Open

Recovery Access Exists

Critical Safety Rule

Never close your current working SSH session immediately after changing remote-access configuration.

Use:

Existing Session
      ↓
Apply Change
      ↓
Validate Configuration
      ↓
Reload Service
      ↓
Open Second Session
      ↓
Confirm Access
      ↓
Only Then Close Original Session

Step 17 — Validate SSH Configuration

Before reload or restart, use the platform’s supported syntax validation where available:

sudo sshd -t

No output normally indicates that no syntax problem was detected.

Always confirm behavior on your system.

Step 18 — Authentication Methods

Organizations may prefer:

SSH Keys

Central Identity

MFA-Integrated Access

over unmanaged password-only administrative access.

The correct configuration depends on your environment.

Do not disable a working authentication method until the replacement has been validated.

Step 19 — Restrict SSH Access

SSH exposure may be restricted using several layers:

Cloud Firewall

Network Firewall

Host Firewall

SSH User/Group Rules

Think:

Who Needs Access?
      ↓
From Which Network?
      ↓
Using Which Identity?

Part 07 — Review SSH Keys

For authorized users, SSH public keys may be stored under locations such as:

~/.ssh/authorized_keys

Security Review

Ask:

Who Owns This Key?

Is It Still Required?

When Was It Issued?

Is It Shared?

Can It Be Revoked?

Does the File Have Appropriate Permissions?

Important

Never copy private SSH keys into:

Reports

Tickets

Chat

Source Repositories

Part 08 — Review Installed Software

More installed software generally means:

More Code

More Vulnerabilities

More Patches

More Attack Surface

Step 20 — Inventory Packages

Debian family:

dpkg -l

RPM family:

rpm -qa

Save package inventory if appropriate.

Example on RPM systems:

rpm -qa | sort > baseline/packages.txt

Example on Debian systems:

dpkg-query -W > baseline/packages.txt

Step 21 — Identify Unnecessary Software

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

For each questionable package determine:

Purpose

Dependency

Application Owner

Support Requirement

Security Impact

Principle

Required Software
      ↓
Keep + Maintain

Unnecessary Software
      ↓
Review for Removal

Part 09 — Review Running Services

Run:

systemctl --type=service --state=running

Create an inventory.

Ask for each service:

What Is It?

Why Is It Running?

Does the Application Need It?

Does It Listen on a Network Port?

Should It Start Automatically?

Step 22 — Review Enabled Services

Where appropriate:

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

Remember:

Running

and:

Enabled at Boot

are different conditions.

Service Review Table

Service	Running	Enabled	Network Exposed	Required
SSH	Yes	Yes	Yes	Yes
Example Service	Yes	Yes	Yes	Review

Part 10 — Reduce Unnecessary Services

If a harmless lab service is clearly unnecessary and you are authorized to modify it, use the appropriate service-management workflow.

Conceptually:

Confirm Not Required
      ↓
Stop
      ↓
Disable
      ↓
Validate

Do not disable services merely to satisfy a checklist.

Finding Example

Finding:
Unnecessary Service Enabled

Observation:
A service without a confirmed business
requirement is running and configured
to start automatically.

Risk:
The service increases operating-system
attack surface and patch-management burden.

Recommendation:
Confirm service ownership and disable
or remove the service if it is not required.

Part 11 — Review Listening Ports

Run:

sudo ss -lntup

Document:

Protocol

Address

Port

Process

Expected?

Example Mental Model

0.0.0.0:PORT

may indicate broader IPv4 listening exposure than:

127.0.0.1:PORT

depending on the application.

Similarly, review IPv6 bindings.

Security Question

For every listening socket ask:

Should This Service
Listen on This Interface?

Part 12 — Map Ports to Business Requirements

Create:

Port	Service	Bound Address	Required	Expected Source
22	SSH	Example	Yes	Admin Network
443	Application	Example	Yes	Approved Users
Unknown	Unknown	Example	Review	Unknown

This transforms:

Port Scan Data

into:

Security Context

Part 13 — Review Host Firewall

Different Linux distributions use different firewall-management layers.

Common environments may include:

firewalld

nftables

ufw

Determine what your server uses before making changes.

Step 23 — Check Firewalld

If installed:

sudo firewall-cmd --state

Then:

sudo firewall-cmd --get-active-zones

Review active rules:

sudo firewall-cmd --list-all

Step 24 — Check UFW

If the system uses UFW:

sudo ufw status verbose

Firewall Principle

Your desired state is:

Required Traffic
      ↓
Allowed

Unnecessary Traffic
      ↓
Restricted

Critical Remote Access Warning

If you are connected through SSH:

DO NOT
Enable a restrictive firewall policy
before ensuring your approved SSH access
will remain allowed.

Otherwise you may lock yourself out.

Part 14 — Firewall Validation

After approved firewall changes validate:

SSH Still Works

Application Works

Required Port Accessible

Unnecessary Port Restricted

Use a second connection/session where practical.

Part 15 — Review File Permissions

Focus on sensitive locations such as:

/etc

/root

User SSH Directories

Application Configuration

Secrets Locations

Service Configuration

Step 25 — Review `/etc/passwd`

ls -l /etc/passwd

Step 26 — Review `/etc/shadow`

Use:

sudo ls -l /etc/shadow

Do not display or copy password-hash contents into your report.

Your goal is to review:

Owner

Group

Permissions

not secret material.

Part 16 — Find World-Writable Files

World-writable files can create security concerns depending on their purpose.

In your lab, perform a controlled review of the local filesystem.

One approach is:

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

Review results carefully.

Do not assume every result is automatically a vulnerability.

Step 27 — Review World-Writable Directories

Conceptually, inspect directories writable by broad user populations.

Pay particular attention to:

Ownership

Sticky Bit

Business Purpose

Shared temporary directories often require specialized permission models.

Part 17 — `/tmp` Security

Check:

ls -ld /tmp

On many systems you may see permissions conceptually similar to:

drwxrwxrwt

The final:

represents the sticky bit.

Sticky Bit Purpose

In a shared directory:

Many Users Can Create Files

but the sticky bit helps prevent users from deleting files owned by other users.

Part 18 — Review SUID Files

SUID can allow executables to operate with the effective identity of the file owner.

Inventory SUID files in your lab:

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

Security Review

For each unexpected entry ask:

Which Package Owns It?

Why Is SUID Required?

Is It Part of the Approved Baseline?

Is It Supported?

Do not remove SUID from legitimate system binaries without understanding the impact.

Part 19 — Review SGID Files

Similarly:

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

Review unexpected entries.

Security Principle

Special Permission
      ↓
Understand Purpose
      ↓
Compare Baseline
      ↓
Investigate Deviation

Part 20 — Review Home Directory Permissions

List:

ls -ld /home/*

Review whether home directories expose more information than required.

Consider:

Business Requirement

Shared Environment

Data Sensitivity

Application Compatibility

Part 21 — Review SSH Directory Permissions

For your own account:

ls -ld ~/.ssh 2>/dev/null

and:

ls -l ~/.ssh 2>/dev/null

Do not expose private key contents.

Security-sensitive SSH files generally require tightly controlled ownership and permissions.

Part 22 — Review PATH

Run:

echo "$PATH"

Break the path into entries:

echo "$PATH" | tr ':' '\n'

Security Review

Ask:

Does PATH Include
World-Writable Directories?

Does It Include "."?

Can Untrusted Users
Modify Earlier Directories?

PATH Security Model

Command Typed
      ↓
PATH Search Order
      ↓
First Matching Executable
      ↓
Executed

Therefore search order matters.

Part 23 — Review Package Updates

Patch management is fundamental to hardening.

On Debian-family systems, approved update review may use:

sudo apt update

followed by an update assessment.

On Red Hat-family systems, appropriate DNF tools may be used to inspect available updates.

Important

Do not automatically patch production systems simply because updates exist.

Use:

Identify
   ↓
Assess
   ↓
Test
   ↓
Approve
   ↓
Deploy
   ↓
Validate

Step 28 — Document Pending Security Maintenance

Record:

Packages Requiring Review:

Kernel Update Required?

Application Restart Required?

Reboot Required?

Change Window Needed?

Part 24 — Review Repository Configuration

Ensure package repositories are:

Expected

Approved

Trusted

Supported

Unknown package sources may create:

Software Supply-Chain Risk

Part 25 — Review SELinux

On Red Hat-family systems:

getenforce

and:

sestatus

where available.

Desired Principle

If SELinux is part of the approved platform design:

Use SELinux

rather than:

Disable SELinux
Because Something Failed

Step 29 — Interpret SELinux State

Possible states include:

Enforcing

Permissive

Disabled

Security Meaning

Enforcing
      ↓
Policy Applied

Permissive
      ↓
Policy Violations Logged

Disabled
      ↓
Policy Not Active

Part 26 — SELinux Troubleshooting

If an application fails:

Application Failure
      ↓
Traditional Permissions
      ↓
Logs
      ↓
SELinux Context
      ↓
Expected Policy
      ↓
Correct Remediation

Do not simply turn off SELinux.

Part 27 — Review AppArmor

On distributions using AppArmor, determine whether profiles are active using the appropriate supported tools.

Conceptually review:

Profile Loaded?

Enforcing?

Complain Mode?

Application Covered?

Security Principle

SELinux and AppArmor provide:

Additional Policy Layer

beyond standard discretionary permissions.

Part 28 — Review Time Synchronization

Accurate system time is essential for:

Authentication

Logs

Incident Response

Distributed Applications

SIEM Correlation

Check:

timedatectl

Look for:

Timezone

System Clock

Synchronization State

Step 30 — Review Time Service

Depending on your distribution, time synchronization may use services such as:

chronyd

systemd-timesyncd

Confirm the approved mechanism is healthy.

Part 29 — Review System Logging

Run:

journalctl -n 50

Check whether:

System Events

Service Events

Authentication Events

Errors

are available.

Step 31 — Review Authentication Logs

Distribution-dependent locations may include:

/var/log/auth.log

/var/log/secure

or the system journal.

Use the appropriate source for your environment.

Step 32 — Review Log Permissions

Logs may contain sensitive information.

Inspect:

ls -ld /var/log

Then review selected log-file ownership and permissions without copying sensitive content.

Part 30 — Log Retention

Hardening is incomplete if security events disappear too quickly.

Review:

Retention

Rotation

Disk Capacity

Central Forwarding

Log Architecture

Linux Server
      ↓
Local Logs
      ↓
Central Collector
      ↓
SIEM
      ↓
SOC

Part 31 — Review Audit Capabilities

Some Linux environments use:

auditd

for detailed auditing.

Determine whether it is present:

systemctl status auditd

where applicable.

Security Value

Audit mechanisms can help record:

Administrative Actions

Sensitive File Access

System Calls

Account Changes

Security Events

Step 33 — Review Existing Audit Rules

Where authorized and supported:

sudo auditctl -l

Do not add large numbers of audit rules blindly.

Poorly designed auditing can:

Generate Noise

Consume Storage

Reduce Analyst Effectiveness

Part 32 — Review Scheduled Tasks

Persistence and maintenance can both use scheduled execution.

Review your user crontab:

crontab -l

Review relevant authorized system scheduling locations.

Ask:

Who Runs It?

What Executes?

Who Owns the Script?

Can an Untrusted User Modify It?

Is It Required?

Part 33 — Review systemd Timers

Modern systems may use:

systemd timers

Review:

systemctl list-timers --all

This helps identify scheduled system activities.

Part 34 — Review Temporary Files

Temporary directories may be used by many applications.

Security concerns include:

Predictable File Names

Weak Permissions

Untrusted Shared Locations

Sensitive Data Exposure

Do not delete temporary files blindly.

Applications may actively depend on them.

Part 35 — Review Mount Security

Run:

findmnt

Review mount options.

Security-sensitive mount options can include concepts such as:

nosuid

nodev

noexec

but these should not be applied blindly.

Example

A filesystem holding executable applications may legitimately require execution.

Therefore use:

Filesystem Purpose
      ↓
Security Requirement
      ↓
Compatible Mount Options

Part 36 — Review `/etc/fstab`

Inspect:

cat /etc/fstab

Do not modify it without understanding boot impact.

Incorrect entries can prevent normal boot or mount required application storage incorrectly.

Part 37 — Review Kernel Parameters

Linux exposes runtime kernel settings through mechanisms such as:

sysctl

Review selected settings with:

sysctl -a 2>/dev/null | less

Do not change kernel parameters randomly.

Security Areas May Include

Networking Behavior

Address Forwarding

Redirect Handling

Memory Protections

Core Dumps

The correct hardening value depends on:

Server Role

Network Architecture

Application Requirement

Approved Security Baseline

Part 38 — Baseline Against a Standard

Enterprise hardening commonly uses recognized guidance such as:

CIS Benchmarks

Vendor Security Guidance

Internal Security Baselines

Do not treat benchmarks as:

Blind Configuration Scripts

Use:

Control
   ↓
Applicability
   ↓
Risk
   ↓
Business Impact
   ↓
Implementation
   ↓
Validation

Part 39 — Review Backups

Hardening also protects availability.

Ask:

Is the Server Backed Up?

What Is Backed Up?

Are Backups Protected?

Are They Encrypted?

Can They Be Restored?

Critical Principle

Backup Exists

does not equal:

Recovery Works

until restoration has been tested.

Part 40 — Review Recovery Access

A hardened system still needs a secure recovery procedure.

Document:

Console Access

Emergency Administrative Access

Recovery Credentials

Break-Glass Procedure

Backup Restore Procedure

These should be controlled and audited.

Part 41 — Perform Before-and-After Port Review

Before changes, save:

sudo ss -lntup > baseline/listening-ports.txt

After approved hardening, save:

sudo ss -lntup > evidence/listening-ports-after.txt

Compare:

diff baseline/listening-ports.txt evidence/listening-ports-after.txt

What You Want

Not necessarily:

Zero Ports

but:

Only Required Ports

Part 42 — Service Comparison

Capture enabled/running service baselines before and after approved modifications.

The goal is to demonstrate:

Reduced Unnecessary Services

No Broken Required Services

Part 43 — Validate SSH After Hardening

After any SSH change:

01 Validate Configuration

02 Reload Safely

03 Keep Existing Session

04 Open Second Session

05 Verify Authentication

06 Verify sudo

07 Confirm Logs

Never treat:

Service Reload Successful

as proof that administrators can still log in.

Part 44 — Validate Firewall

Test:

Required Administrative Access

Required Application Ports

Unexpected Ports

Local Services

The security objective is:

Business Function Works
      +
Unnecessary Exposure Reduced

Part 45 — Validate Application Health

Hardening is not complete until business functionality is tested.

Check:

Application Running?

Required Service Healthy?

Required Port Available?

Storage Accessible?

DNS Working?

Authentication Working?

Logs Healthy?

Part 46 — Review Reboot Requirements

Some changes may require:

Service Reload

Service Restart

Application Restart

System Reboot

Do not reboot automatically without understanding business impact.

Part 47 — Validate Persistence

A common mistake is creating a secure state that disappears after reboot.

Validate that appropriate settings are persistent.

Examples:

Firewall

Services

Mounts

System Configuration

Security Policy

Part 48 — Hardening Checklist

Review the server using:

IDENTITY
Who can log in?

PRIVILEGE
Who can become administrator?

AUTHENTICATION
How is access verified?

SSH
Who can remotely connect?

FILES
Who can read or modify data?

SOFTWARE
What is installed?

SERVICES
What is running?

NETWORK
What is exposed?

FIREWALL
What is allowed?

MAC
Is SELinux/AppArmor active?

PATCHING
Is software maintained?

LOGGING
Can events be reconstructed?

AUDITING
Are important actions recorded?

TIME
Are timestamps reliable?

BACKUP
Can data be recovered?

Part 49 — Hardening Finding 01

Unnecessary Network Exposure

Finding:
Unnecessary Network Exposure

Observation:
A network service is listening on an
interface accessible beyond its
documented business requirement.

Risk:
Additional network exposure increases
the remotely reachable attack surface.

Recommendation:
Restrict the service to the required
interface or network and enforce access
through approved host/network firewall
controls.

Part 50 — Hardening Finding 02

Excessive Administrative Access

Finding:
Excessive Administrative Access

Observation:
Multiple accounts possess broad
administrative permissions without
documented operational requirements.

Risk:
Compromise or misuse of any privileged
account could result in full system
control.

Recommendation:
Apply least privilege, remove unnecessary
administrative memberships, and perform
periodic privileged-access reviews.

Part 51 — Hardening Finding 03

Unnecessary Software

Finding:
Unnecessary Software Installed

Observation:
Software packages exist on the server
without an identified operational
requirement.

Risk:
Additional packages increase attack
surface and patch-management overhead.

Recommendation:
Confirm application dependencies and
remove unnecessary software through
the approved change process.

Part 52 — Hardening Finding 04

Weak Logging Coverage

Finding:
Insufficient Security Logging

Observation:
Security-relevant events are not retained
or centrally collected for an appropriate
investigation period.

Risk:
Security incidents may be difficult to
detect, investigate, or reconstruct.

Recommendation:
Implement approved security-event
collection, retention, time
synchronization, and centralized logging.

Part 53 — Hardening Finding 05

Mandatory Access Control Not Enforced

Finding:
Mandatory Access Control Not Enforced

Observation:
The platform's approved mandatory
access-control mechanism is not enforcing
security policy.

Risk:
Compromised processes may operate with
fewer restrictions beyond traditional
Linux permissions.

Recommendation:
Determine the operational reason,
resolve compatibility issues, and restore
the approved enforcement state.

Part 54 — Risk Prioritization

Not every issue has the same importance.

Use factors such as:

Exposure

Privilege

Exploitability

Business Criticality

Data Sensitivity

Existing Controls

Example prioritization:

Public Administrative Service
      ↓
Higher Priority

Unused Local Package
      ↓
Potentially Lower Priority

Context matters.

Part 55 — Create the Hardening Report

Your final report should contain:

1. Executive Summary

Describe:

System Reviewed

Overall Security State

Highest-Risk Issues

Major Improvements

2. Scope

Hostname

Distribution

Server Role

Review Date

Authorized Scope

3. Baseline

Include:

Accounts

Privileged Users

Services

Ports

Packages

Firewall State

Security Controls

4. Hardening Actions

For each approved change document:

Control

Previous State

New State

Reason

Validation

5. Findings

For each issue:

Finding

Observation

Risk

Evidence

Recommendation

Status

6. Exceptions

Document settings intentionally not changed because of:

Application Requirement

Business Requirement

Compatibility

Accepted Risk

7. Validation

Confirm:

SSH Access

Application Function

Networking

Firewall

Logging

Security Controls

Persistence

Part 56 — Hardening Evidence Table

Control	Before	After	Validation
Unnecessary service	Running	Disabled	Service absent
SSH root access	Review	Hardened if applicable	Second session tested
Firewall	Review	Required access only	Connectivity tested
SELinux/AppArmor	Review	Approved state	Policy validated
Logging	Review	Improved if needed	Events visible

Part 57 — Security Exceptions

A professional hardening assessment may produce:

Exception

rather than:

Failure

Example:

Control:
Disable Service X

Decision:
Not Applied

Reason:
Service X is required by the application.

Compensating Controls:
Restricted firewall exposure
and centralized monitoring.

Owner:
Application Team

Important Lesson

Security engineering is not:

Checklist Says Disable
      ↓
Disable

It is:

Understand Risk
      ↓
Understand Business
      ↓
Design Appropriate Control

Part 58 — Security Baseline Maturity

Think of hardening as stages.

Level 1 — Basic

Patch System

Remove Unused Accounts

Secure SSH

Enable Firewall

Level 2 — Managed

Approved Baseline

Central Logging

Privilege Review

Automated Updates Process

Configuration Monitoring

Level 3 — Enterprise

Configuration as Code

Continuous Compliance

Central IAM

Secrets Management

EDR

SIEM

Automated Drift Detection

Part 59 — Linux Hardening in Cloud

When Linux runs in AWS, Azure, or Google Cloud, host hardening is only one layer.

Think:

Cloud IAM
      ↓
Cloud Firewall
      ↓
Linux Firewall
      ↓
Linux Services
      ↓
Application

All layers matter.

Cloud Security Example

Even if:

Linux Firewall
Is Correct

a weak cloud IAM configuration can still create risk.

Similarly:

Cloud Security Group
Is Restricted

does not justify poor Linux permissions.

Part 60 — Linux Hardening and Containers

Container hosts also require Linux hardening.

Consider:

Host OS

Container Runtime

Users

Services

Firewall

Kernel

SELinux/AppArmor

Logging

A compromised host may affect multiple containers.

Part 61 — Linux Hardening and Kubernetes

Kubernetes nodes still rely on Linux security.

Kubernetes
      ↓
Container Runtime
      ↓
Linux

Therefore Linux hardening supports:

Kubernetes Node Security

Runtime Security

Cluster Resilience

Part 62 — Linux Hardening and SOC

Hardening creates:

Known Good Baseline

which improves detection.

For example:

Expected Services = 8

Later:

Service 9 Appears

This creates a meaningful investigation lead.

Part 63 — Linux Hardening and Incident Response

Strong hardening improves incident response through:

Better Logs

Known Accounts

Reduced Services

Documented Configuration

Accurate Time

Strong Access Controls

Without a baseline it can be difficult to determine:

Normal

versus:

Suspicious

Part 64 — Hardening vs Vulnerability Management

These are related but different.

Vulnerability Management
      ↓
Known Software Weaknesses

Hardening
      ↓
Secure Configuration

A fully patched server may still be insecure because of:

Weak SSH

Excessive sudo

Open Ports

Bad Permissions

Disabled Logging

Part 65 — Hardening vs Monitoring

Hardening reduces opportunities.

Monitoring detects activity.

Hardening
   +
Monitoring
   +
Incident Response
      ↓
Defense in Depth

Part 66 — Practical Challenge

Without immediately applying changes, review your lab server and identify:

3 Identity Controls

3 Network Controls

3 Filesystem Controls

3 Logging Controls

3 Software Controls

For each classify:

Compliant

Needs Improvement

Not Applicable

Requires Business Review

Part 67 — Hardening Validation Challenge

After approved changes answer:

Can I Still Log In?

Does sudo Still Work?

Is the Application Healthy?

Are Required Ports Reachable?

Are Unnecessary Ports Restricted?

Are Logs Being Generated?

Is Security Policy Active?

Will Settings Survive Reboot?

Part 68 — Rollback Plan

Before every important modification document:

Configuration File:

Backup Location:

Original State:

Recovery Command:

Console Access Available:
Yes / No

Part 69 — Common Linux Hardening Mistakes

Avoid:

Applying Checklists Blindly

Disabling SELinux

Disabling Firewall to Fix Problems

Removing Unknown Packages

Deleting System Accounts

Using chmod 777

Blocking Your Own SSH Access

Changing sudo Without Validation

Ignoring Application Requirements

Skipping Backups

Skipping Logs

Skipping Reboot Validation

Part 70 — Professional Hardening Workflow

Use this in real environments:

01 Obtain Authorization

02 Identify Server Role

03 Gather Baseline

04 Identify Required Services

05 Review Security Standard

06 Identify Gaps

07 Assess Business Impact

08 Create Change Plan

09 Create Rollback Plan

10 Test

11 Implement

12 Validate

13 Monitor

14 Document Exceptions

15 Produce Report

Lab Deliverables

Submit:

01 System Baseline

02 User and Group Review

03 sudo Review

04 SSH Review

05 Service Inventory

06 Port Inventory

07 Firewall Review

08 Package Review

09 Permission Review

10 SUID/SGID Review

11 SELinux/AppArmor Review

12 Logging Review

13 Audit Review

14 Hardening Findings

15 Before-and-After Evidence

16 Final Hardening Report

Interview Scenarios

Scenario 01

A security benchmark recommends disabling a service, but the application team says it is required. What should you do?

Use:

Validate Requirement

Understand Exposure

Apply Compensating Controls

Document Exception

Monitor

Do not disable it blindly.

Scenario 02

You change SSH settings and cannot reconnect. What went wrong?

Possible causes include:

Syntax Error

Authentication Disabled

Firewall Rule

User Restriction

Service Failure

This is why you:

Keep Existing Session

Validate Syntax

Test Second Connection

before closing access.

Scenario 03

Why should you not disable SELinux simply because an application fails?

Because the failure may represent:

Incorrect Context

Incorrect Configuration

Policy Violation

Disabling SELinux removes an important security layer instead of correcting the root cause.

Scenario 04

Why can a fully patched Linux system still be insecure?

Because security also depends on:

Identity

Privilege

Configuration

Services

Network Exposure

Permissions

Logging

Scenario 05

Why capture a baseline before hardening?

Because it helps demonstrate:

Original State

Changes Made

Security Improvement

Rollback Information

40 Linux Hardening Interview Questions

What is Linux hardening?
Why is system hardening necessary?
What is attack-surface reduction?
Why should you establish a baseline before making changes?
How do you identify interactive Linux users?
Why should UID 0 accounts be reviewed?
What is least privilege?
How would you review sudo access?
Why are service accounts different from human accounts?
Why might a service account use nologin?
What security risks exist with SSH?
Why is direct root SSH login commonly restricted?
Why should SSH configuration be syntax-validated?
Why should you keep an existing SSH session during hardening?
What is the purpose of a host firewall?
How do you identify listening ports?
Why should unnecessary services be disabled?
Why should unnecessary packages be removed?
What is a world-writable file?
Why are world-writable directories security-sensitive?
What is the sticky bit?
What is SUID?
Why should SUID files be reviewed?
What is SGID?
Why is PATH security-relevant?
Why is patch management important?
Why are third-party repositories a security concern?
What is SELinux?
What is the difference between enforcing and permissive?
Why should SELinux not simply be disabled?
What is AppArmor?
Why is time synchronization security-relevant?
Why is centralized logging useful?
What does auditd provide?
Why should scheduled tasks be reviewed?
What are secure mount options?
Why should hardening controls be tested for application compatibility?
What is a security exception?
What is configuration drift?
How would you validate a Linux server after hardening?

Linux Hardening Readiness Checklist

Baseline

Identity

Authentication

Software

Reviewed installed packages
Identified unnecessary software
Reviewed update status
Reviewed repository trust

Services

Reviewed running services
Reviewed enabled services
Mapped services to business requirements
Disabled only approved unnecessary services

Network

Filesystem

Security Controls

Resilience

Documentation

Final Hardening Mental Model

When hardening Linux, think:

KNOW THE SYSTEM
       ↓
KNOW THE BUSINESS FUNCTION
       ↓
KNOW WHO NEEDS ACCESS
       ↓
REMOVE WHAT IS NOT REQUIRED
       ↓
RESTRICT WHAT REMAINS
       ↓
PATCH WHAT MUST RUN
       ↓
LOG IMPORTANT ACTIVITY
       ↓
VALIDATE BUSINESS FUNCTION
       ↓
MONITOR FOR DRIFT

The goal is not:

Maximum Restriction

The goal is:

Minimum Necessary Exposure
+
Maximum Practical Security
+
Required Business Function

Mission Accomplished

You have now worked through a structured Linux hardening workflow covering:

System Baseline

User Security

Privilege Management

SSH Security

Package Security

Service Reduction

Filesystem Security

Network Exposure

Firewall Controls

SELinux/AppArmor

Logging

Auditing

Time Synchronization

Recovery

Validation

You have moved from:

Linux Administrator

toward:

Linux Security Administrator

Most importantly, you learned that professional hardening follows:

BASELINE
   ↓
UNDERSTAND
   ↓
HARDEN
   ↓
VALIDATE
   ↓
DOCUMENT
   ↓
MONITOR

What’s Next?

➡️ Lab 03 — Linux IAM

In the next lab, you will focus specifically on Linux identity and access management.

You will work through:

Users
   ↓
Groups
   ↓
UID/GID
   ↓
Password Controls
   ↓
Account Lifecycle
   ↓
File Ownership
   ↓
Permissions
   ↓
ACLs
   ↓
sudo
   ↓
Service Accounts
   ↓
SSH Keys
   ↓
Privileged Access Review

Your Linux lab journey continues:

Lab 01 — Linux Administration
        ↓
Lab 02 — Linux Hardening
        ↓
Lab 03 — Linux IAM
        ↓
Lab 04 — Linux Networking
        ↓
Lab 05 — Linux Security
        ↓
Runbook 01 — Linux Incident Investigation
        ↓
Runbook 02 — Linux Security Assessment
        ↓
Runbook 03 — Linux Server Hardening

Lab 02 — Linux Hardening

Mission Information

Mission Scenario

Mission Objectives

Lab Architecture

Important Safety Principle

Recommended Lab Environment

Before You Begin

Hardening Workflow

Part 01 — Establish the Baseline

Step 01 — Confirm Identity

Step 02 — Identify the System

Step 03 — Create a Hardening Workspace

Step 04 — Capture System Information

Baseline Principle

Part 02 — Review Local Accounts

Step 05 — Understand Account Types

Step 06 — Identify Interactive Shell Accounts

Step 07 — Review UID 0 Accounts

Security Question

Step 08 — Review Login Shells

Step 09 — Review Account Ownership

Account Review Table

Part 03 — Review Groups

Step 10 — Review Your Administrative Group

Security Principle

Part 04 — Review sudo Access

Step 11 — Review sudo Configuration

Security Questions

Finding Example

Part 05 — Review Password and Account Controls

Step 12 — Review Password Aging Concepts

Step 13 — Review Locked Accounts

Part 06 — Review SSH Configuration

Step 14 — Locate SSH Configuration

Step 15 — Review Effective SSH Configuration

SSH Hardening Questions

Step 16 — Root SSH Login

Critical Safety Rule

Step 17 — Validate SSH Configuration

Step 18 — Authentication Methods

Step 19 — Restrict SSH Access

Part 07 — Review SSH Keys

Security Review

Important

Part 08 — Review Installed Software

Step 20 — Inventory Packages

Step 21 — Identify Unnecessary Software

Principle

Part 09 — Review Running Services

Step 22 — Review Enabled Services

Service Review Table

Part 10 — Reduce Unnecessary Services

Finding Example

Part 11 — Review Listening Ports

Example Mental Model

Security Question

Part 12 — Map Ports to Business Requirements

Part 13 — Review Host Firewall

Step 23 — Check Firewalld

Step 24 — Check UFW

Firewall Principle

Critical Remote Access Warning

Part 14 — Firewall Validation

Part 15 — Review File Permissions

Step 25 — Review /etc/passwd

Step 26 — Review /etc/shadow

Part 16 — Find World-Writable Files

Step 27 — Review World-Writable Directories

Part 17 — /tmp Security

Sticky Bit Purpose

Part 18 — Review SUID Files

Security Review

Part 19 — Review SGID Files

Security Principle

Part 20 — Review Home Directory Permissions

Part 21 — Review SSH Directory Permissions

Part 22 — Review PATH

Security Review

PATH Security Model

Step 25 — Review `/etc/passwd`

Step 26 — Review `/etc/shadow`

Part 17 — `/tmp` Security

Part 36 — Review `/etc/fstab`