1. Detection and Resolution of Anomalies in Firewall Policy Rules
Muhammad Abedin, Syeda Nessa,
Latifur Khan, Bhavani Thuraisingham
Department of Computer Science,
The University of Texas at Dallas.

2. Outline Firewall Concepts and Definitions The Problem Existing Works
Our Contribution
Anomaly Resolution
Algorithms
Correctness
Cost Analysis
Example
Merging Rules
Conclusion and Future Directions

3. Firewalls
Firewall:
System acting as an interface of a network to one or more external networks.
Implements the security policy of the network
By deciding which packets to let through
Based on rules defined by the network administrator.

4. Firewall Rules Firewall Rules:
Mostly Custom-designed and Hand-written.
Must be defined and maintained carefully.
Result of any slight mistake in defining the rules:
Allow unwanted traffic to be able to enter or leave the network
Deny passage to quite legitimate traffic.
Manual Definition and Maintenance:
Complex, Error-prone, Costly, Inefficient
As number of rules increase
Becomes virtually unmanageable.

5. Our Research Focuses on:
Automating the maintenance of Firewall Rule Set.
Making the rule set error-free
detecting the conflicts and anomalies in the rules
Resolving the errors found
Increasing the efficiency
Reducing the number of rules in the set.

6. Existing Work There has been research in firewall policy analysis.
Static Analysis and Detection of Anomalies
Most of the current work is based on only detection of anomalies.
Some work on Resolution of Anomalies

7. Our Contribution This paper presents:
Complete set of definitions of relations between rules and possible anomalies.
A set of algorithms to simultaneously detect and resolve anomalies in a given rule set.
Proof of correctness of the algorithms and cost analysis.
An algorithm to merge rules whenever possible to reduce the number of rules.

8. Representation of Rules
A rule contains
Set of criteria
Direction, Protocol, Source IP, Source Port, Destination IP, Destination Port.
Action performed on a packet matching the criteria
ACCEPT or REJECT.
A complete rule is defined by the ordered tuple
<Dir, Proto, Src IP, Src Port, Dest IP, Dest Port, Action>
Example:
<OUT, TCP, *, ANY, , 80, ACCEPT>

9. Relations between Rules
Attributes of a rule:
Defined as a range of values
Rule
Can be compared using set relations.
Relation between two rules can be
Disjoint
Exactly Matching
Inclusively Matching
Correlated

10. Disjoint Rules
Two rules r and s are disjoint, denoted as , if they have at least one criterion for which they have completely disjoint values.
Example:
<IN, TCP, , 80, *, ANY, ACCEPT>
<IN, TCP, , 80, *, ANY, REJECT>

11. Exactly Matching
Two rules r and s are exactly matched, denoted by , if each criterion of the rules match exactly.
Example:
<IN, TCP, , 80, *, ANY, ACCEPT>

12. Inclusively Matching
A rule r is a subset, or inclusively matched of another rule s, denoted by , if there exists at least one criterion for which r’s value is a subset of s’s value and for the rest of the attributes r’s value is equal to s’s value.
Example:
<IN, TCP, , 80, , ANY, ACCEPT>
<IN, TCP, , ANY, *, ANY, ACCEPT>

13. Correlated
Two rules r and s are correlated, denoted by , if r and s are not disjoint, but neither is the subset of the other.
Example:
<IN, TCP, , ANY, , ANY, ACCEPT>
<IN, TCP, , 80, *, ANY, REJECT>

14. Possible Anomalies Between Two Rules
Definition of anomalies in terms of relations:
Shadowing Anomaly
Rule r is shadowed by rule s if s precedes r in the policy and s can match all the packets matched by r.
Example:
r = <IN, TCP, , ANY, *, ANY, ACCEPT>
s = <IN, TCP, , 80, , ANY, ACCEPT>
Correlation Anomaly
Rules r and s are correlated if they have different actions and r matches some packets that match s and s matches some packets that r matches.
r = <IN, TCP, , ANY, , ANY, ACCEPT>
s = <IN, TCP, , 80, *, ANY, REJECT>

15. Possible Anomalies Between Two Rules (Contd.)
Definition of anomalies in terms of relations (continued):
Redundancy Anomaly
A redundant rule r performs the same action on the same packets as another rule s such that if r is removed the security policy will not be affected.
Example:
r = <IN, TCP, , 80, , ANY, ACCEPT>
s = <IN, TCP, , ANY, *, ANY, ACCEPT>

16. Anomaly Resolution Algorithms
We resolve the anomalies as follows:
Shadowing anomaly:
Exactly matched
keep the one with the REJECT action.
Inclusively matched
Reorder the rules to bring the subset rule before the superset rule.
Correlation anomaly:
Break down the rules into disjoint parts and insert them into the list.
Of the part that is common to the correlated rules, keep the one with the REJECT action.
Redundancy anomaly:
Remove the redundant rule.

17. Approach Two global lists of firewall rules Incremental approach:
old_rules_list
Contains the rules as they are in the original firewall configuration
new_rules_list
Will contain the output of the algorithm, a set of firewall rules without any anomaly.
Incremental approach:
Take each rule in the old_rules_list
Insert it into new_rules_list in such a way that new_rules_list always remains free from anomalies.

18. The Algorithms
We present the following algorithms to resolve the anomalies
RESOLVE-ANOMALIES
Processes the old_rules_list to produce the anomaly-free new_rules_list.
INSERT
Inserts a rule into the new_rules_list in such a way that the list remains anomaly free.
RESOLVE
Detects and resolves anomalies between two given non-disjoint rules.
SPLIT
Splits two non-disjoint rules into disjoint parts for a given attribute.

19. Interaction of the Algorithms
RESOLVE-
ANOMALIES
Inserts each rule into new_rules_list
INSERT
old_rules_list
Firewall
Rules
Inserts disjoint parts into new_rules_list
Resolves non-disjoint pairs of rules
Splits correlated pairs of rules
SPLIT
RESOLVE

20. Illustrative Example Initialization Step-1 old_rules_list
<IN, TCP, , ANY, *, 80, REJECT>
<IN, TCP, *, ANY, *, 80, ACCEPT>
<IN, TCP, *, ANY, , 80, ACCEPT>
new_rules_list
Empty
Step-1
Rule-1 is inserted into empty new_rules_list

21. Illustrative Example (Contd)
Step-2
Rule-2 is superset of rule-1
Inserted after rule-1 in new_rules_list
new_rules_list:
<IN, TCP, , ANY, *, 80, REJECT>
<IN, TCP, *, ANY, *, 80, ACCEPT>

22. Illustrative Example (Contd)
Step-3
Rule-3 is correlated with rule-1 of new_rules_list
These rules will be split into disjoint parts by algorithm SPLIT
The disjoint and common parts will be inserted by algorithm INSERT

23. Illustrative Example (Contd)
Rule-3:
Original:
<IN, TCP, *, ANY, , 80, ACCEPT>
After Split:
<IN, TCP, , ANY, , 80, ACCEPT>
<IN, TCP, , ANY, , 80, ACCEPT>
<IN, TCP, , ANY, , 80, ACCEPT>
Rule-1:
<IN, TCP, , ANY, *, 80, REJECT>
After Split
<IN, TCP, , ANY, , 80, REJECT >
<IN, TCP, , ANY, , 80, REJECT>
<IN, TCP, , ANY, , 80, REJECT>

24. Illustrative Example (Contd)
We insert these split rules into new_rules_list and get the final list:
<IN, TCP, , ANY, , 80, ACCEPT>
<IN, TCP, , ANY, , 80, ACCEPT>
<IN, TCP, , ANY, , 80, REJECT>
<IN, TCP, , ANY, , 80, REJECT>
<IN, TCP, , ANY, , 80, REJECT>
<IN, TCP, *, ANY, *, 80, ACCEPT>

25. Cost Analysis of INSERT
The cost of running the algorithm depends on the nature of the rules in the input.
A disjoint or superset rule is inserted into the list without further call to INSERT.
In this case INSERT must check the whole new_rules_list.
A subset rule is inserted just before the superset rule.
In the worst case INSERT may check the whole new_rules_list.
A rule equal to any rule in the new_rules_list is discarded.
In the worst case the whole new rules list may have to be traversed.
Two correlated rules will be divided into a set of mutually disjoint rules.
In the worst case the number of rules thus generated will be up to twice the number of attributes plus one, and these rules will be inserted into the new rules list by invoking INSERT recursively.

26. Cost Analysis of RESOLVE-ANOMALIES
Invokes INSERT once for each rule in new_rules_list in a for loop.
Removes the redundancy anomalies in a second for loop
The running time of Resolve-Anomalies is dominated by the number of times INSERT is invoked recursively.
This depends on the number of correlated rules in the input.
Worst case:
If all rules are correlated, the running time may deteriorate to exponential order.

27. Merging Rules Given an anomaly-free list
we can merge the rules with consecutive attribute values to reduce the number of rules.
We can construct a tree representing the anomaly-free rules.
Nodes will represent attributes.
Edges will represent value ranges of the attributes.
To find rules with consecutive attribute values and safe to merge
Traverse the tree in post-order

28. Merge Algorithms TREEINSERT MERGE
Takes as input a rule and a node of the tree
Constructs a tree from the input rules
MERGE
Traverses the tree in post-order
Invokes MERGE on the children of the node
Checks pairs of edges if
Values of ranges are consecutive
Sub-trees of the edges match exactly.
Matching edge pairs are merged into single edges

29. Illustrative Example of the Merge Algorithm
To illustrate the merge operation, consider the following rule set:

30. Generated Tree
From this rules list we generate a tree by the TREEINSERT Algorithm, on which MERGE is applied.
Edges out of node-9 can be merged into one edge.

31. Application of MERGE
In this figure, we show an intermediate state of the tree: node 7’s children are going to be merged next.
After MERGE is complete on the tree, the only rule is
<IN, TCP, , , , ,ACCEPT>.

32. Conclusion and Future Works
Our work:
Presents an automated process for detecting and resolving such anomalies.
Establishes the complete definition and analysis of the relations between rules.
In future:
This analysis can be extended to distributed firewalls
Data mining techniques can be used to analyze the log files of the firewall and discover other kinds of anomalies after the rules have been made free from anomaly by applying the algorithms in this paper.

33. Thank You