Lab 03 — Linux Security Automation with Bash

Mission Information

Difficulty: Intermediate
Estimated Time: 90–120 minutes
Primary Language: Bash
Security Domain: Linux Security / SOC / System Hardening / Incident Triage
Environment: Local Linux lab
Automation Type: Defensive Security Assessment

Mission

Your task is to build a Bash-based Linux security assessment script for a Linux system that you own or are explicitly authorized to administer.

The script will collect and summarize:

SYSTEM INFORMATION

CURRENT USER CONTEXT

LOCAL USERS

GROUPS

SUDO / PRIVILEGED ACCESS CONTEXT

FILE PERMISSIONS

RUNNING PROCESSES

RUNNING SERVICES

LISTENING PORTS

DISK USAGE

MEMORY USAGE

AUTHENTICATION EVENTS

SELECTED SECURITY CONFIGURATION

The final result will be:

LINUX HOST
    ↓
BASH SCRIPT
    ↓
COLLECT
    ↓
FILTER
    ↓
SUMMARIZE
    ↓
REPORT

Why This Lab Matters

Linux appears everywhere in cybersecurity.

You may find it running:

WEB SERVERS

CLOUD SERVERS

CONTAINERS

SECURITY APPLIANCES

LOGGING SYSTEMS

SIEM INFRASTRUCTURE

DATABASE SERVERS

APPLICATION SERVERS

KUBERNETES NODES

A security professional therefore needs to quickly answer questions such as:

What system am I looking at?

Who is logged in?

Which users exist?

Which accounts have privileged access?

Which processes are running?

Which services are enabled?

Which ports are listening?

Is disk space healthy?

What authentication failures occurred?

Are there risky file permissions?

Bash is one of the fastest ways to automate those checks.

Learning Objectives

By completing this lab, you should be able to:

BUILD A BASH SCRIPT

USE VARIABLES

CREATE FUNCTIONS

USE CONDITIONS

USE LOOPS

HANDLE FILE PATHS SAFELY

USE grep

USE awk

USE sort

USE uniq

USE find

USE ps

USE ss

USE systemctl

USE journalctl

CREATE REPORT FILES

LOG SCRIPT EXECUTION

HANDLE ERRORS

BUILD A REUSABLE LINUX SECURITY WORKFLOW

Final Architecture

               LINUX HOST
                   ↓
            ┌──────────────┐
            │ BASH SCRIPT  │
            └──────┬───────┘
                   ↓
      ┌────────────┼────────────┐
      ↓            ↓            ↓
   SYSTEM        USERS       PROCESSES
      ↓            ↓            ↓
   SERVICES     PERMISSIONS    NETWORK
      ↓            ↓            ↓
      └────────────┼────────────┘
                   ↓
          AUTHENTICATION LOGS
                   ↓
             SECURITY REPORT

Authorization and Safety

Run this lab only on:

YOUR OWN LINUX VM

TRAINING LAB

AUTHORIZED SERVER

SANDBOX ENVIRONMENT

This lab is designed for:

INVENTORY

VISIBILITY

AUDITING

DEFENSIVE REVIEW

It does not require exploitation, persistence, credential theft, or disabling security controls.

01 — Prepare the Linux Lab

You can use:

Ubuntu

Debian

Rocky Linux

AlmaLinux

CentOS Stream

Fedora

Examples in this lab assume a modern Linux distribution using:

systemd

Some commands may vary slightly between distributions.

02 — Verify Bash

Run:

bash --version

You should see something similar to:

GNU bash

03 — Create the Lab Workspace

Create:

mkdir -p linux-security-automation/{reports,logs,src}
cd linux-security-automation

Verify:

tree

If tree is unavailable:

find . -maxdepth 2 -type d

Expected:

linux-security-automation/
|
+-- logs/
|
+-- reports/
|
+-- src/

04 — Create the Main Script

Create:

src/linux-security-audit.sh

Open it using your preferred editor.

Example:

nano src/linux-security-audit.sh

05 — Add the Shebang

Start with:

#!/usr/bin/env bash

This tells the system to execute the file using Bash.

06 — Enable Safer Bash Behavior

Add:

set -euo pipefail

This enables:

-e
Stop on many command failures

-u
Treat unset variables as errors

-o pipefail
Detect failures inside pipelines

07 — Understand set -euo pipefail

Without careful error handling:

COMMAND FAILS
     ↓
SCRIPT CONTINUES
     ↓
REPORT MAY BE WRONG

With safer handling:

COMMAND FAILS
     ↓
ERROR BECOMES VISIBLE
     ↓
SCRIPT CAN STOP OR HANDLE IT

08 — Define Base Directories

Add:

SCRIPT_DIR="$(
    cd "$(dirname "${BASH_SOURCE[0]}")"
    && pwd
)"

BASE_DIR="$(
    cd "${SCRIPT_DIR}/.."
    && pwd
)"

REPORT_DIR="${BASE_DIR}/reports"
LOG_DIR="${BASE_DIR}/logs"

09 — Create Output Directories

Add:

mkdir -p "$REPORT_DIR"
mkdir -p "$LOG_DIR"

10 — Create a Run Timestamp

Add:

RUN_TIMESTAMP="$(
    date +"%Y%m%d-%H%M%S"
)"

11 — Define Output Files

Add:

REPORT_FILE="${REPORT_DIR}/linux-security-report-${RUN_TIMESTAMP}.txt"

LOG_FILE="${LOG_DIR}/linux-security-audit-${RUN_TIMESTAMP}.log"

12 — Create a Logging Function

Add:

log_message() {
    local level="$1"
    local message="$2"

    printf '%s [%s] %s\n' \
        "$(date +"%Y-%m-%dT%H:%M:%S%z")" \
        "$level" \
        "$message" \
        | tee -a "$LOG_FILE"
}

13 — Test Logging

Add temporarily:

log_message "INFO" "Test message"

Run:

bash src/linux-security-audit.sh

You should see:

[INFO] Test message

and a log file should appear in:

logs/

14 — Remove the Temporary Test Line

After confirming logging works, remove:

log_message "INFO" "Test message"

15 — Create a Report Section Function

Add:

write_section() {
    local title="$1"

    {
        echo
        echo "============================================================"
        echo "$title"
        echo "============================================================"
    } >> "$REPORT_FILE"
}

16 — Create the Report Header

Add:

initialize_report() {
    {
        echo "Linux Security Assessment Report"
        echo
        echo "Generated: $(date)"
        echo "Hostname: $(hostname)"
        echo "Script: linux-security-audit.sh"
    } > "$REPORT_FILE"
}

17 — Build the Main Workflow

Create:

main() {
    log_message "INFO" "Linux security assessment started"

    initialize_report

    log_message "INFO" "Report initialized"

    log_message "INFO" "Linux security assessment completed"

    echo
    echo "Report:"
    echo "$REPORT_FILE"
}

Then add:

main "$@"

18 — Make the Script Executable

Run:

chmod +x src/linux-security-audit.sh

Then:

./src/linux-security-audit.sh

19 — System Information Function

Add:

collect_system_information() {
    write_section "01 — System Information"

    {
        echo "Hostname:"
        hostname

        echo
        echo "Kernel:"
        uname -r

        echo
        echo "Architecture:"
        uname -m

        echo
        echo "Operating System:"
        if [[ -f /etc/os-release ]]; then
            cat /etc/os-release
        else
            echo "OS information unavailable"
        fi

        echo
        echo "Uptime:"
        uptime
    } >> "$REPORT_FILE"
}

20 — Add System Collection to main()

Add:

collect_system_information

Run the script again.

Review:

reports/

21 — Why System Context Matters

Before analyzing a Linux server, determine:

HOSTNAME

OPERATING SYSTEM

KERNEL

ARCHITECTURE

UPTIME

These values help establish:

WHAT SYSTEM IS THIS?

HOW LONG HAS IT BEEN RUNNING?

WHAT PLATFORM-SPECIFIC COMMANDS APPLY?

22 — Current User Context

Create:

collect_current_user() {
    write_section "02 — Current User Context"

    {
        echo "Current user:"
        whoami

        echo
        echo "User ID and groups:"
        id

        echo
        echo "Current shell:"
        echo "${SHELL:-unknown}"

        echo
        echo "Logged-in users:"
        who || true
    } >> "$REPORT_FILE"
}

23 — Why Current Context Matters

Always know:

WHO AM I?

WHAT GROUPS DO I BELONG TO?

WHAT PRIVILEGES DOES THIS SESSION HAVE?

before interpreting results.

24 — Local User Inventory

Create:

collect_local_users() {
    write_section "03 — Local User Inventory"

    awk -F: '
    {
        printf "user=%s uid=%s gid=%s shell=%s\n",
        $1, $3, $4, $7
    }
    ' /etc/passwd >> "$REPORT_FILE"
}

25 — Understand /etc/passwd

Typical format:

username:x:uid:gid:comment:home:shell

Example:

analyst:x:1001:1001:Analyst:/home/analyst:/bin/bash

The file does not normally contain plaintext passwords.

26 — Human User Review

UID conventions vary, but regular interactive users often have higher UID values.

For many distributions you may inspect:

awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwd

Do not treat this as universal across every Linux environment.

27 — Identify Accounts with Login Shells

Create an additional report block:

awk -F: '
$7 !~ /(nologin|false)$/ {
    print $1, $3, $7
}
' /etc/passwd

This can help identify accounts capable of interactive login.

28 — Group Inventory

Create:

collect_groups() {
    write_section "04 — Group Inventory"

    awk -F: '
    {
        printf "group=%s gid=%s members=%s\n",
        $1, $3, $4
    }
    ' /etc/group >> "$REPORT_FILE"
}

29 — Privileged Group Context

Common administrative groups may include:

sudo

wheel

Distribution-dependent.

Create:

collect_privileged_groups() {
    write_section "05 — Privileged Group Review"

    {
        if getent group sudo >/dev/null 2>&1; then
            echo "sudo group:"
            getent group sudo
        else
            echo "sudo group not present"
        fi

        echo

        if getent group wheel >/dev/null 2>&1; then
            echo "wheel group:"
            getent group wheel
        else
            echo "wheel group not present"
        fi
    } >> "$REPORT_FILE"
}

30 — Root Account Review

Create:

collect_root_context() {
    write_section "06 — Root Account Context"

    {
        getent passwd root

        echo

        echo "Accounts with UID 0:"
        awk -F: '$3 == 0 {print $1}' /etc/passwd
    } >> "$REPORT_FILE"
}

Security Observation

Normally you should understand why every:

UID 0

account exists.

Unexpected UID 0 accounts require review.

31 — Home Directory Review

Create:

collect_home_directories() {
    write_section "07 — Home Directory Review"

    {
        echo "Home directories:"
        ls -ld /home/* 2>/dev/null || true
    } >> "$REPORT_FILE"
}

32 — Why Home Permissions Matter

Overly permissive home directories can expose:

CONFIGURATION FILES

SHELL HISTORY

APPLICATION DATA

USER FILES

33 — World-Writable Files Concept

A world-writable file can be modified by any local user.

This may be legitimate in some locations, but deserves review when found in sensitive directories.

34 — Search Controlled Locations First

Do not start by scanning every mounted filesystem.

For the lab, inspect:

/etc

/opt

/usr/local

where permitted.

35 — World-Writable File Review

Create:

collect_world_writable_files() {
    write_section "08 — World-Writable File Review"

    {
        find /etc /opt /usr/local \
            -xdev \
            -type f \
            -perm -0002 \
            -print \
            2>/dev/null || true
    } >> "$REPORT_FILE"
}

36 — Why -xdev?

-xdev helps prevent find from crossing into other mounted filesystems.

This reduces unexpected scope.

37 — World-Writable Directory Review

Create:

collect_world_writable_directories() {
    write_section "09 — World-Writable Directory Review"

    {
        find /etc /opt /usr/local \
            -xdev \
            -type d \
            -perm -0002 \
            -print \
            2>/dev/null || true
    } >> "$REPORT_FILE"
}

38 — Interpret Results Carefully

World-writable does not automatically equal:

VULNERABILITY

For example, some directories intentionally support shared writing.

Always inspect:

PURPOSE

OWNER

STICKY BIT

LOCATION

APPLICATION REQUIREMENT

39 — SUID Files Concept

SUID files execute with the file owner’s effective permissions.

They deserve inventory and review.

40 — Inventory SUID Files

For a controlled lab:

find /usr/bin /usr/sbin /bin /sbin \
    -xdev \
    -type f \
    -perm -4000 \
    -print \
    2>/dev/null

41 — Add SUID Inventory

Create:

collect_suid_files() {
    write_section "10 — SUID File Inventory"

    find \
        /usr/bin \
        /usr/sbin \
        /bin \
        /sbin \
        -xdev \
        -type f \
        -perm -4000 \
        -print \
        2>/dev/null \
        >> "$REPORT_FILE" || true
}

Important

This lab inventories privileged files for defensive review.

Do not use the results to attempt unauthorized privilege escalation.

42 — SGID File Inventory

Create:

collect_sgid_files() {
    write_section "11 — SGID File Inventory"

    find \
        /usr/bin \
        /usr/sbin \
        /bin \
        /sbin \
        -xdev \
        -type f \
        -perm -2000 \
        -print \
        2>/dev/null \
        >> "$REPORT_FILE" || true
}

43 — Process Inventory

Create:

collect_processes() {
    write_section "12 — Running Processes"

    ps aux \
        --sort=-%cpu \
        >> "$REPORT_FILE"
}

44 — Why Processes Matter

Processes show:

WHAT IS CURRENTLY EXECUTING?

WHO OWNS IT?

HOW MUCH CPU / MEMORY?

WHAT COMMAND STARTED IT?

45 — Top CPU Processes

Add:

{
    echo
    echo "Top CPU-consuming processes:"
    ps aux --sort=-%cpu | head -n 11
} >> "$REPORT_FILE"

46 — Top Memory Processes

Add:

{
    echo
    echo "Top memory-consuming processes:"
    ps aux --sort=-%mem | head -n 11
} >> "$REPORT_FILE"

47 — Service Inventory

If systemd is available:

systemctl list-units \
    --type=service \
    --state=running

48 — Add Running Services

Create:

collect_running_services() {
    write_section "13 — Running Services"

    if command -v systemctl >/dev/null 2>&1; then
        systemctl list-units \
            --type=service \
            --state=running \
            --no-pager \
            >> "$REPORT_FILE" || true
    else
        echo "systemctl unavailable" \
            >> "$REPORT_FILE"
    fi
}

49 — Enabled Services

A service may not be running now but may start automatically during boot.

Create:

collect_enabled_services() {
    write_section "14 — Enabled Services"

    if command -v systemctl >/dev/null 2>&1; then
        systemctl list-unit-files \
            --type=service \
            --state=enabled \
            --no-pager \
            >> "$REPORT_FILE" || true
    else
        echo "systemctl unavailable" \
            >> "$REPORT_FILE"
    fi
}

50 — Security Question

For every running or enabled service, ask:

DO WE NEED THIS SERVICE?

WHO OWNS IT?

IS IT PATCHED?

IS IT NETWORK ACCESSIBLE?

IS IT CONFIGURED SECURELY?

51 — Listening Port Inventory

Modern Linux systems commonly provide:

ss

Run:

ss -lntup

52 — Understand ss

Common options:

-l
Listening

-n
Numeric

-t
TCP

-u
UDP

-p
Process information

Some process information may require elevated privileges.

53 — Add Network Listener Collection

Create:

collect_network_listeners() {
    write_section "15 — Network Listeners"

    if command -v ss >/dev/null 2>&1; then
        ss -lntup \
            >> "$REPORT_FILE" \
            2>&1 || true
    else
        echo "ss command unavailable" \
            >> "$REPORT_FILE"
    fi
}

54 — Why Listener Review Matters

Listening services expand the system’s:

NETWORK ATTACK SURFACE

Ask:

WHY IS THIS PORT OPEN?

WHICH PROCESS OWNS IT?

IS IT EXPECTED?

WHICH INTERFACE IS IT BOUND TO?

IS A FIREWALL RESTRICTING IT?

55 — Localhost vs All Interfaces

Example:

127.0.0.1:5432

means:

LOCALHOST ONLY

Whereas:

0.0.0.0:5432

usually means:

ALL IPv4 INTERFACES

This difference matters.

56 — Active Network Connections

Create:

collect_network_connections() {
    write_section "16 — Active Network Connections"

    if command -v ss >/dev/null 2>&1; then
        ss -ntup \
            >> "$REPORT_FILE" \
            2>&1 || true
    else
        echo "ss unavailable" \
            >> "$REPORT_FILE"
    fi
}

57 — Route Information

Create:

collect_routes() {
    write_section "17 — Routing Information"

    if command -v ip >/dev/null 2>&1; then
        ip route \
            >> "$REPORT_FILE" \
            2>&1 || true
    fi
}

58 — Interface Information

Create:

collect_interfaces() {
    write_section "18 — Network Interfaces"

    if command -v ip >/dev/null 2>&1; then
        ip -brief address \
            >> "$REPORT_FILE" \
            2>&1 || true
    fi
}

59 — Disk Usage

Create:

collect_disk_usage() {
    write_section "19 — Disk Usage"

    df -h \
        >> "$REPORT_FILE"
}

60 — Why Disk Usage Matters to Security

A full disk can cause:

LOGGING FAILURE

APPLICATION FAILURE

DATABASE FAILURE

MONITORING BLIND SPOTS

Therefore disk health is a security-relevant operational control.

61 — Inode Usage

Create:

collect_inode_usage() {
    write_section "20 — Inode Usage"

    df -i \
        >> "$REPORT_FILE"
}

62 — Memory Usage

Create:

collect_memory_usage() {
    write_section "21 — Memory Usage"

    if command -v free >/dev/null 2>&1; then
        free -h \
            >> "$REPORT_FILE"
    else
        cat /proc/meminfo \
            >> "$REPORT_FILE"
    fi
}

63 — CPU Load

Create:

collect_load() {
    write_section "22 — System Load"

    uptime \
        >> "$REPORT_FILE"

    echo \
        >> "$REPORT_FILE"

    cat /proc/loadavg \
        >> "$REPORT_FILE"
}

64 — Mounted Filesystems

Create:

collect_mounts() {
    write_section "23 — Mounted Filesystems"

    findmnt \
        >> "$REPORT_FILE" \
        2>&1 || mount \
        >> "$REPORT_FILE"
}

65 — Authentication Logs

Linux authentication logs vary by distribution.

Common locations:

/var/log/auth.log

or:

/var/log/secure

66 — Detect Authentication Log

Create:

get_auth_log() {
    if [[ -f /var/log/auth.log ]]; then
        echo "/var/log/auth.log"

    elif [[ -f /var/log/secure ]]; then
        echo "/var/log/secure"

    else
        echo ""
    fi
}

67 — Collect Recent Authentication Events

Create:

collect_authentication_events() {
    write_section "24 — Recent Authentication Events"

    local auth_log

    auth_log="$(get_auth_log)"

    if [[ -n "$auth_log" ]]; then
        tail -n 100 "$auth_log" \
            >> "$REPORT_FILE" \
            2>&1 || true

    elif command -v journalctl >/dev/null 2>&1; then
        journalctl \
            --no-pager \
            -n 100 \
            _COMM=sshd \
            >> "$REPORT_FILE" \
            2>&1 || true

    else
        echo "Authentication logs unavailable" \
            >> "$REPORT_FILE"
    fi
}

68 — Permission Consideration

Authentication logs may require:

ROOT

sudo

SECURITY LOG GROUP MEMBERSHIP

Your script should not assume every command succeeds.

69 — Failed SSH Login Review

Create:

collect_failed_authentication() {
    write_section "25 — Failed Authentication Summary"

    local auth_log

    auth_log="$(get_auth_log)"

    if [[ -n "$auth_log" ]]; then
        grep -iE \
            "failed password|authentication failure" \
            "$auth_log" \
            2>/dev/null \
            | tail -n 100 \
            >> "$REPORT_FILE" || true

    elif command -v journalctl >/dev/null 2>&1; then
        journalctl \
            --no-pager \
            _COMM=sshd \
            2>/dev/null \
            | grep -i "failed" \
            | tail -n 100 \
            >> "$REPORT_FILE" || true

    else
        echo "Failed authentication data unavailable" \
            >> "$REPORT_FILE"
    fi
}

70 — Count Repeated Source IPs

For compatible SSH failure records, you can perform a simple summary.

Example:

grep "Failed password" /var/log/auth.log \
    | awk '{print $(NF-3)}' \
    | sort \
    | uniq -c \
    | sort -nr

Log formats differ, so validate the field position before relying on this in production.

71 — Why Log Parsing Needs Validation

This works only when the record format matches your assumption.

Do not write:

FIELD 11 = IP
FOREVER

without checking actual logs.

72 — Build a Safer Failed-Source Function

For the lab:

collect_failed_sources() {
    write_section "26 — Failed Login Source Summary"

    local auth_log

    auth_log="$(get_auth_log)"

    if [[ -z "$auth_log" ]]; then
        echo "Authentication log unavailable" \
            >> "$REPORT_FILE"
        return
    fi

    grep -i "Failed password" "$auth_log" \
        2>/dev/null \
        | grep -oE \
            '([0-9]{1,3}\.){3}[0-9]{1,3}' \
        | sort \
        | uniq -c \
        | sort -nr \
        | head -n 20 \
        >> "$REPORT_FILE" || true
}

Important Limitation

The regex finds IPv4-looking strings but does not fully validate them.

A production pipeline should validate extracted IPs before using them for decisions.

73 — Successful Authentication Review

Create:

collect_successful_authentication() {
    write_section "27 — Successful Authentication Summary"

    local auth_log

    auth_log="$(get_auth_log)"

    if [[ -n "$auth_log" ]]; then
        grep -i "Accepted" "$auth_log" \
            2>/dev/null \
            | tail -n 100 \
            >> "$REPORT_FILE" || true

    elif command -v journalctl >/dev/null 2>&1; then
        journalctl \
            --no-pager \
            _COMM=sshd \
            2>/dev/null \
            | grep -i "Accepted" \
            | tail -n 100 \
            >> "$REPORT_FILE" || true

    else
        echo "Successful authentication data unavailable" \
            >> "$REPORT_FILE"
    fi
}

74 — Last Login Information

Create:

collect_login_history() {
    write_section "28 — Login History"

    last -n 20 \
        >> "$REPORT_FILE" \
        2>&1 || true
}

75 — Failed Login History

If available:

lastb

may display failed login history.

Add:

collect_failed_login_history() {
    write_section "29 — Failed Login History"

    if command -v lastb >/dev/null 2>&1; then
        lastb -n 20 \
            >> "$REPORT_FILE" \
            2>&1 || true
    else
        echo "lastb unavailable" \
            >> "$REPORT_FILE"
    fi
}

76 — Cron Review

Scheduled jobs should be understood.

Create:

collect_cron_configuration() {
    write_section "30 — Scheduled Task Inventory"

    {
        echo "/etc/crontab:"
        cat /etc/crontab \
            2>/dev/null || true

        echo
        echo "/etc/cron.d:"
        ls -la /etc/cron.d \
            2>/dev/null || true

        echo
        echo "Current user crontab:"
        crontab -l \
            2>/dev/null || \
            echo "No accessible user crontab"
    } >> "$REPORT_FILE"
}

77 — Scheduled Task Security Questions

Ask:

WHO CREATED THE JOB?

WHAT COMMAND RUNS?

WHICH ACCOUNT RUNS IT?

WHAT FILES CAN IT MODIFY?

IS THE SCRIPT PATH WRITABLE?

78 — SSH Configuration Review

Create:

collect_ssh_configuration() {
    write_section "31 — SSH Configuration Review"

    local ssh_config="/etc/ssh/sshd_config"

    if [[ -f "$ssh_config" ]]; then
        grep -Ei \
            '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|MaxAuthTries|AllowUsers|AllowGroups)' \
            "$ssh_config" \
            >> "$REPORT_FILE" || true
    else
        echo "sshd_config unavailable" \
            >> "$REPORT_FILE"
    fi
}

79 — Why Ignore Comments?

The pattern begins with:

^

and looks for actual configuration lines rather than commented examples where possible.

But keep in mind:

INCLUDED CONFIGURATION FILES

may also affect effective SSH configuration.

80 — Effective SSH Configuration

Where supported:

sshd -T

can show effective configuration.

This may require appropriate permissions and a valid SSH configuration.

For the lab, treat this as optional.

81 — Firewall Status

Common Linux firewall tools include:

ufw

firewalld

nftables

82 — Add Firewall Review

Create:

collect_firewall_status() {
    write_section "32 — Firewall Status"

    if command -v ufw >/dev/null 2>&1; then
        ufw status verbose \
            >> "$REPORT_FILE" \
            2>&1 || true

    elif command -v firewall-cmd >/dev/null 2>&1; then
        firewall-cmd --state \
            >> "$REPORT_FILE" \
            2>&1 || true

        firewall-cmd --list-all \
            >> "$REPORT_FILE" \
            2>&1 || true

    elif command -v nft >/dev/null 2>&1; then
        nft list ruleset \
            >> "$REPORT_FILE" \
            2>&1 || true

    else
        echo "No supported firewall utility detected" \
            >> "$REPORT_FILE"
    fi
}

83 — Do Not Modify Firewall Rules

This lab only:

READS

REPORTS

firewall configuration.

Do not automatically alter production firewall rules during an assessment.

84 — Package Update Awareness

Package commands vary by distribution.

The assessment can record package manager information without automatically installing updates.

85 — Detect Package Manager

Create:

collect_package_manager() {
    write_section "33 — Package Manager Information"

    for command_name in \
        apt \
        dnf \
        yum \
        zypper \
        pacman
    do
        if command -v "$command_name" >/dev/null 2>&1; then
            echo "Detected package manager: $command_name" \
                >> "$REPORT_FILE"
        fi
    done
}

86 — Why Not Automatically Patch?

Automatic patching can affect:

APPLICATION COMPATIBILITY

REBOOT REQUIREMENTS

BUSINESS OPERATIONS

Assessment automation should generally report:

STATE

before changing:

STATE

87 — Time Synchronization

Accurate time matters for security logs.

Create:

collect_time_status() {
    write_section "34 — Time Synchronization"

    {
        date

        echo

        if command -v timedatectl >/dev/null 2>&1; then
            timedatectl status
        fi
    } >> "$REPORT_FILE" 2>&1 || true
}

88 — Why Time Matters

If server clocks differ significantly:

LOG CORRELATION

becomes difficult.

Incident timelines depend on trustworthy timestamps.

89 — Environment Information

Create:

collect_environment_summary() {
    write_section "35 — Environment Summary"

    {
        echo "PATH:"
        printf '%s\n' "${PATH:-unknown}"

        echo
        echo "Shell:"
        printf '%s\n' "${SHELL:-unknown}"

        echo
        echo "Locale:"
        locale 2>/dev/null || true
    } >> "$REPORT_FILE"
}

90 — Security Note on PATH

A poorly controlled PATH can create unexpected command resolution behavior.

Your script should use trusted execution environments and controlled paths where appropriate.

91 — File Integrity Hash for the Report

Create:

hash_report() {
    local hash_file="${REPORT_FILE}.sha256"

    if command -v sha256sum >/dev/null 2>&1; then
        sha256sum "$REPORT_FILE" \
            > "$hash_file"
    elif command -v shasum >/dev/null 2>&1; then
        shasum -a 256 "$REPORT_FILE" \
            > "$hash_file"
    fi
}

92 — Why Hash the Report?

A cryptographic hash helps identify whether the report changed after generation.

Conceptually:

REPORT
   ↓
SHA-256
   ↓
INTEGRITY VALUE

93 — Build a Summary Section

Create:

generate_summary() {
    write_section "36 — Assessment Summary"

    {
        echo "Assessment completed."
        echo
        echo "Review areas:"
        echo "- Local accounts"
        echo "- Administrative groups"
        echo "- Privileged files"
        echo "- Running services"
        echo "- Network listeners"
        echo "- Authentication failures"
        echo "- Scheduled tasks"
        echo "- Firewall status"
        echo
        echo "Important:"
        echo "This report identifies configuration and activity requiring review."
        echo "It does not automatically prove compromise or vulnerability."
    } >> "$REPORT_FILE"
}

94 — Assemble the Complete Main Workflow

Your main() should now resemble:

main() {
    log_message "INFO" \
        "Linux security assessment started"

    initialize_report

    collect_system_information
    collect_current_user
    collect_local_users
    collect_groups
    collect_privileged_groups
    collect_root_context
    collect_home_directories
    collect_world_writable_files
    collect_world_writable_directories
    collect_suid_files
    collect_sgid_files
    collect_processes
    collect_running_services
    collect_enabled_services
    collect_network_listeners
    collect_network_connections
    collect_routes
    collect_interfaces
    collect_disk_usage
    collect_inode_usage
    collect_memory_usage
    collect_load
    collect_mounts
    collect_authentication_events
    collect_failed_authentication
    collect_failed_sources
    collect_successful_authentication
    collect_login_history
    collect_failed_login_history
    collect_cron_configuration
    collect_ssh_configuration
    collect_firewall_status
    collect_package_manager
    collect_time_status
    collect_environment_summary

    generate_summary

    hash_report

    log_message "INFO" \
        "Linux security assessment completed"

    echo
    echo "Report:"
    echo "$REPORT_FILE"
}

95 — Run the Complete Script

Run:

./src/linux-security-audit.sh

96 — Review Output

You should now have:

reports/
|
+-- linux-security-report-<timestamp>.txt
|
+-- linux-security-report-<timestamp>.txt.sha256

and:

logs/
|
+-- linux-security-audit-<timestamp>.log

97 — Run with Appropriate Privileges

Some data may be inaccessible to a standard account.

Start with:

./src/linux-security-audit.sh

Then, only on your authorized lab system, compare with:

sudo ./src/linux-security-audit.sh

Security Principle

Do not automatically assume:

MORE PRIVILEGE
=
BETTER SCRIPT

Use:

LEAST PRIVILEGE

and elevate only when the data requirement justifies it.

98 — Review the Report as an Analyst

Do not just confirm the script ran.

Ask:

ARE UNEXPECTED USERS PRESENT?

WHO HAS ADMINISTRATIVE ACCESS?

ARE THERE EXTRA UID 0 ACCOUNTS?

ARE WORLD-WRITABLE FILES PRESENT?

ARE PRIVILEGED FILES EXPECTED?

WHICH SERVICES ARE RUNNING?

ARE UNEXPECTED PORTS LISTENING?

ARE AUTHENTICATION FAILURES REPEATED?

IS THE FIREWALL ENABLED?

IS SYSTEM TIME SYNCHRONIZED?

99 — Build a Finding Classification

For the training lab, use:

INFORMATIONAL

REVIEW

HIGH REVIEW

Avoid automatically calling configuration differences:

CRITICAL VULNERABILITIES

without validation.

100 — Example Finding: Unexpected UID 0 Account

Possible output:

Finding:
Additional UID 0 account detected

Evidence:
service-admin

Status:
HIGH REVIEW

Analyst action:

VALIDATE BUSINESS REQUIREMENT

CHECK ACCOUNT OWNER

CHECK CREATION HISTORY

CHECK RECENT AUTHENTICATION

101 — Example Finding: Unexpected Listener

Suppose:

0.0.0.0:8080

is listening.

Do not assume:

MALICIOUS

Ask:

WHICH PROCESS OWNS IT?

IS THE SERVICE APPROVED?

IS IT EXTERNALLY ACCESSIBLE?

IS THE FIREWALL RESTRICTING IT?

IS AUTHENTICATION ENABLED?

102 — Example Finding: Authentication Failures

Suppose:

25 failed logins

come from one source.

Investigate:

SOURCE IP

TARGET USERS

TIME WINDOW

SUCCESSFUL LOGIN AFTER FAILURES

VPN / NAT CONTEXT

MFA EVENTS

103 — Example Finding: World-Writable File

Suppose the script identifies:

/opt/example/config.txt

Review:

OWNER

GROUP

APPLICATION REQUIREMENT

WHO CAN MODIFY IT?

DOES A PRIVILEGED SERVICE READ IT?

104 — Export Dedicated Files

For a more mature version, create separate outputs:

system-information.txt

users.txt

privileged-access.txt

processes.txt

services.txt

network-listeners.txt

authentication-summary.txt

permissions-review.txt

105 — Why Separate Outputs?

It makes integration easier.

For example:

BASH
 ↓
JSON / TEXT
 ↓
PYTHON
 ↓
NORMALIZE
 ↓
CENTRAL REPORT

106 — Add CSV Output for Listening Ports

A future version could convert:

ss

output into:

protocol

address

port

process

Then export:

network-listeners.csv

107 — Add JSON Output

Bash can generate JSON, but complex JSON construction is easier and safer with tools such as:

jq

or by passing raw results to Python.

108 — Check for jq

Run:

command -v jq

If installed:

jq

can support structured JSON workflows.

109 — Bash vs Python Decision

Use Bash when:

COMMANDS ALREADY EXIST

LINUX DATA IS TEXT-ORIENTED

WORKFLOW IS SIMPLE

SHELL PIPELINES ARE CLEAR

Move toward Python when:

DATA STRUCTURES BECOME COMPLEX

MULTIPLE APIs ARE REQUIRED

JSON IS HEAVY

CORRELATION GROWS

TESTING NEEDS INCREASE

110 — Add Script Help

Create:

show_help() {
    cat <<'EOF'
Linux Security Audit

Usage:
  ./linux-security-audit.sh

Purpose:
  Collect defensive Linux security inventory
  and generate a local assessment report.

Run only on systems you own or are
explicitly authorized to administer.
EOF
}

111 — Add --help

Before running the assessment:

if [[ "${1:-}" == "--help" ]]; then
    show_help
    exit 0
fi

112 — Test

Run:

./src/linux-security-audit.sh --help

113 — Add Dependency Checks

Create:

check_dependencies() {
    local commands=(
        awk
        grep
        sort
        find
        ps
        df
    )

    local missing=0

    for command_name in "${commands[@]}"; do
        if ! command -v "$command_name" >/dev/null 2>&1; then
            log_message \
                "ERROR" \
                "Missing command: $command_name"

            missing=1
        fi
    done

    if [[ "$missing" -ne 0 ]]; then
        return 1
    fi
}

114 — Why Dependency Checking Matters

Without it:

SCRIPT STARTS
   ↓
COMMAND MISSING
   ↓
PARTIAL REPORT

With validation:

CHECK FIRST
   ↓
KNOWN ENVIRONMENT
   ↓
RUN

115 — Add Dependency Check to Main

At the beginning:

if ! check_dependencies; then
    log_message \
        "ERROR" \
        "Required dependencies missing"

    exit 1
fi

116 — Add Temporary File Safety

If your future script needs temporary files, use:

mktemp

instead of predictable names such as:

/tmp/report.tmp

117 — Temporary Directory Pattern

Example:

TEMP_DIR="$(mktemp -d)"

Then:

cleanup() {
    rm -rf "$TEMP_DIR"
}

trap cleanup EXIT

118 — Why trap Matters

It ensures cleanup even when the script exits unexpectedly.

CREATE TEMP DATA
      ↓
SCRIPT RUNS
      ↓
EXIT
      ↓
CLEANUP

119 — Avoid Unsafe Expansion

Prefer:

"$variable"

instead of:

$variable

when handling paths or user-supplied values.

120 — Avoid eval

Do not build command strings and execute them using:

eval

unless you have a very specific, reviewed requirement.

Prefer explicit commands and arguments.

121 — ShellCheck

If available, validate the script using:

shellcheck src/linux-security-audit.sh

ShellCheck helps identify:

QUOTING ISSUES

UNSAFE EXPANSIONS

COMMON SHELL BUGS

122 — Syntax Check

Run:

bash -n src/linux-security-audit.sh

No output generally means syntax parsing succeeded.

123 — Test on a Non-Critical VM

Before using any assessment script against a production system:

LAB VM
   ↓
TEST
   ↓
REVIEW OUTPUT
   ↓
FIX
   ↓
CONTROLLED DEPLOYMENT

124 — Failure Test: Missing Command

Temporarily add a fake dependency such as:

not-a-real-command

Verify:

DEPENDENCY CHECK FAILS
CLEANLY

Then remove it.

125 — Failure Test: Read Permission

Run as a normal user.

Document which sections return:

PERMISSION DENIED

PARTIAL DATA

NO DATA

This teaches an important lesson:

NO RESULT

does not always mean:

NO ACTIVITY

126 — Failure Test: Missing Authentication Log

On distributions using only the journal:

/var/log/auth.log

may not exist.

Verify the script falls back to:

journalctl

where possible.

127 — Performance Test

Time the script:

time ./src/linux-security-audit.sh

Security assessment automation should not create excessive load.

128 — Scope Control

Avoid commands such as unrestricted:

find /

by default on production systems.

Why?

Because it may:

SCAN HUGE FILESYSTEMS

CROSS NETWORK MOUNTS

CREATE LOAD

GENERATE LARGE OUTPUT

129 — Better Scope Principle

Use:

KNOWN DIRECTORIES

-xdev

MAX DEPTH WHERE APPROPRIATE

EXPLICIT TARGETS

130 — Add Host Metadata

Add to the report header:

echo "Collection user: $(whoami)"
echo "Collection UID: $(id -u)"

This helps document how the report was collected.

131 — Add Script Version

Near the top:

SCRIPT_VERSION="1.0.0"

Include it in the report:

echo "Script version: $SCRIPT_VERSION"

132 — Why Versioning Matters

If a report was created three months ago, you need to know:

WHICH SCRIPT VERSION
GENERATED IT?

133 — Create an Assessment ID

Add:

ASSESSMENT_ID="LINUX-${RUN_TIMESTAMP}"

Include it in:

REPORT

LOG

134 — Evidence Metadata

A professional assessment should capture:

ASSESSMENT ID

HOSTNAME

DATE

COLLECTION USER

SCRIPT VERSION

REPORT HASH

135 — Create the README

Create:

README.md

Include:

PROJECT PURPOSE

LAB REQUIREMENTS

AUTHORIZED USE

SUPPORTED SYSTEMS

HOW TO RUN

OUTPUT FILES

SECURITY CHECKS

LIMITATIONS

TROUBLESHOOTING

136 — README Security Statement

Include:

This project performs read-only Linux security
inventory and defensive assessment activities.

Use it only against Linux systems you own or
are explicitly authorized to administer.

137 — Document Limitations

Your script does not provide:

FULL CIS BENCHMARK ASSESSMENT

MALWARE DETECTION

ROOTKIT DETECTION

FULL PACKAGE VULNERABILITY ANALYSIS

APPLICATION CONFIGURATION REVIEW

CONTAINER ANALYSIS

CLOUD CONTROL-PLANE REVIEW

These require dedicated workflows.

138 — Portfolio Architecture

Your final repository can look like:

linux-security-automation/
|
+-- src/
|   +-- linux-security-audit.sh
|
+-- reports/
|
+-- logs/
|
+-- tests/
|
+-- README.md
|
+-- architecture.md

139 — Lab Deliverables

Submit:

linux-security-audit.sh

Sample Report

Report SHA-256

Execution Log

README

Architecture Diagram

Analyst Findings Summary

140 — Analyst Findings Summary Template

Create:

Assessment ID:
Host:
Date:

Finding 01:
Title:
Evidence:
Status:
Recommendation:

Finding 02:
Title:
Evidence:
Status:
Recommendation:

141 — Security Assessment Workflow

The lab has now created:

LINUX SERVER
     ↓
SYSTEM INVENTORY
     ↓
IDENTITY REVIEW
     ↓
PERMISSION REVIEW
     ↓
PROCESS REVIEW
     ↓
SERVICE REVIEW
     ↓
NETWORK REVIEW
     ↓
AUTHENTICATION REVIEW
     ↓
SECURITY REPORT

142 — Common Bash Security Automation Mistakes

Avoid:

RUNNING EVERYTHING AS ROOT

UNQUOTED VARIABLES

NO ERROR HANDLING

NO DEPENDENCY CHECKS

NO LOGGING

SCANNING ENTIRE FILESYSTEMS NEEDLESSLY

SUPPRESSING EVERY ERROR

ASSUMING LOG FORMATS NEVER CHANGE

AUTOMATICALLY CHANGING CONFIGURATION

NO REPORT TIMESTAMP

NO SCRIPT VERSION

NO DOCUMENTATION

143 — The Problem with 2>/dev/null

You have used it selectively in this training script.

Do not apply:

2>/dev/null

to everything.

Otherwise you may hide:

PERMISSION ERRORS

COMMAND FAILURES

FILESYSTEM PROBLEMS

Sometimes errors are security-relevant information.

144 — Read-Only First

This lab follows:

COLLECT
 ↓
ASSESS
 ↓
REPORT

not:

COLLECT
 ↓
AUTOMATICALLY MODIFY SYSTEM

This is deliberate.

145 — Hardening Comes After Assessment

A professional workflow is:

ASSESS
   ↓
VALIDATE FINDING
   ↓
UNDERSTAND BUSINESS IMPACT
   ↓
CREATE CHANGE
   ↓
TEST
   ↓
APPROVE
   ↓
REMEDIATE
   ↓
VERIFY

146 — Mission Validation Checklist

Confirm:

• Bash script created
• set -euo pipefail used
• Variables quoted
• Report directory created
• Logging implemented
• Host information collected
• User information collected
• Group information collected
• UID 0 accounts reviewed
• Administrative groups reviewed
• Home directories reviewed
• World-writable files reviewed
• World-writable directories reviewed
• SUID files inventoried
• SGID files inventoried
• Processes inventoried
• Running services inventoried
• Enabled services inventoried
• Listening ports inventoried
• Active connections inventoried
• Routes reviewed
• Interfaces reviewed
• Disk usage collected
• Inodes collected
• Memory status collected
• Load collected
• Authentication logs reviewed
• Failed authentication summarized
• Successful authentication reviewed
• Login history collected
• Cron configuration reviewed
• SSH configuration reviewed
• Firewall status reviewed
• Time synchronization reviewed
• Report generated
• Report hashed
• Script syntax checked
• Script tested in an authorized lab
• Findings manually validated

Mission Review

You started with:

LINUX COMMANDS

such as:

whoami

id

ps

ss

find

grep

awk

systemctl

journalctl

You converted them into:

ONE REPEATABLE
SECURITY ASSESSMENT
WORKFLOW

What You Built

You now have a Bash-based Linux security assessment tool capable of collecting:

HOST INFORMATION

IDENTITY DATA

PRIVILEGED ACCESS CONTEXT

PERMISSION DATA

PROCESS DATA

SERVICE DATA

NETWORK DATA

AUTHENTICATION DATA

SYSTEM HEALTH DATA

and transforming it into:

ANALYST-READY
SECURITY REPORT

Key Security Lesson

The most important lesson is:

INVENTORY
COMES BEFORE
SECURITY DECISIONS

You cannot decide whether something is suspicious until you first understand:

WHAT EXISTS

WHAT IS RUNNING

WHO HAS ACCESS

WHAT IS EXPOSED

WHAT ACTIVITY OCCURRED

Final Mental Model

Whenever you assess a Linux system, think:

WHO AM I?
    ↓
WHAT SYSTEM IS THIS?
    ↓
WHO CAN LOG IN?
    ↓
WHO HAS PRIVILEGE?
    ↓
WHAT IS RUNNING?
    ↓
WHAT IS LISTENING?
    ↓
WHAT FILES ARE HIGH RISK?
    ↓
WHAT AUTHENTICATION ACTIVITY OCCURRED?
    ↓
WHAT REQUIRES HUMAN REVIEW?

The value of Bash is not:

RUNNING ONE COMMAND

The value is:

TURNING MANY SMALL
LINUX SECURITY CHECKS
INTO ONE SAFE,
REPEATABLE WORKFLOW

What’s Next?

➡️ Lab 04 — Windows Security Automation with PowerShell

In the next lab, you will move from Linux security automation into Windows security assessment.

You will build:

WINDOWS HOST
     ↓
POWERSHELL
     ↓
SYSTEM INVENTORY
     ↓
LOCAL USERS
     ↓
LOCAL ADMINISTRATORS
     ↓
PROCESSES
     ↓
SERVICES
     ↓
NETWORK CONNECTIONS
     ↓
WINDOWS EVENT LOGS
     ↓
DEFENDER STATUS
     ↓
FIREWALL STATUS
     ↓
SECURITY REPORT

You will use PowerShell objects and defensive Windows administration capabilities to create a reusable Windows security inventory and assessment workflow.