The Linux Command Line for Security Work

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Security work happens in a terminal. Not because terminals are cool, but because security tools need precision, automation, and the ability to be chained together — and a graphical click-this-button interface can’t do that. The terminal is also where Linux quietly reveals its own security model: every file, every process, every user has permissions, and most real-world breaches are a permission that was set wrong.

Part 1: The Problem

Almost every tool you’ll use in this curriculum — Nmap, Burp Suite’s command companions, Metasploit, your own Python scripts — assumes you can operate a Linux command line. Tutorials will say “just run sudo apt install” and move on. If that sentence is a foreign language, every lab stalls.

There’s a deeper reason too. Linux’s permission system — who can read, write, or run each file — is one of the oldest and most important security models in computing. You can’t understand “privilege escalation” (a whole topic in Phase 3) without first understanding what a privilege is on Linux.

Part 2: The Concept — The Filesystem Is a Tree

Linux organizes everything as a single tree of folders (called directories), starting from the root, written /.

/                    ← root: the top of everything
├── home/
│   └── you/         ← your personal directory ("home")
│       ├── notes.txt
│       └── tools/
├── etc/             ← system configuration files live here
├── var/
│   └── log/         ← system logs live here (important for defense!)
└── usr/
    └── bin/         ← installed programs live here

Two of these matter enormously later:

• /etc holds configuration — including, on older systems, user account info. Attackers love it.
• /var/log holds logs — the record of what happened. Defenders live here.

You move around this tree with three commands you’ll use thousands of times:

Part 3: The Essential Commands

You don’t need hundreds of commands. You need about fifteen, used constantly.

man is your best friend. Stuck on a command? man grep tells you everything. Professionals look things up constantly — it’s not cheating, it’s the job.

Part 4: Piping — Chaining Commands Together

This is the idea that makes the terminal powerful. The pipe symbol | takes the output of one command and feeds it as input to the next.

Analogy — a factory line. Each command is a station. The pipe is the conveyor belt carrying the product from one station to the next.

ls -la  |  grep ".txt"
└──┬──┘     └────┬────┘
 list      keep only lines
everything  containing ".txt"

Result: a list of just the .txt files.

Real security example: searching a huge log file for failed logins:

cat /var/log/auth.log | grep "Failed password" | tail -20

That reads the auth log, keeps only failed-password lines, and shows the last 20. You just did a basic piece of defensive log analysis in one line. This pattern — read | filter | filter | show — is the backbone of working in a terminal.

Part 5: The Linux Permission Model — A Security System You Can See

Run ls -la and you’ll see lines like this:

-rwxr-xr--  1  alice  staff  2048  May 10  report.sh
└────┬───┘     └─┬─┘  └─┬─┘
 permissions   owner  group

That cluster of letters on the left is the permission string. Read it in four parts:

   -      rwx        r-x        r--
  type   owner      group      everyone else
         can do     can do     can do

The three letters in each group mean:

• r = read (can view the file)
• w = write (can change the file)
• x = execute (can run the file as a program)

A - means that permission is denied.

So -rwxr-xr-- reads as: “The owner can read, write, and run it. The group can read and run it but not change it. Everyone else can only read it.”

Why this is the heart of security: Every breach involving “the attacker accessed files they shouldn’t have” is, at bottom, a permission set too loosely. A config file readable by everyone that contains a database password. A script writable by everyone that runs as administrator. Phase 3’s “privilege escalation” is almost entirely the art of finding these mistakes. Phase 4’s “hardening” is the art of preventing them.

chmod changes permissions; chown changes the owner. You’ll use both in the lab.

Part 6: Users, Root, and sudo

Linux has many user accounts, but one is special: root — the all-powerful administrator. Root can read, write, and run anything. There are no permission checks for root.

You normally do not log in as root, because one mistake as root can destroy the system, and any malware you run inherits root’s unlimited power. Instead, you run as a normal user and use sudo (“superuser do”) to run single commands with root power when needed:

apt install nmap          ← fails: normal users can't install software
sudo apt install nmap     ← works: runs that one command as root

The security lesson — “least privilege”: Give every user and every program the minimum power needed, and no more. Running as a normal user and reaching for sudo only when necessary is least privilege in daily practice. It’s one of the most important principles in all of security, and you start living it on day one.

📓 Key Terms

🧪 Hands-On Lab

Task 1 — Get a Linux machine. You have three easy options; any is fine:

• Install VirtualBox (free) and run Ubuntu inside it, or
• On Windows, enable WSL (Windows Subsystem for Linux) and install Ubuntu, or
• Use a free in-browser Linux terminal to practice the commands now, and set up a real VM in section 0.5.

(Section 0.5 builds your full lab properly. For this section, any Linux shell works.)

Task 2 — Explore. Run, in order:

pwd
ls -la
cd /var/log
ls -la
cd ~

~ is shorthand for your home directory. Notice how ls -la in /var/log shows the system’s logs.

Task 3 — Practice piping. Run:

ls /usr/bin | grep python

This lists every program in /usr/bin whose name contains “python”. You just searched the system with a two-stage pipeline.

Task 4 — Break and fix a permission (the important one).

echo "secret stuff" > test.txt
ls -la test.txt
chmod 000 test.txt          ← removes ALL permissions
cat test.txt                ← now fails: permission denied
chmod 644 test.txt          ← restores read for everyone, write for owner
cat test.txt                ← works again

You just experienced, hands-on, how a permission can lock you out — and how fixing the permission fixes the access. This is the mental model behind privilege escalation and hardening.

Task 5 — Read a manual. Run man chmod. Skim it. Get comfortable being slightly lost in a man page — you’ll read hundreds of them.

⚠️ Common Mistakes

• Living as root “to avoid permission errors.” This is the single most dangerous beginner habit. Stay a normal user; use sudo deliberately.
• rm has no undo. rm deletes permanently — no recycle bin. Be extra careful with rm -r (deletes whole folders). Never run rm on a path you didn’t read twice.
• Copy-pasting sudo commands from the internet without reading them. A malicious one-liner run with sudo can wreck your machine. Always understand a command before running it as root.
• Fearing the man pages. They’re dense but authoritative. Skim, don’t memorize.

✅ Recap & What’s Next

• Linux organizes everything as one tree from root /; you navigate with pwd, ls, cd.
• The pipe | chains commands into powerful one-line tools — the core skill of terminal work.
• Linux permissions (rwx) decide who can read/write/run each file; loose permissions cause breaches, and least privilege is the defense.

Next (0.3): We zoom into the single most-attacked piece of technology in the world — the web. How HTTP requests and responses actually work, and what HTTPS does (and doesn’t) protect.