Filtering List Analysis Chotipat Pornavalai and Thawatchai Chomsiri Faculty of Information Technology, King Mongkut's Institute of Technology Ladkrabang Ladkrabang, Bangkok 10520, Thailand. Abstract: Firewalls is an important device for network security. However managing and writing firewall rules must be carefully done in order to implement the security policy correctly. Alternating rule order incorrectly may change meaning of the policy. Many research works proposed methods for finding anomalies within rule set by using several approaches, but they are not cover all anomalies. For example, it could not find shadowed rule which might be shadowed by more than one previous rule, and could not find correlation anomaly that is a correlation within the same attribute. This kind of correlation can be occurred in many firewall products, such as port-range in IPTABLES [5] or using multi-address in Check Point FW- 1 [4]. Many researches consider only two rules. This could possibly get incorrectly results. In this paper, we propose a new technique for analyses packet filtering rule list by using Relational Algebra technique. It can find all anomalies by considering more than two rules at the same time. We also propose an approach to remove anomalies within the rule set, and to combine rules to reduce the rule set s size. 1. Introduction Firewall is essential equipment to secure network that is connected to the Internet. Conflicts and incorrectly order within firewall rules can make system work improperly too. Writing a rule set usually contain many hidden conflicts. Many research works tried to find these conflicts using several approaches. For example, Pasi Eronen [2] proposed an Expert System that is based on constraint logic programming (CLP) for user to write higher-level operations for detecting common configuration mistakes. Scott Hazelhurst [3] using Binary Decision Diagrams (BDDs) to present and analyze rule set. Ehab Al-Shader et.al [1] presents an anomaly discovery algorithm using SET theory. They described a method for finding some error within rule set that called anomalies, Process of simply managing anomalies. But their research can not discovery all anomalies when considering more than two rules at the same time. To solve this problem, we propose an alternative approach using Relational Algebra technique for finding anomalies within the rule sets using Relational Algebra operations. Thus it is easy to resolve relationship between rules, which can discover all the anomalies. This paper is organized as follows. In section 2, we give a background about firewall and Relational Algebra. In section 3, we present how to map the firewall rules into relation. In section 4, we classify and define firewall policy anomalies, and we describe the anomaly discoverng. In section 5, we present how to remove anomalies and how to reduce the rule set s size by combining rules together. We conclude this paper with our future works in section 6. 2. Firewall and Relational Algebra Background Firewall detects all packets IN/OUT of the networks. It can allow or deny any packets by considering the specified rule set. When it receives any packets, it will compare header of packets with all rules defined in rule set from first rule to last rule or until it has found rule matched with condition. Then it performs action specified on that rule. Example of rule set is shown in Figure 1. 1 10.0.0.5 20.0.0.1 20-21 accept 2 10.0.0.5 20.0.0.1 21-22 accept 3 10.0.0.5 20.0.0.1 23-25 deny 4 10.0.0.5 20.0.0.1 22-23 accept 5 10.0.0.0/30 20.0.0.1 80 deny 6 10.0.0.1 20.0.0.0/30 80 accept 10.0.0.0/30 20.0.0.0/30 80 deny 8 10.0.0.1 20.0.0.1 80-143 accept 9 10.0.0.1, 10.0.0.4 20.0.0.1 80 deny 10 10.0.0.0/24 20.0.0.0/24 any accept 11 10.0.0.0/24 20.0.0.0/24 80 deny any any any deny Figure 1. rule set
Relation is a subset of a Cartesian product of a set of domain [6]. Relation Algebra is a procedural query language that consists of a set of operations on the relations. Operations in Relational Algebra are select, project, union, set difference, Cartesian product and rename. The operations that used frequently are shown Figure 2. R1 (Relation 1) is SELECT src_ip dst_ip dst_port action R5 = select (dst_port=80) R4 30.0.0.0 40.0.0.1 80 deny src_ip dst_ip dst_port 30.0.0.1 40.0.0.1 80 deny 30.0.0.0 40.0.0.1 80 30.0.0.2 40.0.0.1 80 deny 30.0.0.1 40.0.0.1 80 30.0.0.3 40.0.0.1 80 deny UNION R2 (Relation 2) is R6 = R3 union R4 src_ip dst_ip dst_port action src_ip dst_ip dst_port 30.0.0.0 40.0.0.1 80 accept 30.0.0.0 40.0.0.1 80 30.0.0.0 40.0.0.1 81 accept 30.0.0.1 40.0.0.1 80 30.0.0.1 40.0.0.1 80 accept 30.0.0.2 40.0.0.1 80 30.0.0.1 40.0.0.1 81 accept 30.0.0.3 40.0.0.1 80 30.0.0.0 40.0.0.1 81 PROJECT 30.0.0.1 40.0.0.1 81 R3 = project (src_ip, dst_ip, dst_port) R1 src_ip dst_ip dst_port INTERSECTION 30.0.0.0 40.0.0.1 80 R = R3 intersect R4 30.0.0.1 40.0.0.1 80 src_ip dst_ip dst_port 30.0.0.2 40.0.0.1 80 30.0.0.0 40.0.0.1 80 30.0.0.3 40.0.0.1 80 30.0.0.1 40.0.0.1 80 R4 = project (src_ip, dst_ip, dst_port) R2 DIFFERENCE src_ip dst_ip dst_port R8 = R3 difference R4 30.0.0.0 40.0.0.1 80 src_ip dst_ip dst_port 30.0.0.0 40.0.0.1 81 30.0.0.2 40.0.0.1 80 30.0.0.1 40.0.0.1 80 30.0.0.3 40.0.0.1 80 30.0.0.1 40.0.0.1 81 Figure 2. Relational Algebra Operation 3. Mapping s into Relation Mapping any rules in the rule set to the relation can be done by doing a Cartesian product between set of attributes in that rule. For example, when src_ip = 30.0.0.0/30, dst_ip = 40.0.0.1, dst_port = 80, action = deny, it can be mapped to relation 1 (R1) as shown in Figure 2, while R2 is the relation that is mapped from rule; src_ip = 30.0.0.0/31, dst_ip = 40.0.0.1, dst_port = 80-81, action = accept. 4. Firewall Policy Anomaly Discovery In this section, we present theories for discover firewall policy anomaly. We define and classify the types of anomaly using Raining 2D-Box Model. In this section, we define -n as a rule number n from the rule set table. Therefore, if n < m, then -m follows -n. Rn is a relation that has been mapped from -n using PROJECT operation to exclude action attribute. 4.1. Firewall Policy anomaly Classification Ehab S. Al-Shaer et.al [1] classified anomaly into 4 types. They are Shadowing anomaly, Correlation anomaly, Generalization anomaly and Redundancy anomaly. We also classify anomaly into 4 types but it covers all anomalies that are occurred when considering many rules at the same time. Our definition here for each anomaly is also different from [1]. We also present many theorems that will be used to discover anomalies which will be used in any anomaly discovery algorithms. Definition 1: -i will be shadowed when Ri (Ri 1U Ri 2 U U R1) = φ Where R i is relation i Definition 2: -x and -y are partially correlated when action of -x is differen from -y Rx Ry, Ry Rx, Ry Rx and Rx I Ry φ, where Definition 3: -x and -y are completely correlated when Rx Ry, and action of -x is different from -y.
Definition 4: -x and -y are correlated when either they are partially correlated or completely correlated. Definition 5: -x and -y are consecutively non-correlated when -x and -y are not correlated, and y = x + 1. Definition 6: We can say that -x is consecutively non-correlated downward to -y, (x < y) if we can recursively swap -x with -(x+1) downward to -y without any changes in firewall policy Definition : We can say that -y is consecutively non-correlated upward to -x, (x < y) if we can recursively swap -y with -(y-1) upward to -x without any changes in firewall policy Definition 8: -y is generalized to -x if -x and -y are completely correlated and x < y. Definition 9: -x is said to be redundant by -y,(x < y) if action is the same and Rx Ry. Definition 10: -x is said to be consecutively redundant by -y if -x is redundant by -y and y = x + 1. 4.1.1. Shadowing Anomaly Shadowed rule is a rule which will never be executed because all the packets that matched this rule are already matched by the one or more rules that are written above in the rule set. For example, -4 is shadowed because R4 (R3 U R2) = φ. No packet can be passed to -4 (see Figure 1). In [1], shadowed rule is defined as a rule that is shadowed by a (and only one) previous rule which has different action. Thus it can not classify that rule-4 is shadowed because it is shadowed by rule 2 and 3. This can be easily shown using Raining 2D-Box model in Figure 3(a). When shadowed rules occur, we should remove them to reduce the rule set s size. Theorem 1: The firewall policy does not change even if we remove -x, when rule-x is shadowed. 4.1.2. Correlation Anomaly Two rules (with different actions) are correlated if the first rule in order matches some packets that match the second rule and the second rule matches some packets that matched the first rule This definition is similar to [1]. But in their definition, this correlation is occurred by considering only when two or more attributes are different in those two rules. For example, in Figure 1, if we placed -6 above -5, firewall will accept packet where source from 10.0.0.1 to destination 20.0.0.1 at port 80. Another example of Correlation anomaly is -3 and -4 (see Figure 1. and Figure 3(b)). However, this kind of anomaly will not be discovered by the algorithm proposed in [1] because both -3 and -4 have only one attribute (dst_port) that is partially correlated. In other words, -3 and -4 are partially correlated because of only one (i.e. dst_port) attribute. There are many firewall products available in the market that allows this kind of correlation can be occurred such as port range port-range attribute in IPTABLES [5] and multi-address in Check Point FW-1 [4]. Therefore using our definition, we can discover this kind of correlations. Theorem 2: The firewall policy does not change even if we swap -x and -y, when -x and -y are consecutively non-correlated. Theorem 3: The firewall policy does not change even if we swap -x and -y, where x < y, and -x is consecutively non-correlated downward to rule-y, and -y is consecutively non-correlated upward to -x. However, by combining definition 1 and 2, we also found that even though -x and -y are correlated, we can swap the order of these two rules in the rule set. For example see -8 and -9. The reason of this example came from that correlate part between -8 and -9 is shadowed by previous rules (in this case -). It can also be explained using Raining 2D-Box model in Figure 3(c). We therefore define -x-y as a rule that is inverse-mapped from the relation resulted from Rx I Ry. -x-y is not in the rule set but we virtually assume that the order of -x-y in the rule set is at x, where x < y. Theorem 4: The firewall policy does not change even if we swap -x and -y, where -x and -y are correlated and -x-y is shadowed, and -x is consecutively non-correlated downward to rule-(y-1), and -y is consecutively non-correlated upward to -(x+1).
4.1.3. Generalization Anomaly A rule is said to be generalized to previous rule if it matches all packets which matched with previous rule, where actions are different. In general, two rules that are generalized can not be swapped. But in some cases, such as shown in Figure 3 (e), when -y is generalized -x, but it can be swapped because -x is shadowed by previous rules. Theorem 4 already covered this case because, in fact, generalization is special case of correlation (generalization is a completely correlation when x less than y). 4.1.4. Redundancy Anomaly Theorem 5: The firewall rule does not change even if we remove -x from the rule set when -x is consecutively redundant by -y. For example as shown in Figure 3 (f), we can remove rule-11 without any changes in firewall policy. Theorem 6: The firewall rule does not change even if we remove -x from the rule set when -x is redundant by -y, and -x is consecutively non-correlated downward to rule-(y-1). For example, -5 is redundant by rule- (as shown in Figure 1 and Figure 3 (g)). But we cannot remove -5 because firewall will accept packet came from 10.0.0.1 and destination to 20.0.0.1 at port 80 (the intersection part of R5 and R6). Because -5 and -6 are correlated, then R5 cannot be removed which is described in Theorem 6. By considering more than two rules at the same time, we can discover anomaly that cannot be explained by using Set approach. For example, Firewall Policy Advisor in [1] will recommend user to remove -5 because it is redundant by -, which in fact it may not be removed as explained. 4.2. Anomaly Representation Raining 2D-Box Model We also propose a model to describe how it occur any anomaly. We called it Raining 2-Dimension Box Model as shown in Figure 3. It is a 2 dimensions box that contains the relations that are mapped from rules in the order described in the rule set. A rectangular is used to represent any relation of rule and action within each box. If action is not specified in the rectangular, it can be any actions (accept or deny). This model simulates packet that fall from the top to the bottom like raining. For example, when the relation in the box is not wet, means it is shadowed, as shown in Figure 3 (a). 2 3 4 Shadowed 3 4 8 9 (a) Shadow anomaly (b) Correlation anomaly (c) Correlation anomaly (can swap correlated rule) 6 x y 11 (d) Generalization anomaly (e) Generalization anomaly (can swap rule x,y) (f) Redundancy anomaly 5 6 (g) Redundancy anomaly (can not remove redundant rule) Figure 3. Raining 2D-Box Model
5. Anomaly Removing and Combinations We should remove anomalies from the firewall policy after we discovered them. It may shorten the size of rule set and make firewall policy easier to be understood by administrator. From the discussion in section 4, it is clear that we can remove rules that are shadowed (Theorem 1), and rules that are redundant which their conditions matched in Theorem 5 and 6. Reordering the rules in the rule set may help administrator understand the rule set easier. It also can increase the performance of the firewall because the rules that are matched to many packets are on the tops in the rule set. s that match in Theorem 2, 3 and 4 can be swapped without any changes in the firewall policy. The Theorems 2, 3 and 4 can help administrator swap the rules the gain the benefit above. Not only removing the rules from the rule set but also combining rules together to one rule can reduce the rule set s size. For example, in Figure 1, -1 and -2 can be combined in one rule where the new rule has dst_port defined as 20-22. before 1 50.0.0.0/26 60.0.0.0/24 80 accept 2 50.0.0.64/26 60.0.0.0/24 80 accept 3 50.0.0.8/26 60.0.0.0/24 80 accept 4 50.0.0.192/26 60.0.0.0/24 80 accept after 1 50.0.0.0/24 60.0.0.0/24 80 accept Figure 4. Combination Another example is shown in Figure 4. Four rules can be combined into one rule by changing the subnet mask from 26 to 24. This is similar to super-net concept. The detail of algorithm to combine the rules can be found in [8]. 6. Conclusion and Future Work In this paper, we analyze firewall rule set using Relational Algebra technique which could help us defining the anomalies that occurred in the rule set. We also explain how to remove anomalies and combining the rules to make the rule set size smaller. Many related works are either complex or can not be used to discover all the anomalies presented in this paper. It also can be used on firewall rule set on many commercial and open-source firewall products such as Checkpoint Firewall-1 and IPTABLES. In our future work, we will present discovery algorithms and implement the policy advisor using those algorithms. Our implementation will be based on Java applet. It can help administrator removing missing rules and combining the rules together to reduce the rule set s size. We will also implement policy editor to allow administrator to insert, and modify rules with alerts. This will make writing or modifying firewall easier to understand and make error-free firewall policy. References [1] Ehab Al-Shaer and Hazem Hamed, "Firewall Policy Advisor for anomaly Detection and Editing", IEEE/IFIP Integrated Management IM'2003, March 2003. [2] P. Eronen and J. Zitting. An Expert System for Analyzing Firewall s. Proceedings of 6thNordic Workshop on Secure IT-Systems (NordSec 2001), November 2001. [3] S. Hazelhusrt. Algorithms for Analyzing Firewall and Router Access Lists. Technical Report TR-WitsCS-1999, Department of Computer Science, University of the Witwatersrand, South Africa, July1999. [4] Check Point Visual Policy Editor Data Sheet. http://www.checkpoint.com/products/downloads/vpe datasheet.pdf [5] Iptables Tutorial 1.1.19 http://iptables-tutorial.frozentux.net/iptables-tutorial.html [6] Abraham Silberschatz, Henry F. Korth, Sudharsan S., Database System Concepts, 3rd Edition, Tata McGraw-Hill, 199. [] Managing Check Point FireWall-1, Using the Windows GUI Version 4.0 http://www.checkpoint.com/support/technical/documents/fwwindows.pdf [8] Chotipat Pornavalai and Thawatchai Chomsiri, Firewall Policy Analyzing by Relational Algebra Draft Technical Report, Faculty of Information Technology, King Mongkut's Institute of Technology Ladkrabang, Thailand, January 2004.