STUDY

Linux Fundamentals

Navigate, read, and investigate a Linux host from the terminal.

Course overview

Linux runs most servers, security tooling, and cloud infrastructure. This course takes you from what Linux is, through the filesystem, navigation, file handling, searching, users and permissions, processes and services, logs, logging, system architecture, and SSH — everything the Linux Fundamentals labs assume when you investigate a compromised host.

Learning objectives

Explain what Linux is and how its filesystem is organized
Navigate and manipulate files confidently from the shell
Search files and directories to surface evidence
Reason about users, groups, and permissions
Inspect processes, services, and logs during an investigation

10 learning modules · study each, then start the labs.

Module 1

What Linux Is & Distributions

Understand what the Linux operating system is, how it is built from a kernel plus userland tools, and why there are many distributions.

Detailed explanation

Linux is an open-source operating system kernel first released by Linus Torvalds in 1991. In everyday use, 'Linux' refers to the kernel plus a collection of GNU userland tools, a shell, and package management — together forming a complete operating system.

A distribution (or 'distro') bundles the kernel with a chosen set of tools, defaults, and a package manager. Debian and Ubuntu use apt and .deb packages; Red Hat, Fedora, and Rocky use dnf/yum and .rpm packages. Security work commonly uses Kali or Parrot, which ship preinstalled tooling.

For investigation it matters because file locations, service managers, and log formats are largely shared across distros, so the skills transfer — but package names and a few paths differ.

Core concepts

Kernel: The core that manages hardware, memory, and processes. Everything else runs on top of it.
Distribution: Kernel + userland + package manager + defaults, packaged as a usable OS (Ubuntu, Fedora, Kali...).
Package manager: Installs and updates software: apt (Debian/Ubuntu), dnf/yum (Red Hat family), pacman (Arch).
Shell: The command interpreter you type into; bash is the most common default.

Command reference

uname -aShow kernel and system info.uname -a

cat /etc/os-releaseIdentify the distribution.cat /etc/os-release

whoamiShow the current user.

Examples

Identify an unknown host

On a host you've just accessed, confirm what it is:
  uname -a
  cat /etc/os-release
This tells you the kernel and distro before you go further.

Best practices

Confirm the distro early — it tells you which package manager and log paths to expect.
Prefer reading /etc/os-release over guessing from prompt styling.

Common mistakes

Assuming every Linux uses apt — Red Hat-family systems use dnf/yum.
Treating 'Linux' and a specific distro as identical.

Why it matters in the labs

Knowing the distribution tells you where logs live, which service manager runs, and how software was installed — the first orientation step on any host in the Linux labs.

Module 2

Filesystem Hierarchy & Navigation

Learn how the Linux filesystem is organized and how to move around it confidently.

Detailed explanation

Linux arranges everything under a single root, '/'. There are no drive letters; storage and devices are mounted into the tree. Key directories: /etc holds configuration, /var/log holds logs, /home holds user files, /tmp is scratch space, /usr holds installed programs, and /root is the superuser's home.

Paths are absolute when they start with '/', and relative otherwise. The shortcuts '.' (current directory), '..' (parent), and '~' (your home) appear constantly. Knowing where you are and moving precisely is the foundation of everything else.

Core concepts

Root (/): The single top of the filesystem tree.
/etc: System and service configuration files.
/var/log: Where system and service logs are written.
/home: Per-user home directories.
Absolute vs relative path: Absolute starts at / ; relative starts from where you are.

Command reference

pwdPrint the directory you're in.

lsList contents.ls -la /var/log

cdChange directory.cd /etc

cd ..Move up to the parent directory.

cd ~Jump to your home directory.

Examples

Orient yourself on a new host

Where am I, what's here, and what's in /var/log?
  pwd
  ls -la
  ls /var/log

Best practices

Run pwd whenever you're unsure where you are before acting.
Use ls -la to see hidden files (dotfiles) — attackers hide things there.
Use tab-completion to avoid path typos.

Common mistakes

Forgetting hidden files exist; plain ls won't show .ssh or .cache.
Confusing absolute and relative paths and acting in the wrong place.

Why it matters in the labs

Hidden directories like ~/.ssh and ~/.cache are classic places for planted keys and malware in the Linux labs — you only find them if you navigate and list deliberately.

Module 3

Working With Files

Create, copy, move, remove, and read files — and read large files without drowning in output.

Detailed explanation

Day-to-day file handling uses a small, composable set of commands. mkdir makes directories, touch creates empty files or updates timestamps, cp copies, mv moves or renames, and rm deletes. rm is unforgiving — there is no recycle bin.

To read files, cat dumps the whole thing, less pages through it interactively, and head/tail show the first or last lines — invaluable for large logs where you only want the newest entries.

Core concepts

touch: Create an empty file or update its timestamp.
cp vs mv: cp duplicates; mv relocates or renames (no copy left behind).
rm is permanent: Deleted files are gone; there is no undo.
Paging: less lets you scroll large files without loading everything to screen.

Command reference

mkdirMake a directory.mkdir evidence

touchCreate an empty file.touch notes.txt

cpCopy a file.cp auth.log /tmp/auth.bak

mvMove or rename.mv old.txt new.txt

rmDelete (permanent).rm scratch.txt

catPrint a whole file.cat /etc/passwd

lessPage through a file.less /var/log/syslog

headFirst lines.head -n 20 access.log

tailLast lines.tail -n 50 auth.log

Examples

Preserve evidence before reading

Copy a log aside, then read the most recent activity:
  cp /var/log/auth.log /tmp/auth.bak
  tail -n 50 /var/log/auth.log

Best practices

Use tail -n on big logs instead of cat to avoid flooding the screen.
Copy evidence before manipulating it so the original stays intact.
Double-check the target path before running rm.

Common mistakes

cat-ing a huge log and losing the relevant lines in the scroll.
Running rm with a wildcard in the wrong directory.

Why it matters in the labs

Reading logs with tail/less and preserving copies mirrors exactly what the Log Analysis and Linux labs ask you to do with evidence.

Module 4

Searching: grep & find

Turn a pile of files into answers by searching content with grep and locating files with find.

Detailed explanation

grep searches inside files for text matching a pattern and prints the matching lines — it is the single most important evidence-finding tool on Linux. Useful flags: -i (case-insensitive), -r (recursive), -c (count matches), -n (show line numbers).

find locates files by name, type, time, size, or permission across a directory tree. Together, find narrows down where to look and grep extracts the lines that matter.

Core concepts

Pattern matching: grep matches text; quotes protect patterns with spaces or symbols.
Recursive search: grep -r searches every file under a directory.
Counting: grep -c reports how many lines match — gauge a pattern's size first.
find predicates: Filter by -name, -type, -mtime, -perm, and more.

Command reference

grepSearch for a pattern.grep root /etc/passwd

grep -iCase-insensitive search.grep -i failed auth.log

grep -rRecursive search.grep -r 'password' /etc

grep -cCount matching lines.grep -c Failed auth.log

findLocate files.find /var/log -name '*.log'

find -mtimeFiles changed in N days.find /home -mtime -1

Examples

Find then filter

Locate all logs, then search them for failures:
  find /var/log -name '*.log'
  grep -i 'failed password' /var/log/auth.log

Size up a pattern first

Count before you read so you know what you're dealing with:
  grep -c 'Failed password' auth.log

Best practices

Quote grep patterns that contain spaces or special characters.
Use grep -c to gauge volume before reading thousands of lines.
Combine find (where) with grep (what) for efficient hunting.

Common mistakes

Forgetting -i and missing matches that differ only in case.
Searching the whole disk when you know the directory — wastes time.

Why it matters in the labs

Nearly every Linux and Log Analysis lab is solved by grepping authored files for the right indicator — brute-force lines, rogue accounts, C2 strings. Mastering grep is mastering the labs.

Module 5

Users, Groups & Permissions

Understand Linux accounts, group membership, and the read/write/execute permission model — including why UID 0 matters.

Detailed explanation

Every account has a name and a numeric user ID (UID). UID 0 is root, the superuser with full control. Accounts live in /etc/passwd and group membership in /etc/group. A second account with UID 0 is effectively a hidden root and a classic backdoor.

Files carry permission bits for owner, group, and others, each with read (r), write (w), and execute (x). 'rwxr-xr-x' means the owner can do everything, group and others can read and execute. chmod changes these bits; chown changes ownership.

Core concepts

UID 0: Root. Any account with UID 0 has full control — watch for imposters.
/etc/passwd: Account list: name, UID, home, shell.
/etc/group: Group definitions and membership.
Permission bits: r/w/x for owner, group, others (e.g. rwxr-xr-x).
chmod / chown: chmod changes permission bits; chown changes the owner.

Command reference

whoamiShow current user.

idShow UID, GID, and groups.id operator

cat /etc/passwdList accounts.grep ':0:' /etc/passwd

chmodChange permissions.chmod 600 id_rsa

chownChange ownership.chown root:root file

Examples

Hunt for a rogue root account

List accounts and look for a second UID 0:
  grep ':0:' /etc/passwd
Any non-root line with UID 0 is suspect.

Best practices

Audit /etc/passwd for unexpected UID 0 accounts on any suspect host.
Treat world-writable sensitive files and over-permissive keys as findings.
Use id to confirm what privileges an account actually has.

Common mistakes

Assuming only the literal 'root' name means root — UID 0 is what counts.
Misreading permission strings and missing an over-exposed file.

Why it matters in the labs

The Linux labs plant a rogue UID-0 account (systemd-helper) and a planted SSH key; this module is exactly how you find and explain them.

Module 6

Processes, Services & Logs

Inspect what's running now (processes), what's managed to persist (services), and the record of what happened (logs).

Detailed explanation

A process is a running program with a numeric PID. ps lists processes; top shows them live, sorted by resource use — a hidden binary pinning the CPU is a red flag. A service is a background process managed by systemd via systemctl, and services can be set to start on boot, which attackers abuse for persistence.

Logs in /var/log are the system's memory. auth.log records logins and sudo, syslog records general events, and service logs record their own activity. Reading logs ties together what processes and services did and when.

Core concepts

Process / PID: A running program identified by a process ID.
Service (unit): A systemd-managed background process that can persist across reboots.
Persistence: Attackers install services, cron jobs, or keys so they survive reboots.
auth.log: Authentication events: logins, failures, sudo.

Command reference

ps auxList all processes.ps aux

topLive process view by resource use.

systemctl statusInspect a service.systemctl status ssh

systemctl list-unitsList active services.

tail /var/log/auth.logRead recent auth events.tail -n 50 /var/log/auth.log

Examples

Find a CPU-hogging miner

List processes and spot the hidden high-CPU binary:
  ps aux
Look for a process running from a hidden path like /home/user/.cache/.x at ~99% CPU.

Trace persistence

Check services and the auth log together:
  systemctl list-units --type=service
  grep -i 'accepted password' /var/log/auth.log

Best practices

Correlate a suspicious process with the service or cron that launched it.
Read auth.log around the time a process appeared to find the entry point.
Note expected services first so anomalies stand out.

Common mistakes

Killing a malicious process without finding what restarts it (the service).
Ignoring timestamps and failing to build a timeline.

Why it matters in the labs

The Linux capstone asks you to reconstruct an intrusion end to end — process, service, cron, and the auth.log entry point. This module is the toolkit for that.

Module 7

SSH & Security Basics

Understand SSH, key-based access, and the everyday security habits that investigations hinge on.

Detailed explanation

SSH (Secure Shell) is the standard encrypted way to access a remote Linux host, normally on port 22. It supports password and key-based authentication. Authorized public keys live in a user's ~/.ssh/authorized_keys; an attacker who plants a key there gains durable access.

Security basics that matter in investigations: brute-force attempts show as repeated failed logins from one source, a successful login from that same source is the breach, and benign service logins are noise to filter out. Least privilege, key hygiene, and log review are the defensive counterparts.

Core concepts

SSH: Encrypted remote shell access, usually on port 22.
authorized_keys: Public keys allowed to log in as a user; a planted key = backdoor.
Brute force: Many failed logins from one source, then a success = compromise.
Benign noise: Expected service/account logins you filter out to find the real event.

Command reference

grep 'Failed password'Find brute-force attempts.grep 'Failed password' /var/log/auth.log

grep 'Accepted password'Find successful logins.grep 'Accepted password' /var/log/auth.log

cat ~/.ssh/authorized_keysInspect allowed keys.cat /home/operator/.ssh/authorized_keys

Examples

Reconstruct an SSH breach

Separate the brute force from the success and the noise:
  grep 'Failed password' auth.log
  grep 'Accepted password' auth.log
Match the successful login's IP to the brute-force source.

Best practices

Always correlate a successful login's source IP with the failure trail.
Inspect authorized_keys for unexpected entries on a suspect account.
Filter known service-account logins so the real breach stands out.

Common mistakes

Treating every 'Accepted password' as the attacker, including benign logins.
Overlooking a planted authorized_keys entry as a persistence mechanism.

Why it matters in the labs

SSH Investigation is a full Linux lab level: brute force from 203.0.113.9, a benign svc_backup login as noise, and a planted key. This module maps directly onto it.

Module 8

Linux Architecture & the Boot Process

Understand how a Linux system is layered — hardware, kernel, userland, and services — and what happens from power-on to login.

Detailed explanation

A Linux system is built in layers. At the bottom is the hardware. The kernel sits directly on top, managing memory, CPU scheduling, devices, and the filesystem. Above the kernel is userland: the shell, system libraries, and the programs you run. Understanding this separation explains why a compromised kernel module is far more serious than a compromised user program.

Boot proceeds in stages: firmware (BIOS/UEFI) initializes hardware and hands off to a bootloader (usually GRUB), which loads the kernel and an initial RAM disk. The kernel then starts the first process, init — on modern systems systemd (PID 1) — which brings up services and reaches a usable login state. Each stage is a place persistence can hide, which is why investigators check bootloader config, kernel modules, and enabled services.

Core concepts

Kernel space vs user space: The kernel runs privileged; user programs run sandboxed and ask the kernel for resources via system calls.
Bootloader (GRUB): Loads the kernel at startup; its config can be abused for persistence.
init / systemd (PID 1): The first process; parents all others and starts services.
Kernel modules: Loadable kernel code (lsmod); a malicious module is a rootkit-class threat.

Command reference

uname -rShow the running kernel version.uname -r

lsmodList loaded kernel modules.lsmod | head

systemctl get-defaultShow the default boot target.systemctl get-default

dmesgRead kernel ring-buffer messages.dmesg | tail

Examples

Check for a suspicious kernel module

List modules and look for anything unexpected:
  lsmod
Unknown modules not tied to installed hardware/drivers warrant investigation.

Best practices

Know your baseline kernel version and loaded modules so anomalies stand out.
Review enabled services and bootloader config when hunting persistence.

Common mistakes

Treating a kernel-level compromise like an ordinary user program.
Ignoring the boot chain (GRUB, initramfs, modules) as a persistence vector.

Why it matters in the labs

Knowing the boot and module layers tells you where deep persistence hides — context the Linux capstone investigation builds on.

Module 9

Ownership & Special Permissions

Go beyond basic rwx: ownership, the execute bit's meaning on directories, and the special bits (setuid, setgid, sticky) that attackers abuse for privilege escalation.

Detailed explanation

Every file has an owning user and group. chown changes ownership; permissions are then evaluated against whether you are the owner, in the group, or 'other'. On a directory, the execute bit means 'can enter', and write means 'can create/delete entries' — which is why a world-writable directory is dangerous.

Special permission bits change execution behavior. setuid on an executable makes it run as its owner (often root) regardless of who launches it; setgid does the same for the group. The sticky bit on a shared directory (like /tmp) stops users deleting each other's files. Attackers hunt for setuid-root binaries because abusing one is a direct path to root.

Core concepts

Owner / group / other: Permissions are checked against your relationship to the file.
setuid: Runs an executable as its owner (e.g. root) — a top escalation target.
setgid: Runs with the file's group; on a dir, new files inherit the group.
Sticky bit: On shared dirs, only the owner can delete their files (e.g. /tmp).

Command reference

chownChange file owner/group.chown root:root file

find / -perm -4000Find setuid binaries.find / -perm -4000 -type f 2>/dev/null

ls -lRead permission + special bits.ls -l /usr/bin/passwd

chmod u+sSet the setuid bit (study only).chmod 4755 prog

Examples

Hunt for escalation paths

List setuid-root binaries and flag anything non-standard:
  find / -perm -4000 -type f 2>/dev/null
A setuid copy of bash or a custom binary is a red flag.

Best practices

Audit setuid/setgid binaries; an unexpected one is a privilege-escalation risk.
Avoid world-writable directories and files holding sensitive data.

Common mistakes

Overlooking special bits and reading only rwx.
Leaving a setuid-root custom binary on a host.

Why it matters in the labs

Privilege escalation in the Linux labs often hinges on a misused setuid binary or an over-permissive file — this module is how you spot it.

Module 10

Common Administrative Tasks & Linux in Cybersecurity

Tie the fundamentals together with everyday admin tasks and see why Linux fluency is foundational to security work.

Detailed explanation

Routine administration is where fundamentals become practical: managing packages (apt/dnf), scheduling jobs with cron, monitoring disk and memory, managing users, and reviewing service health. Each of these is also an investigation surface — cron is a persistence favorite, package logs reveal installs, and disk usage spikes can signal staged exfiltration data.

Linux underpins security work: most servers, containers, and security tooling run on it, and attackers target it constantly. An analyst who can navigate, read logs, inspect processes, and reason about permissions can investigate the majority of real incidents. The Academy's other tracks (logs, traffic, IR, SOC) all assume this Linux baseline.

Core concepts

Package management: apt/dnf install and update software; logs show what changed.
cron / timers: Schedule recurring jobs — also a top persistence mechanism.
Resource monitoring: df, free, and top reveal disk/memory/CPU anomalies.
Why Linux matters: It runs servers, containers, and tooling — and is heavily targeted.

Command reference

crontab -lList a user's cron jobs.crontab -l

df -hShow disk usage.df -h

free -hShow memory usage.free -h

systemctl list-timersList scheduled systemd timers.systemctl list-timers

Examples

Review scheduled jobs for persistence

Check both cron and systemd timers:
  crontab -l
  systemctl list-timers
An unfamiliar job calling out to the network is suspicious.

Best practices

Review cron and timers on any suspect host — they're common persistence.
Baseline normal disk/memory so spikes (e.g. staged data) stand out.

Common mistakes

Forgetting systemd timers when only checking crontab.
Ignoring package/install history that shows attacker tooling.

Why it matters in the labs

This consolidates the Linux skills every later Academy track and lab relies on — the bridge from fundamentals to real investigation.

Ready to practice?

You've studied the theory — now apply it in the hands-on Linux Fundamentals labs.

Start Linux Fundamentals Labs