linux hardening beyond the baseline

you did the baseline. cool. that's not the finish line

disable root login, set up a firewall, run updates, call it a day. that's the checklist every "harden your linux server" post gives you, and it's fine as a starting point. but it's also the exact checklist every bot scanning the internet already assumes you did. if that's where you stopped, you're still an easy target for anything slightly more patient than a script kiddie. here's what actually moves the needle past the copy-paste basics.

move ssh off port 22

this isn't "security," it's noise reduction. port 22 gets hammered by automated scanners 24/7 whether you're a fortune 500 or a raspberry pi in your closet. moving to a random high port doesn't stop a targeted attacker, but it does cut your log spam by like 95% so when something real happens, you can actually see it.

sudo nano /etc/ssh/sshd_config
# change: Port 22
# to: Port 48222 (pick your own, 1024-65535)
sudo systemctl restart sshd

update your firewall rule to match the new port before you restart, or you'll lock yourself out. ask me how i know.

ufw limit ssh, the rate limiter that actually works

this is the command in the title and it does exactly what it sounds like. ufw limit tracks connection attempts and if an ip hits your ssh port 6+ times in 30 seconds, it gets auto-blocked for a while. brute force tools live and die by volume, so this alone kills most of them dead.

sudo ufw limit 48222/tcp
sudo ufw enable
sudo ufw status verbose

compare that to a plain allow rule, which just opens the door and lets anyone knock as fast as they want. limit puts a bouncer at the door counting knocks.

sysctl kernel hardening, tuning the thing under the thing

your firewall and ssh config sit on top of the kernel's own network stack, and the defaults are tuned for compatibility, not defense. a few sysctl tweaks change that without breaking anything normal.

sudo nano /etc/sysctl.conf

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0

sudo sysctl -p

syn cookies stop a specific flavor of syn-flood denial of service by letting the kernel handle half-open connections without exhausting its own memory. rp_filter (reverse path filtering) checks that incoming packets actually make sense for the interface they arrived on, which shuts down a lot of ip spoofing tricks. small changes, real impact, zero downside for a normal server.

crowdsec, because you shouldn't fight alone

fail2ban only reacts to attacks that already happened to you. crowdsec does that too, but it also shares anonymized attack data across its whole user base, so if an ip starts hammering someone else's server in another country, your server can preemptively block it before it ever tries you. it's basically a neighborhood watch for servers.

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec crowdsec-firewall-bouncer-iptables
sudo cscli metrics

run cscli decisions list after it's had some time to bake and watch it start dropping traffic from ips you've never even seen hit you directly.

apparmor in enforce mode, not just installed

most distros ship with apparmor installed but running in complain mode, meaning it logs violations instead of blocking them. that's like having a smoke detector that texts you a memo instead of going off. flip it to enforce and it actually contains a compromised process instead of just narrating the compromise.

sudo aa-status
sudo aa-enforce /etc/apparmor.d/*
sudo aa-status

check aa-status before and after, you want to see profiles move from "complain" to "enforce." test your critical services after this, since a badly scoped profile can block something legit. that's what staging environments are for.

the takeaway

none of this is exotic. it's just the layer past the checklist that everyone stops at because the checklist is what gets copy-pasted into blog posts. rate limiting stops the noise, sysctl hardens the plumbing, crowdsec gives you crowd-sourced eyes, and apparmor makes sure that if something does get in, it doesn't get far. run through each of these on your own boxes this week, one at a time, and check the logs after each change so you actually know what it's doing. that's the difference between a server that's technically secured and one that's actually defended.