Firewall Drift: Keeping Rules Consistent Across Servers

When each server has its own firewall, each one gets set up on a different day, by whoever was around at the time. A port gets opened on one server to fix something urgent and never closed. A rule gets added to two servers, and the third is forgotten. Nobody notices until something gets through, or something legitimate gets blocked.

That gradual divergence is firewall drift. This guide shows how to spot it, decide which rules are correct and keep every server in line from now on. If you want a refresher on how rules work, start with firewall rules in the glossary and our guide to firewall rules and security groups.

How drift happens

Drift is rarely one big mistake. It builds up from small, reasonable changes.

Urgent fixes. A port is opened to get a service working at 11 p.m., with a plan to tidy up tomorrow.

Partial rollouts. A new rule is added to the servers someone remembered, not all of them.

Copied servers. A new server is set up by copying an old one's rules, including the temporary exceptions.

Different tools. One server uses iptables directly, another uses a control panel's firewall, a third uses firewalld, and nobody compares them.

Each change makes sense on the day. Together they leave you with servers that are supposed to be identical but are not.

The quick check

Export the rules from each server and put them side by side.

• iptables: iptables -S prints the full rule set
• nftables: nft list ruleset
• firewalld: firewall-cmd --list-all --zone=public (repeat for each zone you use)
• Control panel firewalls: export or screenshot the rule list from the panel

Save each output to a file named after the server, then compare them. On Linux, diff web01.txt web02.txt shows every line that differs.

Any difference you cannot explain is drift. Some differences are intentional, such as a database server allowing port 3306 when web servers do not. Those should be written down, not discovered.

If you would rather hand firewall hardening to engineers, it is part of the managed services included on every InMotion Cloud plan.

Decide which rule set is correct

Once you can see the differences, decide what each server role should allow. Work role by role, not server by server.

List the roles. Web server, database server, mail server, admin or jump host.

Write the rules for each role. Which ports, from which sources. For example, web servers allow 80 and 443 from anywhere and SSH only from the office or a jump host. Database servers allow 3306 only from web servers.

Deny everything else. A default deny with named exceptions is easier to keep consistent than a default allow with blocks bolted on.

Note every exception and why. If one server genuinely needs something different, record it next to the rule.

Keep it fixed

Fixing drift once is easy. Keeping it fixed is the real work.

Save the correct rules in one place, outside any single server. A file in version control is ideal. It records who changed what and when.

Apply rules from that file, not by hand. A configuration management tool applies the same rules to every server in a role. Our guide to configuring servers with Ansible shows the approach.

Make every change in the file first. Urgent fixes included. If something has to be opened at 11 p.m., change the file and apply it, so tomorrow's tidy-up is a single edit.

Recheck on a schedule. Run the comparison monthly, or automatically, so new drift is caught while it is small.

One thing to do this month

Decide which rule set is correct for each role, save it in one place outside any single server, and from now on, apply every change there first. Even before you automate anything, that one habit stops most new drift.

How InMotion Cloud handles this

On InMotion Cloud, firewall rules for your servers are handled with security groups. You define a group once, such as "web" or "database", and attach it to every server in that role. Change the group, and every server attached to it changes at the same time. New servers get the right rules the moment they are launched with the group attached. Our guide to managing security groups and rules shows how.

Rules inside each server's operating system are still yours to manage, and our engineers can help you line those up with the security groups.

Summary

Firewall drift builds up from small, reasonable changes until servers that should match no longer do. Export and compare rules to find it, decide the correct rules by role, keep them in one place outside any server and apply every change from there.

Frequently asked questions

What is firewall drift? The gradual divergence of firewall rules across servers that are meant to be configured the same way, usually caused by one-off fixes and partial changes.

How do I compare firewall rules between servers? Export each server's rules with iptables -S, nft list ruleset or firewall-cmd --list-all, save them to files and compare them with diff.

Should every server have the same firewall rules? Every server in the same role should. Different roles, such as web and database servers, need different rules, and those differences should be written down.

How do I stop drift from coming back? Keep the correct rules in one file outside any server, apply them with a configuration tool or security groups, and make every change there first.