Conflicting firewall rule sets can make policing your network a nightmare. Here's how to keep traffic flowing smoothly.
Imagine bearing down on a busy intersection. A traffic cop is furiously waving you on, but as you approach, you notice he's also waving on traffic from the cross street with his other hand. In the ever-changing business environment, this is what security managers face every day: increasingly complex and dynamic enterprise networks, where the left hand doesn't know what the right hand is doing.
Administering additional access control devices and maintaining consistent firewall rules throughout this evolving labyrinth can be a nightmare. Layered controls, multiple network entry points and tools that trigger automated changes conspire to produce conflicts and holes in your rule sets, which can impede and shut down legitimate business traffic and expose your enterprise to attack.
But, if you understand how access control rule sets get confused and follow industry best practices to maintain consistency, you can keep your network traffic flowing smoothly.
A tiered architecture built on multiple layers of access control provides a strong defense-in-depth strategy. But, this approach is only effective if the rules are consistent and you have established processes and policies. Poor planning, inadequate change control and lack of communication can turn layered access controls into security liabilities.
Well-designed ordering of rules among tiered devices is critical. Adding or modifying rules requires careful analysis and controlled change processes to avoid conflicts (see "Firewall Rule Conflicts," right). For example, if an upstream device blocks traffic or closes a port that a downstream device allows, the latter rule will never be activated, making it superfluous at best. There are endless permutations of these types of conflicts, which can disrupt your business and leave undetected gaps in your defenses.
|Firewall rule conflicts|
Inconsistent firewall rule sets can cause problems in your increasingly complex and dynamic enterprise network.
Despite your best efforts, rule sets will degrade over time. At least quarterly, devices should be tested for integrity, configuration errors and firewall rule set consistency.
The most accurate--albeit the most tedious and resource-intensive--testing is to compare hard copies of the current rule sets to those set out by the policy and look for discrepancies. By also running a vulnerability assessment scan against the firewall, you should find most rule discrepancies.
Multiple Entry Points
Networks have evolved from a single point of Internet entry to a porous conglomerate of external connectivity. The most important step in managing multiple firewalls is the initial build and configuration: Each firewall must be fully documented to provide a baseline description against which subsequent changes can be tracked.
Also, each firewall must provide the least amount of access required for business functions. For example, an external supplier's entry point should be restricted to the resources necessary for the transaction, such as specific Web sites and databases.
NAT and VPNs further complicate the management of multiple firewalls. When they coexist on the same device, NAT and VPN rules must be compatible with firewall rules.
Case in point: The firewall closest to your private network usually contains the NAT rules. However, if you want all of the tiered firewalls to differentiate between users, the outermost Internet-facing firewall needs to have NAT functionality, which could add complexity to setting up the networks between the firewalls.
Similarly, if your internal firewall performs VPN authentication, the outer firewalls can't see any of the traffic. If you want the outer firewall to handle VPN traffic so it's processed at the perimeter, you should create a secure channel between firewalls so sensitive data isn't compromised.
Central management tools deal with multiple network entry points by enabling security managers to create, modify and track rules across multiple firewalls. Commercial tools will allow you to centrally manage rule sets, configuration, NAT, VPN, log correlation and aggregation, and centralized response to attacks in heterogeneous environments.
Centralized policy management systems often provide version control, allowing you to save and track changes in security policies. Managers need to know what was changed, when, and by whom in order to roll back to any given version and deploy that configuration to a running firewall.
While automation can be a godsend, it can also be a curse for security administrators.
IPSes and other active-response security products can automatically modify access control rule sets--an administrative nightmare when you're trying to keep rules consistent. We've seen cases where automated firewall changes have accidentally caused denial-of-service attacks; worse yet, a savvy attacker could actually launch a DoS by triggering thousands of new rules to be added. Both force lengthy and costly cleanup processes. An attacker could also send spoofed IP addresses of legitimate users, which the automated defense would block, denying access to the users in the process.
Ideally, you never want to allow automated changes. But in very large enterprises where attacks can take down networks in seconds, properly monitored automated changes can be used--in a controlled setting.
Our advice: Tread very cautiously. This type of automated modification violates the idea of a configuration control board instituting formal changes to the rule set. Rather, you should have security devices set to present the modification and let the analyst decide whether to implement it. This requires a security operations center that is staffed full time by analysts ready to respond and make these decisions--a caveat for businesses with tight budgets.
Your job will be a lot easier--and your systems more secure--if you follow the basic guidelines for access control rules.
As the first line of defense, you must apply a default deny to your firewalls. Unless a service or connection type is expressly permitted, it should be prohibited. This will block most white-noise traffic from even getting onto the network.
Rule sets should be as specific as possible with regard to the network traffic they control--source/ destination IP addresses, source/destination port numbers, applications information (for a proxy), etc. The trick is to make your rules broad enough to block all of the unwanted traffic, but not so broad that you also block legitimate traffic by mistake.
Finally, keep it simple. Rule sets should have a minimal number of rules to avoid accidentally introducing holes in access control. Complex rule sets make it tough to figure out what is allowed and what is denied.
Security is complex enough without introducing errors and vulnerabilities on your own. Keep your firewall rules on the straight and narrow, and your networks will be more secure.