DESCRIPTION
Imagine you get an alert in the middle of the night — the server is acting up. You connect via SSH and… have no idea where to look. Where are the logs? Where are the configs? Where is anything? Without understanding the Linux filesystem structure you are a stranger in a strange city with no map. This lesson is that map.
WHAT YOU WILL LEARN
How the Linux filesystem is organised and how it differs from Windows
What lives in each key directory
Where configs, logs, binaries and data are stored
Why the FHS structure matters for security
How to use filesystem knowledge when analysing incidents
EVERYTHING IS A FILE
In Linux, everything is a file. Not just documents and programs — but devices, processes, network connections too. A hard drive is a file. A keyboard is a file. RAM is a file. This is not a metaphor — it is an architectural principle that makes Linux incredibly flexible and predictable.
The Linux filesystem starts at the root — the / symbol. Everything else lives inside it. There are no C:\ and D:\ drives like in Windows — just one directory tree into which all devices and partitions are mounted.
THE FHS STANDARD
The directory structure in Linux is defined by the FHS — Filesystem Hierarchy Standard. This is not a random collection of folders but a clearly defined agreement about what goes where. Every Linux distribution follows this standard — so once you know the Ubuntu structure you immediately find your way around Debian and Rocky Linux too.
FILESYSTEM MAP
/
├── etc/ # config files for all services
│ ├── ssh/ # SSH config
│ ├── nginx/ # nginx config
│ ├── systemd/ # systemd config
│ └── cron.d/ # cron jobs
├── var/ # variable data
│ ├── log/ # system and service logs
│ │ ├── auth.log # login attempts
│ │ ├── syslog # system events
│ │ └── nginx/ # web server logs
│ ├── www/ # website files
│ └── lib/ # application data
├── home/ # user home directories
│ └── username/
│ └── .ssh/ # user SSH keys
├── root/ # root user home directory
├── bin/ -> usr/bin/ # system commands
├── sbin/ -> usr/sbin/ # administration commands
├── usr/
│ ├── bin/ # executable files
│ ├── sbin/ # system utilities
│ └── lib/ # libraries
├── tmp/ # temporary files (danger zone!)
├── proc/ # virtual FS — processes and kernel
│ └── sys/ # kernel parameters (sysctl)
├── sys/ # virtual FS — devices
├── dev/ # device files
│ ├── sda # first disk
│ ├── null # black hole
│ └── urandom # random number generator
├── boot/ # bootloader and kernel
├── lib/ -> usr/lib/ # libraries
├── opt/ # third-party software
├── srv/ # service data
├── mnt/ # temporary mount points
└── media/ # removable devicesKEY DIRECTORIES
/ — the root of the filesystem. Everything starts here. Think of it as the trunk of a tree — all other directories are branches.
/etc — the heart of system configuration. All config files live here: network settings, SSH, nginx, PostgreSQL, cron and hundreds of other services. If something is configurable — the config is almost certainly in /etc. This is the first place an administrator looks when studying a system — and the first place an attacker looks after a breach. Get access to /etc and you essentially have access to the whole system.
/var — variable data. Everything that changes while the system runs: logs, databases, mail queues, package cache. This is where files grow and can fill up the disk if left unattended. A full /var can bring down an entire server — no attack required.
/var/log — the log directory. This is the history of everything that has happened on the system. /var/log/auth.log — login and authorisation attempts. /var/log/syslog — system events (if rsyslog is installed). On systems running pure systemd, logs are read via journalctl. In any incident this is the first place you go. And the first thing a smart attacker does after a breach — is clean exactly these logs.
/home — user home directories. Each user has their own: /home/username. Personal files and SSH keys (~/.ssh/) live here.
SSH key permissions are a critical topic. A private key with permissions 644 is a security hole the size of a barn door. Permissions 644 mean any user on the system can read the key. So if even one account on the server is compromised — the attacker reads your private key and connects to every server that key unlocks. Correct permissions: 600 for the key file and 700 for the ~/.ssh directory. SSH itself will refuse to work if it sees the key is “too open” — it throws a “Permissions are too open” error.
/root — the home directory of the root superuser. Separate from /home — intentionally. Root is not an ordinary user and has a home to match.
/bin and /usr/bin — system command executables. ls, cp, mv, cat and thousands of other utilities. In modern distributions /bin is a symbolic link to /usr/bin. If someone has replaced these files — the system is compromised at the deepest level.
/sbin and /usr/sbin — system administration utilities. Commands that require root privileges: fdisk, iptables, useradd. Regular users cannot access them — and that is by design.
/tmp — temporary files. Cleared on reboot. Any user can write to /tmp — this is the classic place where attackers leave their tools after a breach. After a reboot the traces disappear. Suspicious executable files in /tmp are a strong indicator of compromise.
/proc — a virtual filesystem. Does not exist on disk — created by the kernel in memory at boot. Contains information about running processes and kernel parameters. /proc/sys/ is where the parameters we change via sysctl live. Want to know what is actually happening on the system right now — look in /proc.
/sys — another virtual filesystem. Information about devices and kernel drivers. Like /proc but for hardware.
/dev — device files. /dev/sda — the first hard drive. /dev/null — the “black hole” where you redirect any output you do not need. /dev/random and /dev/urandom — random number generators used in cryptography. Without /dev/urandom not a single SSL certificate would work.
/boot — system boot files. The Linux kernel, initrd, GRUB bootloader config. Do not touch unless necessary — a mistake here and the system will not boot at all.
/lib and /usr/lib — libraries. Shared code used by many programs — the Linux equivalent of DLLs in Windows. Replacing a library is one attack method — called library hijacking.
/opt — additional software. Programs that do not fit the standard FHS structure. Often used for commercial software and self-compiled programs.
/srv — service data. According to the FHS standard this is where data provided by the server should live — website files, FTP data. In practice many distributions use /var/www for web data.
/mnt and /media — mount points. /mnt — for temporary mounting of filesystems by the administrator. /media — for removable devices (USB, CD).
PRACTICE
View the root filesystem structure:
ls -la /Explore the contents of /etc:
ls /etc | head -30View the system logs:
ls -la /var/log/Find all SSH configuration files:
ls -la /etc/ssh/View system information through /proc:
cat /proc/version
cat /proc/cpuinfo | head -20
cat /proc/meminfo | head -10Check kernel parameters that affect security:
cat /proc/sys/net/ipv4/ip_forward
cat /proc/sys/kernel/dmesg_restrictCheck how much disk space is used:
df -hFind the largest files in /var/log:
du -sh /var/log/* | sort -rh | head -10COMMON MISTAKES
Storing application data in /tmp. This is a temporary directory — everything in it is deleted on reboot. Application data belongs in /var or /opt.
Ignoring /var filling up. Logs grow, package cache accumulates — and one day /var hits 100%. The system starts behaving unpredictably. Set up logrotate and disk space monitoring.
Giving applications write access to /etc. Config files should only be modified by an administrator, not by an application. If an application writes to /etc on its own — that is a red flag.
Storing secrets in /tmp or /home. SSH keys, passwords, tokens — only in directories with restricted permissions set correctly.
IMPORTANT TO KNOW
/proc and /sys take up no disk space — they are virtual filesystems in memory. Do not try to clean them up to free space.
Symbolic links — /bin → /usr/bin, /lib → /usr/lib — are normal in modern distributions. Do not panic when you see them in ls -la output.
Mount points are just directories. When you mount a disk at /mnt/backup, the disk contents become accessible through that directory. Unmount it — the directory remains but is empty.
Filesystem security starts with correct permissions. A config file with permissions 777 is a disaster. Correct permissions: /etc — 755, private keys — 600, the .ssh directory — 700.
CHECK YOURSELF
1. In which directory are the config files for all services stored?
2. Where do you look for system and service logs when investigating an incident?
3. How does /proc differ from a regular directory on disk?
4. Why is /tmp dangerous from a security perspective?
5. What permissions should a private SSH key have and why?
CONCLUSIONS
The Linux filesystem is not chaos — it is a clearly organised structure with logic behind every directory. Knowing this structure is a core skill for any security administrator. When an incident happens — and it will — you will know exactly where to look: /var/log for logs, /etc for configs, /proc for system state. This knowledge saves minutes in a critical situation. And when a server is being compromised, minutes are everything.