Automated Framework for Policy Optimization
in Firewalls and Security Gateways
Gianluca Maiolini1, Lorenzo Cignini1, and Andrea Baiocchi2
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. 131–138, 2009.
springerlink.com
© Springer-Verlag Berlin Heidelberg 2009
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 = [R1,…,RN]. The
index i of each rule in set R is also called rule rank. We let the following definitions:
•
Pi is the rule rate, i.e. the matching ratio of rule i, defined as the ratio on the
number ni(T) of packets matching Ri out of the overall number n(T) of packets
processed by the tagged device in the reference time interval T.
Automated Framework for Policy Optimization
•
•
133
Ci 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 Ci=i·Pi;
C(R) is the device rule set overall computational cost, computed as the sum of
the rule weights, C(R)=∑i Ci.
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 (Pi)
and rule weight (Ci).
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 [R1,…,Ri–1].
A data structure called Complete Pseudo Tree (CPT) is built out of this analysis.
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
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
1
2
3
4
5
6
7
8
9
10
Pi
0.18
0.10
0.02
0.07
0.17
0.12
0.05
0.03
0.01
0.25
C(R) = 5.47
Ci
0.18
0.20
0.06
0.28
0.85
0.72
0.35
0.24
0.09
2.5
136
G. Maiolini, L. Cignini, and A. Baiocchi
increment of the starting value of C(R), that was 5.16. 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
Automated Framework for Policy Optimization
137
C(R) equal to 5.99. 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
1
2
3
4
5
6
7
8
tcp
tcp
tcp
udp
udp
tcp
tcp
any
192.168.10.*
192.168.10.*
10.1.1.23
192.168.3.5
192.168.3.5
10.1.1.*
10.1.*.*
any
Table 3.
Rank
1
2
3
4
5
6
7
8
Pi
0.01
0.12
0.02
0.18
0.03
0.07
0.17
0.4
C(R) = 5.99
Source
Port
80
21
any
53
any
any
any
any
Dest. IP
192.168.20.*
192.168.20.*
20.1.1.23
192.168.3.5
192.168.*.*
20.1.1.*
20.1.1.*
any
Table 4.
Ci
0.01
0.24
0.06
0.72
0.15
0.42
1.19
3.2
Old
Rank
rank
4
1
3
2
6
3
7
4
2
5
5
6
1
7
8
8
C(R) = 5.16
Pi
0.18
0.02
0.07
0.17
0.12
0.03
0.01
0.40
Dest.
port
80
21
80
any
80
80
80
any
Action
Deny
Allow
Allow
Deny
Allow
Deny
Allow
Deny
Table 5.
Ci
0.18
0.04
0.21
0.68
0.60
0.18
0.07
3.20
+ 14%
Rank
Pi
1
0.2
2
0.18
3
0.02
4
0.07
5
0.17
6
0.12
7
0.03
8
0.01
9
0.20
C(R) = 4.56
Ci
0.2
0.36
0.06
0.28
0.85
0.72
0.21
0.08
1.8
+10%
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. 4693. 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)