Firewall rules that provide access to a wide array of services in a large network, while at the same time securing the critical assets from attacks, tend to become very large in size and redundant in functionality. As rule bases become large, administrators become hesitant to modify existing rules and instead add new rules for fear of causing an adverse impact on existing service availability. Over time, rule bases become very bloated, requiring not only more effort in making changes but also having an adverse impact on the firewall performance. It is therefore essential to clean up the rule base and reduce its size. This paper presents some techniques to cleaning up the rule base along with an effective solution that addresses these automatically for you using Athena FirePAC for Firewall Rule Cleanup.
Effective Solutions for Firewall Rule Cleanup
Using Athena FirePAC
Abstract Firewall rules that provide access to a wide array of services in a large network, while at the same time securing the critical assets from attacks, tend to become very large in size and redundant in functionality. As rule bases become large, administrators become hesitant to modify existing rules and instead add new rules for fear of causing an adverse impact on existing service availability. Over time, rule bases become very bloated, requiring not only more effort in making changes but also having an adverse impact on the firewall performance. It is therefore essential to clean up the rule base and reduce its size. This paper presents some techniques to cleaning up the rule base along with an effective solution that addresses these automatically for you using Athena FirePAC for Firewall Rule Cleanup. Introduction Firewalls protecting enterprise networks with an already complex web of inter-connections will inevitably grow more complex because of the need to add rules in order to provide network access and protect against attacks. Ideally, rules would be added to the firewall in an organized manner. Furthermore, rules would be organized and enhanced to suit specific business purposes. Unfortunately, that is not reality. Firewall administrators change; as new people transition into the role, rules are added in an ad hoc manner without realizing that the new rules are redundant and not needed in the first place. Moreover, as the rule bases become large, firewall administrators become hesitant to modify existing rules and instead add new rules for fear of causing an adverse impact on existing service availability. This makes the problem even worse and the job of administrators very difficult if they have to address issues raised during firewall or PCI audits. Here are some of the things that administrators should pay attention to to address the rule bases from becoming large and redundant: . New generalized rules are added that replace a number of more specific rules that already exist in the firewall. This typically happens when specific rules are added initially to the firewall to allow services to specific hosts or subnets and then more general rules are added when the business scope expands to other networks or services or much larger subnet or services (sometimes "any" network or service). When this happens, the previous specific rules become redundant and need to be cleaned up. . New rules are added without realizing that one or more rules preceding or succeeding the new rule already handle the functionality being addressed by the new rule. Depending on where the rule is added, the new rule might never be triggered. This happens when there are multiple rules in the rule base that each cover portions of the new rule and together completely cover the new rule. As a general practice, before adding new rules, existing rules should be queried to see if they can be modified to satisfy the change request. Change requests do not happen in a vacuum, they are made to serve a business purpose that probably already exists and is being enhanced. . New rules are added as a special case of one or more subsequent rules to exhibit special behavior (often temporarily). These special cases include enabling or disabling logging only for specific hosts or services instead of the much large networks or services being handled by the subsequent rules, performing application inspection for specific services involving specific assets, tracking quality of service attributes, and requiring user authentication for specific services or assets. Sometimes special cases are created at the beginning of the ruleset for the most used traffic to increase firewall performance. Some of these rules are temporary in nature, sometimes added to track usage or do some testing; however these are not cleaned up even when the reason for adding these in the first place is no longer relevant. . Rules become stale when the business reason for adding the ru... [download for more]
