How do you handle a firewall rule nobody can explain?

Start with the rule's hit count and logs before touching it. If the counter is increasing, look at the source, destination and traffic to work out what is using it. If the existing count doesn't tell you much, record or reset it and check again over a suitable observation period.

No hits for 30, 60 or even 90 days is useful evidence, but it isn't proof the rule is unnecessary. It could be a standby path or something used only during a failover. Check for similar rules and ask the service owner about infrequent use before removing it.

Trace the flow from both ends. For an inbound rule, find out whether the destination server and service are still in use and ask their owner. For outbound traffic, identify the internal machines using it and check what they need it for. A packet capture may help if the logs don't make the traffic clear.

If the investigation still comes up empty, disabling the rule can be a practical test. Record the change in a ticket, make sure it can be restored, and watch for problems rather than deleting it and hoping for the best. Pick the timing carefully, especially if a rarely used service might depend on it.

For future changes, keep a versioned record of the firewall config and tie the rule to a ticket or reason where the equipment supports comments. Rancid and Oxidized can help capture config history, which makes it easier to spot when something changed.

History alone won't tell you why a rule exists, though. An approval process or a deployment pipeline can capture that context, and alerts on direct console changes can flag work that bypasses the process.