Linux for Security Work: The Parts That Actually Matter

You don't need to be a Linux administrator to work in security. You do need to stop being slowed down by the shell, because everything else assumes you aren't.

Open a terminal now and run these as you read. It takes about fifteen minutes and it'll stick far better than reading alone.

The filesystem is one tree

No drive letters. Everything hangs off /. Have a look:

$ ls /
bin  boot  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  tmp  usr  var

The ones that matter to you:

• /etc — system configuration, all plain text. Where misconfigurations live.

• /home — user directories, and usually the interesting files.

• /var/log — logs. First stop when working out what happened.

• /tmp — world-writable, cleared on reboot.

• /proc — not real files. A live view of running processes and kernel state.

Prove that last one to yourself — this file doesn't exist on disk anywhere:

$ cat /proc/version
Linux version 6.8.0-45-generic ...

Permissions, properly

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 2891 Aug 12 09:14 /etc/passwd

Read the first block character by character. Position one is the file type (- for a regular file, d for a directory, l for a symlink). Then three groups of three: owner, group, everyone else, each with read, write, execute.

Here: owner reads and writes, everyone else reads only. In octal that's 644 — read is 4, write is 2, execute is 1, added per group.

Try changing one on a throwaway file:

$ touch /tmp/demo.txt
$ chmod 600 /tmp/demo.txt
$ ls -l /tmp/demo.txt
-rw------- 1 you you 0 Aug 30 14:02 /tmp/demo.txt

Now only you can read it. That single idea — that access is a property of the file, not of the application — is most of Linux security.

The setuid bit, and why it matters

A binary with the setuid bit runs as its owner rather than as you. That's how passwd can edit a root-owned file when you run it. It's also one of the most common privilege escalation routes, because a setuid program with a flaw hands its privileges to whoever exploits it.

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Mar 23 09:11 /usr/bin/passwd

Note the s where the owner's execute bit would be. Find every one on your system:

$ find / -perm -4000 -type f 2>/dev/null

The 2>/dev/null discards permission-denied errors so the useful output isn't buried. Expect twenty or thirty results on a normal desktop. On a hardened server, far fewer — that difference is a real hardening measure.

The commands worth fluency

# search file contents recursively, with line numbers
$ grep -rn "127.0.0.1" /etc 2>/dev/null | head

# what's running, biggest memory first
$ ps aux --sort=-%mem | head

# what's listening, on which port, owned by which process
$ ss -tulpn

# files modified in the last day
$ find /etc -mtime -1 -type f 2>/dev/null

# full metadata on one file
$ stat /etc/passwd

Two habits worth forming early. man is faster than searching and is authoritative — man 5 passwd explains the file format, man 1 passwd explains the command. And when you meet a command you don't recognise, paste it into ExplainShell, which breaks it into its parts.

Pipes are the actual idea

Each tool does one thing and passes text to the next. This is what makes the shell worth learning rather than memorising:

# ten most frequent IPs in a web access log
$ cut -d' ' -f1 access.log | sort | uniq -c | sort -rn | head

Read it left to right: take field one, sort so duplicates sit together, count runs, sort by count descending, show the top ten. Five simple tools, one useful answer. No log file to hand? Build one:

$ printf '10.0.0.1 GET /\n10.0.0.2 GET /\n10.0.0.1 GET /admin\n' > /tmp/access.log
$ cut -d' ' -f1 /tmp/access.log | sort | uniq -c | sort -rn
      2 10.0.0.1
      1 10.0.0.2

Your exercise: audit your own machine

Fifteen minutes. Answer these using only what's above:

1. How many setuid binaries do you have, and does anything in the list look unusual?

2. Which services are listening on a network port? (ss -tulpn) Do you know what each one is?

3. Are there any world-writable directories outside /tmp? (find / -type d -perm -0002 2>/dev/null)

4. What are the last ten commands you ran? (history | tail) Would you want an attacker reading that file?

That last question is the point. ~/.bash_history frequently contains credentials people typed on the command line.

Where to go next

• OverTheWire: Bandit — free, legal, and the standard starting point. Thirty-odd levels, each teaching one command. A weekend here beats any video series.

• The Linux man-pages project — the authoritative reference, online.

• ExplainShell — paste any command, get it decomposed.

Next lesson: How Machines Talk — ports, packets and DNS, with the same hands-on approach.

---

Run this on your own machine or a lab you're authorised to use. Every command here is safe against systems you control. Pointing the same tools at infrastructure you don't own is a criminal offence in most countries, including under the US Computer Fraud and Abuse Act. The practice labs linked above exist so you can do this legally.