02 — Bash for Cybersecurity

Bash is one of the most important command-line and scripting environments for Linux-based cybersecurity work.

Security professionals regularly use Bash when working with:

LINUX SERVERS

CLOUD VMs

CONTAINERS

SECURITY TOOLS

LOG FILES

INCIDENT RESPONSE

DEVSECOPS

AUTOMATION

PENETRATION TESTING LABS

The goal of this module is not to memorize hundreds of Linux commands.

The goal is to understand how to combine small commands into repeatable security workflows.

The core Bash model is:

COMMAND
   ↓
OUTPUT
   ↓
PIPE
   ↓
FILTER
   ↓
PROCESS
   ↓
RESULT

For example:

SECURITY LOG
    ↓
grep
    ↓
FILTER FAILED LOGINS
    ↓
awk
    ↓
EXTRACT USERS
    ↓
sort
    ↓
uniq
    ↓
COUNT EVENTS

This is where Bash becomes extremely useful.

Why Bash Matters in Cybersecurity

Bash gives you direct access to:

FILES

DIRECTORIES

PROCESSES

SERVICES

PERMISSIONS

NETWORK CONNECTIONS

LOGS

SYSTEM CONFIGURATION

It is therefore especially valuable for:

Security Engineers

SOC Analysts

Cloud Security Engineers

Penetration Testers

Incident Responders

DevSecOps Engineers

Linux Administrators

Threat Hunters

Bash Learning Path

Follow this sequence:

LINUX SHELL
    ↓
FILES
    ↓
DIRECTORIES
    ↓
PERMISSIONS
    ↓
PROCESSES
    ↓
SERVICES
    ↓
PIPES
    ↓
REDIRECTION
    ↓
grep
    ↓
cut
    ↓
sort
    ↓
uniq
    ↓
awk
    ↓
sed
    ↓
VARIABLES
    ↓
CONDITIONS
    ↓
LOOPS
    ↓
FUNCTIONS
    ↓
ARGUMENTS
    ↓
NETWORK COMMANDS
    ↓
LOG ANALYSIS
    ↓
SECURITY AUTOMATION

01 — Identify Your Shell

Run:

echo "$SHELL"

You may see:

/bin/bash

Check Bash version:

bash --version

02 — Understand the Shell

The shell sits between:

YOU
 ↓
COMMAND
 ↓
SHELL
 ↓
OPERATING SYSTEM

Example:

whoami

The shell interprets the command and displays the result.

03 — Basic Security Context

Start with:

whoami

Then:

id

Then:

hostname

Then:

pwd

These answer:

WHO AM I?

WHAT GROUPS DO I HAVE?

WHICH HOST AM I ON?

WHERE AM I?

04 — Command History

View your shell history:

history

Security professionals should remember that shell history may contain sensitive information.

Avoid placing:

PASSWORDS

API KEYS

TOKENS

PRIVATE SECRETS

directly into commands where possible.

05 — Working with Directories

Show current directory:

pwd

List contents:

ls

Detailed view:

ls -la

Change directory:

cd /var/log

Return home:

cd ~

06 — Create a Practice Workspace

Create:

mkdir -p ~/bash-cybersecurity

Move into it:

cd ~/bash-cybersecurity

Create folders:

mkdir logs scripts reports evidence

Your structure becomes:

bash-cybersecurity/
|
+-- logs/
|
+-- scripts/
|
+-- reports/
|
+-- evidence/

07 — Working with Files

Create a file:

touch notes.txt

View:

cat notes.txt

Write:

echo "Security lab started" > notes.txt

Append:

echo "Log analysis completed" >> notes.txt

Redirection Mental Model

COMMAND OUTPUT
      ↓
      >
      ↓
FILE

> overwrites.

>> appends.

08 — Standard Output and Error

Linux commands typically use:

STDIN

STDOUT

STDERR

Conceptually:

INPUT
 ↓
COMMAND
 ├── STANDARD OUTPUT
 └── STANDARD ERROR

Redirect normal output:

command > output.txt

Redirect errors:

command 2> errors.txt

Redirect both:

command > output.txt 2>&1

09 — Copy and Move Files

Copy:

cp notes.txt evidence/

Move:

mv notes.txt reports/

Rename:

mv old.txt new.txt

10 — Remove Files Carefully

Remove:

rm file.txt

Directories:

rm -r directory/

Be cautious with:

rm -rf

especially when running with elevated privilege.

Always verify:

pwd

and the exact target before destructive operations.

11 — File Types

Use:

file <filename>

Example:

file security.log

This can help identify whether something is:

TEXT

EXECUTABLE

ARCHIVE

IMAGE

BINARY

12 — View File Metadata

Use:

stat security.log

This provides:

Size

Owner

Permissions

Timestamps

Filesystem Information

13 — Linux Permissions

Run:

ls -l

Example:

-rw-r----- 1 analyst security 1024 Aug 29 security.log

Interpret:

OWNER

GROUP

OTHERS

with:

READ

WRITE

EXECUTE

14 — Permission Values

Common numeric values:

4 = Read

2 = Write

1 = Execute

Example:

750

means:

OWNER
rwx

GROUP
r-x

OTHERS
---

15 — Change Permissions

In your own lab:

chmod 640 security.log

For a script:

chmod 750 script.sh

16 — Review Ownership

Use:

ls -l

Change ownership only when authorized and required.

Example administrative form:

sudo chown user:group file

Do not change ownership on production systems without approval.

17 — Security Importance of Permissions

A key Linux security question is:

WHO CAN READ?

WHO CAN WRITE?

WHO CAN EXECUTE?

Especially for:

CONFIGURATION FILES

SCRIPTS

SERVICE FILES

LOGS

CREDENTIAL FILES

PRIVATE KEYS

18 — Find Files

Find by name:

find . -name "*.log"

Find directories:

find . -type d

Find files:

find . -type f

19 — Find Recently Modified Files

For incident response in an authorized system:

find . -type f -mtime -1

This finds files modified within approximately the last day.

20 — Find Large Files

Example:

find . -type f -size +10M

Useful for:

LOG REVIEW

DISK INVESTIGATION

EVIDENCE COLLECTION

21 — Find Files by Permission

In your own lab:

find . -type f -perm -002

This identifies world-writable files in the current tree.

Do not assume every result is automatically a vulnerability.

22 — Pipes

The pipe operator:

|

passes output from one command into another.

Example:

cat security.log | grep "FAILED"

More simply:

grep "FAILED" security.log

Pipe Mental Model

COMMAND A
   ↓
OUTPUT
   ↓
|
   ↓
COMMAND B

23 — grep

grep is one of the most useful Linux security commands.

Example:

grep "FAILED" security.log

Case-insensitive:

grep -i "failed" security.log

Show line numbers:

grep -n "FAILED" security.log

24 — Recursive grep

Search through a directory you are authorized to inspect:

grep -R "ERROR" ./logs

Useful for:

LOGS

APPLICATION CONFIGURATION

INCIDENT REVIEW

Avoid broad secret-hunting across systems without a legitimate need.

25 — Invert Matching

Show lines not matching:

grep -v "INFO" security.log

This can remove noise.

26 — Count Matching Lines

grep -c "FAILED" security.log

27 — cut

cut extracts fields.

Example file:

admin01,10.10.10.20,FAILED
user01,10.10.10.30,SUCCESS

Extract first column:

cut -d',' -f1 events.csv

28 — sort

Sort lines:

sort users.txt

Numeric sort:

sort -n numbers.txt

Reverse:

sort -r users.txt

29 — uniq

Remove adjacent duplicates:

sort users.txt | uniq

Count:

sort users.txt | uniq -c

Security Example

cut -d',' -f1 events.csv | sort | uniq -c

This can count events by user.

30 — head and tail

First lines:

head security.log

Last lines:

tail security.log

Last 20 lines:

tail -n 20 security.log

31 — Follow Logs in Real Time

For your own lab:

tail -f application.log

This is useful while validating:

APPLICATION EVENTS

AUTHENTICATION EVENTS

SERVICE ACTIVITY

Stop with:

Ctrl+C

32 — wc

Count lines:

wc -l security.log

Count words:

wc -w security.log

33 — awk

awk is powerful for structured text processing.

Suppose:

FAILED admin01 10.10.10.20
SUCCESS user01 10.10.10.30

Extract username:

awk '{print $2}' security.log

Extract IP:

awk '{print $3}' security.log

34 — Filter with awk

awk '$1 == "FAILED" {print $2, $3}' security.log

This prints users and IPs for failed events.

35 — Count Failed Logins by User

Example:

awk '$1 == "FAILED" {print $2}' security.log |
sort |
uniq -c |
sort -nr

Workflow:

LOG
 ↓
FILTER FAILED
 ↓
EXTRACT USER
 ↓
SORT
 ↓
COUNT
 ↓
RANK

36 — sed

sed transforms text.

Example:

sed 's/FAILED/LOGIN_FAILURE/g' security.log

By default this prints the transformed result rather than changing the original file.

37 — Safe sed Practice

Preview first:

sed 's/old/new/g' file.txt

Only modify files in place when you understand the impact and have a backup.

38 — tr

Translate characters.

Example:

echo "HIGH" | tr 'A-Z' 'a-z'

Output:

high

This is useful for normalizing security data.

39 — xargs

xargs can convert input into command arguments.

Example:

printf "%s\n" file1.txt file2.txt | xargs -n1 basename

Use caution when input comes from untrusted sources or filenames containing unusual characters.

40 — Variables

Create:

username="analyst01"

Print:

echo "$username"

41 — Security Variables

Example:

log_file="./logs/auth.log"
report_file="./reports/failed-logins.txt"
threshold=5

Use descriptive names.

42 — Quoting

Double quotes expand variables:

echo "$username"

Single quotes do not:

echo '$username'

Understanding quoting is essential for writing safe shell scripts.

43 — Command Substitution

Capture command output:

current_user=$(whoami)

Then:

echo "Current user: $current_user"

44 — Environment Variables

View:

env

or:

printenv

Common variables:

PATH

HOME

USER

SHELL

45 — PATH

Display:

echo "$PATH"

One directory per line:

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

Security scripts should avoid relying on unsafe or unexpected command-resolution paths.

46 — Script Creation

Create:

nano scripts/security-check.sh

Start with:

#!/usr/bin/env bash

echo "Security check started"

Make executable:

chmod +x scripts/security-check.sh

Run:

./scripts/security-check.sh

47 — Shebang

The first line:

#!/usr/bin/env bash

tells the operating system which interpreter should execute the script.

48 — Script Safety Options

For many automation scripts, consider:

set -euo pipefail

Conceptually:

-e
Stop on unhandled command failure

-u
Fail on unset variables

pipefail
Propagate pipeline failures

Understand how these affect your script before using them.

49 — Conditions

Example:

failed_logins=8

if [ "$failed_logins" -gt 5 ]; then
    echo "Suspicious login activity"
fi

50 — if / else

if [ "$failed_logins" -gt 10 ]; then
    echo "High risk"
else
    echo "Review normally"
fi

51 — if / elif / else

if [ "$failed_logins" -ge 10 ]; then
    echo "High"
elif [ "$failed_logins" -ge 5 ]; then
    echo "Medium"
else
    echo "Low"
fi

52 — Numeric Operators

Common:

-eq   Equal

-ne   Not equal

-gt   Greater than

-lt   Less than

-ge   Greater or equal

-le   Less or equal

53 — String Comparisons

Example:

severity="critical"

if [ "$severity" = "critical" ]; then
    echo "Escalate"
fi

54 — File Tests

Check file exists:

if [ -f "$log_file" ]; then
    echo "Log found"
fi

Directory:

if [ -d "./logs" ]; then
    echo "Logs directory exists"
fi

Readable:

if [ -r "$log_file" ]; then
    echo "Readable"
fi

55 — Loops

Example:

for host in WEB01 APP01 DB01; do
    echo "Reviewing $host"
done

56 — Loop Through Files

for file in ./logs/*.log; do
    echo "Processing $file"
done

Handle cases where no files match carefully in production-quality scripts.

57 — while Loops

Example:

count=1

while [ "$count" -le 3 ]; do
    echo "Iteration $count"
    count=$((count + 1))
done

58 — Read a File Line by Line

A safer pattern:

while IFS= read -r line; do
    echo "$line"
done < security.log

This preserves most input accurately.

59 — Functions

Create reusable logic:

show_alert() {
    echo "ALERT: $1"
}

Call:

show_alert "Multiple failed logins detected"

60 — Return vs Output

Shell functions commonly return a numeric status and print output separately.

Example:

check_file() {
    if [ -f "$1" ]; then
        return 0
    else
        return 1
    fi
}

Then:

if check_file "security.log"; then
    echo "File exists"
fi

61 — Script Arguments

Arguments are:

$1

$2

$3

Example:

#!/usr/bin/env bash

log_file="$1"

echo "Analyzing $log_file"

Run:

./analyze.sh security.log

62 — Argument Validation

Always validate.

if [ "$#" -ne 1 ]; then
    echo "Usage: $0 <logfile>"
    exit 1
fi

63 — Validate File Input

log_file="$1"

if [ ! -f "$log_file" ]; then
    echo "File not found"
    exit 1
fi

64 — Exit Codes

Convention:

0
=
Success

Non-zero
=
Error / Other Status

Check the previous result:

echo "$?"

65 — Logical Operators

AND:

command1 && command2

Second command runs only if the first succeeds.

OR:

command1 || command2

Second command runs if the first fails.

66 — Group Commands Carefully

Example:

mkdir -p reports &&
echo "Reports directory ready"

This is useful for predictable automation.

67 — Process Review

Use:

ps aux

or:

ps -ef

Look for:

User

PID

Process

Arguments

68 — Search Processes

ps aux | grep "application"

A cleaner option may be:

pgrep -a application

when available.

69 — Process Tree

Use:

ps -ef --forest

or:

pstree

This helps understand:

PARENT

CHILD

SERVICE RELATIONSHIPS

70 — System Services

On systemd systems:

systemctl --type=service --state=running

Inspect:

systemctl status <service>

71 — Logs with journalctl

View service logs:

journalctl -u <service>

Recent entries:

journalctl -u <service> -n 50

Since today:

journalctl --since today

72 — Authentication Logs

Depending on distribution, logs may exist at:

/var/log/auth.log

/var/log/secure

Only inspect logs you are authorized to access.

73 — Failed Login Analysis

Example:

grep -i "failed" /path/to/training-auth.log

Count:

grep -ic "failed" /path/to/training-auth.log

74 — Build a Failed Login Pipeline

Example synthetic log:

FAILED admin01 10.10.10.21
FAILED user01 10.10.10.22
FAILED admin01 10.10.10.23
FAILED admin01 10.10.10.21

Run:

awk '$1 == "FAILED" {print $2}' auth.log |
sort |
uniq -c |
sort -nr

Output might be:

3 admin01
1 user01

75 — Count by Source IP

awk '$1 == "FAILED" {print $3}' auth.log |
sort |
uniq -c |
sort -nr

76 — Generate a Report

awk '$1 == "FAILED" {print $2}' auth.log |
sort |
uniq -c |
sort -nr > reports/failed-users.txt

77 — Add a Timestamp

date

Formatted:

date '+%Y-%m-%d %H:%M:%S'

Use in reports:

echo "Generated: $(date '+%Y-%m-%d %H:%M:%S')" \
> reports/report.txt

78 — File Hashing

Use:

sha256sum sample.txt

Security uses:

INTEGRITY

EVIDENCE

IOC COMPARISON

FILE TRACKING

79 — Hash Multiple Files

sha256sum evidence/*

Only use files you are authorized to process.

80 — Verify Hash

Save:

sha256sum sample.txt > sample.sha256

Verify:

sha256sum -c sample.sha256

81 — Archives

Create:

tar -czf evidence.tar.gz evidence/

List contents:

tar -tzf evidence.tar.gz

This can help package lab evidence.

82 — Network Configuration

Use:

ip addr

Routes:

ip route

DNS configuration varies by system, but may be reviewed through appropriate resolver configuration.

83 — Listening Ports

Use:

ss -lntup

This can show:

Local Address

Port

Protocol

Process

depending on permissions.

84 — Established Connections

Use:

ss -ntp

Review:

Local Endpoint

Remote Endpoint

State

85 — DNS Lookup

Use:

dig example.com

or:

nslookup example.com

For security labs, use authorized internal names where appropriate.

86 — HTTP Requests

Use:

curl https://example.com

Headers:

curl -I https://example.com

Verbose:

curl -v https://example.com

Use only against systems you are authorized to interact with.

87 — Work with APIs Using curl

Example placeholder:

curl \
  -H "Accept: application/json" \
  https://example.invalid/api/status

88 — Protect API Credentials

Avoid:

curl -H "Authorization: Bearer real-secret" ...

in situations where the token may be exposed in history or process information.

Prefer approved secure secret handling for the environment.

89 — Download Files Safely

Example:

curl -o file.txt https://example.invalid/file.txt

Only download from trusted and authorized sources.

Verify expected hashes where available.

90 — Disk Usage

Use:

df -h

Directory size:

du -sh ./logs

Identify large entries:

du -sh ./* | sort -h

91 — Memory and CPU Context

Use:

free -h

and:

uptime

These are useful during:

INCIDENT RESPONSE

SYSTEM TROUBLESHOOTING

SERVICE INVESTIGATION

92 — Environment Review

Run:

env

Be careful when capturing evidence because environment variables may contain sensitive configuration.

Redact secrets.

93 — Shell Script Logging

Example:

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') $1"
}

Then:

log "Analysis started"

94 — Write Logs to a File

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') $1" \
        >> reports/script.log
}

Do not write secrets to logs.

95 — Error Handling

Example:

if ! grep "FAILED" security.log > /dev/null; then
    echo "No failed events detected or command failed"
fi

For production scripts, distinguish:

NO MATCH

COMMAND FAILURE

when necessary.

96 — Temporary Files

Avoid predictable temporary filenames for sensitive operations.

Use:

mktemp

Example:

temp_file=$(mktemp)

Clean up:

rm -f "$temp_file"

97 — trap

Use trap for cleanup:

temp_file=$(mktemp)

cleanup() {
    rm -f "$temp_file"
}

trap cleanup EXIT

This helps remove temporary resources even when the script exits unexpectedly.

98 — Avoid Unsafe eval

Avoid patterns involving:

eval "$user_input"

especially with untrusted data.

It can cause input to be interpreted as shell commands.

99 — Quote Variables

Prefer:

rm -- "$file"

not:

rm $file

Quoting helps prevent whitespace and special-character problems.

100 — Use -- Where Appropriate

Some commands support:

--

to indicate the end of options.

Example:

rm -- "$filename"

This is useful when filenames could begin with -.

101 — Avoid Parsing ls

Do not build scripts around patterns like:

for file in $(ls)

This breaks on spaces and unusual filenames.

Prefer:

for file in ./*; do
    ...
done

or appropriate find patterns.

102 — Security Script Structure

A reusable script can follow:

SHEBANG

SAFETY OPTIONS

CONFIGURATION

FUNCTIONS

INPUT VALIDATION

MAIN WORKFLOW

OUTPUT

CLEANUP

103 — Example Structure

#!/usr/bin/env bash

set -u

main() {
    echo "Security analysis started"
}

main "$@"

104 — Project 01: Failed Login Analyzer

Build:

AUTH LOG
   ↓
FILTER FAILURES
   ↓
EXTRACT USERS
   ↓
COUNT
   ↓
SORT
   ↓
REPORT

Example pipeline:

awk '$1 == "FAILED" {print $2}' auth.log |
sort |
uniq -c |
sort -nr

105 — Project 02: Suspicious IP Summary

Input:

FAILED admin01 10.10.10.20
FAILED admin01 10.10.10.20
FAILED user01 10.10.10.30

Process:

awk '$1 == "FAILED" {print $3}' auth.log |
sort |
uniq -c |
sort -nr

Output:

Count by Source IP

106 — Project 03: File Integrity Baseline

Create a baseline:

find evidence -type f -exec sha256sum {} \; \
> reports/baseline.sha256

Later compare carefully using your training data.

This introduces the concept of:

FILE INTEGRITY MONITORING

107 — Project 04: Linux Security Inventory

Create a script that records:

Hostname

Current User

OS

Kernel

IP Addresses

Routes

Listening Ports

Running Services

Disk Usage

Do not include secrets.

108 — Project 05: Security Log Report

Build:

INPUT LOG
   ↓
FAILED EVENTS
   ↓
ERROR EVENTS
   ↓
TOP USERS
   ↓
TOP SOURCES
   ↓
REPORT FILE

109 — Project 06: Permission Review

Within your own training directory:

FILES
 ↓
PERMISSIONS
 ↓
WORLD-WRITABLE
 ↓
GROUP-WRITABLE
 ↓
REPORT

Focus on explaining permissions rather than labeling every writable object a vulnerability.

110 — Project 07: Service Inventory

Collect:

RUNNING SERVICES

LISTENING PORTS

SERVICE NAMES

SYSTEM ROLE

Then manually review whether each service is expected.

111 — Project 08: Evidence Collection Helper

Build a script that:

Creates Evidence Folder

Records Timestamp

Records Hostname

Records User

Calculates File Hashes

Creates Archive

Generates Evidence Index

Use only inside your authorized lab.

112 — Bash for SOC Analysts

Focus on:

grep

awk

sort

uniq

cut

Log Analysis

IOC Processing

Report Generation

113 — Bash for Incident Responders

Focus on:

Processes

Network Connections

Recent Files

Hashes

Logs

Services

Evidence Collection

114 — Bash for Cloud Security

Focus on:

Cloud CLI Output

JSON / Text Processing

Resource Inventory

Configuration Checks

Log Collection

Automation

When structured JSON is available, dedicated parsers such as jq are often preferable to fragile text parsing.

115 — jq for JSON

If installed:

jq '.'

can format JSON.

Example:

cat events.json | jq '.'

More simply:

jq '.' events.json

116 — Extract JSON Fields

Given:

{
  "user": "analyst01",
  "severity": "high"
}

Use:

jq -r '.user' event.json

117 — Filter JSON

Example array:

jq '.[] | select(.severity == "high")' alerts.json

This is useful for cloud and security API data.

118 — Bash vs Python

Use Bash when:

The Task Is Shell-Oriented

You Are Combining Linux Commands

The Workflow Is Short

You Need Quick Automation

Use Python when:

Data Structures Become Complex

Logic Becomes Large

You Need Robust APIs

You Need Advanced Error Handling

The Script Must Scale

119 — When Bash Becomes Too Large

A useful rule:

IF THE SCRIPT BECOMES
DIFFICULT TO READ,
TEST, OR MAINTAIN

consider moving the workflow to:

PYTHON

or another suitable language.

120 — Bash Security Principles

Always think about:

QUOTING

INPUT VALIDATION

FILE PERMISSIONS

SECRET HANDLING

TEMPORARY FILES

ERROR HANDLING

LEAST PRIVILEGE

CLEANUP

121 — Never Hard-Code Secrets

Avoid:

password="real-password"

or:

token="real-token"

in scripts committed to repositories.

Use approved secret-management mechanisms for your environment.

122 — Least Privilege

Do not run:

sudo ./script.sh

simply because the script fails.

Determine:

WHICH ACTION
NEEDS ADDITIONAL PRIVILEGE?

and whether that privilege is actually necessary.

123 — Protect Script Files

Security automation scripts themselves may become sensitive if they:

ACCESS PRIVILEGED DATA

READ CREDENTIAL STORES

MANAGE SERVICES

ACCESS CLOUD APIs

Protect them appropriately.

124 — Review Before Running Scripts

Before executing an unfamiliar script:

READ IT

UNDERSTAND IT

CHECK INPUTS

CHECK FILE OPERATIONS

CHECK NETWORK OPERATIONS

CHECK PRIVILEGES

CHECK CLEANUP

Do not blindly run copied scripts as root.

125 — 4-Week Bash Practice Plan

Week	Focus
1	Shell, Files, Permissions, Pipes
2	grep, awk, sed, sort, uniq
3	Variables, Conditions, Loops, Functions
4	Logs, Networking, Security Automation

126 — Daily Bash Practice

Use:

DAY 01
FILES

DAY 02
PERMISSIONS

DAY 03
PIPES

DAY 04
grep

DAY 05
awk

DAY 06
LOG ANALYSIS

DAY 07
MINI PROJECT

Then repeat with more complex security data.

Bash Readiness Levels

Level 01 — Linux Navigation

You can use:

pwd

cd

ls

cat

cp

mv

Level 02 — Security Data Processing

You can combine:

grep

cut

sort

uniq

head

tail

wc

Level 03 — Advanced Text Processing

You can use:

awk

sed

jq

appropriately.

Level 04 — Bash Scripting

You understand:

Variables

Conditions

Loops

Functions

Arguments

Level 05 — Linux Security Operations

You can review:

Processes

Services

Network Connections

Logs

Permissions

Level 06 — Security Automation

You can build scripts that:

Collect

Parse

Analyze

Report

Clean Up

Bash for Cybersecurity Checklist

Shell Fundamentals

• Shell identified
• Current user identified
• Host identified
• Working directory understood
• History understood

Files

• Create files
• Read files
• Copy files
• Move files
• Remove files safely
• File metadata reviewed

Permissions

• ls -l
• Read/write/execute understood
• Numeric permissions understood
• Ownership understood
• chmod understood

Text Processing

• grep
• cut
• sort
• uniq
• head
• tail
• wc
• awk
• sed
• tr

Shell Programming

• Variables
• Quoting
• Command substitution
• Conditions
• Loops
• Functions
• Arguments
• Exit codes

Processes

• ps
• Process tree
• Process filtering
• Services
• systemd

Logs

• Authentication logs
• Application logs
• journalctl
• Filtering
• Counting
• Reporting

Networking

• ip addr
• ip route
• ss
• DNS lookup
• curl

Security Utilities

• SHA-256
• Archive evidence
• Timestamp reports
• Temporary files
• Cleanup

JSON

• JSON concept understood
• jq formatting
• Field extraction
• Filtering

Secure Scripting

• Variables quoted
• Inputs validated
• Secrets protected
• Least privilege used
• Errors handled
• Temporary files handled safely
• Cleanup performed
• Unfamiliar scripts reviewed before execution

Projects

• Failed login analyzer
• Suspicious IP summary
• File integrity baseline
• Linux inventory
• Log report
• Permission review
• Service inventory
• Evidence helper

40 Bash for Cybersecurity Review Questions

1. What is Bash?
2. Why is Bash useful for cybersecurity?
3. What does whoami show?
4. What does id show?
5. What does pwd show?
6. What does ls -la provide?
7. What do Linux read, write, and execute permissions mean?
8. What does chmod do?
9. What is standard output?
10. What is standard error?
11. What does > do?
12. What does >> do?
13. What is a pipe?
14. What does grep do?
15. What does cut do?
16. Why are sort and uniq often used together?
17. What is awk useful for?
18. What is sed used for?
19. What does tail -f do?
20. What is command substitution?
21. What is an environment variable?
22. Why is PATH security-sensitive?
23. What is a shebang?
24. What does set -u do?
25. What is an exit code?
26. What does $? represent?
27. What are positional arguments?
28. Why should script arguments be validated?
29. What does ps aux show?
30. What does systemctl manage?
31. What does journalctl provide?
32. What does ss show?
33. Why are file hashes useful?
34. What does mktemp help with?
35. What does trap help automate?
36. Why should variables normally be quoted?
37. Why can eval be dangerous?
38. Why should Bash scripts use least privilege?
39. When should you consider replacing Bash with Python?
40. What makes a Bash security workflow repeatable?

Final Bash for Cybersecurity Mental Model

Remember:

LINUX SECURITY DATA
       ↓
COMMAND
       ↓
PIPE
       ↓
FILTER
       ↓
TRANSFORM
       ↓
COUNT / CORRELATE
       ↓
REPORT

For scripting:

INPUT
 ↓
VALIDATE
 ↓
PROCESS
 ↓
DECISION
 ↓
OUTPUT
 ↓
LOG
 ↓
CLEANUP

Do not think:

I NEED TO MEMORIZE
EVERY LINUX COMMAND

Think:

WHAT INFORMATION
DO I NEED?

WHICH COMMAND
PRODUCES IT?

HOW DO I FILTER
THE OUTPUT?

HOW DO I TURN IT
INTO A SECURITY RESULT?

For example:

AUTHENTICATION LOG
       ↓
grep / awk
       ↓
FAILED EVENTS
       ↓
sort / uniq
       ↓
EVENT COUNTS
       ↓
SECURITY REVIEW

or:

LINUX HOST
   ↓
PROCESSES
   +
SERVICES
   +
PORTS
   +
PERMISSIONS
   ↓
SECURITY INVENTORY

That is the real power of Bash for cybersecurity:

SMALL COMMANDS
      +
SHELL LOGIC
      +
SECURITY CONTEXT
      =
POWERFUL AUTOMATION

What’s Next?

➡️ 03 — PowerShell for Cybersecurity

The next module moves from Linux security automation into the Windows and Microsoft ecosystem.

You will learn:

POWERSHELL SHELL
       ↓
CMDLETS
       ↓
OBJECTS
       ↓
PIPELINE
       ↓
VARIABLES
       ↓
CONDITIONS
       ↓
LOOPS
       ↓
FUNCTIONS
       ↓
FILES
       ↓
PROCESSES
       ↓
SERVICES
       ↓
WINDOWS USERS
       ↓
LOCAL GROUPS
       ↓
EVENT LOGS
       ↓
REGISTRY
       ↓
ACTIVE DIRECTORY
       ↓
SECURITY AUTOMATION

The goal will be to use PowerShell as a practical tool for Windows security administration, Active Directory assessment, SOC operations, incident response, evidence collection, configuration review, and Microsoft-focused security automation.