Linux Security Basics

Most Linux servers don't get hacked through some exotic exploit - they get hacked because a password was reused, a file was too permissive, or a system went unpatched for a year. This lesson covers the everyday habits that prevent almost all of that.

sudo: elevate one command, not your whole session

Logging in directly as root (the all-powerful administrator account) is dangerous - one typo in a root shell can wipe a system. sudo is the alternative: it runs a single command with elevated privileges, then hands control straight back to your normal, limited account.

sudo apt update            # run just this one command as root
sudo whoami                # -> root, but only for this command

Which users are allowed to sudo, and what they're allowed to run, is controlled by /etc/sudoers (edited safely with visudo, which validates the syntax before saving). On most desktop distributions, being in the sudo (or wheel) group is what grants this access.

Least privilege, revisited

You met this idea in the permissions lesson: grant only the access a task actually needs, nothing more. In practice that means:

• Application processes run as a dedicated, unprivileged user - never as root.
• Config files with secrets in them get chmod 600 (owner-only), not 644.
• A user or service account that only needs to read something is never given write access "just in case."

SSH keys instead of passwords

Passwords can be guessed, phished, or brute-forced. SSH key pairs are the standard alternative for logging into a remote Linux server:

• A private key stays on your laptop, ideally itself protected by a passphrase, and is never shared.
• A public key is copied onto the server, into ~/.ssh/authorized_keys.
• Logging in proves you hold the private key mathematically, without ever sending a secret over the network.

The private key file itself needs tight permissions - SSH will actually refuse to use it otherwise:

chmod 600 ~/.ssh/id_ed25519       # private key: owner read/write only
chmod 644 ~/.ssh/id_ed25519.pub   # public key: fine for anyone to read

Well-run servers go a step further and disable password login entirely, accepting only key-based authentication.

Firewalls: default deny

A firewall decides which network traffic is allowed to reach your machine at all. The safest default posture is deny everything, then open exactly what's needed - for a typical web server, that usually means allowing only SSH (22), HTTP (80), and HTTPS (443), and nothing else. On Ubuntu-family systems this is commonly managed with ufw (a friendly wrapper); everywhere else it's usually iptables or nftables directly.

Keep the system patched

Most real-world break-ins exploit a known, already-patched vulnerability on a system nobody got around to updating. You already know the commands from the package management lesson - the security habit is simply running them regularly:

sudo apt update && sudo apt upgrade

Try it

sudo apt update
sudo whoami
mkdir -p ~/.ssh
touch ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ls -la ~/.ssh

Notice the -rw------- on the key file in the listing - owner read/write, nothing for anyone else. That's exactly what a real SSH client expects before it will trust the key.

Further reading

• "UNIX and Linux System Administration Handbook" by Nemeth, Snyder, Hein, Whaley, and Mackin (Pearson) - its security chapters cover sudo policy, SSH hardening, and firewalls in real production detail.
• "How Linux Works" by Brian Ward (No Starch Press) - explains the permission and privilege model this lesson builds on, from the kernel's point of view.