Packet Filtering Rule 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.
order src_ip dst_ip dst_port action
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 7 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
12 any any any deny
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 R7 = 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 Rules 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 Rule-n as a rule number n from the rule set table. Therefore, if n < m, then Rule-m follows Rule-n. Rn is a relation that has been mapped from Rule-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: Rule-i will be shadowed when Ri−(Ri−1URi−2U...UR1)=φ Where Ri is relation i
Definition 2: Rule-x and Rule-y are partially correlated when Rx⊄Ry,Ry⊄Rx, Rx≠Ry and Rx IRy≠φ , where action of Rule-x is differen from Rule-y
Definition 4: Rule-x and Rule-y are correlated when either they are partially correlated or completely correlated.
Definition 5: Rule-x and Rule-y are consecutively non-correlated when Rule-x and Rule-y are not correlated, and y = x + 1. Definition 6: We can say that Rule-x is consecutively non-correlated downward to Rule-y, (x < y) if we can recursively swap
Rule-x with Rule-(x+1) downward to Rule-y without any changes in firewall policy
Definition 7: We can say that Rule-y is consecutively non-correlated upward to Rule-x, (x < y) if we can recursively swap Rule-y with Rule-(y-1) upward to Rule-x without any changes in firewall policy
Definition 8: Rule-y is generalized to Rule-x if Rule-x and Rule-y are completely correlated and x < y. Definition 9: Rule-x is said to be redundant by Rule-y,(x < y) if action is the same and Rx
⊂
Ry.Definition 10: Rule-x is said to be consecutively redundant by Rule-y if Rule-x is redundant by Rule-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, Rule-4 is shadowed because R4 – (R3 U R2) =
φ
. No packet can be passed to Rule-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 Rule-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 Rule-6 above Rule-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 Rule-3 and Rule-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 Rule-3 and Rule-4 have only one attribute (dst_port) that is partially correlated. In other words, Rule-3 and Rule-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 Rule-x and Rule-y, when Rule-x and Rule-y are consecutively non-correlated.
Theorem 3: The firewall policy does not change even if we swap Rule-x and Rule-y, where x < y, and Rule-x is
consecutively non-correlated downward to rule-y, and Rule-y is consecutively non-correlated upward to Rule-x.
However, by combining definition 1 and 2, we also found that even though Rule-x and Rule-y are correlated, we can swap the order of these two rules in the rule set. For example see Rule-8 and Rule-9. The reason of this example came from that correlate part between Rule-8 and Rule-9 is shadowed by previous rules (in this case Rule-7). It can also be explained using Raining 2D-Box model in Figure 3(c). We therefore define Rule-x-y as a rule that is inverse-mapped from the relation resulted from Rx I Ry. Rule-x-y is not in the rule set but we virtually assume that the order of Rule-x-y in the rule set is at
x, where x < y.
Theorem 4: The firewall policy does not change even if we swap Rule-x and Rule-y, where Rule-x and Rule-y are correlated and Rule-x-y is shadowed, and Rule-x is consecutively non-correlated downward to rule-(y-1), and Rule-y is consecutively non-correlated upward to Rule-(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 Rule-y is generalized Rule-x, but it can be swapped because Rule-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 Rule-x from the rule set when Rule-x is consecutively redundant by Rule-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 Rule-x from the rule set when Rule-x is redundant by Rule-y, and Rule-x is consecutively non-correlated downward to rule-(y-1).
For example, Rule-5 is redundant by rule-7 (as shown in Figure 1 and Figure 3 (g)). But we cannot remove Rule-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 Rule-5 and Rule-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 Rule-5 because it is redundant by Rule-7, 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).
12 ... Deny Rule No. Packet 5 (g) Redundancy anomaly
(can not remove redundant rule)
Accept Deny 7 6 ... Deny 12 11 Deny Rule No. Packet ... (f) Redundancy anomaly 12 ... Accept Deny 6 7 Rule No. Packet ... (d) Generalization anomaly 12 Rule No. Packet (c) Correlation anomaly
(can swap correlated rule)
... Deny 7 Accept 9 8 ... 12 ... 2 3 Rule No. Packet ...
(a) Shadow anomaly 4 Shadowed 12 ... Deny Accept 3 4 Rule No. Packet ... (b) Correlation anomaly 12 ... Accept Deny x y Rule No. Packet ...
(e) Generalization anomaly
(can swap rule x,y)
5. Anomaly Removing and Rule 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. Rules 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, Rule-1 and Rule-2 can be combined in one rule where the new rule has dst_port defined as 20-22.
before
order src_ip dst_ip dst_port action
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.128/26 60.0.0.0/24 80 accept
4 50.0.0.192/26 60.0.0.0/24 80 accept
after
order src_ip dst_ip dst_port action
1 50.0.0.0/24 60.0.0.0/24 80 accept
Figure 4. Rule 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 Rule Editing", IEEE/IFIP
Integrated Management IM'2003, March 2003.
[2] P. Eronen and J. Zitting. “An Expert System for Analyzing Firewall Rules.” 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, 1997.
[7] “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.
