Lab 05 — Linux Security

Welcome to the final hands-on lab in the Linux lab series.

You have already worked through:

Lab 01 — Linux Administration
        ↓
Lab 02 — Linux Hardening
        ↓
Lab 03 — Linux IAM
        ↓
Lab 04 — Linux Networking

Now you will bring those skills together into:

Lab 05 — Linux Security

This lab changes your perspective from:

How Do I Administer
This Linux Server?

to:

Is This Linux Server Secure?

What Is Exposed?

Who Has Access?

What Is Running?

What Has Changed?

What Looks Suspicious?

Can We Investigate It?

How Should We Remediate It?

Mission Information

Lab: Linux Security
Level: Intermediate
Estimated Time: 150–210 minutes
Environment: Authorized disposable Linux VM
Primary Role: Linux Security Engineer
Secondary Roles: SOC Analyst, Incident Responder, Cloud Security Engineer, Security Consultant, DevSecOps Engineer

Mission Scenario

Your organization is preparing an important Linux application server for a security review.

The server is operational, but the security team wants an independent assessment before approving it for production.

You have been assigned to review:

Operating System
      ↓
Accounts
      ↓
Privileges
      ↓
Authentication
      ↓
Filesystem
      ↓
Processes
      ↓
Services
      ↓
Software
      ↓
Network
      ↓
Firewall
      ↓
Logging
      ↓
Auditing
      ↓
Scheduled Execution
      ↓
Security Controls
      ↓
Suspicious Activity

You must distinguish:

Expected

from:

Unexpected

and convert technical observations into professional security findings.

Mission Objectives

By completing this lab, you should be able to:

Establish a Linux security baseline
Identify the operating system and kernel
Review user and service identities
Identify privileged accounts
Review groups and sudo access
Evaluate authentication exposure
Review SSH security
Assess filesystem permissions
Identify world-writable resources
Review SUID and SGID executables
Identify unusual processes
Review running and enabled services
Assess installed software
Review patch status
Identify network listeners
Investigate active connections
Review host firewall controls
Evaluate SELinux or AppArmor
Review system and authentication logs
Review Linux auditing
Investigate scheduled execution
Identify basic persistence indicators
Build a security timeline
Document findings and remediation
Produce a Linux security assessment report

Lab Architecture

+----------------------------------+
|         Security Analyst         |
+----------------+-----------------+
                 |
                 | SSH / Console
                 |
                 v
+----------------------------------+
|          Linux Server            |
|                                  |
|  Identity       Processes        |
|  Privilege      Services         |
|  Filesystem     Packages         |
|  Network        Firewall         |
|  SSH            Logs             |
|  Audit          Persistence      |
|  SELinux / AppArmor              |
+----------------+-----------------+
                 |
                 v
+----------------------------------+
| Security Findings & Evidence     |
+----------------------------------+

Security Assessment Mental Model

Use:

ASSET
  ↓
IDENTITY
  ↓
PRIVILEGE
  ↓
SOFTWARE
  ↓
PROCESS
  ↓
SERVICE
  ↓
NETWORK
  ↓
LOGGING
  ↓
SECURITY CONTROL
  ↓
EVIDENCE

Golden Rule

Do not assume:

Unfamiliar
=
Malicious

Instead:

Observe
   ↓
Collect Evidence
   ↓
Compare Baseline
   ↓
Establish Context
   ↓
Determine Risk

Part 01 — Prepare the Security Workspace

Create:

mkdir -p ~/linux-security-lab

Enter it:

cd ~/linux-security-lab

Create:

mkdir baseline evidence findings reports

Your structure becomes:

linux-security-lab/
├── baseline/
├── evidence/
├── findings/
└── reports/

Part 02 — Confirm Authorization

Before conducting any security assessment, confirm:

System Is Authorized

Scope Is Known

Assessment Window Is Known

Permitted Actions Are Known

Evidence Handling Is Defined

This lab should be performed only against:

Your Own Linux VM

Authorized Training Infrastructure

Approved Enterprise Systems

Part 03 — Identify the System

Run:

hostname

Then:

cat /etc/os-release

Then:

uname -a

Review:

Hostname

Distribution

Version

Kernel

Architecture

Step 01 — Capture System Baseline

Create:

{
  echo "Linux Security Baseline"
  echo "======================="
  echo "Date: $(date)"
  echo "Hostname: $(hostname)"
  echo "Kernel: $(uname -r)"
  echo "User: $(whoami)"
  echo
  cat /etc/os-release
} > baseline/system.txt

Why This Matters

Security findings require context.

For example:

Vulnerability
      ↓
Affected Software Version
      ↓
Specific Operating System

Without an accurate inventory, vulnerability and configuration analysis becomes unreliable.

Part 04 — Review System Uptime

Run:

uptime

Record:

Uptime

Load Average

Current Time

Security Perspective

Uptime can help answer questions such as:

Was the System Recently Rebooted?

Could a Security Update Be Waiting for Reboot?

Does the Timeline Match the Incident?

It is evidence, not proof by itself.

Part 05 — Review Current Identity

Run:

whoami

Then:

id

Document:

Username

UID

Primary Group

Supplementary Groups

Administrative Capability

Part 06 — Inventory Users

Run:

getent passwd

Save:

getent passwd > baseline/users.txt

Review accounts as:

Human Accounts

Administrative Accounts

Service Accounts

System Accounts

Step 02 — Identify Interactive Accounts

A useful starting point is:

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

Exact shell paths vary by environment.

Ask:

Who Owns This Account?

Does It Need Interactive Login?

Is It Still Required?

Does Its Access Match Its Role?

Part 07 — Identify UID 0 Accounts

Run:

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

UID 0 represents root-equivalent identity.

Security Finding

Unexpected UID 0 accounts should receive immediate review.

Finding:
Unexpected Privileged Identity

Observation:
An account other than the approved root
identity has UID 0.

Risk:
The account possesses root-equivalent
operating-system privileges.

Recommendation:
Validate ownership and business need and
remove unauthorized root-equivalent
identity assignments through the approved
change process.

Part 08 — Review Groups

Run:

getent group

Save:

getent group > baseline/groups.txt

Focus on groups that may grant:

Administrative Access

Application Access

Sensitive File Access

Device Access

Part 09 — Review sudo

For your authorized account:

sudo -l

Review appropriate administrative groups and sudo configuration.

Security questions:

Who Can Elevate Privilege?

What Can They Execute?

Is Broad Access Necessary?

Is Privileged Activity Logged?

Is Access Individually Attributable?

Privilege Model

Standard User
      ↓
Approved Administrative Requirement
      ↓
Controlled sudo
      ↓
Logging
      ↓
Review

Part 10 — Look for Shared Administrative Access

Shared privileged identities weaken accountability.

Poor model:

Admin A ─┐
Admin B ─┼──> shared-admin ──> root
Admin C ─┘

Better:

Admin A ──> Individual Identity ──> sudo
Admin B ──> Individual Identity ──> sudo
Admin C ──> Individual Identity ──> sudo

Finding Example

Finding:
Shared Privileged Account

Risk:
Administrative activity cannot be
reliably attributed to an individual.

Recommendation:
Use individually attributable identities
with controlled privilege escalation.

Part 11 — Review Service Accounts

Identify accounts associated with:

Web Servers

Databases

Monitoring Agents

Backup Agents

Application Services

Ask:

Does the Service Need a Login Shell?

Does It Need a Home Directory?

Does It Need sudo?

Which Files Does It Own?

Which Network Resources Does It Access?

Security Principle

Prefer:

Application
      ↓
Dedicated Service Account
      ↓
Minimum Required Privilege

rather than:

Application
      ↓
root

unless a legitimate technical requirement exists.

Part 12 — Review Logged-In Users

Run:

who

Then:

Review:

User

Terminal

Source

Login Time

Current Activity

Where available:

last

Ask:

Are Sources Expected?

Are Login Times Expected?

Are Privileged Users Expected?

Are There Unusual Patterns?

Part 13 — Review Authentication Failures

Authentication evidence varies by distribution.

Possible sources include:

systemd Journal

/var/log/auth.log

/var/log/secure

Use the appropriate source for your system.

Look for patterns such as:

Repeated Failures

Unknown Users

Unexpected Sources

Successful Login After Many Failures

Important

A failed-login spike can represent:

User Error

Automation Failure

Credential Misconfiguration

Scanning

Password Guessing

Investigate context before assigning cause.

Part 14 — Review SSH

Determine whether SSH is active:

systemctl status sshd

or:

systemctl status ssh

depending on the distribution.

Review the effective SSH configuration where supported:

sudo sshd -T

SSH Security Questions

Ask:

Is Root Remote Login Required?

Which Authentication Methods Are Enabled?

Are Unnecessary Users Allowed?

Which Networks Can Reach SSH?

Are SSH Events Logged?

Are Authorized Keys Managed?

Part 15 — Review SSH Keys

For authorized identities, review:

~/.ssh/

authorized_keys

Do not copy private key material into your evidence.

Ask:

Who Owns Each Key?

Is It Still Required?

Is It Shared?

Is It Stale?

Can It Be Revoked?

Finding Example

Finding:
Unmanaged SSH Authorization

Observation:
An SSH public key is authorized for an
administrative account but its current
owner cannot be confirmed.

Risk:
An unauthorized or former key holder
may retain remote access.

Recommendation:
Validate key ownership and remove stale
or unauthorized keys.

Part 16 — Filesystem Security

Linux filesystem permissions are fundamental security controls.

Start with sensitive locations such as:

/etc

/root

/home

/var

Application Directories

SSH Directories

Log Directories

Step 04 — Review Sensitive Files

Check metadata rather than exposing sensitive contents.

For example:

ls -l /etc/passwd

and:

sudo ls -l /etc/shadow

Do not copy password hashes into reports.

Part 17 — Review Home Directories

Run:

ls -ld /home/*

Review:

Owner

Group

Permissions

Ask:

Can Other Users Read Data
They Do Not Need?

Part 18 — Search for World-Writable Files

In an authorized disposable lab:

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

Do not classify every result as a vulnerability automatically.

For each result determine:

Purpose

Owner

Location

Business Requirement

Exposure

Part 19 — Review World-Writable Directories

Shared writable directories may be legitimate.

Review:

Permissions

Sticky Bit

Ownership

Purpose

Check:

ls -ld /tmp

A common secure shared-directory pattern includes the sticky bit.

Part 20 — Review SUID Files

Run:

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

SUID files can execute with the effective privileges of their owner.

Do not remove SUID permissions blindly.

Investigate:

File

Owner

Package

Purpose

Baseline

Business Requirement

Part 21 — Review SGID Files

Run:

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

Again:

Expected?
      ↓
Known Package?
      ↓
Required?
      ↓
Approved?

Part 22 — Identify Orphaned Ownership

Security assessments should consider files whose UID or GID no longer maps cleanly to an active identity.

Why?

Deleted Identity
      ↓
Files Remain
      ↓
UID/GID Reused
      ↓
Unexpected Ownership

Review orphaned ownership carefully in authorized environments.

Part 23 — Review Recently Modified Files

During investigation, file timestamps can provide useful leads.

For a controlled directory:

find /etc -type f -mtime -7 -print 2>/dev/null

This example identifies files with modification times in a recent window.

Important

Recent modification does not equal compromise.

It may represent:

Patch

Configuration Change

Deployment

Administrator Activity

Automation

Correlate timestamps with approved changes and logs.

Part 24 — Review File Integrity Concept

Security-sensitive files may require monitoring for unexpected change.

Examples:

SSH Configuration

sudo Configuration

Authentication Configuration

Application Configuration

Scheduled Tasks

A mature environment may use:

File Integrity Monitoring

to detect unauthorized modifications.

Part 25 — Review Processes

Run:

ps aux

Then:

ps -ef

Review:

PID

PPID

User

CPU

Memory

Command

Process Investigation Model

PROCESS
   ↓
PID
   ↓
USER
   ↓
PARENT
   ↓
EXECUTABLE
   ↓
NETWORK
   ↓
FILES
   ↓
TIMELINE

Part 26 — Identify Resource-Heavy Processes

Run:

ps aux --sort=-%cpu | head

Then:

ps aux --sort=-%mem | head

High resource usage can indicate:

Normal Application Load

Runaway Process

Misconfiguration

Unexpected Software

Do not conclude malicious activity from resource usage alone.

Part 27 — Investigate a Process

For an authorized PID:

ps -fp <PID>

You can inspect its parent relationship:

ps -o pid,ppid,user,lstart,cmd -p <PID>

Ask:

Which User Started It?

What Is Its Parent?

When Did It Start?

What Executable Is Running?

Is It Expected?

Part 28 — `/proc`

Linux exposes runtime process information through:

/proc

For an authorized PID, information may be available under:

/proc/<PID>/

This can help analysts understand:

Executable

Command Line

Environment

Open Resources

Process State

Be careful: process environments can contain sensitive information.

Do not copy secrets into evidence unnecessarily.

Part 29 — Review Services

Run:

systemctl --type=service --state=running

Then review enabled services:

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

Ask:

What Is Running?

Why?

Who Owns It?

Does It Need Network Access?

Should It Start Automatically?

Part 30 — Correlate Services and Ports

Run:

sudo ss -lntup

Create a matrix:

Service	Process	Port	Bind Address	Required
SSH	sshd	22	Review	Yes
Application	Review	Review	Review	Yes
Unknown	Review	Review	Review	Investigate

Security Principle

Every network listener should have:

Owner

Purpose

Approved Exposure

Part 31 — Investigate Unknown Listener

If you discover an unexpected listener:

PORT
  ↓
PID
  ↓
PROCESS
  ↓
USER
  ↓
EXECUTABLE
  ↓
SERVICE
  ↓
START METHOD
  ↓
BUSINESS REQUIREMENT

Do not identify software as malicious solely because it uses an unusual port.

Part 32 — Review Active Network Connections

Run:

sudo ss -ntp

Review:

Local Address

Remote Address

State

Process

PID

Security Questions

For unexpected outbound communication ask:

Which Process?

Which User?

Which Destination?

Which Port?

When Did It Begin?

Is It Required?

Does It Match the Baseline?

Part 33 — Investigate an Outbound Connection

Use:

NETWORK CONNECTION
        ↓
PID
        ↓
PROCESS
        ↓
PARENT PROCESS
        ↓
USER
        ↓
EXECUTABLE
        ↓
LOGS
        ↓
BUSINESS CONTEXT

This is a powerful Linux incident-analysis workflow.

Part 34 — Review Firewall

Determine the active host-firewall technology.

Possible examples:

firewalld

nftables

ufw

For firewalld:

sudo firewall-cmd --list-all

For UFW:

sudo ufw status verbose

For nftables:

sudo nft list ruleset

Firewall Assessment Questions

Is the Firewall Active?

Which Services Are Allowed?

Which Sources Are Allowed?

Is Administrative Access Restricted?

Are Unnecessary Ports Exposed?

Does IPv6 Receive Equivalent Protection?

Finding Example

Finding:
Administrative Service Broadly Accessible

Observation:
The Linux remote-administration service
is reachable from a broader network range
than required.

Risk:
Unnecessary exposure increases the
opportunity for authentication attacks
and exploitation.

Recommendation:
Restrict administrative access to
approved management sources and enforce
strong authentication and monitoring.

Part 35 — Review Installed Packages

Debian-family example:

dpkg -l

RPM-family example:

rpm -qa

Save an inventory where appropriate.

Package Security Questions

Is the Package Required?

Is It Supported?

Is It Updated?

Which Repository Supplied It?

Does It Introduce a Service?

Part 36 — Review Patch Status

Use the package-management tools appropriate to your distribution to identify available updates.

Do not automatically apply production updates during an assessment.

Follow:

Discover
   ↓
Assess
   ↓
Prioritize
   ↓
Test
   ↓
Approve
   ↓
Deploy
   ↓
Validate

Vulnerability vs Patch

Remember:

Available Update

does not automatically mean:

Currently Exploitable Vulnerability

Similarly:

No Available Package Update

does not prove:

No Security Risk

Security analysis requires context.

Part 37 — Review Package Repositories

Review configured repositories.

Ask:

Are They Approved?

Are They Expected?

Are They Trusted?

Are Unsupported Sources Present?

Finding Example

Finding:
Unapproved Software Repository

Observation:
The server references a package repository
that is not part of the approved software
supply-chain configuration.

Risk:
Software from an untrusted or unmanaged
source could introduce unsupported or
malicious components.

Recommendation:
Validate the repository requirement and
restrict software installation to approved
trusted sources.

Part 38 — Review SELinux

On systems using SELinux:

getenforce

Then, where available:

sestatus

Possible states include:

Enforcing

Permissive

Disabled

Security Principle

Do not use:

Disable SELinux

as a generic troubleshooting solution.

Instead:

Application Problem
      ↓
Standard Permissions
      ↓
Configuration
      ↓
SELinux Evidence
      ↓
Context / Policy
      ↓
Correct Remediation

Part 39 — Review SELinux Context

For an authorized file:

ls -Z <file>

For a directory:

ls -Zd <directory>

When a legitimate application is blocked, investigate whether:

Label Is Incorrect

Boolean Is Required

Policy Is Missing

Application Is Behaving Unexpectedly

Part 40 — Review AppArmor

On distributions using AppArmor, review active profiles with the supported tools available on the platform.

Understand:

Enforce

Complain

Unconfined

The security objective is:

Application
      ↓
Minimum Required Capability

Part 41 — Review System Logs

Start with:

journalctl -n 100

Review:

Errors

Warnings

Service Activity

Authentication

Kernel Events

Step 05 — Review Boot Events

journalctl -b

This may reveal:

Service Failures

Filesystem Problems

Device Problems

Security Control Issues

Part 42 — Review Authentication Logs

Depending on distribution:

/var/log/auth.log

or:

/var/log/secure

may contain authentication-related information.

The system journal may also contain relevant evidence.

Authentication Investigation

Look for:

Failed Login

Successful Login

sudo Activity

Account Changes

SSH Sessions

Part 43 — Review sudo Activity

Your goal is to answer:

Who Elevated Privilege?

When?

What Happened?

Was It Expected?

Correlate:

Authentication Logs

sudo Logs

Shell History Where Appropriate

Change Records

System Logs

Do not treat shell history as authoritative forensic evidence by itself.

Part 44 — Review Audit Framework

Some Linux systems use:

auditd

Check:

systemctl status auditd

where available.

Review configured rules:

sudo auditctl -l

where authorized.

Audit Value

Linux auditing can provide evidence related to:

Security-Relevant System Calls

Identity Changes

Sensitive File Activity

Administrative Actions

Part 45 — Logging vs Auditing

Understand the distinction:

Application/System Logs
      ↓
What Components Reported

versus:

Audit Framework
      ↓
Security-Relevant OS Activity

Both can be useful.

Part 46 — Review Time Synchronization

Run:

timedatectl

Review:

System Time

Timezone

Synchronization

Why Time Matters

Incident timelines may combine:

Linux Logs

Firewall Logs

Cloud Logs

SIEM Events

Application Logs

If clocks disagree significantly:

Timeline Reconstruction

becomes much harder.

Part 47 — Review Scheduled Tasks

Run:

crontab -l

Review authorized system scheduling locations.

Also check:

systemctl list-timers --all

Security Questions

For every scheduled execution ask:

Which User?

Which Command?

Which Script?

Who Owns the Script?

Can Another User Modify It?

Is It Expected?

When Does It Run?

Part 48 — Persistence Concept

Attackers and legitimate administrators may use some of the same operating-system mechanisms.

Potential persistence locations can include:

Scheduled Tasks

systemd Services

Startup Configuration

SSH Authorized Keys

User Accounts

Application Startup Mechanisms

The presence of one does not prove malicious activity.

The question is:

Is It Expected?

Part 49 — Review Enabled Services

An unexpected enabled service may start automatically after reboot.

Review:

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

Compare against:

Approved Server Baseline

Part 50 — Review systemd Unit Locations

Systemd configuration can exist in locations such as:

/etc/systemd/system

/usr/lib/systemd/system

/lib/systemd/system

depending on distribution.

Pay special attention to:

Unexpected Custom Units

Recently Modified Units

Unknown Executables

Unusual Users

Part 51 — Review Authorized Keys as Persistence

An unauthorized public key added to:

authorized_keys

can create continued remote access.

Review:

Key Owner

Account

File Modification Time

Business Requirement

Associated Change Record

Never expose private keys.

Part 52 — Review Shell Startup Files

User shell startup files may include:

.bashrc

.profile

.bash_profile

depending on the environment.

Unexpected commands in startup files may require investigation.

Again:

Custom

does not mean:

Malicious

Part 53 — Review Temporary Locations

Security investigations may include directories such as:

/tmp

/var/tmp

because applications and users frequently write there.

Review:

Unexpected Executables

Unexpected Ownership

Unusual Modification Times

Do not delete suspicious files before deciding whether they are needed as evidence.

Part 54 — Evidence Preservation

When suspicious activity is discovered, avoid unnecessary destructive actions.

Before remediation consider capturing:

Process Information

Network Connections

File Metadata

Relevant Logs

User Information

Service Configuration

Timestamps

Incident Principle

Detect
   ↓
Preserve
   ↓
Understand
   ↓
Contain
   ↓
Remediate

not:

Detect
   ↓
Delete Everything

Part 55 — Build a Timeline

Suppose you observe:

02:10 Failed SSH Logins

02:16 Successful Login

02:18 sudo Activity

02:21 New User Created

02:24 New Service Started

02:27 External Connection

Individually these events may have multiple explanations.

Together they create:

Investigation Context

Timeline Table

Time	Event	Identity	Source	Evidence
02:10	Failed login	user	IP	Auth log
02:16	Successful login	user	IP	Auth log
02:18	Privilege use	user	Local	sudo log
02:21	Account creation	root	Local	Audit/log
02:24	Service start	service	Local	Journal
02:27	Connection	process	Remote IP	Socket/network evidence

Part 56 — Correlation

Security analysis becomes stronger when multiple sources agree.

Authentication Log
        +
Process Information
        +
Network Connection
        +
Filesystem Metadata
        +
Audit Evidence
        ↓
Higher-Confidence Conclusion

Part 57 — Security Investigation Scenario

Scenario

Monitoring reports:

Unexpected Outbound Connection
from Linux Server

Your workflow:

01 Confirm Alert

02 Identify Destination

03 Identify Local Port

04 Identify PID

05 Identify Process

06 Identify User

07 Identify Parent Process

08 Review Executable

09 Review Start Time

10 Review Authentication Activity

11 Review Persistence

12 Build Timeline

13 Determine Business Context

Part 58 — Investigate Without Immediate Destruction

Do not immediately:

Kill Process

Delete File

Remove User

Reboot Server

unless immediate containment is required by your incident-response procedure.

These actions can alter:

Volatile Evidence

Timestamps

Connections

Process State

Part 59 — Security Finding: Unexpected Service

Finding:
Unexpected System Service

Observation:
A running and enabled service is not
included in the approved server baseline
and its business owner cannot initially
be identified.

Risk:
An unauthorized service may increase
attack surface or provide persistent
execution.

Recommendation:
Identify the service owner, executable,
configuration, network exposure, and
installation source. Disable or remove
the service if it is confirmed to be
unauthorized.

Part 60 — Security Finding: Excessive Privilege

Finding:
Excessive Administrative Access

Observation:
A standard user has broad administrative
privileges beyond the requirements of
their documented role.

Risk:
Compromise of the account could provide
full system control.

Recommendation:
Reduce privileges to the minimum required
and periodically review privileged access.

Part 61 — Security Finding: Weak File Permissions

Finding:
Sensitive File Permissions Too Broad

Observation:
A security-sensitive file can be accessed
by users who do not require that access.

Risk:
Unauthorized users may read or modify
sensitive configuration or data.

Recommendation:
Restrict ownership and permissions
according to least privilege and validate
application compatibility.

Part 62 — Security Finding: Missing Security Logging

Finding:
Insufficient Security Event Visibility

Observation:
Important authentication or
administrative activity is not retained
with sufficient detail for investigation.

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

Recommendation:
Enable appropriate system and security
logging, protect logs, synchronize time,
and forward required events to a
centralized monitoring platform.

Part 63 — Security Finding: Unexpected External Connection

Finding:
Unexpected External Communication

Observation:
A Linux process communicates with an
external destination that is not part
of the documented server workflow.

Risk:
The communication could represent
misconfiguration, unauthorized software,
or malicious activity.

Recommendation:
Correlate the connection with process,
identity, executable, destination,
timeline, and business context before
determining containment and remediation.

Part 64 — Security Finding: Mandatory Access Control

Finding:
Mandatory Access Control Not Enforcing

Observation:
The platform's expected SELinux or
AppArmor security control is not operating
in its approved enforcement state.

Risk:
Processes may have fewer restrictions
than required by the security baseline.

Recommendation:
Determine why enforcement is unavailable,
resolve compatibility issues, and restore
the approved security state.

Part 65 — Risk Rating

Prioritize findings using context.

Consider:

Exposure

Privilege

Exploitability

Data Sensitivity

Business Criticality

Existing Controls

Potential Impact

A simple model:

LIKELIHOOD
    ×
IMPACT
    =
RISK

Example

Finding:
Unused Local Package

Exposure:
Low

Privilege:
Low

Impact:
Limited

Priority:
Lower

Compare with:

Finding:
Internet-Reachable Administrative Service

Exposure:
High

Privilege:
High

Impact:
High

Priority:
High

Part 66 — Validate Security Controls

Your assessment should determine whether controls are merely:

Configured

or actually:

Effective

Example:

Firewall Installed

does not prove:

Firewall Protecting Server

Likewise:

auditd Installed

does not prove:

Useful Audit Rules Exist

Part 67 — Negative Testing

Security testing should validate denied behavior where safe and authorized.

Examples:

Unauthorized User
Cannot Access Sensitive Directory

Unapproved Network Source
Cannot Reach Administrative Service

Service Account
Cannot Log In Interactively

Standard User
Cannot Perform Administrative Action

Part 68 — Review Defense in Depth

A secure Linux server should not depend on one control.

Think:

Identity
   +
Least Privilege
   +
Filesystem Permissions
   +
SELinux/AppArmor
   +
Firewall
   +
Patching
   +
Logging
   +
Monitoring
   +
Backups

Part 69 — Linux Security in AWS

For an EC2 Linux workload:

AWS IAM
   ↓
VPC
   ↓
Security Group
   ↓
EC2 Instance
   ↓
Linux IAM
   ↓
Linux Firewall
   ↓
Application

A Linux assessment must consider that some controls may exist outside the operating system.

Part 70 — Linux Security in Azure

Microsoft Entra ID
      ↓
Azure RBAC
      ↓
Virtual Network
      ↓
NSG
      ↓
Linux VM
      ↓
Linux Security

Part 71 — Linux Security in Google Cloud

Google Cloud IAM
      ↓
VPC Firewall
      ↓
Compute Engine
      ↓
Linux IAM
      ↓
Host Security

Cloud Security Lesson

Do not assess:

Linux VM

in isolation from:

Cloud Control Plane

Part 72 — Linux Security and Containers

Container security depends heavily on Linux.

Container
   ↓
Runtime
   ↓
Linux Kernel

Relevant Linux controls include:

Namespaces

Capabilities

Filesystem Permissions

SELinux/AppArmor

Seccomp

Users

Networking

Part 73 — Linux Security and Kubernetes

Kubernetes workloads ultimately execute on Linux nodes in many environments.

Kubernetes
      ↓
Container Runtime
      ↓
Linux Node
      ↓
Kernel

Linux security therefore supports:

Node Hardening

Runtime Security

Container Isolation

Incident Response

Part 74 — Linux Security and SOC Operations

Linux telemetry can help SOC teams investigate:

Suspicious Login

Privilege Escalation

New User

New Service

Unexpected Process

Unknown Port

Outbound Connection

Persistence

Configuration Change

SOC Investigation Model

ALERT
   ↓
HOST
   ↓
USER
   ↓
PROCESS
   ↓
NETWORK
   ↓
FILES
   ↓
LOGS
   ↓
TIMELINE
   ↓
DECISION

Part 75 — Linux Security and Incident Response

Security assessment asks:

Is the Server Secure?

Incident response asks:

What Happened?

Strong Linux skills support both.

Part 76 — Build the Linux Security Report

Create:

Linux Security Assessment Report

Your report should contain the following sections.

1. Executive Summary

Include:

Assessment Scope

Overall Security Posture

Critical Observations

Highest-Risk Findings

Recommended Priorities

2. System Information

Document:

Hostname

Distribution

Version

Kernel

Server Role

Assessment Date

3. Identity Review

Document:

Human Accounts

Service Accounts

UID 0 Accounts

Dormant Accounts

Group Memberships

4. Privileged Access

Document:

sudo

Administrative Groups

Shared Accounts

SUID/SGID

Root Access

5. Authentication

Document:

SSH

Authorized Keys

Authentication Logs

Remote Access Exposure

6. Filesystem Security

Document:

Sensitive Permissions

World-Writable Resources

Home Directories

Special Permissions

Unexpected Changes

7. Process Review

Document:

Unexpected Processes

High Resource Processes

Process Ownership

Parent/Child Relationships

8. Service Review

Document:

Running Services

Enabled Services

Unexpected Services

Business Requirements

9. Network Security

Document:

Listening Ports

Bind Addresses

Active Connections

Firewall

Unexpected Destinations

10. Software Security

Document:

Packages

Pending Updates

Repositories

Unsupported Software

11. Security Controls

Document:

SELinux/AppArmor

Logging

Auditing

Time Synchronization

12. Persistence Review

Document:

Scheduled Tasks

systemd Units

SSH Keys

Startup Configuration

13. Findings

For every finding:

Title

Severity

Observation

Evidence

Risk

Recommendation

Owner

Status

Part 77 — Sample Findings Table

Finding	Risk	Priority
Excessive sudo	Privilege abuse	High
Broad SSH exposure	Remote attack surface	High
Unknown listener	Unapproved exposure	High
Stale account	Unauthorized access	Medium
Weak permissions	Data exposure	Medium
Unnecessary package	Attack surface	Low/Medium
Missing centralized logging	Detection gap	Medium/High

Risk depends on actual context.

Part 78 — Evidence Handling

Security evidence should be:

Relevant

Accurate

Timestamped

Protected

Minimized

Traceable

Do not place:

Passwords

Password Hashes

Private Keys

API Tokens

Application Secrets

into ordinary assessment reports.

Part 79 — Assessment Evidence Checklist

Capture appropriate evidence for:

Part 80 — Final Practical Challenge

Without relying on a graphical security scanner, determine:

01 Which Linux system is this?

02 Which users can log in?

03 Who has administrative access?

04 Which service accounts exist?

05 Which sensitive permissions are excessive?

06 Which SUID/SGID files exist?

07 Which processes are running?

08 Which services start automatically?

09 Which ports are listening?

10 Which processes own those ports?

11 Which external connections exist?

12 Which firewall controls are active?

13 Is SELinux/AppArmor enforcing?

14 Are important events logged?

15 Is auditing available?

16 Which scheduled tasks exist?

17 Are there unexpected persistence mechanisms?

18 What changed recently?

19 What is the highest-risk issue?

20 What should be remediated first?

Part 81 — Professional Security Assessment Workflow

Use this workflow in real environments:

01 Authorization

02 Scope

03 Asset Identification

04 Baseline Collection

05 Identity Review

06 Privilege Review

07 Authentication Review

08 Filesystem Review

09 Process Review

10 Service Review

11 Software Review

12 Network Review

13 Security Control Review

14 Logging Review

15 Persistence Review

16 Evidence Correlation

17 Risk Assessment

18 Findings

19 Remediation

20 Validation

21 Reporting

Part 82 — Common Linux Security Mistakes

Avoid:

Assuming Unknown Means Malicious

Deleting Evidence Immediately

Disabling SELinux to Fix Applications

Disabling Firewall to Troubleshoot

Using chmod 777

Ignoring Service Accounts

Ignoring SSH Keys

Ignoring Outbound Connections

Ignoring IPv6

Ignoring Scheduled Tasks

Ignoring systemd Persistence

Ignoring Cloud-Level Controls

Trusting Shell History as Complete Evidence

Applying Hardening Without Business Context

Reporting Findings Without Evidence

Part 83 — Security Maturity Model

Level 1 — Reactive

Patch When Needed

Manual Account Management

Basic Firewall

Level 2 — Baseline

Documented Hardening

Access Reviews

Central Logging

Approved Services

Level 3 — Managed

Configuration Management

SIEM

EDR

Automated Compliance

Central IAM

Vulnerability Management

Level 4 — Continuous

Continuous Monitoring

Configuration Drift Detection

Automated Response

Policy as Code

Just-in-Time Privilege

Threat Detection

Part 84 — Career Connection

The skills practiced in this lab directly support:

Linux Security Engineer

SOC Analyst

Incident Responder

Cloud Security Engineer

Security Consultant

DevSecOps Engineer

Platform Security Engineer

Cybersecurity Analyst

Security Architect

Interview Scenario 01

You discover an unfamiliar Linux process. What should you do?

Identify PID
      ↓
Identify User
      ↓
Identify Parent
      ↓
Identify Executable
      ↓
Review Network Activity
      ↓
Review Logs
      ↓
Compare Baseline
      ↓
Determine Context

Interview Scenario 02

You find an unknown listening port. Is the server compromised?

Not necessarily.

Investigate:

Process

Service

User

Executable

Business Requirement

Network Exposure

Logs

before concluding.

Interview Scenario 03

You discover suspicious activity. Should you immediately delete the suspicious file?

Usually not before considering evidence requirements and the incident-response procedure.

First determine whether you need to preserve:

File Metadata

Process Information

Connections

Logs

Timeline

Interview Scenario 04

A server is fully patched. Is it secure?

Not necessarily.

It may still have:

Weak IAM

Excessive sudo

Bad SSH Configuration

Open Ports

Weak Permissions

Disabled Logging

Poor Security Controls

Interview Scenario 05

Why is Linux administration knowledge essential for security analysts?

Because you cannot reliably identify:

Abnormal Linux Behavior

without understanding:

Normal Linux Behavior

50 Linux Security Interview Questions

What is Linux security?
What is a Linux security baseline?
Why is asset identification important?
How do you identify the Linux distribution?
Why is kernel information security-relevant?
What is UID 0?
How would you identify privileged accounts?
Why are service accounts security-sensitive?
What is least privilege?
Why are shared administrator accounts risky?
How would you review sudo access?
Why should SSH keys be reviewed?
What is a stale SSH key?
What are world-writable files?
What is the sticky bit?
What is SUID?
What is SGID?
Why should special-permission files be baselined?
What are orphaned files?
Why are file timestamps useful?
What is file integrity monitoring?
How would you investigate an unknown process?
Why is PPID useful during investigation?
What information does /proc expose?
How would you identify running services?
What is the difference between running and enabled services?
How do you identify listening ports?
Why is a wildcard bind security-relevant?
How would you investigate an outbound connection?
Why should egress traffic be monitored?
What is host firewalling?
Why is IPv6 part of a security assessment?
Why should installed packages be inventoried?
Why are software repositories security-relevant?
What is SELinux?
Why should SELinux not simply be disabled?
What is AppArmor?
Why is centralized logging important?
What is Linux auditing?
Why is time synchronization important?
Why should scheduled tasks be reviewed?
How can systemd relate to persistence?
Why are authorized SSH keys part of persistence review?
What is evidence preservation?
Why is timeline reconstruction important?
What is event correlation?
What is defense in depth?
How does Linux security relate to cloud security?
How does Linux security support Kubernetes security?
What is your Linux security assessment methodology?

Lab Completion Checklist

System

Identity

Privilege

Authentication

Reviewed SSH
Reviewed authorized keys
Reviewed authentication events
Reviewed remote access exposure

Filesystem

Reviewed sensitive permissions
Reviewed home directories
Reviewed world-writable files
Reviewed shared directories
Reviewed recent changes
Understood file integrity monitoring

Processes

Services

Reviewed running services
Reviewed enabled services
Mapped services to business requirements
Investigated unexpected services

Network

Software

Reviewed installed packages
Reviewed patch status
Reviewed repositories
Identified unnecessary software

Security Controls

Reviewed SELinux/AppArmor
Reviewed logging
Reviewed auditing
Reviewed time synchronization

Persistence

Investigation

Built an event timeline
Correlated multiple evidence sources
Preserved relevant evidence
Identified suspicious activity
Distinguished evidence from assumptions

Reporting

Final Linux Security Mental Model

When approaching any Linux server, think:

WHAT IS THIS SYSTEM?
        ↓
WHO CAN ACCESS IT?
        ↓
WHO HAS PRIVILEGE?
        ↓
WHAT SOFTWARE EXISTS?
        ↓
WHAT IS RUNNING?
        ↓
WHAT IS EXPOSED?
        ↓
WHO IS IT TALKING TO?
        ↓
WHAT HAS CHANGED?
        ↓
WHAT STARTS AUTOMATICALLY?
        ↓
WHAT SECURITY CONTROLS EXIST?
        ↓
CAN WE SEE WHAT HAPPENED?
        ↓
WHAT IS DIFFERENT FROM BASELINE?

Mission Accomplished

You have completed the five core Linux labs:

Lab 01 — Linux Administration
        ↓
Lab 02 — Linux Hardening
        ↓
Lab 03 — Linux IAM
        ↓
Lab 04 — Linux Networking
        ↓
Lab 05 — Linux Security

You have progressed from:

Linux User

to:

Linux Administrator
        ↓
Linux Security Administrator
        ↓
Linux Security Analyst

More importantly, you now understand the security workflow:

BASELINE
   ↓
OBSERVE
   ↓
COLLECT
   ↓
CORRELATE
   ↓
ANALYZE
   ↓
PRIORITIZE
   ↓
REMEDIATE
   ↓
VALIDATE
   ↓
DOCUMENT

What’s Next?

➡️ Runbook 01 — Linux Incident Investigation

The labs taught you individual technical skills.

The runbooks will now teach you how to apply those skills as repeatable professional operational procedures.

In the next runbook, you will learn how to respond when:

SOC Alert
    ↓
Suspicious Linux Host
    ↓
Initial Triage
    ↓
Identity Investigation
    ↓
Process Investigation
    ↓
Network Investigation
    ↓
Persistence Review
    ↓
Log Correlation
    ↓
Timeline Reconstruction
    ↓
Scope Assessment
    ↓
Containment Decision
    ↓
Evidence and Reporting

Your Linux journey now moves into operational security:

Linux Certifications
        ↓
Linux Labs
        ↓
Runbook 01 — Linux Incident Investigation
        ↓
Runbook 02 — Linux Security Assessment
        ↓
Runbook 03 — Linux Server Hardening

Lab 05 — Linux Security

Mission Information

Mission Scenario

Mission Objectives

Lab Architecture

Security Assessment Mental Model

Golden Rule

Part 01 — Prepare the Security Workspace

Part 02 — Confirm Authorization

Part 03 — Identify the System

Step 01 — Capture System Baseline

Why This Matters

Part 04 — Review System Uptime

Security Perspective

Part 05 — Review Current Identity

Part 06 — Inventory Users

Step 02 — Identify Interactive Accounts

Part 07 — Identify UID 0 Accounts

Security Finding

Part 08 — Review Groups

Part 09 — Review sudo

Privilege Model

Part 10 — Look for Shared Administrative Access

Finding Example

Part 11 — Review Service Accounts

Security Principle

Part 12 — Review Logged-In Users

Step 03 — Review Login History

Part 13 — Review Authentication Failures

Important

Part 14 — Review SSH

SSH Security Questions

Part 15 — Review SSH Keys

Finding Example

Part 16 — Filesystem Security

Step 04 — Review Sensitive Files

Part 17 — Review Home Directories

Part 18 — Search for World-Writable Files

Part 19 — Review World-Writable Directories

Part 20 — Review SUID Files

Part 21 — Review SGID Files

Part 22 — Identify Orphaned Ownership

Part 23 — Review Recently Modified Files

Important

Part 24 — Review File Integrity Concept

Part 25 — Review Processes

Process Investigation Model

Part 26 — Identify Resource-Heavy Processes

Part 27 — Investigate a Process

Part 28 — /proc

Part 29 — Review Services

Part 30 — Correlate Services and Ports

Security Principle

Part 31 — Investigate Unknown Listener

Part 32 — Review Active Network Connections

Security Questions

Part 33 — Investigate an Outbound Connection

Part 34 — Review Firewall

Firewall Assessment Questions

Finding Example

Part 35 — Review Installed Packages

Package Security Questions

Part 36 — Review Patch Status

Vulnerability vs Patch

Part 37 — Review Package Repositories

Finding Example

Part 38 — Review SELinux

Security Principle

Part 39 — Review SELinux Context

Part 40 — Review AppArmor

Part 41 — Review System Logs

Step 05 — Review Boot Events

Part 42 — Review Authentication Logs

Authentication Investigation

Part 43 — Review sudo Activity

Part 44 — Review Audit Framework

Audit Value

Part 45 — Logging vs Auditing

Part 46 — Review Time Synchronization

Why Time Matters

Part 28 — `/proc`