Module 24 · System administration
Plug a brand-new Linux server into the internet and within minutes, robots are trying to break in. They guess passwords and try the same handful of known holes against every machine they can find. This module is the day-one checklist that keeps them out: a firewall, an auto-banner for bad guesses, careful user accounts, and the habit of checking what's on your machine before an attacker does.
By the end of this module, you will:
- Use htop to identify processes consuming excessive CPU or memory
- Start, stop, restart, enable, and check the status of systemd services
- Read and filter system logs with journalctl -u, -f, --since, --until
- Diagnose disk and memory pressure with df -h and free -h
- Schedule recurring tasks with cron and crontab
[Coming soon - module body will be authored in the next commit. The quiz will populate when the body lands.]
AppArmor — building on what you learned in Module 10
In Module 10 you learned about Linux's normal permissions — owner, group, others, read, write, execute. AppArmor works on top of those. Even if a program technically has permission to open a file, AppArmor can still stop it if the file isn't part of that program's job. Think of AppArmor as a job description that Linux enforces: a web server's job is to serve web pages — not to read your SSH keys. AppArmor makes sure it sticks to its job, no matter what permissions say.
Reading the SUID list — what's normal, what's not
When you run the SUID search (find / -perm -4000 -type f 2>/dev/null), the list it gives back can look scary at first. Most of it is totally normal Linux stuff. Here's how to tell the boring from the bad:
Totally fine — these are on every Ubuntu
/usr/bin/sudo · /usr/bin/passwd · /usr/bin/su · /usr/bin/mount · /usr/bin/umount · /usr/bin/ping · /usr/lib/openssh/ssh-keysign. These are normal Linux tools that genuinely need extra power to do their jobs (changing passwords, mounting disks, and so on). They come with Ubuntu — nobody's messed with them.
Worth a look — find out where it came from
Anything in the list you don't recognise. Run dpkg -S /path/to/binary to ask Linux which installed package this file belongs to. If dpkg says nothing — it doesn't know — then that file did not come from the normal Linux software store. Find out why it's there.
Red flag — fix this now
Any shell with the SUID bit set is bad news. If /bin/bash, /bin/sh or /usr/bin/python3 shows up in the list, anyone on the system can use them to become root instantly. Also worth checking: find / -perm -4000 -newer /etc/passwd 2>/dev/null — this shows SUID files that were changed after your system was first set up. Any of those deserve a hard look.
GPG — checking downloads and scrambling secret files
GPG (it stands for "GNU Privacy Guard") is Linux's all-purpose crypto tool. Two everyday things to know it for: checking that a file you downloaded hasn't been tampered with, and scrambling a secret file so only the right person can read it. It's already installed on every Ubuntu desktop.
Use 1 — Make sure your download wasn't tampered with
Whenever you download Linux software from a serious project, they also publish a tiny SHA256 number — a sort of fingerprint of the file. If your copy's fingerprint matches theirs, it's the same file. Some projects also sign that fingerprint with GPG. Together these two steps catch both broken downloads and downloads where someone swapped the file out for a bad one.
Use 2 — Scramble a sensitive file with a password
Need to email a tax return or store some passwords? Scramble the file first using a password. This is the simple way to use GPG — no fancy key setup, just a password you and the other person already know. (Tell them the password by phone or in person — never in the same email.)
If you want to send something secret to a person and not have to share a password with them first, GPG has a more advanced mode — you each make a key pair (gpg --full-gen-key) and swap your "public" half. It's a bit more setup, but stronger. The GnuPG handbook walks you through it.
The end-of-course security checklist
Go through these ten checks on any Linux machine you plan to use seriously. Most of them take under a minute. Tick all ten and you're ahead of 95% of the Linux machines on the internet.
| # | Check | How |
|---|---|---|
| 1 | All updates installed | sudo apt update && sudo apt upgrade -y |
| 2 | Security updates run by themselves | sudo dpkg-reconfigure unattended-upgrades |
| 3 | Firewall on; only the doors you need are open | sudo ufw status · only allow what your machine actually serves |
| 4 | SSH only takes keys, not passwords | Set PasswordAuthentication no in /etc/ssh/sshd_config |
| 5 | Root can't log in over SSH | Set PermitRootLogin no in /etc/ssh/sshd_config |
| 6 | fail2ban is running | systemctl status fail2ban · sudo fail2ban-client status sshd |
| 7 | Disk encrypted | lsblk -o NAME,FSTYPE — look for crypto_LUKS |
| 8 | Screen locks when you walk away | Settings → Privacy → Screen Lock — switch it on |
| 9 | Backups exist AND you've tested one | Déjà Dup / Timeshift / rsync — restore a single file to make sure it works |
| 10 | Lynis score is good enough | sudo lynis audit system — aim for 70 or higher |
Re-do #1, #2 and #10 once a month. Re-do the rest whenever you make a big change — installing new software, adding a user, or changing the network. Security is a habit, not a one-off project.