1

Discovery of Policy Anomalies in Distributed FirewallsEhab S. Al-Shaer and Hazem H. Hamed

Multimedia Networking Research LaboratorySchool of Computer Science, Telecommunications and Information Systems

DePaul University, Chicago, USAEmail: {ehab, hhamed}@cs.depaul.edu

Abstract— Firewalls are core elements in network security.However, managing firewall rules, particularly in multi-firewallenterprize networks, has become a complex and error-prone task.Firewall filtering rules have to be written, ordered and distributedcarefully in order to avoid firewall policy anomalies and mightcause network vulnerability. Therefore, inserting or modifyingfiltering rules in any firewall requires a thorough intra- andinter-firewall analysis to determine the proper rule placementand ordering in firewalls. In this paper, we identify all anomaliesthat could exist in a single- or multi-firewall environments. Wealso present a set of techniques and algorithms to automati-cally discover and rectify policy anomalies in centralized anddistributed legacy firewalls. These techniques are implementedin a tool called the “Firewall Policy Advisor” that simplifies themanagement of filtering rules and maintains the integrity andsecurity of next-generation firewalls.

I. I NTRODUCTION

With the global Internet connection, network security hasgained significant attention in research and industrial com-munities. Due to the increasing threat of network attacks,firewalls have become important integrated elements not onlyin enterprize networks but also in small-size and home net-works. Firewalls have been the frontier defense for securenetworks against attacks and unauthorized traffic by filteringout unwanted network traffic coming from or going to thesecured network. The filtering decision is based on a set ofordered filtering rules defined according to predefined securitypolicy requirements.

Although deployment of firewall technology is an impor-tant step toward securing our networks, the complexity ofmanaging firewall policies might limit the effectiveness offirewall security. In a single firewall environment, the localfirewall policy may includeintra-firewall anomalies, wherethe same packet may match more than one filtering rule.Moreover, in distributed firewall environments, firewalls mightalso haveinter-firewall anomalieswhen individual firewalls inthe same path perform different filtering actions on the sametraffic. Therefore, the administrator must give special attentionnot only to all rule relations in the same firewall in orderto determine the correct rule order, but also to all relationsbetween rules in different firewalls in order to determine theproper firewall placement of a particular rule. As the numberof filtering rules increases, the difficulty of adding a new ruleor modifying an existing one significantly increases. It is verylikely, in this case, to introduce conflicting rules such as onegeneral rule shadowing another specific rule, or correlatedrules whose relative ordering determines different actions forthe same packet. In addition, a typical large-scale enterprize

network might involve hundreds of rules that might be writtenby different administrators in various times. This significantlyincreases the potential of anomaly occurrence in the firewallpolicy, jeopardizing the security of the protected network.

Therefore, the effectiveness of firewall security is depen-dent on providing policy management techniques and toolsthat network administrators to analyze, purify and verify thecorrectness of written firewall filtering rules. In this paper, wefirst provide a formal definition of filtering rule relations andthen identify all anomalies that might exist in any firewallpolicy in centralized and distributed firewall environments.We also used a tree-based filtering representation to developanomaly discovery algorithms for reporting any intra- andinter-firewall anomaly in any general network. We finally de-velop an rule editor to produce anomaly-free firewall policies,and greatly simplify adding, removing and modifying filteringrules. These algorithms and techniques were implementedusing Java programming language in a tool called the “FirewallPolicy Advisor.”

Although firewall security has been given strong attentionin the research community, the emphasis was mostly on thefiltering performance and hardware support issues [5, 8, 10,11, 22]. On the other hand, few related work [6, 10] attemptto address only one of the conflict problems which is therule correlation in filtering policies. Other approaches [2, 9,12, 14, 16, 23] propose using a high-level policy language todefine and analyze firewall policies and then map this languageto filtering rules. Although using such high-level languagesmight avoid rules anomalies, they are not practical for themost widely used firewalls that contain low-level filteringrules. It is simply because redefining already existing policiesusing high-level languages require far more effort than justusing stand-alone tools such as the Firewall Policy Advisor.In addition, we consider our classification and discovery ofinter-firewall anomalies is new contribution in this area asnone of the previous work has a significant attempt to addressanomalies in distributed firewalls. Therefore, we consider thiswork a significant progress in this area as it offers noveland comprehensive framework to automate anomaly discoveryand rule editing in legacy firewalls in both centralized anddistributed firewall environments.

This paper is organized as follows. In Section II we givean introduction to firewall operation and filtering rule format.In Section III, we formally define filtering rule relations,and we present our formalization of filtering rule relationsand the policy tree representation. In Section IV, we classifyand define policy anomalies in centralized firewalls, and then

2

R/FW

D1

140.192.37.0

Internet

D2

161.120.33.0

1: tcp, 140.192.37.20, any, *.*.*.*, 80, deny 2: tcp, 140.192.37.*, any, *.*.*.*, 80, ac cept 3: tcp, *.*.*.*, any, 161.120.33.40, 80, ac cept 4: tcp, 140.192.37.*, any, 161.120.33.40, 80, deny 5: tcp, 140.192.37.30, any, *.*.*.*, 21, deny 6: tcp, 140.192.37.*, any, *.*.*.*, 21, ac cept 7: tcp, 140.192.37.*, any, 161.120.33.40, 21, ac cept 8: tcp, *.*.*.*, any, *.*.*.*, any, deny 9: udp, 140.192.37.*, any, 161.120.33.40, 53, ac cept10: udp, *.*.*.*, any, 161.120.33.40, 53, ac cept11: udp, 140.192.38.*, any, 161.120.35.*, any, ac cept12: udp, *.*.*.*, any, *.*.*.*, any, deny

Figure 1. An example for centralized firewall setup.

we describe the intra-firewall anomaly discovery algorithm.In Section V, we classify and define policy anomalies indistributed firewalls, and then we describe the inter-firewallanomaly discovery algorithm. In Section VI we describe thetechniques for anomaly-free rule editing. In Section VII weshow the implementation and evaluation of the Firewall PolicyAdvisor tool. In Section VIII, we give a summary of relatedwork. Finally, in Section IX, we show our conclusions and ourplans for future work.

II. F IREWALL BACKGROUND

A firewall is a network element that controls the traversalof packets across the boundaries of a secured network basedon a specific security policy. A firewall security policy is alist of ordered filtering rules that define the actions performedon packets that satisfy specific conditions. A rule is composedof set of filtering fields (also called network fields) such asprotocol type, source IP address, destination IP address, sourceport and destination port, as well as an action field. Thefiltering fields of a rule represent the possible values of thecorresponding fields in actual network traffic that matches thisrule. Each network field could be a single value or range ofvalues. Filtering actions are either toaccept, which permitsthe packet into or from the secure network, or todeny, whichcauses the packet to be blocked. The packet is permitted orblocked by a specific rule if the packet header informationmatches all the network fields of this rule. Otherwise, thefollowing rule is examined and the process is repeated until amatching rule is found or the default policy action is performed[3, 4]. In this paper, we assume a “deny” default policy action.

Filtering Rule Format: It is possible to use any field inIP, UDP or TCP headers in the rule filtering part, however,practical experience shows that the most commonly usedmatching fields are: protocol type, source IP address, sourceport, destination IP address and destination port. Some otherfields, like TTL and TCP flags, are occasionally used forspecific filtering purposes [5]. The following is the commonformat of packet filtering rules in a firewall policy:

<order><protocol><s ip><s port><d ip><d port><action>

In this paper, we refer to the network fields as the “5-tuple filter.” The order of the rule determines its positionrelative to other filtering rules. IP addresses can be a host (e.g.140.192.37.120), or a network address (e.g. 140.192.37.*).

Ports can be either a single specific port number, or any portnumber indicated by “any.” Some firewall implementationsallow the usage of non-wildcard ranges in specifying sourceand destination addresses or ports. However, it is alwayspossible to split a filtering rule with a multi-value field intoseveral rules each with a single-value field [18]. An exampleof typical firewall rules is shown in Figure 1.

III. F IREWALL POLICY MODELLING

As a basic requirement for any firewall policy managementsolution, we first model the relations between the rules in afirewall policy. Rule relation modelling is necessary for analyz-ing the firewall policy and designing management techniquessuch as anomaly discovery and policy editing. In this section,we formally describe our model of firewall rule relations.

A. Formalization of Firewall Rule Relations

To be able to build a useful model for filtering rules, weneed to determine all the relations that may relate packetfilters. In this section we define all the possible relations thatmay exist between filtering rules, and we show that there isno other relation exists. We determine the relations based oncomparing the network fields of filtering rules as follows.

Definition 1: Rules Rx and Ry are completely disjointifevery field inRx is not a subset and not a superset and notequal to the corresponding field inRy.

Formally, Rx<CDRy iff

∀i : Rx[i] 6./ Ry[i]where ./ ∈ {⊂,⊃, =},

i ∈ {protocol, sip, s port, d ip, d port}Definition 2: RulesRx andRy areexactly matchedif every

field in Rx is equal to the corresponding field inRy.Formally, Rx<EMRy iff

∀i : Rx[i] = Ry[i]wherei ∈ {protocol, sip, s port, d ip, d port}

Definition 3: RulesRx and Ry are inclusively matchedifthey do not exactly match and if every field inRx is a subsetor equal to the corresponding field inRy. Rx is called thesubset matchwhile Ry is called thesuperset match.

3

tcp

∗.∗.∗.∗

udp

140.192.37.∗

∗ ∗ ∗

161.120.33.40

80

accept

rule 3

∗.∗.∗.∗

80 21

accept accept

rule 6rule 2

∗.∗.∗.∗

∗

161.120.33.40

∗.∗.∗.∗

53

accept

rule 10

deny

rule 12

∗

53

accept

rule 9

src_ip

src_port src_port

dst_ip

dst_portdst_port

actionaction

src_port

dst_port dst_port

action actionaction

140.192.37.20

∗∗.∗.∗.∗

80

deny

rule 1

deny

rule 5

src_port

dst_ip

dst_port

action action

140.192.37.30

∗∗.∗.∗.∗

21

src_port

dst_ip

dst_port

∗.∗.∗.∗

deny

rule 8

∗

dst_port

action

dst_ip

161.120.33.40

dst_ip

dst_port

161.120.33.40

21

deny accept

rule 7rule 4

action

dst_ip

protocol

140.192.37.∗

src_ip

action

src_port

80

action

dst_port

2 3 6 7

Shadowing

Redundancy

Correlation

Generalization

8 4 8 7 8 4 8 12 129

Figure 2. The policy tree for the firewall policy in Figure 1.

Formally, Rx<IMRy iff

∀i :Rx[i] ⊆ Ry[i]and∃j such that:Rx[j] 6= Ry[j]

wherei, j ∈{protocol, sip, s port, d ip, d port}

For example, in Figure 1, Rule 1 inclusively matches Rule2. Rule 1 is the subset match of the relation while Rule 2 isthe superset match.

Definition 4: Rules Rx and Ry are partially disjoint (orpartially matched) if there is at least one field inRx that is asubset or a superset or equal to the corresponding field inRy,and there is at least one field inRx that is not a subset andnot a superset and not equal to the corresponding field inRy.

Formally, Rx<PDRy iff

∃i, j such thatRx[i] ./ Ry[i] andRx[j] 6./ Ry[j]where ./ ∈ {⊂,⊃, =},

i, j ∈ {protocol, sip, s port, d ip, d port}, i 6= j

For example, Rule 2 and Rule 6 in Figure 1 are partiallydisjoint (or partially matched).

Definition 5: RulesRx andRy arecorrelatedif some fieldsin Rx are subsets or equal to the corresponding fields inRy, and the rest of the fields inRx are supersets of thecorresponding fields inRy.

Formally, Rx<CRy iff

∀i :Rx[i] ./ Ry[i] and

∃i, j such that:Rx[i] ⊂ Ry[i] andRx[j] ⊃ Ry[j]where ./ ∈ {⊂,⊃, =},

i, j ∈ {protocol, sip, s port, d ip, d port}, i 6= j

For example, Rule 1 and Rule 3 in Figure 1 are correlated.

The following theorems show that these relations aredistinct, i.e. only one relation can relateRx and Ry, andcomplete, i.e. there is no other relation betweenRx and Ry

could exist.

Theorem 1:Any two k-tuple filters in a firewall policy arerelated by one and only one of the defined relations.

Proof: Intuitively, we can simply show that the intersectionbetween any two relations in< is an empty set. In [1], weprove by contradiction that there are no two rulesRx andRy

such thatRx<1Ry andRx<2Ry and<1 6= <2 .

Theorem 2:The union of these relations represents theuniversal set of relations between any twok-tuple filters ina firewall policy.

Proof: Intuitively, we first prove that the relation betweenany two 2-tuple filters,Rx and Ry, must be in<. This issimply shown by enumerating permutations of all possiblerelations between the fields ofRx andRy. Since any two fieldscan be related with any relation in{=,⊂,⊃, 6=}, thus thereare only 16 possible combinations forRx and Ry relations(e.g. Rx[field1] = Ry[field1], Rx[field2] ⊂ Ry[field2] ⇒Ry<IMRx. This shows that any relation betweenRx andRy

must be one of the rules relations in<. Next, we prove thatadding one more field to any two filters related with one of thedefined relations above will produce two filters,R′x and R′y,that are also related by one of the defined relations above. Wecan also show this by enumerating all combinations betweenRx and Ry and the added field as follows:Rx<IMRy,Rx[fieldk + 1] ⊃ Ry[fieldk + 1] ⇒ R′y<CR′x. Based onthese two results, we then prove by induction that any tworules with k-tuple filters must be related with each other byone of the rule relations defined in this section.

4

B. Firewall Policy Representation

We represent the firewall policy by a single rooted tree thatwe name thepolicy tree. The tree model provides a simple andapprehensible representation of the filtering rules and at thesame time allows for easy discovery of relations and anomaliesamong the rules. Each node in a policy tree represents a fieldof the filtering rule, and each branch at this node representsa possible value of the associated field. The root node ofthe policy tree represents the protocol field, the leaf nodesrepresent the action field, and intermediate nodes representother 5-tuple filter fields in order. Every tree path starting atthe root and ending at a leaf represents a rule in the policy andvice versa. Rules that have the same field value at a specificnode, will share the same branch representing that value.

Figure 2 illustrates the policy tree model of the securitypolicy given in Figure 1. Notice that every rule should havean action leaf in the tree. The dotted box below each leafindicates the rule represented by that branch in addition toother rules that are in anomaly with it as described in thefollowing section. The tree shows that Rules 1 and 5 each hasa separate source address branch as they have different fieldvalues, whereas Rules 2, 4, 6 and 7 share the same sourceaddress branch as they all have the same field value. Alsonotice that rule 8 has a separate branch and also appears onother rule branches of which it is a superset, while Rule 4 hasa separate branch and also appears on other rule branches ofwhich it is a subset.

The basic idea for building the policy tree is to insert thefiltering rule in the correct tree path. When a rule field isinserted at any tree node, the rule branch is determined basedon matching the field value with the existing branches. If abranch exactly matches the field value, the rule is inserted inthis branch, otherwise a new branch is created. The rule alsopropagates in superset or superset branches to preserve therelations between the policy rules.

IV. I NTRA-FIREWALL ANOMALY DISCOVERY

The ordering of filtering rules in a centralized firewallpolicy is very crucial in determining the security policy withinthis firewall. This is because the packet filtering process isperformed by sequentially matching the packet against filteringrules until a match is found. If filtering rules are disjoint,the ordering of the rules is insignificant. However, it is verycommon to have filtering rules that are inter-related. In thiscase, if the relative rule ordering is not carefully assigned,some rules may be always screened by other rules producingan incorrect security policy. Moreover, when a security policycontains a large number of filtering rules, the possibility ofwriting conflicting or redundant rules is relatively high. Anintra-firewall policy anomaly is defined as the existence oftwo or more filtering rules that may match the same packetor the existence of a rule that can never match any packeton the network paths that cross the firewall. In this section,we classify different anomalies that may exist among filteringrules and then describe a technique for discovering theseanomalies.

A. Intra-Firewall Anomaly Classification

Here, we describe and then define a number of possibleintra-firewall policy anomalies. These include errors fordefinite conflicts that cause some rules to be alwayssuppressed by other rules, or warnings for potential conflictsthat may be implied in related rules.

1) Shadowing anomaly:A rule is shadowed when a previ-ous rule matches all the packets that match this rule, such thatthe shadowed rule will never be activated. Formally, ruleRy

is shadowed by ruleRx if the following condition holds:

Rx[order] < Ry[order], Rx<EMRy, Rx[action] 6= Ry[action]Rx[order] < Ry[order], Rx<IMRy, Rx[action] 6= Ry[action]

As illustrated in the rules in Figure 1, Rule 4 is a subsetmatch of Rule 3 with a different action. We say that Rule 4 isshadowed by Rule 3 because Rule 4 will never get activated.

Shadowing is a critical error in the policy, as the shadowedrule never takes effect. This might cause an accepted trafficto be blocked or a denied traffic to be permitted. Therefore,as a general guideline, if there is an inclusive or exact matchrelationship between two rules, the superset (or general) ruleshould come after the subset (or specific) rule. It is importantto discover shadowed rules and alert the administrator tocorrect this error by reordering or removing the shadowed rule.

2) Correlation anomaly:Two rules are correlated if theyhave different filtering actions, and the first rule in ordermatches some packets that match the second rule and thesecond rule matches some packets that match the first rule.Formally, ruleRx and ruleRy have a correlation anomaly ifthe following condition holds:

Rx<CRy, Rx[action] 6= Ry[action]

As illustrated in the rules in Figure 1, Rule 1 is in correlationwith Rule 3 because each rule performs a different action onpart of the traffic that matches the other rule. The two ruleswith this ordering imply that all HTTP traffic that is comingfrom the address 140.192.37.20 and going to 161.120.33.40is denied. However, if their order is reversed, the same trafficwill be accepted.

Correlation is considered an anomaly warning becausethe correlated rules imply an action that is not explicitlyhandled by the filtering rules. Therefore, in order to resolvethis conflict, we point out the correlation between the rulesand prompt the user to choose the proper order that complieswith the security policy requirements.

3) Generalization anomaly:A rule is a generalization ofa preceding rule if they have different actions, and if thefirst rule can match all the packets that match the secondrule. Formally, ruleRy is a generalization of ruleRx if thefollowing condition holds:

Rx[order] < Ry[order], Ry<IMRx, Rx[action] 6= Ry[action]

As illustrated in the rules in Figure 1, Rule 2 is a gen-eralization of Rule 1 because Rule 1 applies on a subset of

5

start

0

exact?

1

exact?

4

superset?

3

Ry ℜ

IM Rx

8

redundant

12

shadowed

11

general

13

correlated

14none

15

proto y = proto x

proto y ⊂ p

roto x

protoy ⊃ proto

x superset?

6

srcy = srcx

srcy ⊇ src

x

dsty ⊆ dstx

actiony = action

x

actiony ≠ actionx

dst y ⊆ d

st x

dsty ⊇ dstx

srcy ⊂ src

x

srcy ⊃

srcx

subset?

2

subset?

5

srcy ⊆ src

x

correlated?

7

srcy ⊃ src

x

srcy ⊂ src

x

dsty ⊆ dstx

dsty ⊃ dstx

dsty ⊃ dst

x

dsty ⊃ dst

x

dst y ⊂ dst x

src y ≠ srcx

src y ≠ srcx

src

y ≠ src

x

dsty ≠ dst x

dsty ≠ dstx

dst y

≠ dst x

dsty ≠ dstx

protoy ≠ proto

x

Rx ℜ

IM Ry

9

action y

= actio

n x

actiony ≠ action

x

Rx ℜ

C Ry

10

actiony ≠ action

x

action y = action x

Figure 3. State diagram for detecting intra-firewall anomalies for rulesRx andRy , whereRy comes afterRx.

the traffic that matches Rule 2. These two rules imply that allHTTP traffic that is coming from the address 140.192.37.* willbe accepted ,except the traffic that comes from 140.192.37.20.

Generalization is often used to exclude a specific part ofthe traffic from a general filtering action. It is consideredonly an anomaly warning because the specific rule makes anexception of the general rule. This might cause an acceptedtraffic to be blocked or a denied traffic to be permitted, andthus it is important to highlight its action to the administratorfor confirmation.

4) Redundancy anomaly:A redundant rule performs thesame action on the same packets as another rule such that ifthe redundant rule is removed, the security policy will not beaffected. Formally, ruleRy is redundant to ruleRx if one ofthe following conditions holds:

Rx[order] < Ry[order], Rx<EMRy, Rx[action] = Ry[action]Rx[order] < Ry[order], Rx<IMRy, Rx[action] = Ry[action]

Whereas ruleRx is redundant to ruleRy if:

Rx[order] < Ry[order], Ry<IMRx, Rx[action] = Ry[action]

provided thatRx is not involved in any generalization orcorrelation anomalies with other rules in betweenRx andRy.

Referring to Figure 1, Rule 7 is redundant to Rule 6, andRule 9 is redundant to Rule 10. Therefore, if Rules 7 and 9 areremoved, the effect of the resulting policy will not be changed.

Redundancy is considered an error in the firewall policy.A redundant rule may not contribute in making the filteringdecision. However, it adds to the size of the filtering ruletable, and therefore increases the search time and spacerequirements of the packet filtering process [17]. In general,to avoid redundant rules, a superset rule following a subsetrule should have an opposite filtering action. It is importantto discover redundant rules so that the administrator maymodify its filtering action or remove it altogether.

5) Irrelevance anomaly:A filtering rule in a firewall isirrelevant if this rule cannot match any traffic that might flowthrough this firewall. This exists when both the source addressand the destination address fields of the rule do not match anydomain reachable through this firewall. In other words, thepath between the source and destination addresses of this ruledoes not pass through the firewall. Thus, this rule has no effecton the filtering outcome of this firewall. Formally, ruleRx infirewall F is irrelevant if:

F 6∈ {n : n is a node on a path fromRx[src] to Rx[dst]}Referring to Figure 1, Rule 11 is irrelevant because the

traffic that goes between the source (140.192.38.*) and thedestination (161.120.35.*) does not pass through this firewall.

Irrelevance is considered an anomaly because it adds un-necessary overhead to the filtering process and it does notcontribute to the policy semantics. It is well-understood thatkeeping the filtering rule table as small as possible helpsin improving the overall firewall performance [17]. Thus,discovering irrelevant rules is important goal for the networksecurity administrator.

B. Intra-Firewall Anomaly Discovery Algorithm

The state diagram shown in Figure 3 illustrates intra-firewallanomaly discovery states for any two rules,Rx andRy, wherethe two rules are in the same firewall andRy comes afterRx in the order. For simplicity, the address and port numberare both integrated into one field for the rule source anddestination fields. This simplification reduces the number ofstates and simplifies the explanation of the diagram. A similarstate diagram can be produced for the real case of five fieldswith a substantially larger number of states involved.

Initially no relationship is assumed. Each field inRy iscompared to the corresponding field inRx starting with theprotocol, then source address and port, and finally destinationaddress and port. The relationship between the two rules isdetermined based on the result of subsequent comparisons. Ifevery field ofRy is a subset or equal to the corresponding fieldin Rx and both rules have the same action,Ry is redundant

6

function IntraAnomalyDiscovery(rule_list)root = new nodefor each rule in rule_list do

IntraAnomalyTransition(rule, PROTOCOL, root, UNDETERMINED)return root

end function

Figure 4. Inra-firewall anomaly discovery algorithm.

function IntraAnomalyTransition(rule, field, node, relation)if field = ACTION then

value_found = FALSEfor each branch in node.branch_list do

if branch.value = rule.field.value thenvalue_found = TRUEif relation = UNDETERMINED then relation = EXACTIntraAnomalyTransition(rule, field.next, branch.node, relation)

else if rule.field.value is superset of branch.value thenif relation is in {SUBSET, CORRELATED} then

IntraAnomalyTransition(rule, field.next, branch.node, CORRELATED)else

IntraAnomalyTransition(rule, field.next, branch.node, SUPERSET)else if rule.field.value is subset of branch.value then

if relation is in {SUPERSET, CORRELATED} thenIntraAnomalyTransition(rule, field.next, branch.node, CORRELATED)

elseIntraAnomalyTransition(rule, field.next, branch.node, SUBSET)

end ifend forif value_found = FALSE then

new_branch = new TreeBranch(rule, rule.field, rule.field.value)node.branch_list.add(new_branch)IntraAnomalyTransition(rule, field.next, new_branch.node, DISJOINT)

end ifelse /* action field reached */

IntraAnomalyTermination(rule, field, node, relation)end if

end function

Figure 5. State transition of intra-firewall anomaly discovery algorithm.

function IntraAnomalyTermination(rule, field, node, relation)anomaly = NOANOMALYif node has branch_list then

branch = node.branch_list.first()if relation = CORRELATED then

if not rule.action = branch.value thenanomaly = CORRELATIONbranch.rule.anomaly = CORRELATIONreport rule rule.id is in correlation with rule branch.rule.id

end ifelse if relation = SUPERSET and not rule.action = branch.value then

anomaly = GENERALIZATIONbranch.rule.anomaly = SPECIALIZATIONreport rule rule.id is a generalization of rule branch.rule.id

else if relation = SUPERSET and rule.action = branch.value thenif branch.rule.anomaly = NOANOMALY then

branch.rule.anomaly = REDUNDANCYreport rule branch.rule.id is redundant to rule rule.id

end ifelse if rule.action = branch.value then

anomaly = REDUNDANCYreport rule rule.id is redundant to rule branch.rule.id

else if not rule.action = branch.value thenanomaly = SHADOWINGreport rule rule.id is shadowed by rule branch.rule.id

end ifend ifrule.anomaly = anomaly

end function

Figure 6. State termination of intra-firewall anomaly discovery algorithm.

7

to Rx, while if the actions are different,Ry is shadowedby Rx. If every field of Ry is a superset or equal to thecorresponding field inRx and both rules have the same action,Rx is potentially redundant toRy, while if the actions aredifferent,Ry is a generalization ofRx. If some fields ofRx aresubsets or equal to the corresponding fields inRy, and somefields of Rx are supersets to the corresponding fields inRy,and their actions are different, thenRx is in correlation withRy. Identifying irrelevant rules requires the knowledge of thenetwork connectivity. Discovering this intra-firewall anomalyis discussed later in Section V-C along with the inter-firewallanomaly discovery algorithm. If none of the preceding casesoccur, then the two rules do not involve any anomalies.

The basic idea for discovering anomalies is to determineif any two rules coincide in their policy tree paths. If thepath of a rule coincides with the path of another rule, there isa potential anomaly that can be determined based on intra-firewall anomaly definitions in Section IV-A. If rule pathsdo not coincide, then these rules are disjoint and they haveno anomalies. The routine for building the policy tree anddiscovering intra-firewall anomalies is shown in Figure 4. Theroutine invokes two main routines: an anomaly state transitionroutine (Figure 5), which represents the transition states inthe state diagram, and an anomaly state termination routine,(Figure 6), which represents the termination states.

The discovery routine is initially invoked for every rulewith an UNDETERMINEDrelation. If the field of the newrule matches an already existing field branch, then the nextrelation state is determined based on the shown state diagram.The algorithm is executed recursively to let the rule propagatein existing branches and check the remaining fields. As therule propagates, the relation state is updated until the finalstate is reached. If there is no exact match for a field value, anew branch is created at the current node to represent a newfield value, and the relation state is set toDISJOINT . Thedecision routine is activated once all the rule fields have beeninserted in the tree and the action field is reached. If the ruleaction coincides with the action of another rule on the tree, ananomaly is discovered. At that point the final anomaly state isdetermined and any anomalies are reported together with therules involved.

Applying the algorithm on the rules in Figure 1, the discov-ered anomalies are marked in the dotted boxes at the bottomof the policy tree in Figure 2. Shadowed rules are marked witha triangle, redundant rules with a square, correlated rules witha pentagon and generalization rules with a circle.

V. I NTER-FIREWALL ANOMALY DISCOVERY

It is very common to have multiple firewalls installedin the same enterprize network. This has many networkadministration advantages. It gives local control for eachdomain according to the domain security requirements andapplications. For example, some domains might demand toblock RTSP traffic or multicast traffic, however, other domainsin the same network might request to receive the same traffic.Multi-firewall installation also provides inter-domain security,and protection from internally generated traffic. Moreover,

�������������������→����Figure 7. Cascaded firewalls isolating two domains.

end-users might use firewalls in their personal workstationsfor other reasons. However, because of the decentralized natureinherent to the security policy in distributed firewalls, the po-tential of anomalies between firewalls significantly increases.Even if every firewall policy in the network does not containrule anomalies described in Section IV-A, there could beanomalies between policies of different firewalls. For example,an upstream firewall might block a traffic that is permitted bya downstream firewall or vice versa. In the first case, thisanomaly is called inter-firewall “shadowing” which similarin principle to rule shadowing discussed in the intra-firewallanomaly analysis. In the other case, the resulted anomaly iscalled “spurious traffic” because it allows unwanted trafficto cross portions of the network and increases the networkvulnerability to denial of service attack. In this section, we firstdefine the anomalies that may exist in a distributed firewallenvironment, and then we identify with examples differenttypes of inter-firewall anomalies.

A. Inter-Firewall Anomaly Definition

In general, an inter-firewall anomaly may exist if any twofirewalls on a network path take different filtering actions onthe same traffic. We will first illustrate the simple case ofmultiple cascaded firewalls isolating two network sub-domainswhere the firewalls are installed at the routing points in thenetwork.

Referring to Figure 7, we assume a traffic stream flowingfrom sub-domainDx to sub-domainDy across multiple cas-caded firewalls installed on the network path between the twosub-domains. At any point on this path in the direction of flow,a preceding firewall is called anupstream firewallwhereas afollowing firewall is called adownstream firewall. The closestfirewall to the flow source sub-domain (FWx) is called themost-upstream firewall, while The closest firewall to the flowdestination sub-domain (FWy) is called themost-downstreamfirewall.

Using the above network model, we can say that for anytraffic flowing from sub-domainDx to sub-domainDy ananomaly exists if one of the following conditions holds:

1) The most-downstream firewall accepts a traffic that isblocked by any of the upstream firewalls.

2) The most-upstream firewall permits a traffic that isblocked by any of the downstream firewalls.

3) A downstream firewall denies a traffic that is alreadyblocked by the most-upstream firewall.

On the other hand, all upstream firewalls should permit anytraffic that is permitted by the most-downstream firewall inorder that the flow can reach the destination.

8����������������������� �� �� ������������� �� �� ������ �� �� ����� �� �� �

1: tcp, 161.120.*.* : any, *.*.*.* : 80, accept2: tcp, 140.192.*.* : any, *.*.*.* : 25, accept3: tcp, *.*.*.* : any, 140.192.*.* : 25, accept4: tcp, 140.192.*.* : any, 161.120.*.* : 80, deny5: tcp, 161.120.33.* : any, 140.192.37.1 : 23, deny6: tcp, 161.120.*.* : any, 140.192.*.* : 22, deny7: tcp, 161.120.*.* : any, 140.192.*.* : any, accept8: tcp, 140.192.*.* : any, 161.120.*.* : any, accept9: tcp, *.*.*.* : any, *.*.*.* : any, deny

1: tcp, 161.120.*.* : any 140.192.*.* : 80, accept2: tcp, 140.192.*.* : any, 161.120.*.* : 80, accept3: tcp, 161.120.*.* : any, 140.192.22.5 : 21, accept4: tcp, 161.120.33.* : any 140.192.37.* : 23, deny5: tcp, 161.120.*.* : any, 140.192.*.* : 23, accept6: tcp, 161.120.24.* : any, 140.192.37.3 : 25, deny7: tcp, 161.120.24.* : any, 140.192.*.* : 25, accept8: tcp, *.*.*.* : any, *.*.*.* : any, deny

1: tcp, 161.120.*.* : any, 140.192.*.* : 80, accept2: tcp, 161.120.*.* : any, 140.192.22.5 : 21, deny3: tcp, 161.120.*.* : any, 140.192.*.* : 21, accept4: tcp, 140.192.*.* : any, 161.120.33.* : 23, accept5: tcp, 161.120.33.* : any, 140.192.*.* : 23, accept6: tcp, 161.120.24.* : any, 140.192.37.3 : 25, deny7: tcp, 161.120.24.* : any, 140.192.22.5 : 25, deny8: tcp, 161.120.*.* : any, 140.192.37.* : 25, accept9: tcp, *.*.*.* : any, *.*.*.* : any, deny

Figure 8. An example for a hierarchical distributed firewall setup.

B. Inter-Firewall Anomaly Classification

In this section, we classify anomalies in multi-firewallenvironments. Our classification rules are based on the basiccase of cascaded firewalls illustrated in Figure 7, assumingthe network traffic is flowing from domainDx to domainDy.Rule Ru belongs to the policy of the most-upstream firewallFWx, while rule Rd belongs to the policy of the most-downstream firewallFWy. We assume that no intra-firewallshadowing or redundancy exists in any individual firewall.As illustrated in Section IV-A, this implies that every “deny”rule should be followed by a more general “accept” rule, andthe default action of unspecified traffic is “deny”.

1) Shadowing Anomaly:A shadowing anomaly occurs ifan upstream firewall blocks the network traffic accepted by adownstream firewall. Formally, ruleRd is shadowed by ruleRu if one of the following conditions holds:

Rd<EMRu, Ru[action]=deny, Rd[action]=accept (1)

Rd<IMRu, Ru[action]=deny, Rd[action]=accept (2)

Ru<IMRd, Ru[action]=deny, Rd[action]=accept (3)

Ru<IMRd, Ru[action]=accept, Rd[action]=accept (4)

Intuitively, in cases (1) and (2), the upstream firewallblocks completely the traffic permitted by the downstreamfirewall. Rules (2/FW2, 3/FW1), and Rules (8/FW1, 4/FW2)in Figure 8 are examples of cases (1) and (2) respectively.In cases (3) and (4) the upstream firewall blocks partiallythe traffic permitted by the downstream firewall. Rules(7/FW2, 7/FW1), and Rules (5/FW2, 5/FW1) in Figure 8are examples of cases (3) and (4) respectively.

2) Spuriousness Anomaly:A spuriousness anomaly occursif an upstream firewall permits the network traffic denied by adownstream firewall. Formally, ruleRu allows spurious traffic

to rule Rd if one of the following conditions holds:

Ru<EMRd, Ru[action]=accept, Rd[action]=deny (5)

Ru<IMRd, Ru[action]=accept, Rd[action]=deny (6)

Rd<IMRu, Ru[action]=accept, Rd[action]=deny (7)

Rd<IMRu, Ru[action]=accept, Rd[action]=accept (8)

Ru<IMRd, Ru[action]=deny, Rd[action]=deny (9)

In cases (5) and (6), the ruleRu in the upstream firewallpermits unwanted traffic because it is completely blockedby Rd in the downstream firewall. Examples of these casesare Rules (2/FW1, 4/FW0), and Rules (2/FW1, 9/FW2) inFigure 8 respectively. In cases (7) and (8) part of the trafficallowed by ruleRu in upstream firewall is undesired spurioustraffic since it is blocked by ruleRd in the downstreamfirewall. Examples of these cases are also found in followingRules: (5/FW2, 4/FW1), and (3/FW2, 3/FW1) in Figure 8respectively. Case (9) is not as obvious as the previous casesand it needs further analysis. Since we assume there is noredundancy in the upstream firewall, the fact thatRu has adeny action implies that there exists a superset rule in theupstream firewall that followsRu and accepts traffic blockedby Rd. Rules (5/FW0, 4/FW2) in Figure 8 are an exampleof this case.

3) Redundancy Anomaly:A redundancy anomaly occursif a downstream firewall denies the network traffic alreadyblocked by an upstream firewall. Formally, ruleRd is redun-dant to ruleRu if, on every path to whichRu and Rd arerelevant, one of the following conditions holds:

Rd<EMRu, Ru[action]=deny, Rd[action]=deny (10)

Rd<IMRu, Ru[action]=deny, Rd[action]=deny (11)

In both of these cases, the deny action in the downstreamfirewall is unnecessary because all traffic denied byRd isalready blocked byRu in the upstream firewall. In Figure 8,Rules (6/FW2, 6/FW1), and Rules (9/FW2, 6/FW0) areexamples of cases (10) and (11) respectively.

9

4) Correlation Anomaly: A correlation anomaly occursas a result of having two correlated rules in the upstreamand downstream firewalls. We defined correlated rules inSection III-A. Intra-firewall correlated rules are anomaly onlyif these rules have different filtering actions. However, corre-lated rules of any action are always a source of anomaly indistributed firewalls because of the implied rule resulting fromthe conjunction of the correlated rules. This creates not onlyambiguity in the inter-firewall policy, but also spurious, andshadowing anomalies. Formally, the correlation anomaly forrules Ru and Rd occurs if one of the following conditionsholds:

Ru<CRd, Ru[action]=accept, Rd[action]=accept (12)

Ru<CRd, Ru[action]=deny, Rd[action]=deny (13)

Ru<CRd, Ru[action]=accept, Rd[action]=deny (14)

Ru<CRd, Ru[action]=deny, Rd[action]=accept (15)

An example for case (12) isRu : tcp, 140.192. ∗ .∗, any, 161.120.33.∗, 80, acceptRd : tcp, 140.192.37.∗, any, 161.120. ∗ .∗, 80, accept

In this example, effectively, the correlative conjunction ofthese two rules implies that only the traffic coming from140.192.37.* and destined to 161.120.33.*. will be acceptedas indicated in the following implied ruleRi

Ri : tcp, 140.192.37.∗, any, 161.120.33.∗, 80, acceptThis means that other traffic destined to 161.120.*.* willbe shadowed at the upstream firewall, while spurious trafficoriginating from 140.192.*.* will reach the downstreamfirewall.

For case (13) the example isRu : tcp, 140.192. ∗ .∗, any, 161.120.33.∗, 80, denyRd : tcp, 140.192.37.∗, any, 161.120. ∗ .∗, 80, deny

In this case, the resulting action at the downstream firewallwill deny the traffic coming from 140.192.37.* and destinedto 161.120.33.*. The implied filtering ruleRi will be

Ri : tcp, 140.192.37.∗, any, 161.120.33.∗, 80, denyThis means that other traffic originating from 140.192.*.*will be shadowed at the upstream firewall, while spurioustraffic destined to 161.120.*.* may reach the downstreamfirewall. A possible resolution for cases (11) and (12) is toreplace each of the correlated rules with the effective filteringrule.

The example for case (14) isRu : tcp, 140.192. ∗ .∗, any, 161.120.33.∗, 80, acceptRd : tcp, 140.192.37.∗, any, 161.120. ∗ .∗, 80, deny

This example shows that the resulting filtering action at theupstream firewall permits the traffic that is coming from140.192.37.* and destined to 161.120.33.*. However, thesame traffic is blocked at the downstream firewall, resultingin spurious traffic flow. To resolve this anomaly, an extra ruleRi should be added in the upstream firewall prior toRu suchthat it blocks the spurious traffic as follows

Ri : tcp, 140.192.37.∗, any, 161.120.33.∗, 80, deny

As for case (15), the example is

Ru : tcp, 140.192. ∗ .∗, any, 161.120.33.∗, 80, denyRd : tcp, 140.192.37.∗, any, 161.120. ∗ .∗, 80, accept

This example shows a different situation where the resultingfiltering action at the upstream firewall will block thetraffic that is coming from 140.192.37.* and destined to161.120.33.*. However, because this traffic is accepted at thedownstream firewall,Rd is shadowed byRu. To resolve thisanomaly, an extra ruleRi should be added in the upstreamfirewall beforeRu to avoid the shadowing anomaly as follows

Ri : tcp, 140.192.37.∗, any, 161.120.33.∗, 80, acceptIn the following theorem, we prove that the set of anomaly

cases we presented above are covering all the possibleinter-firewall anomalies.

Theorem 3:This set of anomalies represent all filteringanomalies that might exist between rules in any two firewalls.

Proof: Based on the rule relations defined in Section III-Aand all possible permutations with action values, we cansimply enumerate all possible relations between any twofiltering rules in two different firewalls. This results in 24possible relations. In addition to the 15 relation described inthis section, there are 9 more relations listed below:

Ru<EMRd, Ru[action] = accept,Rd[action] = accept (16)

Ru<CDRd, Ru[action]∈ {accept,deny},Rd[action]∈ {accept,deny} (17-20)

Ru<PDRd, Ru[action]∈ {accept,deny},Rd[action]∈ {accept,deny} (21-24)

None of the nine cases cause any anomaly. For instance,case (16) is needed to permit the traffic between the twofirewalls and cases (17-24) represent disjoint rules that operateon different traffic. Therefore, none of these cases could leadto a possible anomaly between two firewalls. Since these casesidentify all possible relations between two inter-firewall rules,the set of anomalies defined in this section is a complete set.Without loss of generality, this result can be applied on anynumber of rules in distributed firewalls.

C. Inter-Firewall Anomaly Discovery Algorithm

This algorithm finds the relations described in Section V-B and discovers the anomalies between filtering rules in twoor more connected firewalls. In Figure 9 we show the statediagram of the inter-firewall anomaly discovery algorithm.The figure shows the anomaly discovery for any two rules,Ru and Rd, where Ru is a rule in the upstream firewallpolicy, and Rd is a rule in the downstream firewall policy.For simplicity, we integrated both the address and port in onefield for the source and destination fields. At the start state,we assume no relationship between the two rules. Each fieldin Rd is compared to the corresponding field inRu startingwith the protocol then source and destination addresses andports. Based on these comparisons, the relation between thetwo rules is determined, as well as the anomaly if it exists. Forexample, ifRu is found to inclusively matchRd (State 10),thenRd is partially shadowed if its action is “accept”, orRu

is spurious if the action ofRd is “deny.”

10

���������������� ���� ����ℜ��������������� ��������������������������

!"#"$% !"#"&'()*)+⊃'()*), ���� ��-./01-./23456⊇345789:;⊂89:<=>?@AB=>?@CDEFGHIJKKELMNOPQR⊆OPQSTUVW⊇TUVXYZ[\⊂YZ[]̂_̀a⊃_̂̀b �c �d �c ��efgh⊆efgijk��lm��lnopqrs⊃pqrtuvwx⊂uvwyz{|}⊆z{|~z{|}⊃z{|~����⊃��������⊃��������⊂��������≠��������≠��������≠��������≠������� ≠���¡¢£¤¥≠¢£¤¦§̈©ª≠§̈©«¬­®̄®°≠¬­®̄®±��ℜ�� ���� ���²�� �d��ℜ³���́µ¶·̧=µ¶·¹º»»¼½¾¿ÀÁ¼ÂÃÄÅÆÇÈÉÊËÌÌÆÍÎÏÐÑÒÓÔÕÐÑÒÓÖ×ØØÙÚÛÜÝ×ØÛÞßàáâããäåæçèâããäåæéêëìíîïðñòóïôõö÷øùúûüýö÷÷þÿø����©�ª⊂���©�«

Figure 9. State diagram for inter-firewall anomaly discovery for rulesRu and Rd, whereRu belongs to the upstream firewall andRd belongs to thedownstream firewall.

function InterAnomalyDiscovery(path_list)for each path in path_list do

IntraAnomalyDiscovery(path.firewalls[1].rules)root = BuildPolicyTree(path.firewalls[1].rules)for each firewall in path.firewalls except path.firewalls[1] do

IntraAnomalyDiscovery(firewall.rules)for each rule in firewall.rules do

if rule.src_ip intersects path.src_domain andrule.dst_ip intersects path.dst_domain thenInterAnomalyTransition(rule, PROTOCOL, root, UNDETERMINED)rule.mark = true

end ifend for

end forend function

Figure 10. Inter-firewall anomaly discovery algorithm.

function InterAnomalyTransition(rule, field, node, relation)if field = ACTION then

value_found = FALSEfor each branch in node.branch_list do

if branch.value = rule.field.value thenvalue_found = TRUEif relation = UNDETERMINED then relation = EXACTInterAnomalyTransition(rule, field.next, branch.node, relation)

else if rule.field.value is superset of branch.value thenif relation is in {SUBSET, CORRELATED} then

InterAnomalyTransition(rule, field.next, branch.node, CORRELATED)else

InterAnomalyTransition(rule, field.next, branch.node, SUPERSET)else if rule.field.value is subset of branch.value then

value_found = TRUEif relation is in {SUPERSET, CORRELATED} then

InterAnomalyTransition(rule, field.next, branch.node, CORRELATED)else

InterAnomalyTransition(rule, field.next, branch.node, SUBSET)exit for

end ifend forif value_found = FALSE then

new_branch = new TreeBranch(rule, rule.field, rule.field.value)node.branch_list.add(new_branch)InterAnomalyTransition(rule, field.next, new_branch.node, DISJOINT)

end ifelse /* action field reached */

call InterAnomalyTermination(rule, field, node, relation)end if

end functionFigure 11. State transition of inter-firewall anomaly discovery algorithm.

11

function InterAnomalyTermination(rule, field, node, relation)anomaly = UNDETERMINEDfor each branch in node.branch_list do

if rule.firewall = branch.rule.firewall thenexit for

else if relation = EXACT thenif rule.action = accept and branch.rule.action = deny then

anomaly = SHADOWINGreport rule rule.id is shadowed by rule branch.rule.id

else if rule.action = deny and branch.rule.action = accept thenbranch.rule.anomaly = SPURIOUSNESSreport rule branch.rule.id is spurious to rule rule.id

else if rule.action = deny and branch.rule.action = deny thenanomaly = REDUNDANCYreport rule rule.id is potentially redundant to rule branch.rule.id

end ifelse if relation = SUBSET then

if rule.action = accept and branch.rule.action = deny thenanomaly = SHADOWINGreport rule rule.id is shadowed by rule branch.rule.id

else if branch.rule.action = acceptbranch.rule.anomaly = SPURIOUSNESSreport rule branch.rule.id is partially spurious to rule rule.id

else if rule.action = deny and branch.rule.action = deny thenanomaly = REDUNDANCYreport rule rule.id is potentially redundant to rule branch.rule.id

end ifelse if relation = SUPERSET then

if rule.action = deny thenbranch.rule.anomaly = SPURIOUSNESSreport rule branch.rule.id is spurious to rule rule.id

else if rule.action = accept thenanomaly = SHADOWINGreport rule rule.id is partially shadowed by rule branch.rule.id

end ifelse if relation = CORRELATED then

anomaly = CORRELATIONbranch.rule.anomaly = CORRELATIONreport rule rule.id is in correlation with rule branch.rule.id

end ifend forrule.anomaly = anomaly

end function

Figure 12. State termination of inter-firewall anomaly discovery algorithm.

Since more than two firewalls may exist between sub-domains in an enterprize network, the inter-firewall anomalydiscovery process should be performed on all firewalls inthe path connecting any two sub-domains in the network.For example, in Figure 8, inter-firewall anomaly analysis isperformed on (FW1, FW0) for all traffic that goes betweenD1.2 and the Internet, on (FW2, FW0) for all traffic that goesbetweenD2.2 and the Internet, and on (FW1, FW0, FW2)for all traffic that goes betweenD1.2 andD2.2. Although weuse a hierarchical network topology example, this analysis canbe performed on any network topology as long as there is afixed route between source and destination sub-domains.

The inter-anomaly discovery routine shown in Figure 10invokes two main algorithms: an anomaly state transitionroutine (Figure 11), which represents the transition states in thestate diagram, and an anomaly state termination routine (Fig-ure 12), which represents the termination states. Intuitively,inter-firewall anomaly discovery is achieved by building theaggregate policy tree presented in Section III-B for the fire-walls isolating every two sub-domains in the network. Theroutine takes as an input the list of network paths betweensub-domains. For each path, we determine all the firewalls in

the traffic flow. Then for every firewall in the path, we first runthe intra-firewall anomaly discovery algorithm (Figure 4) toensure that every individual firewall is free from intra-firewallanomalies. Next, we build the policy tree of the most upstreamfirewall (firewall[1] ) and then add into this tree the rulesof all the consecutive firewalls in the path. During this process,only the rules that apply to this path (have the same sourceand destination) are selected and marked. At the end of theroutine, as a result of applying the algorithm on all the networkpaths, the rules that potentially create anomalies are reported.In addition, any rule left unmarked is reported as an irrelevantrule anomaly (Section IV-A) because it does not apply to anypath in the network.

The anomaly state transition routine (Figure 11) is initiallyinvoked for every rule with anUNDETERMINEDrule relation.Based on the field values, the current rule is inserted in thepolicy tree by matching the fields of previously inserted rulesin the tree, these rules belong to the preceding upstreamfirewalls. If the rule is disjoint or correlated, it is inserted intoa new branch. If the rule is a superset match, it is insertedinto all branches of the subset rules. Otherwise, the rule isinserted in the first branch of a rule that is an exact or superset

12

match. Once the rule is inserted in the tree, the anomalystate termination routine (Figure 12) is activated. The routinedetermines the anomaly based on the discovered relation andthe actions of the currently inserted rule with the existing rulein the policy tree as described in Figure 9. If an anomaly isdiscovered, the involved rules are marked accordingly and theanomaly is reported.

As an example, we apply the inter-firewall anomaly dis-covery routine on the example network in Figure 8. We startby identifying the participating sub-domains in the networkgiven the network topology and routing tables. The domainsin the figure areD1.1, D1.2, D2.1, D2.2 in addition to theglobal Internet domain. The Internet domain is basically anyaddress that does not belong to one of the network sub-domains. Afterwards, we identify all the possible directedpaths between any two sub-domains in the network anddetermine the firewalls that control the traffic on that path, andwe run the algorithm on each one of these paths. According tothe figure, the algorithm analyzes 20 distinct paths for inter-firewall anomalies and produces the anomalies indicated inSection V-B.

VI. F IREWALL POLICY EDITING

Firewall policies are often written by different network ad-ministrators and occasionally updated (by inserting, modifyingor removing rules) to accommodate new security requirementsand network topology changes. Editing an enterpriser securitypolicy can be far more difficult than creating a new one.A new filtering rule may not apply to every network sub-domain, therefore this rule should be properly located in thecorrect firewalls to avoid blocking or permitting the wrongtraffic. Moreover, as rules in a local firewall policy are ordered,a new rule must be inserted in a particular order to avoidcreating intra-firewall anomalies. The same applies if the ruleis modified or removed. In this section, we present firewallpolicy editing techniques that simplify the rule editing tasksignificantly, and avoids introducing anomalies due to policyupdates. The policy editor helps the user to determine thecorrect firewalls at which a new rule should be locatedavoiding inter-firewall anomalies, and helps to determine theproper position for the rule within these firewalls avoidingintra-firewall anomalies, and provides visual aids for usersto track and verify policy changes. Using the policy editor,administrators require no prior knowledge or understating ofthe firewall policy in order to insert, modify or remove a rule.

A. Rule Insertion

The process of inserting a new rule in the global securitypolicy is performed in two steps. The first step is to identify thefirewalls in which this rule should be deployed. This is neededin order to apply the filtering rule only on the relevant sub-domains without creating any inter-firewall anomalies. Thesecond step is to determine the proper order of the new rulein each one of these firewalls so that no intra-firewall anomalyis created.

In the first step (Figure 13), we first identify all the possiblepaths that go from the source address to the destination address

of the rule. If any of the source or destination addresses isan external address (Internet address), then we find the pathto/from the closest firewall to the Internet. Second, the rule isinserted in all firewalls in the identified paths if the rule actionis “accept.” Otherwise, the rule is inserted only in the most-upstream firewalls(s) relative to the source(s). As an example,the following two rules are inserted in the security policyshown in Figure 8:R1 : icmp, ∗. ∗ . ∗ .∗, any, 140.192. ∗ .∗, any, denyR2 : icmp, 140.192. ∗ .∗, any, 161.120. ∗ .∗, any, accept

R1 is installed in firewallsFW0 and FW2 because they arethe most-upstream firewalls on the paths from the Internetand domainD2 (161.120.*.*) to domainD1 (140.192.*.*)respectively. On the other hand,R2 is installed in firewallsFW0, FW1 and FW2 because they exist on the path fromthe domainD1 (140.192.*.*) to domainD2 (161.120.*.*).

In the second step (Figure 14), the order of the new rule inthe local policy is determined based on its relation with otherexisting rules. In general, a new rule should be inserted beforeany rule that is a superset match, and after any rule that is asubset match of this rule. The local policy tree is used to keeptrack of the correct ordering of the new rule, and discover anypotential anomalies. We start by searching for the correct ruleposition in the policy tree by comparing the fields of the newrule with the corresponding tree branch values. If the fieldvalue is a subset of the branch, then the order of the new ruleso far is smaller than the minimum order of all the rules inthis branch. If the field value is a superset of the branch, theorder of the new rule so far is greater than the maximum orderof all the rules in this branch. On the other hand, if the ruleis disjoint, then it can given any order in the policy. Similarly,the tree browsing continues evaluating the next fields in therule recursively as long as the field value is an exact match ora subset match of the branch. When the action field is reached,the rule is inserted and assigned the order determined in thebrowsing phase. A new branch is created for the new rule anytime a disjoint or superset match is found. If the new rule isredundant because it is an exact match or a subset match andit has the same action of an existing rule, the policy editorrejects it and prompts the user with an appropriate message.

After inserting the rule in the appropriate firewalls, the inter-firewall anomaly discovery algorithm in Figure 10 is activatedto verify that no intra-firewall or inter-firewall anomalies areintroduced in the distributed security policy, and to identifyany correlation anomalies the new rule might have created.

B. Rule Removal

In distributed firewall environments, removing a rule froma specific firewall may result in creating an inter-firewallanomaly. For example, if a “deny” rule is removed from theupstream firewall, this will result in spurious traffic flowingdownstream, but if an “accept” rule is removed from theupstream firewall, it will block the relevant traffic, and all therelated (exact, subset or superset) downstream rules will beshadowed.

When the user decides to remove a rule from a certainfirewall, the first step is to identify all the source and des-tination sub-domains that will be impacted by removing this

13

function InsertGlobal(rule, network)for every path in network do

if rule.src belongs to path.src andrule.dst belongs to path.dst thenadd path to relevant_paths

for every path in relevant_paths doif rule.action = "accept" then

for every firewall in path.firewalls doInsertRule(rule, rule.id, firewall);

else if rule.action = "deny" thenInsertRule(rule, rule.id, path.firewall[0]);

end forend function

Figure 13. Algorithm for inserting a new rule in distributed firewalls policy.

function InsertRule(rule, field, node)read rule.field.valueif not field = ACTION then

for each branch in node.branch_list doif branch.value = rule.field.value then

target_branch = branchelse if rule.field.value is subset of branch.value then

if rule.max_order > branch.rule_list.getMinOrder() thenrule.max_order = branch.rule_list.getMinOrder()-1target_branch = branch

end ifelse if rule.field.value is superset of branch.value then

if rule.min_order < branch.rule_list.getMaxOrder() thenrule.min_order = branch.rule_list.getMaxOrder()+1

end ifend forif exists target_branch then

InsertRule(rule, field.next, target_branch.node)else

new_branch = new TreeBranch(rule, rule.field, rule.field.value);node.branch_list.add(new_branch);InsertRule(rule, field.next, new_branch.node);

end ifelse

read rule.order where rule.max_order > rule.order > rule.min_orderif node has branch_list then

if rule.min_order=UNDERTERMINED and rule.max_order=UNDERTERMINED thenbranch = node.branch_list.first()if rule.action = branch.value then

error rule rule.id is redundant to rule branch.rule.idelse

error rule rule.id is shadowed by rule branch.rule.idend if

else if not rule.max_order = UNDETERMINED andrule.action = branch.value then

error rule rule.id is redundant to rule branch.rule.idend if

end ifrule_list.insertAt(rule, rule.order)DiscoverAnomaly(rule, tree_root, anomaly)if anomaly in {CORRELATION, GENERALIZATION} then

alert potential anomaly, please confirm policy semanticsend if

end function

Figure 14. Algorithm for inserting a new rule in the local firewall policy.

rule. We use the same technique described in rule insertionprocess to determine the network path between every source-destination domain pair relevant to this rule. In the secondstep, we remove the rule from the firewall policy as follows.If the rule is an “accept” rule, then we remove it from thefirewalls in all paths from source to destination. Otherwise,shadowing and/or spuriousness anomaly is created if the ruleis removed from the upstream and/or the downstream firewalls

respectively. However, if the rule is a “deny” rule, then we justremove it from the local firewall because it does not have anyeffect on other firewalls in the network.

Modifying a rule in a firewall policy is also a criticaloperation. However, a modified rule can be easily verified andinserted based on the rule removal and insertion techniquesdescribed in this section.

14

0

50

100

150

200

250

0 20 40 60 80 100

Number of rules in the firewall

Processing tim

e (m

s)(1) distinct dst

(2) distinct src

(4) average case

(3) worst case

Figure 15. Processing time for intra-firewall anomaly discovery.

Experience Shadowing Redundancy Correlation IrrelevanceExpert 0% 5% 3% 0%

Intermediate 1% 9% 3% 0%Beginner 4% 12% 9% 2%

Figure 16. The average percentage of discovered anomalies in a man-writtencentralized firewall policy.

VII. F IREWALL POLICY ADVISOR:IMPLEMENTATION AND EVALUATION

We implemented the techniques and algorithms describedin Sections V and IV in a software tool called the “FirewallPolicy Advisor” or FPA 1. The tool implements the inter-firewall and intra-firewall anomaly discovery algorithms, aswell as the distributed firewall policy editor. The FPA wasdeveloped using Java programming language and it includesa graphical user interface. In this section, we present ourevaluation study of the usability and the performance of theanomaly discovery techniques described in this paper.

To assess the practical value of the FPA techniques, wefirst use the FPA tool to analyze real firewall rules in ouruniversity network as well as in some local industrial networks(Stonewater Software, Inc.). In many cases, the FPA has shownto be effective by discovering many firewall anomalies thatwere not discovered by human visual inspection. We, thenattempted to quantitatively evaluate the practical use of theFPA by conducting a set of experiments that consider thelevel of network administrator expertise and the frequency ofeach anomaly type. In this experiment, we created two firewallpolicy exercises and asked twelve network administratorswith varying level of expertise in the field to complete eachexercise. The two exercises include writing filtering rules incentralized and distributed firewalls based on a given securitypolicy requirements. We then used the FPA tool to analyze therules in the answer of each one and calculated the ratio of eachanomaly relative to total number of rules. The average numberof rules was 40 in the centralized firewall, and 90 in thedistributed firewall for a network of only three firewalls. The

1http://www.mnlab.cti.depaul.edu/mnlab/projects/FPA

0

40

80

120

160

200

0 10 20 30 40 50

Average number of rules per firewall

Pro

cess

ing

time

(s)

(1) 2-2-2

(2) 3-2-2

(3) 3-3-2

(4) 3-3-3

Figure 17. Processing time for inter-firewall anomaly discovery.

Experience Shadowing Spuriousness Redundancy CorrelationExpert 1% 7% 9% 1%

Intermediate 3% 10% 11% 2%Beginner 6% 14% 17% 2%

Figure 18. The average percentage of discovered anomalies in a man-writtendistributed firewall policy.

results of this experiment are shown in Figures 16 and 18 forthe centralized and distributed firewall exercises respectively.

These results show clearly that the margin of error that canbe done even by an expert administrator is quite significant(about 8% for centralized one and 18% for the distributedone). This figure is even much higher for an intermediate andbeginner administrators (about 13% and 27% for centralizedfirewall and 26% and 39% for the distritbuted firewallsrespectively). Another interesting observation is the highpercentage of redundant as well as spurious rules in allexperience levels.

In the third phase of our evaluation study, we conductednumber of experiments to measure the performance and thescalability of the FPA under different filtering policies andnetwork topologies. Our experiments were performed on aPentium PIII 400 MHz processor with 128 MByte of RAM.

To study the performance of the intra-firewall anomalydiscovery algorithm, we produced four sets of firewall rules.The first set includes rules that are different in the destinationaddress only, and the second set includes rules that havedistinct source addresses. These two sets resemble a realisticcombination of practical firewall rules, and represent the bestcase scenario because they require the minimum policy-treenavigation for analyzing each rule. In the third set, each ruleis a superset match of the preceding rule. This set representsthe worst case scenario because each rule requires completepolicy-tree navigation in order to the analyze the entire rule set.The fourth set includes rules that are randomly selected fromthe three previous sets in order to represent the average casescenario. We used the FPA tool to run the intra-firewall policyanalysis algorithm on each set using various sizes of rule

15

sets (10-90 rules). In each case, we measured the processingtime needed to produce the policy analysis report. The resultswe obtained are shown in Figure 15. Set 1 shows the leastprocessing time because all the rules are aggregated in onebranch in the policy tree, which makes the number of fieldmatches and node creations minimal. Set 2 has a slightlyhigher processing time, since each rule in the set has a distinctbranch at a higher level in the policy tree. This requires moretime to create new tree nodes for inserting each rule in the tree.Set 3 is expected to have the highest processing time sinceevery rule in the set must be matched with all rules in thepolicy tree. Set 4 shows a moderate (average) processing timeand represents the most practical scenario as it combines manydifferent cases. Even in the worst case scenario (Set 3), theprocessing time looks very reasonable; approximately 20-240ms for 10-90 rules. In addition, the processing time increasesabout 2.1-2.8 ms per rule, which is considered insignificantoverhead even if hundreds of rules exist in a firewall.

For evaluating the performance of the inter-firewall anomalydiscovery algorithm, we conducted a similar experiment on anetwork of distributed firewalls. We used a balanced three-level hierarchical network topology connected to the Internetvia the root node. Each non-leaf node in the network hasfiltering capability. We created four networks with differentbranching degrees at each level in the hierarchy starting at theroot node: (1) 2-2-2, (2) 3-2-2, (3) 3-3-2 and (4) 3-3-3. Forexample, the root node in Network 2 has 3 branches, whereasevery node on levels two and three has 2 branches. For eachnetwork, we installed a random set of filtering rules in eachfirewall. The generated topology information and the firewallsetup of each network are used as inputs for our experiment.We then used the FPA to run the inter-firewall policy analysisalgorithm on each network with a different number of rules(10-50 rules) for each firewall. We measured, in each case, theprocessing time required to produce the final policy analysisreport. The results are shown in Figure 17. We noticed thatfor small and mid-size networks (such as Network 1 that has8 sub-domains and Network 2 that has 12 sub-domains), theprocessing time ranges from 3 to 40 seconds. However, in caseof large networks (such as Networks 3 and Network 4 that have18 and 27 sub-domains respectively), the firewall anomalydiscovery requires much higher processing time ranging from11 to 180 depending on the rule complexity. The increase inthe processing time as the network size increases is due to thefact that the complexity of our algorithm is dependant on thetotal number of paths between sub-domains in the network.

VIII. R ELATED WORK

A significant amount of work has been reported in thearea of firewall and policy-based security management. In thissection, we focus our study on related work that intersectswith our work in three areas: packet filter modelling, conflictdiscovery and rule analysis.

Several models have been proposed for filtering rules.Ordered binary decision diagram is used as a model foroptimizing packet classification in [11]. Another model usingtuple space is developed in [21], which combines a set of filters

in one tuple and stored in a hash table. The model in [22]uses bucket filters indexed by search trees. Multi-dimensionalbinary tries are also used to model filters [18]. In [6] ageometric model is used to represent 2-tuple filtering rules.Because these models were designed particularly to optimizepacket classification in high-speed networks, we found themtoo complex to use for firewall policy analysis. We can confirmfrom experience that the tree-based model we use is simpleand powerful enough for this purpose.

Research in policy conflict analysis has been actively grow-ing for many years. However, most of the work in this areaaddresses general management policies rather than firewall-specific policies. For example, authors in [14] classify possiblepolicy conflicts in role-based management frameworks, anddevelop techniques to discover them. A policy conflict schemefor IPSec is presented in [8]. Although this work is very usefulas a general background, it is not directly applicable in firewallanomaly discovery. On the other hand, few research projectsaddress the conflict problem in filtering rules. Both [6] and[10] provide algorithms for detecting and resolving conflictsamong general packet filters. However, they only detect whatwe defined as correlation anomaly because it causes ambiguityin packet classifiers. Other research work go one step forwardby offering query-based tools for firewall policy analysis. In[16] and [23], the authors developed a firewall analysis toolto perform customized queries on a set of filtering rules andextract the related rules in the policy. In [7], an expert systemis used for verifying the functionality of filtering rules byperforming queries. All these tools help in manually verifyingthe correctness of the firewall policy, however, they requirehigh user expertise to write the proper queries that identifiesdifferent firewall policy problems.

In the field of distributed firewalls, current research mainlyfocuses on the management of distributed firewall policies.The first generation of global policy management technologyis presented in [9], which proposes a global policy definitionlanguage along with algorithms for verifying the policy andgenerating filtering rules. However, in [2] the authors adopted abetter approach by using a modular architecture that separatesthe security policy and the underlying network topology toallow for flexible modification of the network topology withoutthe need to update the security policy. Similar work has beendone in [12] with a procedural policy definition language,and in [15] with an object-oriented policy definition language.In terms of distributed firewall policy enforcement, a novelarchitecture is proposed in [13] where the authors suggestusing a trust management system to enforce a centralizedsecurity policy at individual network endpoints based onaccess rights granted to users or hosts. We found that noneof the published work in this area addressed the problem ofdiscovering anomalies in distributed firewall environments.

In conclusion, we could not find any published researchwork that uses low-level filtering rules to perform a completeanomaly analysis and guided editing of centralized and dis-tributed firewall policies.

16

IX. CONCLUSIONS ANDFUTURE WORK

Firewall security, like any other technology, requires propermanagement support to provide proper security services. Thus,just having firewalls on the network boundaries or betweensub-domains may not necessarily make the network any se-cure. One reason of this is the complexity of managing firewallrules and the resulting network vulnerability due to ruleanomalies/conlficts. The Firewall Policy Advisor presentedin this paper provides a number of techniques for purifyingand protecting the firewall policy from rule anomalies. Theadministrator may use the firewall policy advisor to managelegacy firewall policies without prior analysis of filteringrules. In this paper, we formally defined a number of firewallpolicy anomalies such as shadowing, generalization, corre-lation, spurious, redundancy in both centralized and inter-connected (distributed) firewalls. We then proved that theseare the only conflicts that could exist in firewall policies, andpresented a set of algorithms to detect rule anomalies withina single firewall (intra-firewall), and between inter-connectedfirewalls (inter-firewall) in the network. When an anomaly isdetected, users are prompted with proper corrective actions.We intentionally made the tool not to automatically correctthe discovered anomaly but rather alarm the user becausewe believe that the administrator should have the final callon policy changes. A tree-based implementation of FirewallPolicy Advisor is also described in the paper.

Using Firewall Policy Advisor was shown to be veryeffective for firewalls in real-life networks. In regards tousability, the tool was able to discover filtering anomaliesin rules written by expert network administrators. In regardsto performance, although the policy analysis algorithms areparabolically dependant on the number of rules in the firewallpolicy, our experiments show that the average processing timein intra- and inter-firewall anomaly discovery is very reason-able for practical applications. Using our Java implementationof the anomaly discovery algorithms, our results indicate thatit, in the worst case, it takes 10-240 ms of processing time toanalyze a security policy of 10-90 rules in a single firewall.However, in a considerably large network (27 sub-domainswith 13 firewalls), it takes 20-180 s to analyze the filteringrules of all distributed firewalls.

We believe that there is much more to do in firewallpolicy management area. Our future research plan includesimplementation optimization of intra- and inter-firewallanomaly discovery, automatic recovery of anomalies createdas a result of the rule removal in distributed firewalls, ruleplacement based on firewall performance, self-configurablefirewalls, translating low-level filtering rules into high-leveltextual description and vice versa, and policy visualization.

REFERENCES

[1] E. Al-Shaer and H. Hamed. “Design and Implementation of FirewallPolicy Advisor Tools.” Technical Report, August 2002.

[2] Y. Bartal., A. Mayer, K. Nissim and A. Wool. “Firmato: A NovelFirewall Management Toolkit.”Proceedings of 1999 IEEE Symposiumon Security and Privacy, May 1999.

[3] D. Chapman and E. Zwicky.Building Internet Firewalls, Second Edition,Orielly & Associates Inc., 2000.

[4] W. Cheswick and S. Belovin.Firewalls and Internet Security, Addison-Wesley, 1995.

[5] S. Cobb. “ICSA Firewall Policy Guide v2.0.” NCSA Security WhitePaper Series, 1997.

[6] D. Eppstein and S. Muthukrishnan. “Internet Packet Filter Managementand Rectangle Geometry.”Proceedings of 12th Annual ACM-SIAMSymposium on Discrete Algorithms (SODA), January 2001.

[7] P. Eronen and J. Zitting. “An Expert System for Analyzing FirewallRules.” Proceedings of 6th Nordic Workshop on Secure IT-Systems(NordSec 2001), November 2001.

[8] Z. Fu, F. Wu, H. Huang, K. Loh, F. Gong, I. Baldine and C. Xu.“IPSec/VPN Security Policy: Correctness, Conflict Detection and Res-olution.” Proceedings of Policy’2001 Workshop, January 2001.

[9] J. Guttman. “Filtering Posture: Local Enforcement for Global Policies.”Proceedings of 1997 IEEE Symposium on security and Privacy, May1997.

[10] B. Hari, S. Suri and G. Parulkar. “Detecting and Resolving Packet FilterConflicts.” Proceedings of IEEE INFOCOM’00, March 2000.

[11] S. Hazelhusrt. “Algorithms for Analyzing Firewall and Router AccessLists.” Technical Report TR-WitsCS-1999, Department of ComputerScience, University of the Witwatersrand, South Africa, July 1999.

[12] S. Hinrichs. “Policy-Based Management: Bridging the Gap.”Pro-ceedings of 15th Annual Computer Security Applications Conference(ACSAC’99), December 1999.

[13] S. Ioannidis, A. Keromytis, S Bellovin and J. Smith. “Implementing aDistributed Firewall.”Proceedings of 7th ACM Conference on Computerand Comminications Security (CCS’00), November 2000.

[14] E. Lupu and M. Sloman. “Model-Based Tool Assistance for Packet-Filter Design.” Proceedings of Workshop on Policies for DistributedSystems and Networks (POLICY’2001), January 2001.

[15] I. Lck. C. Schfer and H. Krumm. “Conflict Analysis for ManagementPolicies.” Proceedings of IFIP/IEEE International Symposium onIntegrated Network Management (IM’1997), May 1997.

[16] A. Mayer, A. Wool and E. Ziskind. “Fang: A Firewall Analysis Engine.”Proceedings of 2000 IEEE Symposium on Security and Privacy, May2000.

[17] R. Panko. Corporate Computer and Network Security, Prentice Hall,2003.

[18] L. Qiu, G. Varghese, and S. Suri. “Fast Firewall Implementations forSoftware and Hardware-based Routers.”Proceedings of 9th Interna-tional Conference on Network Protocols (ICNP’2001), November 2001.

[19] R. Smith, S. Bhattachayra. “Firewall Placement in a Large NetworkTopology.” Proceedings of 6th Workshop of Future Trends of DistributedComputing (FTDCS’97), October 1997.

[20] R. Smith, S. Bhattachayra. “A Protocol and Simulation for DistributedCommunicating Firewalls.” Proceedings of 23rd IEEE InternationalComputer Software and Applications Conference (COMSPAC’99), Oc-tober 1999.

[21] V. Srinivasan, S. Suri and G. Varghese. “Packet Classification UsingTuple Space Search.” Computer ACM SIGCOMM CommunicationReview, October 1999.

[22] T. Woo. “A Modular Approach to Packet Classification: Algorithms andResults.” Proceedings of IEEE INFOCOM’00, March 2000.

[23] A. Wool. “Architecting the Lumeta Firewall Analyzer.”Proceedings of10th USENIX Security Symposium, August 2001.

[24] “Cisco Secure Policy Manager 2.3 Data Sheet.”http://www.cisco.com/warp/public/cc/pd/sqsw/sqppmn/prodlit/spmgrds.pdf

[25] “Check Point Visual Policy Editor Data Sheet.”http://www.checkpoint.com/products/downloads/vpedatasheet.pdf