Automatic detection of firewall misconfigurations using firewall and network routing policies

Transcription

1 Automatic detection of firewall misconfigurations using firewall and network routing policies Ricardo M. Oliveira Sihyung Lee Hyong S. Kim Portugal Telecom Carnegie Mellon University Portugal Pittsburgh, PA Abstract Firewalls are the most prevalent and important means of enforcing security policies inside networks and across organizational boundaries. However, effective and fault free firewall management in large and fast growing networks becomes increasingly more challenging. Firewall security policies are complex and their interaction with routing policies and applications further complicates policy configurations. It is often that routing is ignored in firewall management. Configuration problems can occur in a device or multiple devices along several network paths that change over time according to routing. We present an application, Prometheus, which implements mechanisms for automatic detection of firewall configuration problems that are extremely difficult to resolve manually. In addition to firewall configurations, Prometheus incorporates and analyzes dynamic routing information. We believe that the routing information is critical to obtain the complete view of the network and cannot be ignored for firewall configurations. We test Prometheus in a large production network and report its effectiveness. Prometheus is currently being deployed in the production network. Keywords: Distributed systems; networking and networked systems; performance and QoS; reliability, availability, and safety; security; self-managing systems. I. INTRODUCTION Firewalls are the most common method of maintaining a degree of security in connections between different segments of a network and also in connections between these segments and the Internet. Although this type of device is extremely effective in enforcing security policies when deployed with a sound design and topology, ensuring a consistent, conflict-free global security policy becomes a daunting task in a large corporate network, where many different sections of the network are managed by different organizational units, with their own staff and goals. This complexity results in a number of misconfigurations, leading to security and connectivity problems that prevent business from proceeding as usual. In addition to the complexity of managing a network of firewalls, the process of ensuring their correctness is even more complicated due to subtle interactions between firewall configurations and the dynamics of routing. Configuration problems occur between firewalls of different devices placed along a network path, and such a distributed problem might surface only in a particular routing state. Fig. 1 illustrates an example of a corporate network, where firewall problems are This work is supported in part by ICTI. caused by a routing change. This network is divided into two zones. Zone 1 represents an additional layer of protection of the internal network; zone 2 is safe even when zone 1 is compromised. When there is no failure in the network, Host F communicates with Host G via the primary path (F, A, C, D, G). Packets between these two hosts go through three firewalls (F3, F4, F5). However, when the link between A and C goes down, the routing may forward the same flow of packets via the shortest available path (F, A, B, D, G), passing through zone 1, rather than staying within zone 2 using the other available path (F, A, E, C, D, G). This rerouting has two undesirable effects, which might be inconsistent with the intended policies. First, the packets between the two internal hosts F and G go through the less secure zone 1. Second, these packets go through a different set of four firewalls (F3, F1, F2, F5), which may prevent the packets from reaching their destinations, due to the lack of proper firewall rules. To detect this type of inconsistencies, we need to consider routing as well as firewall configurations. Particularly in a large, growing network with a complex topology, keeping track of all of the possible sets of routes can be extremely time-consuming and inaccurate, without an appropriate tool. Zone 1 Zone 2 F3 Host F F1 A LAN segment E Internet B F4 C F2 D Host G Figure 2. An example of a network of firewalls. Zone boundary F5 LAN segment There are numerous works on misconfiguration detection in firewalls, some of which also discuss the impact of routing [1,2,3,4,5]. However, these works either do not describe the details on how to infer routing changes, or they require a manual input of a set of possible routes, considering that routing is fully known beforehand and predictable. Our system, Prometheus, differs from the previous works in that it detects

2 firewall misconfigurations by analyzing dynamic routing information in addition to device configurations. Based on these two information sources, Prometheus builds a model of firewall policies, an accurate view of network topology, and its possible routes. Prometheus then performs a static analysis to identify possible misconfigurations. We summarize our contributions as follows. To the best of our knowledge, our work is the first to include dynamic routing information in the model, allowing automatic discovery of a set of possible routes and detection of misconfigurations according to these routes. Routing information is directly obtained from equipment s routing tables. We deploy Prometheus in a production network of a large European provider. The network segment chosen for our evaluation is a representative of a large, complex, and constantly changing environment. This segment includes servers of critical applications in the network, the connections to all other applications with which these applications interact, and clients of these applications. The 30 nodes in the segment are composed of routers and firewalls from several different vendors, and has a high degree of connectivity, represented by 350 firewall rule sets applied to individual interfaces and a total of nearly 12,000 firewall rules. Although Prometheus uncovered only a few misconfigurations since the critical segment has been audited on a regular basis, the evaluation has shown its good performance (Section V). Prometheus also received extremely positive feedback from the network administrators. Misconfigurations in firewall rules are often caused by other rules, either within the same firewall or in a different firewall. Prometheus automatically locates these sources of a misconfiguration (Section IV.C), which can significantly reduce the time to correct misconfigurations. For example, in the path (F, A, C, D, G) as shown in Fig. 1, a rule in F3 may accidentally disallow packets that are allowed by a rule in F5. Although most of the previous works only identify the rule in F5 as being ineffective, Prometheus also highlights the rule in F3 as a culprit of this ineffectiveness. This identification algorithm adds only a constant time to the original detection algorithm. In addition to the detection of misconfigurations and the identification of their respective causes, Prometheus suggests corrective actions for the detected problems based on these causes (e.g., modify the rule in F3 so that this rule does not drop the particular set of packets that are supposed to be allowed) (Section IV.D). Prometheus offers a mechanism to test connectivity between any arbitrary pair of nodes in a network (Section IV.E). For example, given two nodes F and G as shown in Fig. 1, Prometheus can determine whether a particular set of packets can cross the network from F to G, where it fails, and why. This feature is greatly appreciated by the network operators. FIREMAN [1], a firewall misconfiguration detector, defines the basic algorithms and concepts for misconfiguration detection that we use. Their work successfully detects errors in firewalls over the rules within a single firewall as well as rules in a network of firewalls. Unlike FIREMAN, Prometheus automatically incorporates routing information, and determines the rules that triggered misconfigurations. Prometheus also uses a larger testbed, allowing us to perform a more realistic and exhaustive analysis. The remainder of this paper is organized as follows. In Section II, we describe our network model. In Section III, we present an overview of misconfigurations that Prometheus detects. In Section IV, we detail the method of misconfiguration detection using routing information. The evaluation setup, results, and positive feedback from the operators are presented in Section V. Finally, we conclude in Section VI. Node ID Node Type Routing Table Routes : one-to-one : one-to-many II. NAT Table NAT rules MODEL OF NETWORK Network Node Interface IP address Neighbor firewall Outbound firewall firewall rules Figure 3. Network Model Node ID Interface IP Inbound firewall firewall rules Our network model is composed of nodes that represent a router, a Layer 3 switch, or a firewall box as shown in Fig. 2. Different nodes are interconnected through interfaces, according to the network topology. Each node has a routing table, a Network Address Translation (NAT) table, and one or more interfaces. Interfaces may connect to a neighbor node s interface. Each interface is assigned an IP address and two firewalls, one for inbound traffic and the other for outbound traffic. To build the network model from configurations of a wide variety of devices from different manufactures, we use Nipper [6], a network configuration parser that supports several vendors devices. Routers and switches usually apply a set of firewall rules to each interface in each of the two directions, ingress and egress. In the case of a firewall with a single set of firewall rules and multiple interfaces, the same rule set is assigned to all of the interfaces in both of the directions. Table I presents an example of a set of firewall rules applied to an interface in a particular direction. We assume that given a packet, the rules are sequentially matched beginning rule number 1, and the first rule that matches the packet determines the action the packet takes. Note that the special object Any is used in the source and destination port columns,

3 representing any port numbers. Similarly, an IP address column can have a special object such as Any (any address) and Internet (any address from the Internet), instead of a particular IP address. TABLE I. EXAMPLE FIREWALL RULE SET Rule Source Destination Protocol Action no. IP Port IP Port /24 Any /24 Any TCP Deny /16 Any /24 Any TCP Accept /24 Any /32 Any TCP Accept /24 Any /32 Any TCP Accept /24 Any /25 80 TCP Accept /24 Any /25 80 TCP Accept 7 Any Any Any Any Any Deny III. MISCONFIGURATIONS In this section, we present an informal description of two types of misconfigurations that Prometheus detects: inconsistencies (Section III.A III.C), and inefficiencies (Section III.D). In Section IV, we define a formal framework to detect these two types of misconfigurations. A. Intra-firewall Inconsistencies Inconsistencies arise within a single firewall when some rules totally or partially mask other rules. These intra-firewall inconsistencies can be one of the three types: shadowing, generalization, and correlation. Shadowing: the rule currently being analyzed matches a subset of the packets that a previous rule matches, and the two rules define different actions. In Table I, rule 3 is shadowed by rule 1. The consequence of a shadowing is either a connectivity problem or a security problem, depending on the action of the masked rule. If the masked rule is an accept rule (e.g., rule 3), this masking is likely to cause a connectivity issue, since traffic that should be allowed to enter the network is rejected. If the masked rule is a deny rule, this masking can cause a security issue, since traffic that should be rejected is allowed to enter the network. Note that a rule can also be shadowed by a set of multiple rules that are previously defined. Generalization and Correlation: a subset of packets that the current rule applies to is matched by a previous rule, with different actions. If this subset covers the entire set of packets that the previous rule matches, the current rule is a generalization of the previous rule. If this subset covers less than the entire packet set of the previous rule, the current rule has a correlation with the previous rule. In Table I, rule 2 is a generalization of rule 1; the entire set of packets that rule 1 matches is also matched by rule 2. Generalizations and correlations are commonly used to act on a set of packets except its small subset. We therefore raise these inconsistencies as warnings rather than errors. B. Inter-firewall Inconsistencies The three types of intra-firewall inconsistencies can also occur among the rules in different firewalls along a path. For example, rule 1 in Table I can be configured in F4 in Fig. 1, and rule 3 in F5, shadowing rule 3 in path (F, A, C, D, G). Prometheus indentifies inter-firewall inconsistencies along a set of possible paths that are extracted from current routing state. We describe the way to extract these paths in Section IV.A. Unlike intra-firewall shadowing, we only raise a shadowed rule as a possible error if it is an accept rule (as shown in the previous example); we raise a deny rule as a warning. A deny rule further down a path can represent an increased level of security along the path. C. Cross-path Inconsistencies Cross-path inconsistencies occur when packets that are expected to travel a network through one path are actually diverted through another path. If the two paths have different security policies, the new path allows and drops different sets of packets from those of the original path, possibly contradicting the intended policies of the original path. A crosspath inconsistency is illustrated by the two paths between hosts F and G in Fig. 1: (F, A, C, D, G) and (F, A, B, D, G). D. Intra-firewall Inefficiencies Prometheus identifies two types of intra-firewall inefficiencies: redundancies and verbosities. Redundancies refer to rules which, if removed, do not alter the policies enforced by the firewall. In Table I, rule 4 is redundant; a previous rule, rule 2, accepts all the packets that rule 4 is supposed to accept. Verbosities are a set of rules that can be summarized in fewer rules. In Table I, rule 5 and rule 6 are verbose; these two rules can be replaced with a single rule, ( /24, Any, /24, 80, TCP, Accept). Redundancies and verbosities are not necessarily errors, so we raise them as warnings. Some redundancies are left in configurations for future use and verbosities for an improved level of readability. Redundancies can also occur among different firewalls along a path. We do not raise these interfirewall redundancies as errors. Inter-firewall redundancies often represent an additional layer of security; when an upstream firewall becomes compromised or faulty, a downstream firewall can still enforce the same policy as the upstream firewall. IV. METHOD OF DETECTION We detect misconfigurations in the following two steps. Step 1: for each pair of source and destination nodes we determine the set of possible routes between the pair of nodes (Section IV.A). This route set is derived from routing information obtained directly from network devices. Consequently, we detect misconfigurations with accurate routing information according to the current state of the network. Step 2: for each possible path, we detect intra- and interfirewall misconfigurations (Section IV.B). For each misconfiguration, we also identify rules that cause the

4 misconfiguration (Section IV.C) and suggest corrective actions (Section IV.D). We also detect cross-path inconsistencies for the entire set of possible paths given a node pair. Prometheus can also be used to test the reachability between any arbitrary pair of nodes in a network (Section IV.E). A. Route Discovery Given a pair of source and destination nodes, we determine a set of possible paths between the nodes from the network s current routing information. This set may not represent all of the possible paths, but the most likely ones, given the current state of routing. We can include more routes as we want to test different scenarios. Prometheus identifies a possible route set by using the Depth-Limited Search (DLS) algorithm [7], a special case of the Depth-First Search where the depth of search is limited. DLS finds a route set, if one exists within a specified depth limit. DLS s time complexity is O(b d ), where b is the branching factor of a graph and d is the depth of the graph. In our case, b is limited to the number of existing routes in the current state of routing, and d is limited to a specified value of 30, taking into account the fact that most of the Internet paths are less than 30 hops, with mean path length of 15.9 hops [8]. DLS s space complexity is O(d). The use of routing information and the depth limit improves the performance of the DLS algorithm, since it precludes the need for an exhaustive search over an entire network graph. We further enhance its performance by limiting the maximum size of a possible route set between a node pair; there may be a large number of valid routes but only a small subset is likely to be used. In our evaluation, we identify a full range of routes to measure the worst case performance. Another method of performance optimization is to take advantage of what we call Overlapping Path Segments (OPS). An OPS is a path segment where nodes are repeated between two paths. We reuse the models of firewalls on an OPS as well as their corresponding results of misconfiguration detection. For example, the two paths (F, A, C, D, G) and (F, A, B, D, G) in Fig. 1 overlap in the segments (F, A) and (D,G). These two OPSs include firewalls F3 and F5, and we therefore build their models only once and reuse these models to detect misconfigurations in both of the paths. More details can be found in our report [9]. B. ACL and Rule Definition Given a path, we analyze the firewalls on the path in the order they appear along the path. Within each firewall, we sequentially analyze each rule beginning with the first rule. We represent a firewall rule with a logical AND of five different variables: source and destination addresses (SrcAddr, DstAddr), source and destination ports (SrcPort, DstPort), and the protocol (Proto). Since each variable represents a range of values, a rule represents the set of packets accepted or rejected by the rule, depending on the rule s action. Rule i = SrcAddr i DstAddr i SrcPort i DstPort i Proto i To detect the misconfiguration of Rule i in a firewall, we maintain a few sets, each of which represents a particular set of packets: I represents the input set to the firewall. A i and D i represent the set of packets that are accepted and rejected before Rule i, respectively. R i = I (A i D i ), which represents the set of packets that are neither accepted nor rejected before Rule i and therefore can be evaluated against Rule i. In the beginning of the process, when the first rule of the first firewall on a path is evaluated, A i = D i = and R i = I. After each rule is processed, R i is adjusted as previously defined, and A i and D i sets are updated according to the following operations: if Rule i is an accept rule, A i+1 = A i Rule i, and if Rule i is a deny rule, D i+1 = D i Rule i. When the last rule of the firewall is evaluated, the resulting A i set represents the input set I for the next firewall on the path. In case a NAT exists before the next firewall, we modify the input set by applying its NAT rules. We detail the handling of NAT rules in our report [9]. While updating the A i, D i, R i, and I sets, we identify misconfigurations according to the following rules. O i denotes the packet set matched by previous rules with the opposite action of Rule i s action. In other words, O i is { A i, if Rule i s action is deny. D i, if Rule i s action is accept. 1) Rule i R = : Rule i is masked by previous rules. (a) Rule i O i : Rule i is shadowed. (b) Rule i O i : Rule i is redundant. (c) Otherwise, Rule i is correlated with previous rules. 2) (Rule i R) (Rule i R ): Rule i is partially masked. (a) (Rule k Rule i, k < i) (Rule k O i ): Rule i is a generalization of a previous rule Rule k. This check does not require iterating over all previous rules but it suffices to check only the rules in Rule i O i. These rules are identified by using the numbered sets as described in Section IV.C. (b) Rule i O i : Rule i is correlated. C. Identifying the Source of a Misconfiguration Given a misconfiguration of a firewall rule Rule i, we determine the rule(s) that caused this misconfiguration using two new sets: A i and D i sets augmented with their associated rule numbers. These augmented sets are denoted by A i_numbered and D i_numbered and are updated the same way as A i and D i sets are updated, except that Rule i is replaced with its augmented set Rule i_numbered = (RuleNumber i Rule i ). For example, if Rule i is a deny rule, D i+1_numbered = D i_numbered Rule i_numbered. When Rule i is identified as being partially or fully masked, we extract the rule number of the rules that mask Rule i by computing a new set, (Rule i O i_numbered ). Table II presents an example of a firewall rule set and its Rule i_numbered in the last column. For ease of exposition, we do

5 not present Rule i with all of the five fields in a packet (IP addresses, port numbers, and protocol). Instead, we abstract Rule i as a single range of integer values (e.g., 0 y 4). Note that rule 3 is shadowed by the two previous rules. When rule 3 is evaluated, the augmented deny set D 3_numbered is the union of the augmented sets of Rule 1 and Rule 2, i.e., D 3_numbered = Rule 1_numbered Rule 2_numbered = [(x=1) (0 y 4)] [(x=2) (5 y 6)]. We then compute the set (Rule 3 O 3_numbered ) = (Rule 3 D 3_numbered ) = [(x=1) (y = 4)] [(x=2) (y = 5)]. This set precisely shows that rule 1 and rule 2 shadows rule 3 s packet range (y = 4) and (y = 5), respectively. Rule no. (x) TABLE II. EXAMPLE OF NUMBERED RULE SET Rule i (y - range of packets) Action Rule i_numbered (x y) 1 0 y 4 Deny (x=1) (0 y 4) 2 5 y 6 Deny (x=2) (5 y 6) 3 4 y 5 Accept (x=3) (4 y 5) D. Suggesting Solutions Suggesting corrective actions for detected misconfigurations is not a simple task and must be carried out with caution to avoid causing further configuration problems. We offer a set of suggestions, and inform about the advantages and disadvantages of each suggestion, leaving a decision up to network operators. These suggestions have one of the three forms: removal, reordering, and modification of a rule. For example, upon the detection of rule 1 s shadowing rule 3 as shown in Table I, the suggestions are: 1) Verify the intended policy. 2) If rule 1 is the intended policy, remove rule 3. If rule 3 is the intended policy, (a) Modify rule 1 to to remove the set that conflicts with rule 3. This can increase the number of rules by (b) Move rule 3 to before rule 1. This can shadow another rule, rule x, so you need to move rule x to before rule 3 as well. In addition to suggesting solutions, we check whether executing a set of suggested actions can cause other misconfigurations. For example, the reordering of a shadowed rule leads to another misconfiguration if this rule in a new position shadows another rule. To account for this problem, after determining a possible course of actions, a second verification is carried out, including suggested changes, to determine whether other misconfigurations surface. E. Detecting Flow Connectivity Issues When a new application is installed in a large corporate network, a practical issue is to determine whether the application server is accessible from different locations of the network. If these locations are several devices away from the server, unforeseen errors may cause connectivity to fail. Prometheus allows a network operator to simply detect these connectivity problems by leveraging its route discovery and misconfiguration detection functions. Given a pair of source and destination nodes and their flow description (IP addresses, Port numbers, and protocol), Prometheus first computes a set of possible routes between the nodes. It then updates the accept set A i along each path, according to the algorithm described in Section IV.B. If the flow belongs to the resulting A i, there is no connectivity issue. Otherwise, Prometheus pinpoints the firewall rules that reject the flow by using the numbered sets as described in Section IV.C. V. EVALUATION We implement Prometheus and evaluate it with firewall configurations from a large European provider. The testbed is a section of the provider, which contains a total of 30 nodes with more than 350 firewalls and nearly 12,000 firewall rules. The nodes in the network have a high degree of connectivity, with a mean degree of 6, with 90-th percentile of 12 and 10-th percentile of 2.5. Equipment vendors include Cisco (different versions of Cisco IOS, PIX, FWSM, and Catalyst software) and CheckPoint [11]. The implementation is written in approximately 12,800 lines of C++ codes. The total running time is slightly over 15 minutes, and the memory usage never reached 45 MB, over all of the possible source-destination pairs in the network. These pairs have a total of 121,329 possible routes according to the network s routing information. The implementation is run on a machine with a CPU of 2.8GHz and 2GB of memory. Although we implement the optimization algorithms as described in Section IV.A, the code can be further optimized if a faster runtime is required. The complexity of the interfirewall misconfiguration detection procedure between a source-destination pair is linearly proportional to n f n p, where n f is the number of firewalls on a path and n p is the number of paths between the two nodes. The complexity is also linearly proportional to the number of rules within each firewall. The implementation uses BuDDY [10] to represent packet sets. The implementation has an easy-to-use GUI, which allows visualization of a network topology and a current state of routes, highlighting inconsistent and inefficient rules as well as the rules that cause these misconfigurations. By pinpointing the origin of misconfigurations, the interface also suggests a course of actions for their correction. The initial input set I for rule checking, is the full range of traffic possible, unless we know the specific input set for the node being checked. A. Misconfigurations Discovered Table III presents the intra-firewall misconfigurations detected by Prometheus. We show only the nodes that have misconfigurations. In the table, S, G, C, R, and V represent shadowing, generalization, correlation, redundancy, and verbosity, as defined in Section III. We detect only a small number of inconsistencies despite the large number of firewalls. There are two main reasons for this small number of inconsistencies. First, according to an internal policy of the organization, the filtering rules are subject to an audit process routinely, in order to remove existing inconsistencies and

6 TABLE III. INTRA-FIREWALL MISCONFIGURATIONS DETECTED Node # of # of Inconsistencies Inefficiencies no. firewalls rules S G C R V inefficiencies. Second, the software used to configure firewalls has become increasingly intelligent and detects and notifies operators about certain types of intra-firewall inconsistencies on rule compilation [11]. We execute the inter-firewall check over a full route set with nearly 120k possible routes. The check uncovers seven misconfigurations: six redundancies and one shadowing. The redundancies correspond to an added level of security. The one shadowing does not jeopardize connectivity but has a negative impact; the shadowed rule is supposed to accept ICMP requests from a set of host, and therefore the misconfiguration causes any ICMP request to be dropped, unlike the desired behavior. VI. CONCLUSION The configurations of firewall security policies are complex by themselves and their interaction with routing policies and applications further complicates the configuration, often creating security and connectivity problems. We propose Prometheus, a system for diagnosing these problems by analyzing not only firewall configurations but also dynamic routing information, crucial for obtaining a complete view of a network. We also define a set of optimizations that improve the scalability of our solution, enabling it to cope with large networks with a number of nodes and filtering rules. We implement Prometheus and evaluate it with firewall configurations and routing policies from a large provider network. The system detects several real inter- and intrafirewall misconfigurations quickly and accurately, according to the current state of routing. We give a presentation and a demonstration of Prometheus to several major IT personnel responsible for managing the network. Their reaction is extremely positive, and they are very interested in the results obtained, wishing to analyze them further, as well as to expand the testbed to a larger segment of the network. Currently, they are in the process of developing a full-blown application of Prometheus, based on our implementation. In addition to the correction of inconsistencies, the elimination of inefficiencies is also important to the network operators since redundant and outdated configurations can have a significant impact on the performance of network devices, particularly when a large number of packets need to be filtered. The operators also consider other practical features to be valuable, such as the verification of flow connectivity and the construction and visualization of network topology and its routes. Given a flow that has a problem, the connectivity verification function quickly pinpoints the location of the failure. The automatic generation of network topology and its routes allows operators to keep an accurate, latest view of their network, eliminating the need to update documents about their network. One potential use of this work, taking advantage of its use of routing information, is to verify a variety of security policies associated with flows and their corresponding routes. For example, assume that we define a policy that enforces a high level of security for a flow with critical traffic all of the paths where this flow goes through must have firewalls configured in every hop along the paths. Prometheus can find a path that violates this policy by using its automatic route discovery and flow connectivity test (i.e. a path that carries the critical traffic but has firewalls on only a few of the hops). The solution to this problem is either to add necessary firewalls on the violated path or to reroute the traffic through another path that implements the policy. When the rerouting option is chosen, Prometheus can give information about a set of paths through which the traffic can be rerouted. REFERENCES [1] L. Yuan, J. Mai, Z. Su, H. Chen, C. Chuah, and P. Mohapatra, FIREMAN: a toolkit for firewall modeling and analysis, in Proc. IEEE Symposium on Security and Privacy, pp , [2] Y. Bartal, A. Mayer, K. Nissim, and A. Wool, Firmato: A novel firewall management toolkit, in Proc. IEEE Symposium on Security and Privacy, pp.17-31, [3] A. Mayer, A. Wool, and E. Ziskind, Fang: A firewall analysis engine, in Proc. IEEE Symposium on Security and Privacy, pp , [4] E. Al-Shaer, H. Hamed, R. Boutaba, and M. Hasan, Conflict classification and analyssi of distributed firewall policies, in IEEE Journal on Selected Areas in Communications, vol. 23, no. 10, pp , Oct [5] J. Alfaro, N. Boulahia-Cuppens, and F. Cuppens, Complete analysis of configuration rules to guarantee reliable network security policies, in International Journal on Information Security, vol. 7, no. 2, pp , Apr [6] Nipper Network Infrastructure Parser. Available: [7] S. J. Russel and P. Norvig, Artificial Intelligence: A Modern Approach, 2 nd ed., NJ, Upper Saddle River:Prentice Hall, [8] V. Paxson, End-to-end routing behavior in the Internet, in IEEE/ACM Transactions on Networking, vol. 5, no. 5, pp , Oct [9] R. Oliveira, Prometheus: Operational optimization of firewalls in large corporate networks, Msc. Thesis, Carnegie Mellon University, [10] J.Lind-Nielsen, Buddy version 2.4. Available: [11] CheckPoint Firewall, VPN, Network Security, Endpoint Security, Data Security, Security Management and PointsecData Encryption.