This section explains the proposed modified tree rule firewall. Figure 2 shows the workflow of the MTRFcloud.
A new virtual firewall presents the rules dynamically rather than statically or manually. The firewall filters network traffic using IP addresses, protocols, and ports; it can also keep track of the flow's connection status and is therefore referred to as a stateful inspection firewall. First, this firewall will read the packet's attribute information and compare it to the information in its root nodes. The firewall will next examine the packet's additional properties sequentially by limiting its search to pertinent nodes at the appropriate levels. Thus, the packet will be promptly decided using a certain action.
The modified tree rule firewall is generated using algorithm-1. The algorithm takes a list of the firewall as input and generates tree rules. Initially, the first rule is added to the firewall tree rule. Then, the remaining rules are added based on the node index. Here, the node indicates the fields in firewall rules (protocol, source IP, Port, destination IP and Port).
Algorithm-1 Firewall Rule Tree Generation |
Input: Firewall Rule List FR={fr1,fr2,fr,3…,frn} Output: Tree Rule TR Step01: Insert rule fr1 into TR Step02: for i = 2 to n Step03: for each field (fj) in fri Step04: Node_Index = checkIndex(fj) Step05: if( Node_Index < 0) Step06: insert fj into TR Step07: endif Step08: endfor Step09: endfor Step10: n_index = checkIndex(Field fj, Node(fj)) Step11: edges = fj.getEdges() Step12: n_index=-1 Step13: while(edges!=null and n_index < 0) Step14: ed = edges.next() Step15: if ed != null and ed = fj Step16: n_index = Node.getIndex(ed) Step17: endfor Step18: endwhile Step19: return n_index |
Working example for tree rule generation
Consider the list of firewall rules
1. {TCP, 1.1.1.41, Any, 2.2.2.8, 22, Allow}
2. {TCP, 2.2.2.48, Any, 1.1.1.16, 80, Allow}
3. {TCP, 2.2.2.48, Any, 1.1.1.17, 22, Deny}
4. {TCP, 1.1.1.41, Any, 2.2.2.8, 22, Allow}
5. {TCP, 1.1.1.62, Any, 2.2.2.46, 8080, Deny }
6. {TCP, 2.2.2.48, Any, 1.1.1.17, 22, Allow }
7. {TCP, 1.1.1.86, Any, 2.2.2.91, 443, Allow }
8. {TCP, 2.2.2.20, Any, 1.1.1.20, 8443, Allow }
9. {TCP, 1.1.1.37, Any, 2.2.2.84, 46, Deny }
10. {TCP, 1.1.1.40, Any, 2.2.2.12, 161, Allow }
The first rule {TCP, 1.1.1.41, Any, 2.2.2.8, 22, Allow} is inserted into TR as shown in Fig. 3 (a). The for-loop is started for adding the remaining rules. Figure 3 (b) shows the insertion of rule-2 {TCP, 2.2.2.48, Any, 1.1.1.16, 80, Allow}. For rule-3, {TCP, 2.2.2.48, Any, 1.1.1.17, 22, Deny} the source IP address 2.2.2.48 already exist in TR. It will check the index and add rule-3 (Fig. 3 (c) shows rule-3 insertion). Figure 3 (d) the generation of tree rule firewall.
Figure 3 Tree Rule Generation
A redundant rule performs the same operation as another rule. For instance, Rule-1 in Table 1 is redundant to Rule-4. Removing a redundant rule shouldn't cause a firewall policy to change. However, redundant rules can slow things down since too many can take up too much processing time on the firewall. Therefore, the tree rule firewall automatically removes the redundant rules. The MTRFcloud does not add duplicate rules. In this example, rule 4 is automatically removed from the tree. The remaining rules are taken for further process.
1. {TCP, 1.1.1.41, Any, 2.2.2.8, 22, Allow}
2. {TCP, 2.2.2.48, Any, 1.1.1.16, 80, Allow}
3. {TCP, 2.2.2.48, Any, 1.1.1.17, 22, Deny}
4. {TCP, 1.1.1.62, Any, 2.2.2.46, 8080, Deny }
5. {TCP, 2.2.2.48, Any, 1.1.1.17, 22, Allow }
6. {TCP, 1.1.1.86, Any, 2.2.2.91, 443, Allow }
7. {TCP, 2.2.2.20, Any, 1.1.1.20, 8443, Allow }
8. {TCP, 1.1.1.37, Any, 2.2.2.84, 46, Deny }
9. {TCP, 1.1.1.40, Any, 2.2.2.12, 161, Allow }
Security issues are likely to arise, particularly in a corporate network with a significant number of firewall rules. For example, consider a scenario in which a new worm attacks the network by sending packets. The firewall admin will add a new rule once this threat is discovered to provide a defence. If the existing rules above that permit attacker packets to pass through are obscured by this new rule, then a security issue has unquestionably arisen.
Several shadowing rules can spend the firewall's processing time on these pointless rules, which can cause speed issues. Furthermore, the shadowed rules must be executed to match the packets before the last rule because most packets will be matched with the last rule (the rule that refuses all packets). This may result in a low firewall throughput. This paper will identify the shadow rule based on the tree rule firewall.
Algorithm-2 explains the identification of shadow rules from generated tree rule firewall. The input to this algorithm is the root node of the firewall tree.
Algorithm-2 Find Shadow Rules |
Input: Tree Rule Root Node (TRN) Output: Shadow Rule (SR) Step01: If TRN = = LeafNode Step02: parent = getParent(TRN) Step03: childCount = getChildCount(parent) Step04: if(childCount > 1) Step05: add TRN into SR Step06: endif Step07: endif Step08: childs = getChildren(TRN) Step09: if (childs ≠ NULL) Step10: FindShadowRule(childs.next) Step11: endif Step12: return SR |
Figure 4 shows the shadow rules. The shadow rules are identified based on the node (field) child count. In Fig. 4, rule-3 and rule-5 are considered shadowed rules.