Linux Server Security

ABOUT THE COURSE

A few minutes after a server goes online, it starts getting scanned. Not by hackers — by bots. They don’t care what’s running or who owns it. They’re just looking for open ports, default passwords, known vulnerabilities.

Most people don’t think about this. They set it up, it works, good enough. Until one day something goes wrong.

This course is about not finding out that way.

104 lessons, 12 blocks — from your first day with Linux to centralized monitoring with Grafana and Loki. Every tool is explained not just as “type this command” but why this command, what happens if you skip it, and how to verify it’s actually working.

WHO THIS IS FOR

For people who know how to get a server running — but aren’t sure how secure it actually is.

You work with Linux. You know the basic commands. You’ve configured SSH. But if someone asks “have you looked at pg_hba.conf?” or “is nftables set up?” — there’s that small uncomfortable pause. Sound familiar? That’s exactly what this course addresses. Not random Stack Overflow articles, but a systematic understanding of how everything fits together and why.

Complete beginner? That’s fine too. Block 0 starts from scratch, and the difficulty builds gradually. Nobody throws you in the deep end without explanation.

WHAT’S INSIDE

Each block builds on the previous one — by the end you don’t have a collection of tools, you have a complete picture.

We start with Linux fundamentals: filesystem, users, permissions, processes, networking, SSH. Sounds basic — but this is where understanding forms. Without it, everything else is just magic spells you copy from the internet.

Then — who’s actually allowed to do what on the server. sudo, PAM, SELinux, AppArmor. Why root appearing in your SSH logs isn’t just a log entry, it’s a reason to stop and investigate.

Most people know systemd as “systemctl start/stop.” But it can isolate a service so thoroughly that even if nginx gets compromised — it can’t read /etc/passwd, write files outside its own directory, or spawn new processes. There’s a whole block on this.

The kernel. sysctl parameters aren’t magic lines you paste from tutorials without reading. Each one does something specific: closes an attack vector, limits information leakage, changes how the network stack behaves under load.

Certificates. “Just install Let’s Encrypt” and “actually understanding how it works” are very different things. We cover chains of trust, building your own CA, mTLS, disk and file encryption. After this block, OpenSSL stops being scary.

Firewall with nftables — not iptables with its 1990s syntax, but a proper modern tool. We build a default-deny policy, protect against DDoS and port scanning, and learn to debug rules when something stops working.

nginx — not just “serving files.” Proper HTTPS, security headers, rate limiting, reverse proxy. And how to actually read logs so you see attacks, not just numbers.

The database lives in a private network, behind double isolation, with mTLS and minimal privileges. Because “PostgreSQL listening on 0.0.0.0” isn’t a configuration — it’s an open door.

fail2ban automatically blocks by log analysis. We look at how it works under the hood, write custom filters, integrate with nftables — and figure out why it sometimes stays silent when it should be blocking.

Cloudflare — CDN, WAF, DDoS protection, Tunnel, Zero Trust. How to properly integrate it into your stack without losing real client IPs along the way.

Auditing and monitoring: auditd, file integrity checking, traffic analysis, CIS Benchmarks, CVE tracking, automatic updates. How to know what’s happening on your server — not only when things are already on fire.

The final block is logging and troubleshooting. How Linux logging is structured, how to analyze it, and how to diagnose real problems: nginx returning 502, fail2ban not blocking, a systemd service refusing to start, TLS complaining about a certificate. Grafana and Loki for those who want everything in one place.

WHAT CHANGES

You take a clean server and configure it for production yourself.

SSH with keys, no root, restricted by IP. A firewall that’s closed by default. nginx with proper HTTPS and security headers. The database in a private network. Automatic attack blocking. Logs you actually know how to read. Monitoring that catches problems before a client calls.

And — most importantly — you understand why it’s done this way. When something goes wrong in production, and sooner or later it will, you’ll know where to look.