1 / 33

Detection and Resolution of Anomalies in Firewall Policy Rules

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. Outline. Firewall Concepts and Definitions The Problem Existing Works Our Contribution

kyran
Télécharger la présentation

Detection and Resolution of Anomalies in Firewall Policy Rules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Algorithms • Example • 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, 192.168.20.*, ANY, 64.233.179.104, 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, 64.233.179.104, 80, 192.168.20.*, ANY, ACCEPT> • <IN, TCP, 64.233.179.104, 80, 172.16.20.*, 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, 64.233.179.104, 80, 192.168.20.*, ANY, ACCEPT> • <IN, TCP, 64.233.179.104, 80, 192.168.20.*, 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, 64.233.179.104, 80, 192.168.20.3, ANY, ACCEPT> • <IN, TCP, 64.233.179.104, ANY, 192.168.20.*, 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, 64.233.179.104, ANY, 192.168.20.3, ANY, ACCEPT> • <IN, TCP, 64.233.179.104, 80, 192.168.20.*, 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, 64.233.179.104, ANY, 192.168.20.*, ANY, ACCEPT> • s = <IN, TCP, 64.233.179.104, 80, 192.168.20.3, 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. • Example: • r = <IN, TCP, 64.233.179.104, ANY, 192.168.20.3, ANY, ACCEPT> • s = <IN, TCP, 64.233.179.104, 80, 172.16.20.*, 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, 64.233.179.104, 80, 192.168.20.3, ANY, ACCEPT> • s = <IN, TCP, 64.233.179.104, ANY, 192.168.20.*, ANY, ACCEPT>

  16. Anomaly Resolution Algorithms • Weresolve 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 • 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 • old_rules_list • <IN, TCP, 129.110.96.117, ANY, 129.110.96.*, 80, REJECT> • <IN, TCP, 129.110.96.*, ANY, 129.110.96.*, 80, ACCEPT> • <IN, TCP, 129.110.96.*, ANY, 129.110.96.80, 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, 129.110.96.117, ANY, 129.110.96.*, 80, REJECT> • <IN, TCP, 129.110.96.*, ANY, 129.110.96.*, 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, 129.110.96.*, ANY, 129.110.96.80, 80, ACCEPT> • After Split: • <IN, TCP, 129.110.96.117, ANY, 129.110.96.80, 80, ACCEPT> • <IN, TCP, 129.110.96.1-116, ANY, 129.110.96.80, 80, ACCEPT> • <IN, TCP, 129.110.96.118-254, ANY, 129.110.96.80, 80, ACCEPT> • Rule-1: • Original: • <IN, TCP, 129.110.96.117, ANY, 129.110.96.*, 80, REJECT> • After Split • <IN, TCP, 129.110.96.117, ANY, 129.110.96.80, 80, REJECT > • <IN, TCP, 129.110.96.117, ANY, 129.110.96.1-79, 80, REJECT> • <IN, TCP, 129.110.96.117, ANY, 129.110.96.81-254, 80, REJECT>

  24. Illustrative Example (Contd) • We insert these split rules into new_rules_list and get the final list: • <IN, TCP, 129.110.96.1-116, ANY, 129.110.96.80, 80, ACCEPT> • <IN, TCP, 129.110.96.118-254, ANY, 129.110.96.80, 80, ACCEPT> • <IN, TCP, 129.110.96.117, ANY, 129.110.96.1-79, 80, REJECT> • <IN, TCP, 129.110.96.117, ANY, 129.110.96.81-254, 80, REJECT> • <IN, TCP, 129.110.96.117, ANY, 129.110.96.80, 80, REJECT> • <IN, TCP, 129.110.96.*, ANY, 129.110.96.*, 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 • 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 • 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, 202.80.169.29-110, 483-484, 129.110.96.64-164, 100-127,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

More Related