lock down a fresh linux box with three ufw commands

the three commands that save you from yourself

you just spun up a fresh linux box. maybe it's a vps, maybe it's a raspberry pi in the closet, maybe it's a homelab server you're proud of. right now, before you install anything else, it's sitting there with every port wide open waiting for the internet to say hello. and the internet says hello a lot faster than you'd think. bots are scanning fresh ip ranges within minutes of them going live.

here's the one liner that gets you from "wide open" to "reasonably locked down" in about three seconds:

ufw default deny incoming && ufw allow OpenSSH && ufw enable

let's break down what each piece is actually doing, because typing a command you don't understand is how you lock yourself out of your own server.

ufw default deny incoming

ufw stands for "uncomplicated firewall," and it's a friendly wrapper around iptables/nftables so you don't have to write raw firewall rules by hand. this first part sets the default policy: any incoming connection that isn't explicitly allowed gets dropped. silently. no response, no "connection refused," just nothing. attackers hate nothing, because nothing tells them nothing about what's running on your box.

note this only touches incoming traffic. outgoing connections still work fine, so your server can still update packages, phone home, whatever it needs to do.

ufw allow OpenSSH

if you locked down all incoming traffic and stopped there, you'd also lock yourself out of ssh, which is usually how you're managing this box in the first place. this line punches a specific hole for ssh traffic. "OpenSSH" here is a named application profile that ufw ships with, it just maps to port 22 by default. you can check what it actually allows with:

ufw app info OpenSSH

if you've moved ssh to a custom port (which is a decent move for cutting down on automated noise), you'd swap this line for something like ufw allow 2222/tcp instead. the goal is the same either way: keep your one lifeline open while everything else stays shut.

ufw enable

none of the rules above matter until the firewall is actually turned on. this flips the switch. ufw will warn you that it might disrupt existing ssh connections, that's just a heads up, not a reason to panic, since you already allowed ssh in the previous step.

run ufw status verbose afterward to confirm what's actually active. you should see "deny (incoming), allow (outgoing)" as the defaults, and OpenSSH sitting in the allow list. if that's what you see, you're in decent shape.

what people forget to add

three commands is a great start, not a finish line. a few things worth layering on:

allow only what you actually run. hosting a web server? add ufw allow 80/tcp and ufw allow 443/tcp (or just ufw allow "Nginx Full" if it's registered). don't pre-open ports for services you might install someday, that's future-you's problem.

rate limit ssh. swap the plain allow for ufw limit OpenSSH, which throttles repeated connection attempts from the same ip. it's a cheap way to blunt brute force scanning without touching sshd config.

lock ssh down further at the sshd level. disable password auth, use key based login only, consider moving off port 22. ufw controls what can knock on the door, sshd config controls what happens once someone does.

check for ipv6. ufw handles ipv6 rules too if it's enabled in /etc/default/ufw, don't assume you're covered on ipv4 alone if your box has a public ipv6 address.

log it. ufw logging on gives you a paper trail in /var/log/ufw.log so when something looks weird later, you're not flying blind.

the takeaway

a fresh linux box is basically a house with no doors installed yet. these three commands hang a door and lock it, but you still get to decide who has a key. run the base three commands first, then go back and add rate limiting, service specific rules, and proper ssh hardening on top. the point isn't to memorize one magic line, it's to actually understand what each rule is doing so you can adjust it when your setup changes, because it will.