This is an implementation of the paper, M Abedin, et al. "Detection and resolution of anomalies in firewall policy rules" for Ryu restful firewall.
Firewall rules define the security policy for network traffic. Any error can compromise the system security by letting unwanted traffic pass or blocking desired traffic.
- Usage
- Relation Between Two Rules
- Possible Anomalies Between Two Rules
- Illustrative Example of the Resolve Algorithm
- Illustrative Example of the Merge Algorithm
- Task List
- More about this program
usage: main.py [-h] [--path PATH] [--detect] [--resolve] [--merge]
Anomaly Firewall Rule Detection and Resolution
optional arguments:
-h, --help show this help message and exit
--path PATH path of firewall rules file
--detect detect anomaly firewall rule
--resolve resolve anomaly firewall rule
--merge merge contiguous firewall rule
- Install dependency
pip install -r requirements.txt
- This will run the demo program
python anomaly_resolver.py
- This will perform anomaly detection
python main.py --path rules/example_rules_1 --detect
- This will perform anomaly resolving
python main.py --path rules/example_rules_1 --resolve
- This will perform rule merging
python main.py --path rules/example_rules_2 --merge
A rule is defined as a set of criteria and an action to perform when a packet matches a criteria. The criteria of a Ryu restful firewall rule consist of the elements VLAN, priority, input switch port, Ethernet source, Ethernet destination, Ethernet frame type, IP source, IP destination, IPv6 source, IPv6 destination, IP protocol, source port, and destination port. These are also the matching fields defined in OpenFlow Switch Specification.
The relation between two rules is the relation between the set of packets they match. Assume a rule matches A packets and the other matches B packets.
- Disjoint: at least one criterion in the rules has completely disjoint values
- Exactly Matching: every criterion in the rules match exactly
- Inclusively Matching: a rule and the other rule have at least one criterion which is a subset of one another and for the rest of the attribute one is equal to the other
- Correlated: two rules are not disjoint and not inclusively matching to one another
- Shadowing Anomaly: a rule is shadowed by the other if the other precedes the rule in the policy and the other can match all packets matched by the rule and they have different actions
- Correlation Anomaly: two rules have different actions and one rule matches some packets that match the other and vice versa
- Redundancy Anomaly: a redundant rule performs the same action on the same packets as another rule
This algorithm resolves the anomalies as follows:
- shadowing anoamly: When rules are exactly matched, keep the one with the reject action. When the rules are inclusively matched, reorder the one with the reject action.
- 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.
Firewall rules are expected in the following format:
- priority. <direction, source IP, source port, destination IP, destination port, actions>
1. <IN, TCP, 129.110.96.117, ANY, ANY, 80, REJECT>
2. <IN, TCP, 129.110.96.*, ANY, ANY, 80, ACCEPT>
3. <IN, TCP, ANY, ANY, 129.110.96.80, 80, ACCEPT>
4. <IN, TCP, 129.110.96.*, ANY, 129.110.96.80, 80, REJECT>
5. <OUT, TCP, 129.110.96.80, 22, ANY, ANY, REJECT>
6. <IN, TCP, 129.110.96.117, ANY, 129.110.96.80, 22, REJECT>
7. <IN, UDP, 129.110.96.117, ANY, 129.110.96.*, 22, REJECT>
8. <IN, UDP, 129.110.96.117, ANY, 129.110.96.80, 22, REJECT>
9. <IN, UDP, 129.110.96.117, ANY, 129.110.96.117, 22, ACCEPT>
10. <IN, UDP, 129.110.96.117, ANY, 129.110.96.117, 22, REJECT>
11. <OUT, UDP, ANY, ANY, ANY, ANY, REJECT>
After anomaly resolving, the list is free from anomalies.
<IN, TCP, 129.110.96.0/24, *, 129.110.96.81-255.255.255.255, 80, ALLOW>
<IN, TCP, 129.110.96.0/24, *, 0.0.0.0-129.110.96.79, 80, ALLOW>
<IN, TCP, 129.110.96.117, *, 0.0.0.0-129.110.96.79, 80, DENY>
<IN, TCP, 129.110.96.0-129.110.96.116, *, 129.110.96.80, 80, ALLOW>
<IN, TCP, 0.0.0.0-129.110.95.255, *, 129.110.96.80, 80, ALLOW>
<IN, TCP, 129.110.97.0-255.255.255.255, *, 129.110.96.80, 80, ALLOW>
<IN, TCP, 129.110.96.118-129.110.96.255, *, 129.110.96.80, 80, ALLOW>
<IN, TCP, 129.110.96.0/24, *, 129.110.96.80, 80, DENY>
<OUT, TCP, 129.110.96.80, 22, *, *, DENY>
<IN, TCP, 129.110.96.117, *, 129.110.96.80, 22, DENY>
<IN, UDP, 129.110.96.117, *, 129.110.96.0/24, 22, DENY>
<OUT, UDP, *, *, *, *, DENY>
1. <IN, TCP, 202.80.169.29-63, 483, 129.110.96.64-127, 100-110, ACCEPT>
2. <IN, TCP, 202.80.169.29-63, 483, 129.110.96.64-127, 111-127, ACCEPT>
3. <IN, TCP, 202.80.169.29-63, 483, 129.110.96.128-164, 100-127, ACCEPT>
4. <IN, TCP, 202.80.169.29-63, 484, 129.110.96.64-99, 100-127, ACCEPT>
5. <IN, TCP, 202.80.169.29-63, 484, 129.110.96.100-164, 100-127, ACCEPT>
6. <IN, TCP, 202.80.169.64-110, 483-484, 129.110.96.64-164, 100-127, ACCEPT>
From this rules list, we can generate the tree:
On this tree, the merge function is run and the result of the merged tree:
- A parser from firewall rule file to Rules
- resolve_anomalies function which resolves anomalies in firewall rules file
- insert function which inserts the rule r into new_rules_list
- resolve function which resolves anomalies between two rules r and s
- split function which split overlapping rules r and s based on attribute a
- tree_insert function which inserts rule r into the node n of the rule tree
- merge function which merges edges of node n representing a continuous range
- IP range representation to multiple CIDR representations
- Support for handling dl_src, dl_dst, dl_type, ipv6_src, ipv6_dst, multiple nw_proto
- Output resolved and merged rules to firewall rules file
Detailed descrptions about this program is in this blog post Anomaly Firewall Rule Detection and Resolution.