The Linux Command Line for Security

The Linux Command Line for Security

Almost every security tool, server, and remote system you''ll touch speaks one language: the Linux command line. Scanners, log analysis, exploit frameworks, cloud servers, and a shell popped on a remote box are all driven from the terminal. Get comfortable here and the whole field opens up.

Moving around and reading files

The shell is just a text conversation with the operating system:

pwd                 # where am I?
ls -la              # list everything, including hidden files, with details
cd /var/log         # change directory
cat auth.log        # print a file
less auth.log       # scroll a big file

Security work lives in files — logs, configs, captured data — so reading and navigating them fast is the baseline skill.

Permissions: who can do what

Every file has permissions for three classes — owner, group, other — each with read (r), write (w), execute (x). You''ll see them two ways:

• Symbolic: -rwxr-xr--
• Octal: each class is a digit, summing $r=4$, $w=2$, $x=1$.

So -rwxr-xr-- is 754: owner $rwx = 4+2+1 = 7$, group $r\text{-}x = 4+1 = 5$, other $r\text{-}\text{-} = 4$. You set them with chmod:

chmod 600 id_rsa      # owner read/write only - correct for a private key
chmod +x scan.sh      # make a script executable

Permissions are security: a private key readable by everyone, or a config writable by any user, is a real vulnerability.

Pipes: small tools, combined

The Unix superpower is chaining single-purpose tools with the pipe |, feeding one command''s output into the next. This is how you analyse logs without any special software:

grep "Failed password" auth.log | wc -l

grep filters the lines mentioning failed logins; wc -l counts them — the number of failed SSH attempts. Add sort and uniq -c and you can rank attackers by IP. Filter, sort, count, extract — four tools, endless investigations.

A real investigation, one pipeline at a time

Say a server feels sluggish and you suspect a brute-force attack on SSH. You never leave the terminal:

grep "Failed password" /var/log/auth.log | wc -l          # how many failures total?
grep "Failed password" /var/log/auth.log \
  | grep -oE "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" \
  | sort | uniq -c | sort -rn | head            # which IPs, ranked

The first line quantifies the problem; the second extracts every IP address (grep -oE), counts each one (sort | uniq -c), and ranks them (sort -rn | head). In seconds you have your top attackers — no dashboard, no special tool, just composable commands. This filter-extract-sort-count pattern is the everyday reflex of a security analyst.

Common pitfalls

• rm -rf is unforgiving. There''s no recycle bin; a wrong path deletes irreversibly. Double-check before you run it.
• Over-permissive modes. chmod 777 gives everyone full control — a classic audit finding. Grant the least access that works.
• Case sensitivity. Auth.log and auth.log are different files on Linux.
• Running untrusted scripts. curl ... | bash executes code you haven''t read. Read it first.

Why this is your on-ramp

The Security Foundations, Network Security, and Penetration Testing modules ahead all assume you can move around a Linux box, read a log, fix a permission, and chain a quick pipeline. Spend an hour in the terminal now and every later module gets easier.