a complete independent field of research in firewall analysis, dealing with problems ..... However, it may be argued that as a firewall is a critical line of defense.
Modular Verification and Design of Firewalls Hrishikesh Bhatt Acharya
Abstract Firewalls, packet filters placed at the boundary of a network in order to screen incoming packets of traffic (and discard any undesirable packets), are a prominent component of network security. In this dissertation, we make several contributions to the study of firewalls. 1. Verification of the correctness of firewall policies is very expensive - the current algorithm uses O(nd ) space, where n is the number of rules in the firewall (several thousand) and d the number of fields in a rule (about five). Consequently, most firewalls are never verified, but only tested. This situation raises the question of whether it is possible to develop a less expensive firewall verification algorithm. In response to this need, we develop a fast firewall verification algorithm. Our probabilistic verification algorithm runs in time and space O(nd), in contrast to the O(nd ) of current algorithms, and determines whether or not a firewall F satisfies a property P . The algorithm is provably correct in several interesting cases - notably, for every instance where it states that F does not satisfy P - and the overall probability of error is extremely small, of the order of .005%. 2. As firewalls are often security-critical systems, it may be necessary to verify the correctness of a firewall with no possibility of error. In such a case, we cannot use a probabilistic algorithm, so there is still a need for a fast deterministic firewall verifier. In this dissertation, we present a deterministic firewall verification algorithm that uses only O(nd) space. The time complexity is still O(nd ), but we demonstrate experimentally with over two million test runs that in practice the algorithm is very fast, and requires runtimes of a few seconds to verify an industrialstrength firewall of 2000 rules.
3. In addition to the question of firewall correctness, another issue that is frequently studied is that of firewall performance and optimization. The reason for this is that a slow-running firewall can itself become a target of attacks, such as a denial-of-service attack. There exists a complete independent field of research in firewall analysis, dealing with problems such as the detection and removal of redundant rules. We demonstrate in this dissertation that in fact, there is a very strong connection between firewall verification and redundancy detection; an algorithm for one can be readily adapted to the other task. Based on this result, we suggest that our algorithms for firewall verification can be used for rapid redundancy detection and optimization of firewalls. 4. Our contributions to firewall verification and analysis require a preexisting firewall. The question naturally arises whether we can in fact develop techniques to enable the construction of a correct and efficient firewall at the design stage. In order to facilitate this goal, we suggest two metrics for the complexity of a firewall, and demonstrate a novel way to design firewalls: as a battery of simple firewalls, which we call modules, rather than as a monolithic sequence of rules. We also demonstrate how to convert an existing monolithic firewall into a modular firewall. We propose that the use of a modular design can help reduce the complexity of firewalls, making firewalls easy to design and easy to understand. Thus, this dissertation covers all stages in the life cycle of a firewall design, testing and verification, and analysis - and makes contributions to the current state of the art in each of these fields.
2
Chapter 1 Introduction The subject of this dissertation is the study of firewalls, security systems that act as a protective boundary between a private computer network and the “outside world (usually the rest of the Internet). A firewall is a packet filter that is placed at a point where a private computer network connects to the Internet. The firewall intercepts each packet that is exchanged between the network and the Internet, examines the headers of the packet, and based on a sequence of rules in the firewall, makes a decision concerning the packet: it may “accept the packet and allow it to proceed, or it may “discard the packet. As firewalls are a critical component of security for enterprises as well as for governments, considerable research has been devoted to the problems of firewall correctness as well as firewall performance. The study of firewalls can be divided into the following major sub-areas. 1. Firewall Design: Firewall design is the study of how to develop secure, compact, high-performance firewalls. In order to ensure that a firewall does not have vulnerabilities or other problems, it can be designed from the outset using structured algorithms. Such algorithms, that can generate a firewall from its specification, were developed by Gouda [1] and Liu [2]. In most cases, however, a legacy firewall is already present, and the administrator does not have the freedom to write a new one from scratch. Consequently, as a complement to the study of how to design firewalls, there is a field of study that concentrates on pre-existing firewalls. 2. Firewall Analysis: Firewall analysis involves the use of algorithms to 1
study pre-existing firewalls. Such study is focused on the detection of “anomalies”, such as conflicts (when two rules match a packet, but have different decisions), redundancy (when a rule can be removed from a firewall without affecting its operation), and so on. The concept of conflicts between rules in a firewall is due to Eppstein et al. in [3] and [4]. The concept of anomalies, as well as algorithms to detect them, was provided by Al-Shaer [5]. A framework for understanding the vulnerabilities in a single firewall is outlined by Frantzen [6], and an analysis of these vulnerabilities presented in [7]. Wool [8] provides a quantitative study of configuration errors for a firewall. An example of an efficient firewall analysis algorithm is given in FIREMAN [9]. An integrated analysis engine for firewalls in a network is given in Fang [10]. Unfortunately, firewall analysis by itself does not constitute a complete study of firewalls. Research in the field makes very general assumptions - for example, that the existence of conflicting rules is a problem in firewall design. In fact, a firewall may well be designed taking advantage of first-match semantics (i.e. the first rule to match a packet specifies the decision for the packet), and be concise and comprehensible because it makes liberal use of conflicting rules, as demonstrated by Gouda [1]. The aim of analysis is simply to identify the interesting features of a firewall. (These features may be important because they affect firewall correctness or performance.) Once these features are identified, the correctness of a firewall can be checked using testing and verification, and performance bottlenecks can be optimized (for example, by removing all redundant rules). 3. Firewall Testing: To test a given firewall F , one generates packets for which the “expected” decisions of F , accept or discard, are known a priori. The generated packets are then sent to F , and the actual decisions of F for these packets are observed. If the expected decision for each generated packet is the same as the actual decision for the packet, one concludes that the given firewall F is probably correct. Otherwise, the given firewall F has errors. A scheme for targeting test packets for better fault coverage is given in [11]. In [12], Al-Shaer et al. provide a complete framework to generate targeted packets so as to obtain good coverage in testing. 2
Testing is in fact commonly used because of its simplicity, but of course, testing cannot guarantee the correctness of a system (unless the testing is exhaustive, and covers all possible inputs). As a firewall may be a critical component of security, there has been some research in the field of formal firewall verification, which can ensure that a firewall is absolutely correct. 4. Firewall Verification: A verification algorithm takes a firewall F and a property R, and determines whether or not the firewall F satisfies the property R. The question of how to query a given firewall and obtain the answer (whether or not it satisfies a given property) is discussed by Mayer [10] and [13]. It is interesting to note that the work presented in this dissertation follows almost exactly the reverse of the order in which we present the fields of firewall study. In the next two chapters, we present our work on firewall verification - first, a probabilistic algorithm, then our deterministic linear-space firewall verifier, “Probe”. Next, we show how our work relates to firewall analysis, by demonstrating the connection between firewall verification and redundancy detection. Finally, taking inspiration from our method of projection and division, we propose a method to design firewalls in parallel “modules”, rather than as a single monolithic sequence of rules. We begin by describing our probabilistic verification algorithm in the next chapter.
3
Chapter 2 Probabilistic Verification The previous chapter served to introduce our concept of a firewall as a filter, that classifies incoming packets of data into two classes - packets to accept, and packets to discard. We begin this chapter with a discussion of the working of a firewall, and the concept of firewall verification. The decision that a firewall makes when it receives a packet depends on the values in the headers of the packet. Hence, for the purpose of modeling the operation of a firewall, we may simply consider a packet to be a tuple of header values (called fields). A firewall is a sequence of rules; each rule matches certain packets, with specific header values, and specifies the decision (accept or discard) to be made for that packet. In case there are multiple rules matching a packet, the first rule (according to the order of the rule sequence), that matches the packet, takes precedence. A firewall property is specified by a set of packets and a decision (accept or discard) that needs to be made by the firewall for all the packets in the specified set. A firewall is said to satisfy a property iff the decision made by the firewall for all the packets specified by the property matches the decision specified by the property. Firewall verification is the formal process of proving that a firewall satisfies a property. A verification algorithm takes as input a firewall F and a property P , and determines whether or not F satisfies P . The standard algorithm for firewall verification [1], by Gouda et al., involves the construction of a firewall decision diagram (FDD), a directed tree with the following features: 1. Every non-leaf node is labeled with the name of a field. 4
2. Each outgoing edge from a node labeled with field f is labeled with a nonempty set of values for f . The union of these labels of the edges covers all possible values for f . 3. No two nodes on a path from the root to a leaf are labeled with the same field. 4. The leaf nodes are labeled with a decision (accept/discard). Unfortunately, a firewall decision diagram is exponentially large in size; the worst-case size of the diagram, as reported by Liu et al. [2], is (2n + 1)d where n is the number of rules in the given firewall F , and d is the number of fields checked by each rule. In an industrial setting, a firewall has about 2, 000 rules, each rule checks between 4 and 7 fields, and a firewall needs to be verified against 10, 000 or more properties. Hence there is clearly a need for less time- and space-intensive firewall verification algorithms. Our first contribution, which we present in [14], is a fast, though probabilistic, verification algorithm for firewalls. An interesting feature of our algorithm is its low time as well as space complexity - O(nd), where n is the number of rules in F , and d is the number of fields checked by each rule. Thus the algorithm is linear in both n and d, in contrast to the O(nd ) complexity of previous algorithms. Our algorithm consists of two passes: a deterministic pass and a probabilistic pass. The deterministic pass produces any one of three outcomes: (a) F satisfies P . (b) F does not satisfy P . (c) No conclusion can be reached. The probabilistic pass, which is applied only if the deterministic pass produces outcome (c), produces one of two outcomes: (c1 ) F satisfies P with a high probability. (c2 ) F does not satisfy P . Thus, our firewall verification algorithm returns any one of four outcomes: (a), (b), (c1 ) and (c2 ). Outcomes (a), (b) and (c2 ) are guaranteed to be 5
correct. Only outcome (c1 ) can possibly be erroneous, and even in this case, analysis shows that the probability of outcome (c1 ) being erroneous is very small - around 0.6%. In [14], we implement our algorithm and apply it extensively to verify whether randomly-generated firewalls satisfy given properties. Our experiments, using 80, 000 firewall-property pairs, have shown that our verification algorithm returns outcome c1 less than 1% of the time. Therefore, we conclude that the probability of our verification algorithm producing an erroneous result is less than .006 × .01 = 6 × 105 , which is vanishingly small. A very interesting idea which we first developed in our work on probabilistic firewall verification is that of firewall projection, in which we replace the predicate of each rule (i.e. the set of packets matched by the rule) with the intersection between the predicates of the rule and the property to be verified. For example, given a rule x ∈ [5, 10] ∧ y ∈ [3, 7] → accept and the property x ∈ [6, 18] ∧ y ∈ [1, 5] → discard the projected rule becomes x ∈ [6, 10] ∧ y ∈ [3, 5] → accept Building on the concept of firewall projection over a property, we developed a deterministic firewall verification algorithm using the concepts of firewall projection and division. We discuss this algorithm in the next chapter.
6
Chapter 3 Deterministic Verification In the previous chapter, we introduced the concept of firewalls, properties, and firewall verification, and introduced our probabilistic verification algorithm for firewalls. A firewall property is specified by a set of packets and a decision (accept or discard) that needs to be made by the firewall for all the packets in the specified set. A firewall is said to satisfy a property iff, for all the packets specified by the property, the decision made by the firewall matches the decision specified by the property. The probabilistic verification algorithm of the previous chapter is interesting because it provides a linear-time and linear-space algorithm that can, with a very high probability, detect if the firewall fails to satisfy a given property. However, it may be argued that as a firewall is a critical line of defense against attacks, it may be important for security that the network administrator be able to state with absolute confidence that the firewall behaves correctly. Indeed, this is the main reason for formal verification. Testing is the commonly used method for checking the correctness of a firewall. But while testing can prove the presence of faults, it cannot prove their absence. Verification can provide stronger guarantees, and in fact a good analysis engine like FA [9] can automatically suggest which properties to verify. In this context, we see that there is a need for verification algorithms that are provably correct. Unfortunately, as we have already mentioned, the current deterministic algorithms for firewall verification are too expensive: as pointed out in [2], the current method of using Firewall Decision Diagrams [13] has a space complexity of O(nd ), where n is the number of rules in a firewall and d is the number of fields in a rule. The value of n is usually up to around 2000; d is 7
4 to 7, with the usual value being 5 (the usual fields checked are source and destination port, source and destination IP address, and protocol). In this chapter, we attempt to meet the need for deterministic but lowcost firewall verification algorithms. Building on our probabilistic firewall verification algorithm, we develop the first linear-space deterministic algorithm to verify whether a firewall satisfies a property. Our algorithm uses no data structures other than the firewall itself, and some smaller firewalls produced from it by our technique of “projection” and “division”. The worst-case space complexity is O(nd), the size of the firewall (and thus clearly a lower bound). This firewall verification algorithm always terminates with the correct answer, and requires very little memory to run (around 0.5 kB per rule for large firewalls with several thousand rules). Our time complexity is still O(nd ) - this may be a lower bound for a deterministic algorithm that verifies whether a firewall satisfies a property. However, we show by verifying millions of firewall-property pairs that in practice our algorithm has very modest time requirements: the worst observed time on a 2000 rule firewall was 0.71 seconds. Our complete algorithm consists of two passes: a projection pass, and a division pass. The projection pass is a quick check that produces any one of the following three outcomes: (a) F satisfies P . (b) F does not satisfy P . (c) No conclusion can be reached. In case of outcome (c), the projection pass also outputs a firewall F 0 , called the projection of F over P . In order to obtain the projection of F over P , we begin by listing the projections of all the rules in F over P , as discussed in the previous chapter. Next, we remove two classes of rules. • Rules that do not match any packets that are matched by P , which, after the projection, no longer match any packets at all. • All rules following the first rule that matches all packets matched by P. F 0 is usually much smaller than F , and satisfies P iff F satisfies P . The division pass, which is applied only if the projection pass produces outcome (c), produces “slices” of F 0 , which are even smaller firewalls. If 8
for any slice Si we can find a packet p, such that the decision of Si for p is not the decision of property P , then (and only then) F 0 does not satisfy P . This task of finding a counter-example packet is performed by the “Probe” algorithm, which reduces the search from O((2n)d ) to O(nd ) time complexity. The division pass produces one of the following two outcomes: (a) F satisfies P . (b) F does not satisfy P . The details of our deterministic verification algorithm are presented in our paper [15].
9
Chapter 4 Redundancy Detection is equivalent to Verification In the previous chapters, we study a firewall in the form of its implementation, as a sequence of rules. Of course, a firewall has a function as well as an implementation. A firewall is a packet filter that is placed at a point where a private computer network is connected to the rest of the Internet. The function of the firewall is to intercept each packet that is exchanged between the private network and the Internet, examine the fields of the packet headers, and decide whether to accept the packet and allow it to proceed on its way, or to discard the packet. The decision that a firewall makes, when it receives a packet, depends on two factors: 1. The values of the fields in the packet headers 2. The sequence of firewall rules that is specified by the firewall designer A firewall rule consists of a predicate and a decision, which is either accept or discard. When the firewall receives a packet, the firewall searches its sequence of rules for the first rule, whose predicate is satisfied by the values of the fields in the packet headers, and then applies the decision of this rule to the packet. Hence, a firewall can be completely specified as a sequence of rules. However, it is not necessary to know the actual rules in a firewall to completely specify its function. Another way to specify a firewall is to tabulate its behavior: what is the decision of the firewall for every possible packet? 10
There are two sets of packets that are associated with each firewall: the set of all packets that are accepted by the firewall, and the set of all packets that are discarded by the firewall. If both these sets are completely known, this is also a description of the firewall. This functional description of the behavior of a firewall does not specify it as uniquely as listing the firewall rules. In fact, it is possible to construct two firewalls with completely different rule sequences, which exhibit the same behavior with respect to any packet. Accordingly, we define a term to capture the concept that two firewalls have identical behavior. Two firewalls are equivalent iff they accept the same set of packets and discard the same set of packets. In other words, given that a firewall F accepts (discards) packet p, and that firewall G is equivalent to F , we conclude that G also accepts (discards) packet p. A rule in a firewall is said to be redundant iff removing the rule from the firewall yields a firewall that is equivalent to the original firewall. Redundant rules are a major problem for firewall designers, as they make a firewall large and slow, and thus more vulnerable to attacks such as denialof-service attacks. After the rules of a firewall are designed (by a firewall designer), they are usually validated by subjecting them to two seemingly different algorithms: a verification algorithm and a redundancy checking algorithm. The function of the verification algorithm is to verify that the firewall rules accept all packets that should be accepted and discard all packets that should be discarded. The function of the redundancy checking algorithm is to check whether any rule in the firewall is redundant. A firewall verification algorithm takes as input a firewall F and a property r, and produces as output a determination of whether F satisfies r. (As we have discussed in the previous chapters, a firewall property, like a firewall rule, consists of a predicate and a decision, which is either accept or discard. A firewall is said to satisfy a property iff one of the following two conditions holds: 1. The decision of the property is accept and the firewall accepts every packet that satisfies the predicate of the property. 2. The decision of the property is discard and the firewall discards every packet that satisfies the predicate of the property. ) 11
A redundancy checking algorithm takes as input a firewall F and a rule r in F , and produces as output a determination of whether r is redundant in F (and so should be removed from F ). Up until now, these two types of algorithms, verification algorithms and redundancy checking algorithms, have been developed independently, because they solve quite different problems - verification deals with firewall correctness, and redundancy detection with firewall performance. Our contribution is to demonstrate that in fact, the two algorithms are very closely related, as can be seen from the following dual results: (i) Any verification algorithm can also be used as a subroutine in checking whether a given rule in a given firewall is redundant in this firewall. (ii) Any redundancy checking algorithm can also be used as a subroutine in verifying whether a given firewall satisfies a given property. In our paper [16], we show that two important problems in the study of firewalls, namely firewall verification and firewall redundancy checking, are in a sense equivalent: there exists a constant-time transformation to convert a verification problem to one of redundancy detection, and a lineartime transformation to convert a redundancy detection problem to one of verification. Any progress that one can achieve in solving either problem can be regarded also as progress in solving the other problem.
12
Chapter 5 Modular Design of Firewalls In the previous chapters, we have studied firewalls as rule sequences. A firewall performs its function based on a specified sequence of rules. Each rule is of the form < predicate >→< decision > where < predicate > is a function that assigns to each packet a boolean value, true or false, and < decision > is either ”accept” or ”discard”. When a packet p reaches a firewall F , F performs two steps: 1. F identifies the first rule r (in its sequence of rules) whose < predicate > assigns the value true to packet p. 2. If the < decision > of rule r is accept (or discard, respectively) then F accepts (or discards, respectively) packet p. A firewall employs a “first-match” criterion to determine which rule (in its sequence of rules) should be applied to which packet. This first-match criterion allows the rules in the rule sequence to “overlap”. In this chapter, we begin by recognizing the fact that this “first-match semantics” of firewalls can be both advantageous and disadvantageous. The advantage of making the rules in the rule sequence overlapping is that it reduces the number of rules in the rule sequence, sometimes dramatically. The disadvantage of making the rules in the rule sequence overlapping is that it creates many dependencies between the rules in the rule sequence. This, in turn, complicates the task of designing and understanding the rule sequence. To compute the set of packets to which a rule r (in the rule
13
sequence) applies, the firewall designer needs to consider not only rule r, but also all the rules that precede r in the rule sequence. To formalize the notion of how overlapping rules increase the complexity of a firewall, we introduce a metric, called the “dependency metric”. The more the value of the metric for a given firewall, the more complex the firewall is and the harder it is to design and understand. Unfortunately, the dependency metric, though accurate, does not seem to suggest methods for designing firewalls for which the values of the metric are small. Thus, we introduce another complexity metric, called the “inversion metric”, for measuring the complexity of firewalls. Next, we demonstrate that the dependency metric and the inversion metric are correlated (at least for a rich class of firewalls called “uniform firewalls”). This result allows us to use the inversion metric as a good approximation of the dependency metric. The natural next step is to study how to develop firewalls with a small value of the inversion metric. At this point, we take note of the fact that it is not strictly necessary for a firewall to be implemented as a single sequence of rules; this is just a standard practice. A firewall is a packet filter, placed at an entry point of a network in the Internet, that checks each packet that goes through the entry point (at which the firewall is located) and determines whether to accept or to discard the packet. As long as a firewall performs these functions, it may have any internal structure. Using this insight, we identify three classes of firewalls, namely “simple firewalls”, “partitioned firewalls”, and “modular firewalls”, for which the values of the inversion metric are small. (This implies that these classes of firewalls are easier to design and understand.) We also describe methods for designing firewalls in these three classes. Of particular interest is the class of modular firewalls. Each modular firewall consists of simple firewall components, called “firewall modules”. The value of the inversion metric for each firewall module is 1 or 2. This causes the value of the inversion metric for the full firewall to be 1 or 2. (Note that the smallest possible value of the inversion metric is 1.) In our paper [17], we present an algorithm that takes as input any firewall F whose inversion metric is large and computes as output an equivalent modular firewall M F whose inversion metric is (by definition) 1 or 2. The complexity of this algorithm is O(n2 ) where n is the number of rules in the input firewall F and we verify by simulation that the algorithm is in fact fast for practical firewalls. Hence, we conclude that designing a modular firewall is not harder than designing an equivalent non-modular firewall. 14
Chapter 6 Concluding Remarks In this dissertation, we make four contributions to the study of firewalls. In Chapter 2, we note that the current algorithms for firewall verification are very expensive, requiring O((2n)d ) space, where n is the number of rules in a firewall and d the number of fields in a rule. In order to meet the need for a fast verification algorithm, we develop a probabilistic firewall verifier, which has very small probability of error (≈ 10−5 ), and runs in time and space O(nd). In Chapter 3, we build on this verifier to develop a deterministic algorithm for firewall verification. Our deterministic algorithm, Probe, also takes space O(nd), and though the time is still theoretically O(nd ), we demonstrate that it runs very fast for practical firewalls. In Chapter 4, we prove a very interesting result: firewall verification and redundancy detection are very closely related, and an algorithm to solve one problem can be readily adapted to solve the other. This, of course, suggests the possibility of using the Probe algorithm for optimization as well as verification of firewalls. Finally, in chapter 5, we develop two metrics for firewall complexity - the dependency metric and the inversion metric - and demonstrate a new algorithm for firewall design, in which a firewall is designed as a “battery of modules”, rather than as a single sequence of rules. Each of the modules in the firewall is itself a simple firewall, and no packet is accepted by more than one module. We suggest that this new algorithm for firewall design produces firewalls that are easy to understand, and demonstrate that the design is no more difficult than the current designs of non-modular firewalls. Thus, we make a complete set of contributions to firewall theory, covering the design, analysis, and verification of firewalls.
15
Bibliography [1] M. G. Gouda and A. X. Liu, “Structured firewall design,” Computer Networks, vol. 51, pp. 1106–1120, 2007. [2] A. X. Liu and M. G. Gouda, “Diverse firewall design,” IEEE Transaction on Parallel and Distributed Systems, vol. 19, no. 9, pp. 1237–1251, 2008. [3] D. Eppstein and S. Muthukrishnan, “Internet packet filter management and rectangle geometry,” in SODA, 2001, pp. 827–835. [4] H. Adiseshu, S. Suri, and G. M. Parulkar, “Detecting and resolving packet filter conflicts,” in INFOCOM, 2000, pp. 1203–1212. [5] E. S. Al-Shaer, H. Hamed, R. Boutaba, and M. Hasan, “Conflict classification and analysis of distributed firewall policies,” IEEE Journal on Selected Areas in Communications, vol. 23, no. 10, pp. 2069–2084, 2005. [6] M. Frantzen, F. Kerschbaum, E. E. Schultz, and S. Fahmy, “A framework for understanding vulnerabilities in firewalls using a dataflow model of firewall internals,” Computers & Security, vol. 20, no. 3, pp. 263–270, 2001. [7] S. Kamara, S. Fahmy, E. E. Schultz, F. Kerschbaum, and M. Frantzen, “Analysis of vulnerabilities in internet firewalls,” Computers & Security, vol. 22, no. 3, pp. 214–232, 2003. [8] A. Wool, “A quantitative study of firewall configuration errors,” IEEE Computer, vol. 37, no. 6, pp. 62–67, 2004. [9] L. Yuan, J. Mai, Z. Su, H. Chen, C.-N. Chuah, and P. Mohapatra, “Fireman: A toolkit for firewall modeling and analysis,” Security and Privacy, IEEE Symposium on, vol. 0, pp. 199–213, 2006. 16
[10] A. J. Mayer, A. Wool, and E. Ziskind, “Fang: A firewall analysis engine,” in IEEE Symposium on Security and Privacy, 2000, pp. 177–187. [11] A. El-Atawy, K. Ibrahim, H. Hamed, and E. S. Al-Shaer, “Policy segmentation for intelligent firewall testing,” Secure Network Protocols, 2005. (NPSec). 1st IEEE ICNP Workshop on, pp. 67–72, Nov. 2005. [12] E. S. Al-Shaer, A. El-Atawy, and T. Samak, “Automated pseudo-live testing of firewall configuration enforcement.” IEEE Journal on Selected Areas in Communications, vol. 27, no. 3, pp. 302–314, 2009. [13] A. X. Liu and M. G. Gouda, “Firewall policy queries,” IEEE Transactions on Parallel and Distributed Systems (TPDS), to appear 2009. [14] H. B. Acharya and M. G. Gouda, “Linear-time verification of firewalls,” in Proceedings of the IEEE International Conference on Network Protocols, 2009. [15] ——, “Projection and division: Linear-space verification of firewalls,” in Proceedings of the 2010 IEEE 30th International Conference on Distributed Computing Systems, 2010. [16] ——, “Firewall verification and redundancy checking are equivalent,” in Proceedings of The 30th IEEE International Conference on Computer Communications, 2011. [17] ——, “Firewall modules and modular firewalls,” in Proceedings of the IEEE International Conference on Network Protocols, 2010.
17
