Firewall rule helper with CIDR validation, Linux commands, edge snippets and rollback notes
I locked myself out of a box once. One careless deny rule, three time zones of distance, a very long evening. So I built this to slow me down. You type in a source, some ports, an action. It drafts the rules, UFW, iptables, nftables, firewalld, with Nginx and Cloudflare-style snippets thrown in. It checks your IPv4 CIDR. It shows you what you’re actually exposing, which is usually more than you think, and it writes you a change report plus a rollback before you go near anything live.
Drafts. Not gospel. Run them on staging or in a maintenance window, keep a console session you can crawl back to, then bend the syntax to fit your distro and whatever cloud firewall or host panel sits in the way.
A firewall rule helper should help you think before you paste
Firewall syntax is trivial to copy. Also trivial to fat-finger. One too-wide allow and SSH or a database or some forgotten admin dashboard is sitting on the open internet. One too-wide deny and you’ve locked yourself out of a server that’s three time zones away, at 2am, with no console handy. So before I touch a single rule I ask the same boring questions, every time, in the same order: who needs to reach which service, coming from where, over what protocol. And the one most people skip until it’s too late, if this goes sideways, how do I undo it?
That’s the whole reason it exists. It checks the source IP or CIDR. It blows port ranges out into a matrix you can actually read instead of squinting at. It drafts commands for the usual Linux firewalls, drops in Nginx and Cloudflare-style edge examples, flags the exposure that tends to bite people, then writes you a rollback. What it won’t do, ever, is apply anything. That’s deliberate. I’d rather you read the rule one more time than let a script fire it at a production box while you’re not looking.
How to use the generated rules safely
My rule of thumb, and honestly I might be too paranoid here, start with the narrowest source range that solves the problem and widen only when something forces you to. For SSH that means your current public IP, a VPN range, maybe a management subnet. Never the whole internet. Ports 80 and 443 can stay open for real web traffic. Everything else (admin panels, databases, caches, Elasticsearch, RDP, your monitoring dashboards) stays shut. And if a cloud provider firewall sits in front of the box, set both layers on purpose. I once burned the better part of an hour chasing a “blocked” service that was open at the host and shut at the provider. The two were quietly disagreeing and neither one told me.
- Keep a second session open before you go anywhere near an SSH rule. Cheapest insurance you’ll ever buy, and you’ll only forget it once.
- Apply allow rules first whenever a deny landing later could cut off your own admin path.
- Watch your CIDR. A /32 is exactly one IPv4 address. A /0 is, well, the entire planet.
- Write the rollback down before you run a single command on a live host. Not after. After is too late.
- Check it from outside with a port checker once the rule’s in. Don’t just take your own word for it.
Common firewall examples
A typical SSH admin rule lets port 22 in from one source you trust and slams the door on everyone else at the boundary. A web server opens 80 and 443 to the public. Protecting wp-admin, though, that’s a job for auth and rate limits and app-level controls, not the firewall, people get this wrong constantly. And a database rule should basically never put 3306, 5432, 6379 or 9200 on the open internet. I’ve watched exactly that go sideways more than once, and it’s never a small mess. Emergency blocks have their place. Just read a broad one twice before you commit, because the source you’re swatting can turn out to be a proxy. Or an uptime monitor. Or a payment callback you very much wanted to keep.
Common questions
Can I paste these commands directly on my server?
I wouldn’t, not blind anyway. Treat them as a starting point and sanity-check the bits that change from box to box first. Interface names. Whether you also need IPv6. What your cloud firewall already allows. Where the rule actually lands in the existing order, and how it gets persisted across a reboot. Five seconds of reading beats an evening of lockout, every time.
Which firewall tool should I use?
Whichever one your server is already driving. That’s the honest answer, boring as it sounds. On Ubuntu that’s usually UFW. On newer distros nftables is often what’s really doing the work down underneath. The thing you want to avoid is mixing tools when you don’t actually know what the live ruleset looks like. That’s exactly how you wind up with two rules fighting, and neither one winning the way you expected.
Why include rollback commands?
Because the moment you actually need a rollback is the absolute worst moment to start writing one. Work out how you’ll back the change out while you’re still calm and still connected. With SSH, or anything remote-admin really, that’s not optional. It’s the whole difference between a five-second undo and a panicked drive across town to the data center.
What is the difference between ufw, iptables and nftables?
Layers, mostly. nftables is the modern packet filter living in the kernel. iptables is the older command set you probably grew up with, and on most current systems it’s quietly just talking to nftables under the hood anyway. ufw sits on top of the whole stack and hands you a friendlier syntax. My take, for what it’s worth: reach for ufw on a simple host, and drop down to nftables when you genuinely need fine-grained control.
What is a sensible default firewall policy?
Here’s the one I set on almost every box. Deny inbound by default. Let established and related connections back through, then open only the exact ports you actually need, which is SSH and HTTPS usually and honestly not much else. Leave outbound open unless you’ve got a concrete reason to clamp it down. Start closed, open things deliberately, one at a time. It’s far less painful than auditing a wide-open host weeks after the fact and wondering what that port is for.
Do I need to persist firewall rules?
Yes. And this one trips up more people than you’d think. Rules you add at runtime vanish the second the box reboots, unless you save them somewhere. I’ve watched a server come back up wide open after a routine kernel update, purely because nobody had persisted the ruleset. Nobody noticed for a while either. Use whatever your distro hands you (ufw enable, netfilter-persistent, or an nftables config file) so the rules actually come back on boot.
