Listen to this Post
Introduction:
The Linux File System Hierarchy Standard (FHS) is the backbone of every Linux distribution, defining where configuration files, user data, logs, and system binaries reside. For cybersecurity professionals, IT engineers, and DevOps practitioners, mastering this structure is not optional—it is the difference between quickly mitigating a breach and fumbling through unknown paths while an attacker escalates privileges.
Learning Objectives:
- Navigate and explain the purpose of critical Linux directories (/boot, /etc, /home, /var, /usr, /proc, /dev, /tmp)
- Use terminal commands to inspect logs, configurations, and system state for troubleshooting and security forensics
- Apply Linux file system hardening techniques to prevent privilege escalation and data leakage
You Should Know:
1. /var/log – The Cyber Investigator’s Goldmine
Most production incidents—from failed cron jobs to intrusion attempts—leave traces in /var/log. This directory houses system logs (syslog, messages), authentication logs (auth.log, secure), and application-specific logs. As a DevOps or security engineer, you should live here during an investigation.
Step‑by‑step guide:
- Check real‑time authentication failures:
`sudo tail -f /var/log/auth.log` (Debian/Ubuntu) or `sudo tail -f /var/log/secure` (RHEL/CentOS) - Search for SSH brute-force attempts:
`grep “Failed password” /var/log/auth.log | awk ‘{print $11}’ | sort | uniq -c | sort -nr`
– View systemd service logs (alternative for modern distros):
`journalctl -xe -u nginx.service`
- Windows equivalent: Use `Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625}` in PowerShell to audit failed logons.
2. /etc – The Nerve Center of Configuration
`/etc` contains plain‑text configuration files for nearly every system service, network settings, and user authentication. Misconfiguring a file here is a common root cause of breaches (e.g., exposed SSH keys or weak sudo rules).
Step‑by‑step hardening guide:
- List all world‑readable config files (a security risk):
`find /etc -type f -perm -o+r -exec ls -l {} \; 2>/dev/null`
– Restrict access to shadow password file:
`sudo chmod 640 /etc/shadow` (already default, but verify)
- Audit sudoers for risky entries:
`sudo visudo` – look for `NOPASSWD` directives that allow privilege escalation. - Backup before editing:
`sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak`
- Windows comparison: Registry keys under `HKLM\SOFTWARE` and `C:\ProgramData` serve a similar purpose but are less transparent.
- /proc – A Live Snapshot of the Kernel & Processes
`/proc` is a virtual file system that exposes kernel, process, and hardware information in real time, making it invaluable for threat hunting and performance analysis. Attackers often probe `/proc` for sensitive data (e.g., command-line arguments of other processes).
Step‑by‑step investigation:
- View CPU info and potential side‑channel leakage:
`cat /proc/cpuinfo | grep -i “flags”` – check for vulnerability indicators (e.g., `pti` for Meltdown patch). - List all processes with their full command lines (reveals hidden malware):
`for pid in /proc/[0-9]; do echo -n “$pid: “; cat $pid/cmdline 2>/dev/null; echo; done`
– Check network connections per process (Linux):
`sudo netstat -tulpn` or `ss -tulpn` – cross‑reference PIDs with/proc. - Security note: A process that unlinks its own executable can still be recovered from
/proc/<pid>/exe. Use `cp /proc/1234/exe /tmp/recovered_binary` to dump it for malware analysis.
- /tmp & /dev/shm – Sticky Bits and Shared Memory Risks
`/tmp` is world‑writable, often used for temporary files. `/dev/shm` is a memory‑backed tmpfs that can be abused for privilege escalation or data exfiltration in shared hosting environments.
Step‑by‑step mitigation:
- Set the sticky bit on `/tmp` (already default but verify):
`ls -ld /tmp` → should showdrwxrwxrwt. If not: `sudo chmod 1777 /tmp`
– Prevent execution of binaries in `/tmp` (hardening):
`sudo mount -o remount,noexec,nosuid /tmp` – add to `/etc/fstab` for persistence. - Audit `/dev/shm` for suspicious files:
`sudo ls -la /dev/shm` – attackers sometimes drop scripts there to avoid disk forensics. - Windows equivalent: `C:\Windows\Temp` and `C:\Users\username\AppData\Local\Temp` – enable controlled folder access and periodic cleanup via GPO.
- /home & /root – User Data and the Almighty Home
`/home` stores personal user files, while `/root` is the superuser’s home. Compromising `/root/.ssh/authorized_keys` or `.bashrc` gives attackers persistence. Many misconfigured systems allow non‑root users to read `/root` – a critical flaw.
Step‑by‑step security assessment:
- Find world‑readable SSH private keys anywhere on system:
`sudo find /home /root -name “id_rsa” -o -name “.pem” -perm -o+r 2>/dev/null`
– Check for malicious aliases injected into.bashrc:
`grep -E “alias.sudo|alias.chmod” /home//.bashrc /root/.bashrc`
- Harden user home directories (set correct ownership):
`sudo chmod 750 /home/username` – prevents other users from browsing. - Linux command to list all users with home directories:
`getent passwd | cut -d: -f1,6 | grep -E “:/home”`
- /usr – System Binaries and Libraries (The Attack Surface)
`/usr` contains most user‑land applications, shared libraries (/usr/lib), and headers. Attackers who gain write access here can backdoor common commands like `ls` orps. Integrity monitoring is crucial.
Step‑by‑step validation:
- Verify integrity of core binaries (using RPM or Debian’s debsums):
On Debian/Ubuntu: `sudo apt install debsums && sudo debsums -c` (lists changed files)
On RHEL: `sudo rpm -Va | grep ‘^..5’` – checks MD5 sums of binaries. - List SUID binaries in `/usr/bin` (potential privilege escalation vectors):
`find /usr/bin -perm -4000 -exec ls -l {} \; 2>/dev/null`
– Monitor writes to `/usr` with auditd:
`sudo auditctl -w /usr -p wa -k usr_binaries`
- Windows analogy: `C:\Windows\System32` – use `sigcheck` from Sysinternals or PowerShell `Get-FileHash` for integrity.
- /boot – The Kernel and Bootloader (Pre‑Boot Security)
`/boot` holds the Linux kernel (vmlinuz), initramfs, and GRUB configuration. An attacker who can modify these files can bypass all OS‑level security controls, install rootkits, or demand ransomware before the OS even starts.
Step‑by‑step hardening:
- Set a GRUB password to prevent single‑user mode tampering:
Run `grub-mkpasswd-pbkdf2` (generate hash) → add to `/etc/grub.d/40_custom` → update-grub. - Verify kernel and initramfs signatures (if UEFI SecureBoot enabled):
`sudo sha256sum /boot/vmlinuz-` – compare with known good values from a trusted source. - Protect `/boot` with immutable flag (advanced):
`sudo chattr +i /boot/grub/grub.cfg` – prevents even root from modifying until cleared. - Linux command to check which kernel is currently running vs. installed:
`uname -r` vs `ls /boot/vmlinuz-`
What Undercode Say:
- Logs are your first line of defense – `/var/log` provides the raw intelligence for any forensic investigation. Set up centralized logging (rsyslog, ELK, or Splunk) immediately.
- Virtual filesystems like `/proc` and `/dev/shm` are often overlooked – they can leak sensitive data or be used as attack staging grounds. Harden mount options (
noexec,nosuid) on world‑writable tmpfs locations.
The Linux FHS is not just a directory tree; it is a security map. Every folder tells you what an attacker will target first: `/etc` for configs, `/tmp` for ephemeral payloads, `/root/.ssh` for persistence. By internalizing these paths and the commands to inspect them, you transform from a passive user into an active defender. The difference between a panic‑filled outage and a calm, methodical root cause analysis is often just knowing where to type `cd` and tail -f.
Prediction:
As cloud workloads and containerization (Docker, Kubernetes) continue to dominate, the Linux FHS will evolve in subtle but critical ways. Immutable operating systems (like Fedora CoreOS, Google’s Container-Optimized OS) will mount `/usr` and `/etc` as read‑only, forcing attackers to shift their focus to writable volumes like `/var/lib/docker` and ephemeral storage. Future breaches will likely exploit misconfigured `–privileged` containers that bypass these filesystem restrictions, making knowledge of namespaces and cgroups as important as traditional directory hierarchies. Cybersecurity training must adapt to teach not only FHS but also overlay filesystems and eBPF-based runtime detection, because the battle lines are moving from static files to dynamic kernel primitives.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Shahzadms Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
