I am documenting every day of my cybersecurity learning journey publicly. This is Day 4. Previous entries are on my profile if you want to follow from the start.
What was covered today
Linux fundamentals through linuxjourney.com, 18 commands practiced in my Kali terminal, OverTheWire Bandit levels 0 through 3, and TryHackMe Linux Fundamentals Part 1.
Why Linux specifically
I want to write this down because I think it is worth stating clearly.
90% of servers on the internet run Linux. Every major cloud platform runs Linux underneath. Kali Linux — the operating system I use for all my security work — is built on Linux. When a penetration tester gains initial access to a system, it is almost always a Linux shell they end up in.
Linux is not background knowledge in cybersecurity. It is the main environment. Knowing it well is the difference between being able to do the actual work and just knowing the theory.
The commands that surprised me the most
I expected Linux to be harder to learn than it is. The commands themselves are short and logical — ls to list, cd to change directory, cat to read, and find to search. The difficulty is not memorizing them. It is understanding what happens when you combine them.
The one that clicked for me today was this:
find / -perm -4000 2>/dev/null
This searches the entire file system for files with SUID permissions set. SUID means the file runs with the permissions of its owner rather than the person running it. If a SUID file is owned by root and has a vulnerability, a low-privilege attacker can exploit it to gain root access.
This command — one line — is something every attacker runs within the first few minutes of getting a shell on a Linux system. I ran it in Kali today and found several SUID files. Now I understand why privilege escalation checklists always start with checking for SUID binaries.
OverTheWire Bandit — the best learning experience of the week
OverTheWire Bandit is at overthewire.org/wargames/bandit. It is free. You connect with SSH and work through levels, each one teaching a real Linux skill through a practical challenge.
I went in expecting it to feel educational. It did not. It felt like working.
Level 0: Connect, find a file, and read it. Simple. cat readme. Done.
Level 1: The file is named with a single dash character. I ran cat - and nothing happened — it just waited for keyboard input. Spent a few minutes on this one.
The reason: in Linux (and in most Unix-like systems), a single dash is a special character that means standard input. The shell interprets it before even looking for a file. The fix is to give the shell a path context:
cat ./-
The ./ says "this is a file in the current directory." Now the shell treats the dash as part of a filename rather than a special character. Problem solved.
That one challenge explained something about Linux command parsing that I had not thought about before — the shell is doing interpretation work before any command even runs. That becomes relevant in web security too: SQL injection and command injection both exploit the fact that interpreters process special characters before treating input as data.
Level 2: File with spaces in the name. Spaces break shell syntax because the shell treats each space-separated word as a separate argument. Solution: quote the filename.
cat "spaces in this filename."
Level 3: Hidden file inside a directory. Running ls shows nothing. Running ls -la shows a file called .hidden — the dot at the start makes it a hidden file in Linux.
cd inhere
ls -la
cat .hidden
Four levels. Each one taught something I will use in real security work: filename edge cases, shell character handling, and hidden files. These are not academic concepts. They come up in CTF competitions, in post-exploitation on real systems, and in forensic investigations.
File permissions — the concept that unlocks Linux security
When I ran ls -la in Kali, I saw lines like this:
-rwxr-xr-- 1 kali kali 4096 Apr 6 16:00 myscript.sh
That string of r, w, x, and dashes at the start is the permission set. It tells you exactly who can read, write, and execute the file — the owner, the group, and everyone else.
Understanding permissions is what makes privilege escalation possible to understand. Misconfigured permissions are one of the most common vulnerabilities on Linux systems. A file that should only be readable by root but is readable by everyone — that is a misconfiguration that leaks sensitive data. A script that runs as root but is writable by a low-privilege user — that is a privilege escalation waiting to be exploited.
Once you understand permissions, you start seeing why so many security findings come back to "this file has incorrect permissions set."
TryHackMe Linux Fundamentals Part 1
Completed today. The room has a built-in terminal so you can practice without needing your own Linux machine. The questions reinforce the same commands I practiced in Kali, which is exactly the kind of deliberate repetition that builds muscle memory.
One concept this room clarified: the difference between absolute and relative paths. An absolute path starts from / and works from anywhere. A relative path depends on where you currently are. In security scripts, absolute paths are safer because the script behaves predictably regardless of where it is called from.
What four days of this have felt like
The pattern I have noticed: every day, there is at least one moment where something abstract becomes concrete. Day 2 it was watching a TCP handshake happen in Wireshark. On Day 3, it was seeing open ports on a real server through Nmap. Day 4, it was the cat ./- moment in Bandit — realizing the shell is doing interpretation work I never thought about.
These moments do not come from reading. They come from doing something in a terminal and hitting an unexpected result. That is when the learning actually happens.
Four days in. Every day on GitHub. Tomorrow: DNS records, HTTP details, and Python starts.
Notes are on my GitHub — link on my profile if you want to follow along.
SOCIAL SHARE CARD GENERATOR