We’ve all done it before, removed a system from our network without thinking twice about what changes need to be made to the firewall. As long as the replacement is up and working without any issues what’s the problem? Often we may even copy the rules of the previous system to make sure that we have the proper communication, but do we ever really remove the old rules? Or do we leave stale rules in our firewall “just in case” that system needs to be turned on or put back into production? In this post we will discuss the dangers of leaving firewall rules in place when decommissioning a server, and some best practices for removing them.
- One of the biggest dangers of not removing the rules within a firewall is, of course, that it allows for misconfigurations in your network which could be abused by cyber attackers. It’s one of the most common threat exploits and it gives hackers access to systems that you thought were locked down.
- Additionally, retaining firewall rules related to decommissioned applications either disabled or active, gives a potential new system, which will reuse its IP address in the future, additional access that it shouldn’t have. The original rules were created for another system with dedicated access to communications and are most likely not relevant for the new system. Yet, by keeping the old rules active in the firewall it allows access to or from the new system too. I’ve seen many issues arise where access into sensitive zones, egress to the internet, or misconfigurations were created because of these oversights.
- When making firewall changes do you know if the system in question uses NAT? NAT allows public access into the network, so it pretty much gives that IP address a public presence on your network. When you decommission an application make sure to remove the NAT too.
- If rules from decommissioned applications aren’t deleted they will start adding up within your ruleset and create unnecessary bloat. In addition, each packet will have to pass by these unnecessary rules too, which will impact performance. While this is not specifically a security issue (unless there’s a DDoS attack and the firewall has to work much harder to process every single packet), these rules should be removed from an operational and performance management standpoint.
So what should you do?
- Perform audits on your rulesets and look for rules that haven’t been hit in a while. Using tools like AlgoSec allows for an automated review of the rulesets including identifying unused rules and objects.
- Make sure the distribution of IP addresses is properly managed and controlled, especially static addresses, and assign specific IP addresses as needed, rather than DHCP ranges, for new systems. This will prevent someone from putting an IP on the network that was previously used by a decommissioned application, and thereby risk adopting its old rules which may still be in the firewall.
- The most important step of all is to create process for removing systems once they’re pulled off the network. This is something that is often forgotten since it’s out of sight, but a proper decommission process, including the removal of firewall objects or rules must be part of the process. This cleans up the firewall and doesn’t allow any inherited access from a new system, which will use the same IP address in the future.
Overall this process is somewhat straightforward. It might take some work up front, but will pay for itself later on with cleaner rulesets and tighter security. Without these best practices you could be allowing security vulnerabilities into your network, opening the door for hackers or for internal resources to abuse the access these systems were given in the past. Having a ruleset that allows data to only the systems they’re intended for is the reason we have firewalls to begin with. Let’s not circumvent security by having stale or unnecessary rulesets.
Subscribe to Blog
Receive notifications of new posts by email.