Introduction to the Open-Source Operating System

Introduction to the Open-Source Operating System: Linux

Every machine on the TOP500 supercomputer list runs Linux. So does most of the public cloud, the majority of web-facing servers, every Android handset, and the router in the corner of your office that nobody has logged into since it was installed. For most people that is invisible plumbing. For anyone doing security work it is the actual job: the thing you attack, the thing you defend, and the thing your tooling runs on.

The reason Linux ended up at the centre of security work is not that it is inherently safe — it isn’t, and a default install exposed to the internet will be found and probed within the hour. It is that you can read it. The kernel source is public, you can compile a build with the modules you need and nothing else, and you can verify what a binary does rather than take a vendor’s word for it. That auditability is the whole argument, and it comes with a bill: nobody is accountable to you for what you compile, and “the community will patch it” is a hope, not a support contract.

Linux is a kernel, not an operating system. What you install is that kernel plus a userland — GNU utilities, an init system, a package manager, a libc — assembled by a distribution. Knowing where that seam sits saves you a lot of confusion later, because most of what people call “a Linux problem” is a distribution decision.

Almost every security control on the box lives at the boundary between user space and kernel space. A process asks the kernel to do something via a system call; the kernel decides whether to allow it. Mandatory access control frameworks such as SELinux and AppArmor sit exactly on that path, which is why they can stop a compromised web server from reading /etc/shadow even when the file permissions would otherwise permit it. The diagram below shows the two halves and the checkpoint between them.

Understanding the Linux Directory Structure

Linux organises everything under a single root directory, /. There are no drive letters; a second disk appears as a directory somewhere in the same tree. The layout is standardised by the Filesystem Hierarchy Standard, so a path you learn on Debian mostly transfers to Rocky — mostly, because /bin and /sbin are now symlinks into /usr on nearly every current distribution, and forensic tooling that assumes otherwise will hand you duplicate results.

The reason this matters for security is that the tree tells you where to look. Persistence lives in a small number of predictable places, and so does evidence.

Discretionary Access Control: File Permissions

Linux’s default model is discretionary: the owner of a file decides who else may touch it, and root may ignore the decision entirely. That is the whole security model on most boxes, and it is weaker than people assume — a single world-writable script in a cron job is all it takes. Every file and directory is assigned to an owner and a group, and the kernel checks three tiers in order, stopping at the first that matches:

1. User (u): The user who owns the file.
2. Group (g): Members of the group associated with the file.
3. Others (o): Everyone else on the system.

Running ls -l shows permissions as a character string like this:

-rwxr-xr-x 1 webadmin developers 1234 May 31 10:00 deploy.sh

Breaking it down:

• The first character is the file type (- for regular file, d for directory, l for symlink).
• The next nine characters are three permission triplets:
  • rwx (Owner): webadmin can read, write, and execute.
  • r-x (Group): The developers group can read and execute.
  • r-x (Others): Everyone else can read and execute.

That ordering catches people out. If you are webadmin and you strip your own write bit, being a member of developers does not give it back — the kernel matched on owner and stopped. It is also why “the file is 640 but I still can’t read it” is almost always a directory problem: you need execute on every directory in the path before the file’s own bits are ever consulted.

For a full guide covering octal notation, special bits (SUID, SGID, Sticky Bit), and Access Control Lists (ACLs), see our dedicated post on Linux File Permissions and Ownership Management .

Essential Linux Commands

Serious Linux work happens at the command line, and not out of nostalgia — a shell session is scriptable, loggable, and works identically over a 200 ms satellite link to a machine with no display attached. Commands follow this general format:

command [options] [arguments]

These are the ones you will type thousands of times. Learn them properly rather than half-remembering them, because the difference between rm -rf /tmp/staging and rm -rf /tmp/staging / is one character and no confirmation prompt:

Why Choose Linux? A Cybersecurity Perspective

Each of these is a real advantage. Each of them also costs something, and the honest version says so:

• Auditable source code. Anyone can inspect the kernel, which is how subtle bugs get found by people the vendor never hired. It is not a guarantee: Heartbleed and Shellshock both sat in widely read open-source code for years. “Many eyes” only works where eyes are actually looking, and that is unevenly distributed across the tree.
• Minimal attack surface. A server install with no desktop, no printing stack and no unused daemons has far fewer things listening than a consumer OS. The cost is that you own the decision about what to remove, and stripping a module that something needed six months later produces a failure nobody connects back to the hardening ticket.
• Granular privilege control. sudo gives you delegated administration with an audit trail, per-command rules, and no shared root password. It is also routinely undermined by a single ALL=(ALL) NOPASSWD: ALL line added to unblock a deployment, which is the first thing any local privilege-escalation check looks for.
• Native hardening frameworks. SELinux and AppArmor confine a process to the files and operations its policy allows, which is what turns a web-server compromise into a contained nuisance rather than a whole-host loss. The trade-off is denials that surface as inexplicable application errors, and the reason setenforce 0 remains the most-followed piece of advice on the internet.
• Stability and long uptime. Linux will happily run for years without a reboot, which matters for firewalls and IDS sensors. Long uptime is also a tell: it means you are running a kernel with known CVEs unless you are live-patching. Uptime is not a trophy.

Linux vs. Windows: The Enterprise Security Battle

The table flatters Linux, so here is the correction: Windows in an enterprise has centralised policy, a mature EDR ecosystem, and Group Policy that actually reaches every endpoint. Linux fleets frequently have none of that, and “we manage it with Ansible” often means three people manage it with Ansible and everything else drifted years ago. The platform is more securable; whether it is more secure in your estate is a question about your operations, not about the kernel.

Popular Linux Distributions (Distros)

A distribution is a set of decisions: which kernel version, which init system, which libc, which package manager, and — the one that actually matters in production — how long they will keep shipping security patches for the release you installed. Pick on the support lifecycle first and the desktop theme never. What you’re doing narrows it further:

• Ubuntu & Debian: Ubuntu LTS is the default for cloud images and the one with the most third-party install instructions written against it; the standard LTS security window is five years, extended further under Ubuntu Pro. Debian stable updates conservatively, which is exactly what you want under a database and exactly what frustrates you under an application that needs a package two versions newer than the archive has.
• Red Hat Enterprise Linux (RHEL), Fedora & Rocky Linux: The enterprise default, with SELinux enforcing out of the box and a long support lifecycle. RHEL buys you someone contractually obliged to answer the phone; Rocky gives you the same package base without that. Fedora is the upstream proving ground — useful for seeing what RHEL will look like in two years, unsuitable for anything you need to leave alone.
• Arch Linux: Rolling release, no installer decisions made for you, and a wiki better than most vendors’ paid documentation. Rolling means you get security fixes fast and you also get a breaking change on a Tuesday. Excellent workstation, poor choice for a fleet you patch unattended.
• Kali Linux & Parrot OS: Debian-based, preloaded with several hundred offensive and forensics tools. Both are testing platforms, not hardened hosts — Kali historically ran as root by default and is built to run tools, not to survive being attacked. Do not use one as a jump box.
• Alpine Linux: A roughly 5 MB base built on BusyBox and musl libc, which is why so many container images start FROM alpine. The catch is musl: anything expecting glibc behaviour — DNS resolution edge cases, some Python wheels, several proprietary agents — may misbehave in ways that only show up under load.
• Tails & Qubes OS: Tails runs from RAM and forces traffic through Tor, leaving nothing on disk by design; that also means nothing persists unless you deliberately configure it. Qubes isolates each activity in its own Xen VM, giving you the strongest desktop compartmentalisation available at the cost of GPU acceleration, battery life, and fussy hardware compatibility.

Modern Networking and Connectivity Commands

The single most useful command in an early triage is ss -tulpn. It answers the question everything else depends on: what is listening on this box, and which process owns it. Run it without sudo and the process column comes back empty for anything you don’t own — no error, just blanks — which is how people conclude a port has no owner.

[!NOTE] Legacy tools like ifconfig and netstat are deprecated in modern distributions and are frequently not installed at all on minimal images and containers. They have been replaced by the iproute2 utilities, which are faster and read kernel state through netlink rather than parsing /proc.

# Identify listening ports and the processes behind them
sudo ss -tulpn

Frequently Asked Questions

Q: Is Linux inherently more secure than Windows?

No. It is more securable, which is a different claim. Privilege separation is strict, patches arrive quickly, and you can strip the system to almost nothing. None of that survives a server with password SSH on port 22, a five-year-old WordPress install, and no log forwarding — and that describes a great many Linux boxes on the internet right now. The compromises we get called about are almost never kernel bugs. They are exposed services, reused credentials, and a sudoers entry someone added at 6 p.m. to make a deploy work.

Q: Can Linux systems be infected by malware?

Yes, and the interesting cases are all server-side. Expect ELF backdoors, LD_PRELOAD and kernel-module rootkits, web shells dropped through an application flaw, cryptominers that show up first as a cloud bill, and IoT botnets in the Mirai lineage. Ransomware crews have spent years building Linux and ESXi lockers specifically, because encrypting a hypervisor’s datastores takes out every guest at once. The reason desktop antivirus signatures feel irrelevant here is that the payload usually is not a file sitting still — it is a process, a cron entry, and a systemd unit.

Q: Is Linux harder to learn than Windows?

Steeper at the start, flatter forever after. The first week is genuinely worse: no obvious place to click, error messages that assume you know what a file descriptor is, and documentation that answers a question adjacent to yours. What you get for it is a system where every action is expressible as text, which means it can be scripted, reviewed, version-controlled and run across a thousand hosts. That is the whole payoff, and it does not arrive until you stop trying to use the terminal as a slower file manager.

Additional Resources

• The Linux Foundation — Official documentation and open-source project governance.
• Ubuntu Command Line Tutorial — Hands-on practice for command-line beginners.
• GTFOBins — A curated list of Unix binaries that can be abused to bypass local security restrictions.

Advanced Linux Concepts

Commands get you through a single box. Scripting and process management are what let you handle a hundred, and they are also where most self-inflicted outages originate.

Shell Scripting and Automation

A shell script is a program that runs as root, was written in ten minutes, and is never reviewed. Treat it accordingly. The example below is a backup routine with the two checks that people habitually skip — privilege verification and source validation — because a backup script that silently archives a directory that no longer exists produces a tidy 45-byte tarball every night and nobody notices until the restore.

#!/bin/bash
# Backup Script with basic input validation and logging

SOURCE_DIR="/var/www/html"
BACKUP_DIR="/opt/backups"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
LOG_FILE="/var/log/backup_service.log"

# Verify execution as root or sudo
if [[ $EUID -ne 0 ]]; then
   echo "[CRITICAL] This backup script must be run as root." >&2
   exit 1
fi

# Validate source directory exists
if [ ! -d "$SOURCE_DIR" ]; then
    echo "[ERROR] Source directory $SOURCE_DIR not found. Aborting." >> "$LOG_FILE"
    exit 1
fi

mkdir -p "$BACKUP_DIR"
chmod 700 "$BACKUP_DIR"

# Execute backup using tar archiving
BACKUP_FILE="$BACKUP_DIR/backup_$TIMESTAMP.tar.gz"
tar -czf "$BACKUP_FILE" "$SOURCE_DIR" 2>> "$LOG_FILE"

if [ $? -eq 0 ]; then
    echo "[SUCCESS] Backup of $SOURCE_DIR saved to $BACKUP_FILE on $(date)" >> "$LOG_FILE"
    chmod 600 "$BACKUP_FILE"
else
    echo "[FAILED] Backup execution failed on $(date)" >> "$LOG_FILE"
fi

[!WARNING] Shell Scripting Security Best Practices:

1. Never hardcode secrets. Keep API keys, database passwords, and private keys out of scripts. Use environment variables or a secrets manager like HashiCorp Vault.
2. Restrict execution permissions. Run chmod 700 script.sh so only the owner can read and execute it.
3. Quote all variables. Use "$VAR" to prevent word splitting, globbing, and command injection vulnerabilities. An unquoted $DIR containing a space turns one argument into two, and rm -rf $DIR/* with DIR unset expands to rm -rf /*.
4. Fail loudly. Add set -euo pipefail near the top. Without it a script carries on cheerfully after a failed command, which is how half a backup gets uploaded and marked successful.

Managing Processes and Signals

The kernel tracks every running application by Process ID (PID), and process state is where an intrusion usually becomes visible before anything else does — a bash with a parent of nginx, an outbound connection from a process whose binary has been deleted from disk, a miner politely renamed [kworker/0:2]. Processes run either in the foreground, holding your terminal, or in the background.

• Background Execution: Append & to run a command without locking up your terminal:

  nmap -sV -p- 10.0.0.1 > scan_results.txt &
  

• Signal Transmission: Processes respond to signals sent via the kill command:
  • SIGTERM (Signal 15): The default signal. Asks the process to clean up and exit gracefully.
  • SIGKILL (Signal 9): Cannot be caught or ignored. The kernel stops the process where it stands, so open files are not flushed and locks are not released — which is why reaching for -9 first is how you corrupt a database rather than restart it. It also will not help against a process stuck in uninterruptible sleep on failed I/O; that one needs the storage fixed, not a bigger signal.

Package Management Systems

A package manager is a supply-chain control, not a convenience. It resolves dependencies, verifies GPG signatures against keys you already trust, and gives you an inventory of what is installed and at what version — which is the only reason you can answer “are we affected?” on a CVE morning. Every curl … | sudo bash install you run steps outside that inventory, and those are precisely the packages nobody patches.

[!IMPORTANT] Package managers verify integrity using GPG (GNU Privacy Guard) keys. If a signature cannot be verified, the manager aborts rather than installing a tampered file. This protection is only as good as the keys you have imported: adding a third-party repository means adding its signing key, and from that moment its maintainer can install anything on your system at root. Audit /etc/apt/sources.list.d/ and /etc/yum.repos.d/ on any host you inherit.

Linux in Cybersecurity and Server Management

Linux dominates backend infrastructure, so security teams end up needing both halves: ordinary server administration, and the tooling built on top of it.

Tools for Security Operations and Pentesting

Security distributions ship these preconfigured. Knowing what each one is actually good at saves you from the common mistake of reaching for the heaviest tool first:

• Nmap: Port scanning, service version detection, and OS fingerprinting. Version detection (-sV) is what makes it useful and also what makes it noisy — it opens full connections and talks to services, which fragile embedded devices sometimes do not survive.
• Metasploit Framework: Modular exploitation, primarily valuable for validating that a finding is real rather than theoretical. Running an exploit module against production is a decision with a blast radius; the memory-corruption ones can and do leave services dead.
• Wireshark: A graphical packet analyser with dissectors for hundreds of protocols. Excellent for reading a capture, poor for taking one on a busy server — the GUI and the full dissection cost you memory you may not have.
• tcpdump: The right tool for capture on a headless box. Take the pcap with a tight BPF filter and a -C/-W ring buffer, then read it in Wireshark somewhere else. Capturing unfiltered on a gigabit link fills the disk faster than most people expect.
• John the Ripper / Hashcat: Password auditing against a hash dump you already have. Hashcat is GPU-driven and dramatically faster; John is more flexible about odd formats. Both are for offline cracking — pointing either at a live login service is a different, much louder activity.

Linux as a Secure Server OS

One box, one role, is the rule worth keeping. Every additional service on a host is another set of credentials, another log source nobody reads, and another way for a compromise of the least important thing on the machine to reach the most important:

• Web servers: Apache (httpd) or Nginx for static content and reverse proxying. Bind the application itself to 127.0.0.1 and let the proxy be the only thing on a public port — otherwise the app is reachable directly and your proxy’s security headers and rate limits are decorative.
• File servers: Samba for Windows interoperability, NFS for Unix-to-Unix. Neither belongs on an internet-facing interface; SMB in particular has a long history of being exactly the port worms travel over.
• Database servers: PostgreSQL, MySQL, or MongoDB. Every one of these has shipped a version that listened on all interfaces by default at some point, and internet-wide scans still find thousands of them. Check the bind address before you check anything else.
• Reverse proxies and load balancers: HAProxy, Nginx or Traefik in front of your application tier. They also become the point where TLS terminates, which means they hold the private keys and see every request in plaintext — treat them as your highest-value host, not as plumbing.

Enterprise-Grade Security Hardening Best Practices

A fresh cloud instance with a public IP will see its first SSH login attempt within minutes of the address being allocated — the scanning is continuous and entirely automated. None of it is targeted at you; it does not need to be. These five steps get you past the automated layer, which is the overwhelming majority of what will ever knock on the door:

1. Enable Automated Updates

Unpatched known vulnerabilities beat novel exploits in every breach report, year after year. Automate the patching. The trade-off is real — an unattended upgrade can restart a service at 3 a.m. or pull in a package change you did not test — so restrict it to the security pocket, and pair it with monitoring rather than pretending the risk is zero. On Ubuntu or Debian, use unattended-upgrades:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

2. Configure a Host Firewall

Default-deny inbound, then allow the three ports you actually serve. One warning worth internalising: if Docker is installed, publishing a container port writes rules into the DOCKER chain that bypass UFW entirely, so a port you believe is firewalled may be answering the internet. Verify by scanning the host from another machine, not by reading ufw status.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH Access'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

3. Harden the SSH Daemon

Turning off password authentication removes the entire brute-force category in one line — the scanners keep knocking, but there is nothing to guess. Edit /etc/ssh/sshd_config. Note that on current distributions a drop-in file under /etc/ssh/sshd_config.d/ may override whatever you write in the main file, which is the usual reason a change appears to have no effect:

# Disable root logins over SSH
PermitRootLogin no

# Enforce SSH public key authentication
PasswordAuthentication no

# Limit login access to specific users
AllowUsers security_admin sysop

Keep a second session open while you do this, and test the configuration before restarting. sshd -t catches syntax errors; it does not catch you having disabled password auth on a host where your key was never installed. That one you find out about immediately and permanently:

sudo sshd -t && sudo systemctl restart sshd

4. Monitor Log Files

Local logs are evidence right up until the moment someone owns the box, at which point they are whatever the intruder left behind. Watch them, but ship them off-host as well — a remote copy is the only version an attacker cannot edit:

• Systemd Journal: Query active logs with journalctl:

  sudo journalctl -u ssh -g "Failed password" -f
  

• Fail2Ban: Automatically block IPs that exceed login failure thresholds:

  sudo apt install fail2ban
  sudo systemctl enable --now fail2ban
  

5. Audit Local SUID Binaries

A SUID binary runs as its owner regardless of who launched it, which makes an unexpected one a straight path to root. Take this inventory on a freshly built host and keep it — the value is in the diff later, not the list today. Cross-check anything unfamiliar against GTFOBins, which catalogues exactly how ordinary utilities become escalation primitives once they carry the SUID bit:

find / -perm -4000 -type f 2>/dev/null

Take Your Linux Skills Further

Recommended Reading

• “The Linux Command Line” by William Shotts — An excellent introduction to terminal usage for all skill levels.
• “Linux Basics for Hackers” by OccupyTheWeb — Perfect for understanding Linux through a security and offensive tooling lens.
• “How Linux Works” by Brian Ward — A deep dive into kernel internals, the boot process, and device drivers.

Online Training

• The Linux Foundation Training — Official courses and certifications (LFCS, LFCE).
• NDG Linux Unhatched (Cisco Networking Academy) — A solid entry point for beginners.

100 Essential Linux Commands

The following reference covers 100 commands organised by function. Don’t memorise it — skim it once so you know a tool exists, then come back when you need it. Recognising the right command is the hard part; the flags are in man.

1. File and Directory Operations

2. Text Processing and Search

3. System Information and Hardware

4. Disk Management and Filesystems

5. Process Management and Performance

6. User, Group, and Privilege Management

7. Networking and Connectivity

8. Package Management

9. Compression and Archiving

10. Shell Builtins and Command History

Pro tip: man <command> is the authoritative reference for the exact version installed on the box in front of you, which a web search is not. When the man page is dense, man 5 <file> covers configuration file formats and apropos <keyword> finds the command when you only remember what it does.

The way this knowledge actually sticks is by breaking something you can afford to break. Build a VM, harden it using the five steps above, then scan it from another machine and see what still answers. The gap between what you configured and what the scan reports is the entire lesson. ✨