Automated Framework for Policy Optimization in Firewalls and Security Gateways

Transcription

1 Automated Framework for Policy Optimization in Firewalls and Security Gateways Gianluca Maiolini 1, Lorenzo Cignini 1, and Andrea Baiocchi 2 1 Elsag Datamat Divisione Automazione Sicurezza e Trasporti Rome, Italy {Gianluca.Maiolini, Lorenzo2.Cignini}@elsagdatamat.com 2 University of Roma La Sapienza Rome, Italy {Andrea.Baiocchi}@uniroma1.it Abstract. The challenge to address in multi-firewall and security gateway environment is to implement conflict-free policies, necessary to avoid security inconsistency, and to optimize, at the same time, performances in term of average filtering time, in order to make firewalls stronger against DoS and DDoS attacks. Additionally the approach should be real time, based on the characteristics of network traffic. Our work defines an algorithm to find conflict free optimized device rule sets in real time, by relying on information gathered from traffic analysis. We show results obtained from our test environment demonstrating for computational power savings up to 24% with fully conflict free device policies. Keywords: Firewall; Data mining; network management; security policy; optimization. 1 Introduction A key challenge of secure systems is the management of security policies, from those at high level down to the platform specific implementation. Security policy defines constraints, limitations and authorization on data handling and communications. The need for high speed links follows the increasing demand for improved packet filtering devices performance, such as firewall and S-VPN gateway. As hacking techniques evolves and routing protocols are becoming more complex there is a growing need of automated network management systems that can rapidly adapt to different and new environments. We assume that policies are formally stated according to a well defined formal language, so that the access lists of a security gateway can be reduced to an ordered list of predicates of the form: C A, where C is a condition and A is an action. We refer to predicates implementing security policies as rules. For security gateway the condition of a filtering rule is composed of five selectors: <protocol> <src ip> <src port> <dst ip> <dst port>. The action that could be performed on the packet is allow, deny or process, where process imply that the packet has to be submitted to the IPSec algorithm. How to process that packet is described in a specific rule which details how to apply the security mechanism. Conditions are checked on each packet flowing through the device. The process of inspecting incoming packets and looking up the policy rule set for a match often results in CPU overload and traffic or application s delay. Packets that match high rank rules require a small computation time compared to those one at the end of rule set. Shaping list of rules on traffic E. Corchado et al. (Eds.): CISIS 2008, ASC 53, pp , springerlink.com Springer-Verlag Berlin Heidelberg 2009

2 132 G. Maiolini, L. Cignini, and A. Baiocchi flowing through devices could be useful to improve devices performance. This operation performed on all packet filtering devices give an improvement in global network performance. Our analysis shows how shaping access list based on network traffic can often results in conflicts between policies. As reported by many authors [1-6], conflicts in a policy can cause holes in security, and often they can be hard to find when performing only visual or manual inspection. In this paper we propose architecture based on our algorithm to automatically adapt packet filtering devices configuration to traffic behavior achieving the best performance ensuring conflict-free solution. The architecture retrieves traffic pattern from log information sent in real time from all devices deployed in the network. 2 Related Works In the last few years the critical role of firewall in the policy based network management led to a large amount of works. Many of these concern the correctness of implemented policies. In [1] the Authors only aim at detecting if firewall rules are correlated to each other, while in [2][3][4] a set of techniques and algorithms are defined to discover all of the possible policy conflicts. Along this line, [5] and [6] provide an automatic conflict resolution algorithm in single firewall environment and tuning algorithm in multi-firewall environment respectively. Recently great emphasis has been placed on how to optimize firewall performance. In [7] a simple algorithm based on rule re-ordering is presented. In [11] Authors present an algorithm to optimize firewall performance that order the rules according to their weights and consider two factors to determine the weight of a rule: rule frequency and recency which reflect the number and time of rule matching, respectively. Finally extracting rules from the deny all rule is another big problem to address. The few works on this issue [8] [10] do not define how many rules must be extracted, which combine values; how to define their priorities and they not check whether this process really improve the firewall packet filtering performance. In this paper we propose a fully automated framework composed by a log management infrastructure, policy compliance checking and a tool that, based on log messages collected from all device in the network, calculate rules rate related to traffic data, re-orders ranks guaranteeing conflict-free configuration and maximum performance optimization. Moreover our tool is able to extract a rule from the deny all rule if this leads to further improved performance. To make the framework automatic we are actually working to define a threshold to understand how many logs are needed to automatically start rule set update. 3 Adaptive Conflict-Free Optimization (ACO) Algorithm In the following we refer to a tagged device rule set, denoted by R = [R 1,,R N ]. The index i of each rule in set R is also called rule rank. We let the following definitions: P i is the rule rate, i.e. the matching ratio of rule i, defined as the ratio on the number n i (T) of packets matching R i out of the overall number n(t) of packets processed by the tagged device in the reference time interval T.

3 Automated Framework for Policy Optimization 133 C i is the rule weight, i.e. the computational cost of rule i; if the same processing complexity can be assumed for each rule in R, then C i =i P i ; C(R) is the device rule set overall computational cost, computed as the sum of the rule weights, C(R)= i C i. Our aim is to minimize C(R) in all network devices, under the constraint of full rule consistency. The aim is to improve both device and global filtering operation. In the following paragraph we are going to describe phases for algorithm. To develop our algorithm we used two repository systems, in particular: DVDB: database storing devices configurations including security policy. LogDB: database designed to store all log messages coming from devices. Analysis and correlation among logs are performed in order to know how many times each device s rule was matched. 3.1 Phase 1: Starting ACO ACO starts operation when: i) policy configurations (rule set) are retrieved to solve conflicts in all devices; ii) a sufficiently large amount of log for each device are collected, e.g. to allow reliable weight estimates (i.e. logs collected in a day). Since ACO is aimed at working in real time, we need to decide which events trigger its run. We monitor in real time all devices and decide to start optimization process when at least one of the following events occurs: rule set change (such as rule insertion, modification and removal); the number of logs received from a device in the last collection time interval (in our implementation set to 60 s) has grown more than 10% with respect to the previous collection interval. The first criterion is motivated mainly to check the policy consistency; the second one to optimize performance adapting to traffic load. Specifically, performance optimization is needed the more the higher the traffic load, i.e. as traffic load attains critical values. In fact, rule set processing time optimization is seen as a form of protection of secure networks from malicious overloads (DoS attacks by dummy traffic flooding). 3.2 Phase 2: Data Import The algorithm retrieves from Device DB (DVDB): the IP address of devices interfaces to the networks; devices rule set R. For each device algorithm retrieves all rules hit number (how many times a rule was applied to a packet) from Log DB (LogDB). Then it calculates rule match rate (P i ) and rule weight (C i ). 3.3 Phase 3: Rules Classification In this phase for each device a classifier analyzes one by one the rules in R and it determines the relations between Ri and all the rules previously analysed [R 1,,R i 1 ]. A data structure called Complete Pseudo Tree (CPT) is built out of this analysis.

4 134 G. Maiolini, L. Cignini, and A. Baiocchi Definition. A pseudo tree is a hierarchically organized data structure that represents relations between each rule analysed. A pseudo tree might be formed by more than one tree. Each tree node represents a rule in R. The relation parent-children in the trees reflect the inclusion relation between the portions of traffic matched by the selectors of the rules: a rule will be a child node if the traffic matched by its selectors is included in the portion of traffic matched by the selectors of the parent node. Any two rules whose selectors match no overlapping portions of traffic will not be related by any inclusion relation. In each tree there will be a root node which represents a rule that includes all the rules in the tree and there will be one or more leaves which represent the most specific rules. When the classifier finds a couple of rules which are not related by an inclusion relation, it will split one of them into two or three new rules so as to obtain derived rules that can be classified in the pseudo tree. The output of this phase is a conflict-free tree where there remain only redundant rules that will be eliminated in the next phase. The pseudo code of the algorithm for the identification of the Complete Pseudo Tree is listed below. Algorithm 1: Create new Complete Pseudo Tree CPT 2: foreach rule r in Ruleset do 3: foreach ClassifiedRule cr in CPT do 4: classify(r,cr) 5: if r is to be fragmented then 6: fragment(r,classifiedrule) 7: remove(r, pseudotree) 8: insert fragments at the bottom of the Ruleset 9: calculate statistic from LogDB (fragments) 10: else 11: insert(r,cpt). 3.4 Phase 4: Optimization In this phase core operations upon the single devices rule lists optimization will be performed. The aim of these operations is twofold: to restrict the number of rules in every rule list without changing the external behavior of the device and to optimize filtering performance. We ought to take into consideration the data structures introduced in previous section, namely the Device Pseudo Tree (DPT), one for each device, obtained from the CPT by considering only the rules belonging to one device. Each of these structures shows a hierarchical representation of the rules in the rule list of each device. Chances are that one rule might have the same action as a rule that directly includes it. This means that the child rule is in a way redundant because, if it was not in the rule list, the same portion of traffic would be matched by the parent rule which has got the same action. The child rule is indeed not necessary to describe the device behavior and could be eliminated simplifying the device rule list. Therefore, our algorithm will locate in every device pseudo tree all these cases, in which a child rule has got the same action as the father s, and will delete the child rule. So the rule set obtained is composed by two kinds of rules: one completely disjoint that can be located in any rank of rule list, the other one characterized by dependencies constraints among rules. In addition we need to update the rate of the father rule when one or more child rules are deleted. At this point each device rule set R is re-ordered according to nonincreasing rule rates, i.e. so that Pi Pj for i j The resulting ordering minimizes the

5 Automated Framework for Policy Optimization 135 overall cost C(R), yet it does not guarantee the correctness of the policies implemented. As a matter of fact, it may happen that one more specific rule is placed after a more general rule, so violating the constraints imposed by security policy consistency. For this reason, after re-ordering operation, relations father-child of the DPT are restored. It s clear that the gain achieved by optimization heavily depends on the degree of dependencies of the rules. The two limit cases are: i) no rules dependencies (all disjoint rules), that yields the biggest optimization margin; ii) complete dependency (every rule depends on any other one), where the optimization process produces a near zero gain. The device rule set total cost C(R) is evaluated and fed as input for the next phase. The pseudo code of the optimization algorithm is listed below. Algorithm 1: foreach Node node in CPT do 2: get the id of the device the rule belongs to 3: if exist DPT.id = = id then 4: insert(node,dpt) 5: else 6: create(dpt,id) 7: insert(node,dpt) 8: foreach DPT do 9: foreach Rule rule in DPT do 10: if rule.action = = rule s father.action then 11: update rule s father.rate 12: delete(rule) 13: foreach Device dv do 14: sort the dv.ruleset except deny all in non-increasing order of rule.rate 15: foreach Rule rule do 16: if rule is a child 17: move rule just above father rule 18: calculate dv.cost 3.5 Phase 5: Extracting Rules from Deny all String The common idea about rules extraction from deny all rule is to obtain better optimization rate. It consists in selecting only heavily invoked rules and simply extract them in rule set according of their rates. However, this is a very delicate operation, since the inclusion of these rules often does not improve performance. In Table 1 we show this case: two new rules extracted and ordered according to their rates produce an Table 1. Rule list with two rules extracted (Rank = 2 and Rank = 7) Rank Pi Ci C(R) = 5.47

6 136 G. Maiolini, L. Cignini, and A. Baiocchi increment of the starting value of C(R), that was In addition extracted rules are always disjoint from all others in the rule sets, so it is impossible to introduce additional conflicts. Our algorithm extracts a new rule when its rate exceeds 20% of deny all rule rate. But this is not enough; in fact we perform an additional control to assess efficacy of the new rule in the process of optimization. Changing the position of rules implies cost changes so we will choose the position of rule that grants for the lowest overall cost C(R). The derived rule will be actually inserted in the rule list if the overall cost improves over the value it had before rule extraction. Detailed pseudo code of this phase is listed below. Algorithm 1: foreach Device dv 2: foreach denyall log record in LogDB 3: count log occurrence 4: if log.rate > 0.2 denyall.rate 5: extract new rule from log record 6: add rule to extracted_ruleset 7: foreach Rule rule in extracted_ruleset 8: calculate vector dv.costvector 9: if min(dv.costvector) < dv.cost 10: update dv.cost 11: update ruleset including rule. 3.6 Phase 6: Update Devices At this point we have obtained for each packet filtering device an optimized and conflict-free rules list, shaped on traffic flowed through the network. In this phase the algorithm updates devices configuration on device DB. Network management system manages configuration upload to deployed devices. 4 Performance Evaluations Our approach is based on real test scenario even if due to privacy issues we can t provide reference and traffic contents. We have observed for traffic behaviour during a day in ten different devices deployed in a internal network. We analyzed configuration in order to detect and solve eventual conflict, results of this phase are not important because we are focused on log gathering and optimization. We have stored conflict free configurations in device DB. We have also configured devices for sending log to our machine where our tool is installed. We collected logs for 24 hour storing them in logdb. We started our tool based on the algorithm described in section 3, obtaining different level of optimization depending on devices configuration and traffic. For us optimization rate consists in calculate parameter C(R). In this section we are going to describe the results obtained in the most significant device deployed on the network, it could describe the concept of the algorithm. Table 2 shows the initial device rule set comprising access list for IP traffic and IPSec configuration. It s easy to see that if we exchange rules 3, 6 and 7 shadowing conflicts occur. Table 3 shows the Pi and Ci values of the initial rule set calculated retrieving data stored in logdb. According to the metric used we obtain a value of

7 Automated Framework for Policy Optimization 137 C(R) equal to Re-ordering operation (line 14 of phase 4 algorithm) produces the best optimization gain (+22%) but adjustments are necessary to ensure a conflict-free configuration. At the end of phase 4 we obtained the order showed in Table 4. The value of C(R) obtained is 5.16, so the improvement is about 14%. Another good optimization is obtained by algorithm in phase 5. In this phase new rules are extracted because of packet flow matched with a specific denied rule (obviously included in deny all) a lot of time. Our algorithm calculates the best position to insert rule in the list to minimize cost C(R) so in this case it has been positioned at the top of rule-list. In Table 5 are shown the changing occurring in Pi and Ci values. The value of C(R) obtained is 4.56, so additional gain obtained in this phase is about 10 %. At the end of the process the total optimization gain is about 24%. Similar values (±2 %) were obtained in the remaining devices. Optimization is not always feasible. In the end, we have achieved a conflict-free configuration with a gain of 24%. These results depend on specific traffic behaviour and security policies applied on devices. Our work is continuing performing further traffic test looking for relations between number of rules and optimization rate also refining the extraction from deny all rules. A further issue is the fine tuning of heuristic parameters used in the algorithm, like time interval duration between two updates. Finally a device spends significant CPU time to send logs, especially when it has to be sent them for all packets flowing through it. Table 2. Rank Protocol Source IP Source Dest. Dest. IP Port port Action 1 tcp * * 80 Deny 2 tcp * * 21 Allow 3 tcp any Allow 4 udp any Deny 5 udp any *.* 80 Allow 6 tcp * any * 80 Deny 7 tcp 10.1.*.* any * 80 Allow 8 any any any any any Deny Table 3. Table 4. Table 5. Rank Pi Ci C(R) = 5.99 Old rank Rank Pi Ci C(R) = % Rank Pi Ci C(R) = %

8 138 G. Maiolini, L. Cignini, and A. Baiocchi References 1. Hari, H.B., Suri, S., Parulkar, G.: Detecting and Resolving Packet Filter Conflicts. In: Proceedings of IEEE INFOCOM 2000, Tel Aviv (2000) 2. Al-Shaer, E., Hamed, H.: Modeling and Management of Firewall Policies. In: IEEE etransactions on Network and Service Management, vol. 1-1 (2004) 3. Al-Shaer, E., Hamed, H., Boutaba, R., Hasan, M.: Conflict Classification and Analysis of Distributed Firewall Policies. IEEE Journal on Selected Areas in Communications 23(10) (2005) 4. Al-Shaer, E., Hamed, H.: Firewall Policy Advisor for Anomaly Detection and Rule Editing. In: Proceedings of IEEE/IFIP Integrated Management Conference (IM 2003), Colorado Springs (2003) 5. Ferraresi, S., Pesic, S., Trazza, L., Baiocchi, A.: Automatic Conflict Analysis and Resolution of Traffic Filtering Policy for Firewall and Security Gateway. In: IEEE International Conference on Communications 2007 (ICC 2007), Glasgow (2007) 6. Ferraresi, S., Francocci, E., Quaglini, A., Picasso, F.: Security Policy Tuning among IP Devices. In: Apolloni, B., Howlett, R.J., Jain, L. (eds.) KES 2007, Part II. LNCS (LNAI), vol Springer, Heidelberg (2007) 7. Fulp, E.W.: Optimization of network firewall policies using directed acyclical graphs. In: Proceedings of the IEEE Internet Management Conference (2005) 8. Acharya, S., Wang, J., Ge, Z., Znati, T., Greenberg, A.: Simulation study of firewalls to aid improved performance. In: Proceedings of 39th Annual Simulation Symposium (ANSS 2006), Huntsville (2006) 9. Acharya, S., Wang, J., Ge, Z., Znati, T., Greenberg, A.: Traffic-aware firewall optimization Strategies. In: IEEE International Conference on Communications (ICC 2006), Istambul (2006) 10. Zhao, L., Inoue, Y., Yamamoto, H.: Delay reduction for linear-search based packet filters. In: International Technical Conference on Circuits/Systems, Computers and Communication (ITC-CSCC 2004), Japan (2004) 11. Hamed, H., Al-Shaer, E.: Dynamic rule ordering optimization for high speed firewall Filtering. In: ACM Symposium on InformAtion, Computer and Communications Security (ASIACCS 2006), Taipei (2006)