Adaptive Optimization of Packet Filtering Devices ... - Semantic Scholar

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE INFOCOM 2008 proceedings.

Adaptive Optimization of Packet Filtering Devices Performance Ensuring a Conflict-free Network Configuration Gianluca Maiolini, Lorenzo Cignini

Andrea Baiocchi

Elsag Datamat S.p.A. Rome, Italy [email protected] [email protected]

INFOCOM Dept. University of Roma “La Sapienza” Rome, Italy [email protected]

Abstract— Security rules management in firewall and security gateway is a hard and error prone task as administrators must correctly implement and update a large amount of policies especially when rapid changing occurs due to new security needs. 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. There is a vast amount of literature on security policy conflict detection and resolution and on device rule set shaping to improve policy implementation performance. 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 confirming that operational costs of devices could be improved based on traffic analysis via log files of the security device. We demonstrate computational power savings up to 24% with fully conflict free device policies. Keywords - Firewall; Data mining; network management; security policy; optimization.

I. 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. In this new scenario the edge appliances are quickly becoming the crucial point of a new generation of secure network. Secure policies are integrated into networking devices to prevent attacks or allow inbound services without any concern for traffic type or traffic shaping. 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. Moreover the implementation of security devices and policies should not turn out to be the network performance bottleneck. To improve performances while maintaining network security policies should be tailored according to the network traffic and

applications characteristics. 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: . 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 (ESP, AH). 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 action associated to the first matching rule of the first rule set is applied to each packet, for this reason, any rule set encompasses a “deny all” rule as its bottom line. 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. For each packet the security devices has to go through high priority policies down to the “deny all” rule. Packets that match high rank rules require a small computation time compared to those one at the end of rule set. Unfortunately significant part of packet flow matches with low priority rules especially when complex configurations are deployed. Shaping list of rules on traffic 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. Optimization techniques rely on ranks and matching percentage of rules, where matching percentage is a parameter depending on how many packets match with each rule. Algorithms aiming at packet filter processing time improvements are presented in [11-16]. These algorithms can introduce inconsistency of policies implemented by firewalls and secure access gateways interconnected over insecure networks, especially when particular traffic pattern flowing through devices are detected. Our analysis shows how shaping access list based on network traffic can often results in conflicts between policies. As reported by many authors [4-9], conflicts in a policy can

978-1-4244-2219-7/08/$25.00 ©2008 IEEE.


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. This work is organized as follows. In Section II we briefly describe related works. In Section III we present operational scenario and platforms and in section IV a detailed description of our algorithm. In Section V we report tests and results. Finally, in Section VI, we give our conclusions and plans for future work. II.

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 Policy Core Information Model (PCIM) is described as an object-oriented model for representing policy information as extensions to the Common Information Model (CIM) activity within the Distributed Management Task Force (DMTF). The definition of policy and policy rule presented in PCIM and its extension shown in RFC-3198 [2] gave to the Author of [3] the starting point to refine these concepts in a way useful for a formal approach. In [4] the Authors only aim at detecting if firewall rules are correlated to each other, while in [5][6][7] a set of techniques and algorithms are defined to discover all of the possible policy conflicts. Along this line, [8] and [9] provide an automatic conflict resolution algorithm in single firewall environment and tuning algorithm in multifirewall environment respectively. Recently great emphasis has been placed on how to optimize firewall performance. In [10] a simple algorithm based on rule re-ordering is presented. This work describes rule dependencies using Directed Acyclical Graphs (DAGs) but it does not provide a methodology to build the DAG. In addition this algorithm is unable to move groups of rules and is unfeasible in real environment with large rule sets and complex graphs. The authors of [11] [12] [13] propose framework and methodologies to inspect and analyze both multidimensional firewall rules and traffic logs information. In [11] and [12] the optimization tool uses current traffic characteristics to determine the order in which rules in the rule set are to be invoked to optimize the operational cost of the firewall and four schemes are used to achieve this goal (hot caching, total re-ordering, default proxy, online adaptation). In [13] Authors propose OPTWALL, an adaptive firewall optimization framework built to reflect the current traffic pattern and rule sets. Furthermore the Authors do not define when the update process must be started and weight parameters used in the rule size estimation. The approach proposed in [14] optimizes the performance by rule re-ordering but does not define how to create the necessary statistics for rule weight estimation and how to find dependency relations between rules. In [15] 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. Moreover they present two types of update: “performance-based triggered update” and “time-based periodic update”. In [16] Authors present a process of managing firewall policy rules, consisting of anomaly detection, generalization and policy update using Association Rule Mining and frequency-based techniques but a complex distributed network with multiple firewalls and log acquisition mechanism are not contemplated. Finally extracting rules from the “deny all” rule is another big problem to address. The few works on this issue [11] [14] 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, a 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. III.

OPERATIONAL SCENARIO

We have developed a system to retrieve and store device configuration in a database (deviceDB - DVDB). A tool developed in our previous work [9] allows us to detect whether configurations gathered in DVDB contain conflicts among policies (Fig. 1). If conflict are detected our tool solves them storing conflict free configurations in DVDB. We can modify configurations by using a network management station. All packet filtering devices, such as firewalls and security gateways are set up to send log for each packet they allow or deny. Analyzing log messages permit us to have: •

real time traffic behaviour information without using further device such as network agents;

•

how many rules are working and how many packets match with rules in order to perform our analysis.

We have developed a monitoring infrastructure in order to collect and store log information in a log database (LogDB). It was designed to easy receive all log messages coming from devices deployed from test network scenario (Fig. 1). On this database analysis and correlation among logs are performed in order to know how many times each device’s rule was matched. Logs collected from devices are sent by using “syslog” standard [17][18]. Information concerning logs permits to understand: which device has sent log and the rank of rule applied on packet from device. Fig. 2 shows which relevant data are stored. In particular: •

IP address is retrieved from “syslog” packet. It identifies a device interface on the network;


Packet filtering devices deployed

Monitoring infrastructure DeviceDB DVDB

LogDB

ACO Conflict detection and resolution

Optimization Tool

Log correlation and analisys

Network management system Figure 1. Architecture proposed.

Figure 2. LogDB relevant table.

• • • IV.

Device type selects typology of the rule. Device could be configured with both FW and IPSec access list (this is an optional field); Rule rank that is rule’s priority in the device rule set; Count: number of packets those matched rule. 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. 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.

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). B. 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 ). C. 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 (an example is shown in Fig. 3). Definition: A pseudo tree is a hierarchically organized data structure that represents relations between each rule analysed. The pseudo code of the algorithm for the identification of the Complete Pseudo Tree is given in Fig. 4.

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. A. Phase 1: Starting ACO ACO starts operation when: i) policy configurations (rule set) are retrieved to solve conflicts in all devices; ii) a

Figure 3.

Example of Complete Pseudo Tree.


Pseudo Tree 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) Figure 4. Pseudo code of the algorithm to derive the Complete Pseudo Tree.

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. For example in table I a fragmentation of involved selectors of one of the two correlated rules can solve the problem. Table II represents the case of fragmentation of destination port field of rule B. The new rule set contains no correlated rules: rule B1 and rule A are Disjoint; rule B2 and rule A are Inclusively Matching; rule B3 and rule A are Disjoint. The output of this phase is a conflict-free tree where there remain only redundant rules that will be eliminated in the next phase. D. 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 behaviour 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 behaviour 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 non-increasing rule rates, i.e. so that PiPj for ij The resulting ordering minimizes the 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. Figure 5 details the algorithm phase pseudo code. TABLE I. ID

Protocol

Source IP

Source Port

Destinatio n IP

Destinatio n port

A

any

20.1.1.*

100-200

30.1.1.*

300-320

B

any

20.1.1.*

120-150

30.1.1.*

250-500

TABLE II. ID

Protocol

Source IP

Source Port

Destinatio n IP

Destinatio n port

A

any

20.1.1.*

100-200

30.1.1.*

300-320

B1

any

20.1.1.*

120-150

30.1.1.*

250-299

B2

any

20.1.1.*

120-150

30.1.1.*

300-320

B3

any

20.1.1.*

120-150

30.1.1.*

321-500

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 Figure 5. Pseudo code of the algorithm for optimization of rule set list constrained by rule set correctness.


E. 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 III we show this case: two new rules extracted and ordered according to their rates produce an 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 algorithm phase is listed in Figure 6. F. 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. TABLE III. Rule list with two rules extracted (2 and 7) Rank

Pi

Ci

1 2

0.18 0.10

0.18 0.20

3 4 5 6 7 8 9 10

0.02 0.07 0.17 0.12 0.05 0.03 0.01 0.25 C(R) = 5.47

0.06 0.28 0.85 0.72 0.35 0.24 0.09 2.5

V.

PERFORMANCE EVALUATIONS

A. Test platform 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 on section IV, obtaining different level of optimization depending on devices configuration and traffic. For us optimization rate consists in calculate parameter C(R). B.

Results 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 IV 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 V 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 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 VI. 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 VII 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. TABLE IV.

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 Figure 6. Pseudo code of the algorithm for rule extraction from “deny all” rule.

Rank

Protocol

Source IP

Source Port

Destination IP

Destination port

Action

1

tcp

192.168.10.*

80

192.168.20.*

80

Deny

2

tcp

192.168.10.*

21

192.168.20.*

21

Allow

3

tcp

10.1.1.23

any

20.1.1.23

80

Allow

4

udp

192.168.3.5

53

192.168.3.5

any

Deny

5

udp

192.168.3.5

any

192.168.*.*

80

Allow

6

tcp

10.1.1.*

any

20.1.1.*

80

Deny

7

tcp

10.1.*.*

any

20.1.1.*

80

Allow

8

any

any

any

any

any

Deny


TABLE V.

TABLE VI. Old rank

Rank

Pi

Ci

4

1

0.18

0.18

3

2

0.02

0.04

6

3

0.07

0.21

0.72

7

4

0.17

0.68

0.03

0.15

2

5

0.12

0.60

0.07

0.42

5

6

0.03

0.18

7

0.17

1.19

8

0.4

3.2

1

7

0.01

0.07

Rank

Pi

Ci

1

0.01

0.01

2

0.12

0.24

3

0.02

0.06

4

0.18

5 6

8

C(R) = 5.99

8

0.40

C(R) = 5.16

3.20

+ 14%

Rank

Pi

Ci

1

0.2

0.2

2

0.18

0.36

3

0.02

0.06

4

0.07

0.28

5

0.17

0.85

6

0.12

0.72

7

0.03

0.21

8

0.01

0.08

9

0.20

1.8

VI.

VII. REFERENCES [1] [2]

[3]

TABLE VII.

C(R) = 4.56

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.

+10%

CONCLUSION

This work focuses on optimization techniques for packet filtering devices such as firewall and security gateways. Results obtained from our test platform confirm that operational cost of devices can be improved by relying on traffic flowing through the network. The entire process can be automated, by collecting traffic log information, exploiting it to re-order device rule set files. We demonstrated that policy conflict handling affects achievable optimization results. Relevant case is related to one of device analyzed with a conflict free configuration embedded. We collected logs coming from this device for 24 hours. Calculating rates and costs, we found that optimization rate would be 22% that means significant improvements of computational time, but the configuration needed to achieve this gain was affected to conflicts among policies. In fact we detected “shadowing” conflicts. Applying our algorithm to the same inputs we also achieved a gain that was 14% with a conflict free configuration. We enhanced performance extracting a rule from deny all obtaining an additional gain. This additional

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17] [18]

B. Moore, E. Ellesson, J. Strassner, A. Westerinen, “Policy Core Information Model Version 1 Specification”, RFC-3060. A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. Waldbusser, “Terminology for Policy-Based Management”, RFC-3198. C. Basile, A. Lioy, “Towards an Algebraic Approach to Solve Policy Conflicts”, Foundations of Computer Security (FCS’04), WOLFASI subworkshop, Turku, Finland, July 2004. HB. Hari, S. Suri and G. Parulkar, “Detecting and Resolving Packet Filter Conflicts”, Proceedings of IEEE INFOCOM 2000, Tel Aviv, Israel, March 2000. E. Al-Shaer and H. Hamed, “Modeling and Management of Firewall Policies”, in IEEE eTransactions on Network and Service Management,Volume 1-1, April 2004. E. Al-Shaer, H. Hamed, R. Boutaba, M. Hasan, “Conflict Classification and Analysis of Distributed Firewall Policies”, in IEEE Journal on Selected Areas in Communications,vol.23, no.10, October 2005. E. Al-Shaer and H. Hamed, “Firewall Policy Advisor for Anomaly Detection and Rule Editing”, in Proceedings of IEEE/IFIP Integrated Management Conference (IM2003), Colorado Springs, US, March 2003. S.Ferraresi, S.Pesic, L.Trazza, A.Baiocchi, “Automatic Conflict Analysis and Resolution of Traffic Filtering Policy for Firewall and Security Gateway”, in IEEE International Conference on Communications 2007 (ICC’07), Glasgow, Scotland, June 2007. S.Ferraresi, E.Francocci, A.Quaglini, F.Picasso, "Security Policy Tuning among IP Devices", Knowledge-Based Intelligent Information and Engineering Systems, Springer Berlin/Heidelberg, volume 4693/2007. Errin W. Fulp, “Optimization of network firewall policies using directed acyclical graphs”, in Proceedings of the IEEE Internet Management Conference, 2005. S. Acharya, J. Wang, Z. Ge, T. Znati, A. Greenberg, “Simulation study of firewalls to aid improved performance”, Proceedings of 39th Annual Simulation Symposium (ANSS’06), Huntsville, US, April 2006. S. Acharya, J. Wang, Z. Ge, T. Znati, A. Greenberg, “Traffic-aware firewall optimization strategies”, in IEEE International Conference on Communications (ICC 2006), Istambul, Turkey, June 2006. S. Acharya, M. Abliz, B. Mills, T. Znati, “Optwall: a hierarchical trafficaware firewall”, Proceedings of 14th Annual Network & Distributed System Security Symposium (NDSS), San Diego, US, February 2007. L. Zhao, Y. Inoue, H. Yamamoto, “Delay reduction for linear-search based packet filters”, International Technical Conference on Circuits/Systems, Computers and Communication (ITC-CSCC2004), Japan, July 2004. H. Hamed, E. Al-Shaer, “Dynamic rule ordering optimization for high speed firewall filtering”, in ACM Symposium on InformAtion, Computer and Communications Security (ASIACCS'06), Taipei, Taiwan, March 2006. K. Golnabi, R. K. Min, L. Khan, E. Al-Shaer, “Analysis of firewall policy rules using data mining techniques”, in Network Operations and Management Symposium (NOMS’06) Vancouver, Canada, April 2006. C. Lonvick, “The BSD syslog Protocol”, RFC-3164. D. New, M. Rose, “Reliable Delivery for syslog”, RFC-3195.