What this does
Builds a complete, ready-to-run command sequence for either UFW (Ubuntu/Debian) or firewalld (Fedora/RHEL) from a list of allow/deny rules — port, protocol, and an optional source address or CIDR range for each one. The generated sequence always applies a default-deny policy (when enabled) and every rule before actually enabling or reloading the firewall, so the one command that would cut off a remote session — enabling a default-deny firewall with no rule in place yet — structurally can't happen from output this tool produces.
Why rule order is handled automatically
The classic way to lock yourself out of a remote server is enabling a default-deny firewall before an SSH rule exists. This tool sorts any SSH-related allow rule to the front of the generated sequence regardless of the order you added rules in, and always places ufw enable or firewall-cmd --reload last — so copying the output top to bottom is safe by construction, not just by convention.
FAQ
Why does the SSH rule always end up first in the generated commands?
Because it's structurally the only order that can't lock you out: every allow/deny command is emitted before the firewall is actually enabled or reloaded, and the SSH-related rule specifically is sorted to the front of that group. As long as ufw enable or firewall-cmd --reload is the last command run, remote access is never cut off partway through.
Why does firewalld use a rich rule instead of --add-port when I set a source?
firewalld's plain --add-port applies to any source address — it has no concept of "this port, but only from this address" on its own. A rich rule is the mechanism that adds a source restriction, at the cost of a more verbose command.
What's the difference between deny and reject?
This tool's deny maps to firewalld's reject, which sends back an explicit rejection response — the connecting client finds out immediately that it was refused. The alternative, drop, silently discards the packet with no response at all, which is slower for an attacker to notice but also slower to debug when it's your own legitimate traffic being blocked.
Does this tool check that the ports I'm opening make sense together?
No — it only builds correct syntax for the rules you specify. Deciding which ports actually need to be open for a given server's role is a judgment call this tool doesn't make; see the Linux Hardening Checklist Generator for the broader default-deny-then-allow-only-what's-needed reasoning.
Does this tool run these commands for me?
No — it only generates the command text. Copy it into your own terminal; nothing here touches a real firewall or server.
Try it yourself
For the reasoning behind default-deny and which ports a server actually needs open, see Linux Firewall Guide or the complete picture in Linux Security.