1
Performance Optimization of Network Firewalls
by Rulebase Reordering based on Traffic
Conditions
A. Chirag Sheth, B. Rajesh A. Thakker
Tata Consultancy Services Limited, Leamington Spa, United Kingdom – CV325AE, chirag.sheth@tcs.com
Electronics & Communication Dept., Vishwakarma Govt. Engg. College, Chandkheda –382424, India rathakker2008@gmail.com
Abstract
With the growth of network complexity, it is very common to find firewall policies with thousands of rules. Modern firewall rulebase are growing in size and complexity at an exponential rate. As changes add up, the firewall rule base gets more complex. Firewall rulebase works on first-match principle. As a result, there exists scope of improvement in firewall performance, if highest utilized rule is brought ahead in rulebase. This will facilitate earlier matching and hence less firewall resource utilization. However, this should be done carefully without compromising overall firewall security or without loss of semantic integrity. In this paper, authors have proposed framework for rulebase reordering based on traffic conditions. To evaluate the performance of approach, authors further carried out performance testing on OpenBSD PF firewall by reordering rulebase under laboratory traffic. Results obtained indicate 9.57% improvement in firewall throughput and 11.9% improvement in concurrent connections after rulebase is reordered based on traffic conditions.
Keywords: Network Firewall, Firewall Rulebase, OpenBSD Packet Filter, Network Security
I. Introduction
Today, 61.5% of all internet traffic is generated by non-humans as per study by Incapsule (2013). This makes firewall one of the most critical network security component deployed in virtually all operational networks exposed to internet. It controls the traversal of packets across the boundaries of a secured network based on a specific security policy. A firewall security policy is a list of ordered filtering rules that defines the actions to be performed on matching packets. Filtering actions are either to accept, which passes the packet into or from the secure network, or to deny, which causes the packet to be discarded.
2
packet. Service is the protocol type to be used for packet transmission. Action is to allow or drop instruction which firewall needs to perform when matching happens. When a packet is received, the rulebase is scanned from the start to the end, and the action associated with the first match is taken if the packet header information matches all the network fields of that rule. Often a deny-all rule is included at the end of the list.
As a result, higher the order of the matching rule, more firewall resources will be consumed to perform filtering actions. This will in turn, result into more firewall filtering overhead. To reduce this overhead, it is critical to have the proper rule ordering in the firewall policy. Today, an attacker launch distributed denial of service (DDoS) attacks by targeting firewalls with packets that matching ordered rules. This rule could also be default deny rule, generally located at end of rulebase, which will further add to overhead of travelling through all rules to reach the end.This attack can drastically reduce the overall throughput of firewalls by consuming firewall computational resources and increase network delays dramatically. It is important to design firewall policies dynamically based on traffic conditions, without losing semantic integrity.
Authors have attempted to classify firewall rulebase optimization methods broadly into two categories – (1) Matching optimization techniques and (2) Blocking optimization techniques. Matching optimization techniques try to minimize the matching time of normal network traffic. Blocking Optimization techniques focus on filtering out the maximum amount of denied traffic.
Figure.1. Firewall rulebase optimization methods.
Rulebase re-ordering based on traffic conditions falls under both Static and Dynamic matching optimization methods. In analysis carried out in this paper, authors have used firewall logs to arrive at optimal reordering. This can further be deployed to use live traffic conditions to arrive at optimal reordering which will make it dynamic.
3
rulebase and some of the suggested decision making process for firewall administrators. In Section IV, authors have attempted to present framework and algorithm for firewall rulebase reordering based on traffic conditions. Section V highlights firewall performance testing and results obtained by optimizing rulebase and limitations. Finally, conclusions are drawn in Section VI.
II. Related Work
In their previous work, C. Sheth and R. Thakker (2011 & 2013) have carried out performance evaluation and comparative analysis of most widely used network firewalls by identifying various key performance indicators. In this paper, authors carries out further work by suggesting method for rulebase reordering based on traffic conditions and analyzing its impact on firewall performance. It is observed that majority of the reported work carried out to improve performance based on traffic-aware reordering of firewall rulebase is theoretical and lacks practical implementation.
As per literature review undertaken by authors, the earliest reported work to exploit traffic properties for packet classification is by Gupta et al. (2000), in which alphabetic trees were used to reduce the lookup time of destination IP addresses of packets against entries in the routing table. Further S. Acharya et al. (2006, 2007) proposed an offline statistical-based rule generation technique called traffic-aware firewall optimizer. Though limited adaptively, it presented technique for traffic-aware optimization of firewall. Technique which uses heuristic approximation algorithm for optimal dynamic firewall rule ordering based on real-time traffic characteristics was proposed by H. Hamed et al. (2006 a, b). Muhammad et al. (2010) also made a notable contribution by carrying out analysis of firewall policy rules using traffic mining techniques. A. El-Atawy et al. (2007) proposed online traffic statistical matching for optimizing packet filtering performance. H. Acharya and M. Gouda (2010) came up with linear-space verification of firewall policy. Qi Duan, Ehab Al-Shaer (2013) also carried out significant work in classification of traffic-aware dynamic firewall policy management and techniques.
III. Firewall Rulebase – Changes and Complexity
Tradition firewalls were stateless as they use stateless techniques to filter packets. Whenever a packet is received, stateless firewall will compare it against its rulebase. The matching rule decides if the packet is allowed or not. The advantage of this approach is that it will not consume memory resource since it does not need memory to keep states for packets. The disadvantage is that it needs computation efforts for every packet. While it saves memory resource, it needs CPU computation resource to look up the whole rule set for each packet. When the rule set contains thousands of rules, the overhead to look up rules in the rule set for each packet will become very high. Hence, the performance disadvantage of stateless firewall is obvious. Nowadays, most firewalls are stateful firewalls and they maintain state of packet in their state tables. If the rules accept one packet, they also accept all the subsequent packets that are in the same connection of the checked packet.
4
(2) Audits and reviews of rulebase performed for security and compliance, and (3) Log monitoring and review associated with troubleshooting and forensic work.
Each of these processes has drawback that makes rulebase complex, which further weaken the security. Administrators often have to add temporary rules for ad-hoc testing / changes which in turn remains permanent. Also, changes to the network without rulebase cleanup results in unused rules. Change management requests for the firewall will often open up more ports than required, in order to allow connections through it. These problems revolve around the manual nature of firewall administration. The best way to become more efficient and effective in firewall management is to incorporate automated techniques to assist in performing the three main processes of the administrator.
There are number of additional rules and errors introduced in firewall by below –
(1)Promiscuous rules – These are rules in firewall which allows alleviated access than what is required to meet the stated business or change requirements. Examples of promiscuous rules include allowing access to whole subnet instead of single IP addresses, allowing access on multiple ports when only single port is needed.
(2)Redundant rules – These are rules which duplicates the already existing rule provisioned for providing same level of access. Example of redundant rule is one that allows single IP address to access destination when already the whole subnet which contacts that IP address is already white listed.
(3)Orphaned rules – These are rules which exist in the firewall rulebase but are never used. Many times this rules remains in firewall rulebase due to decommissioning of source and destination servers, without removing these rules. Example of orphaned rules includes a rule placed in order to allow access to a server that no longer exists in network.
(4)Shadowed rules – These are rules which drives the incorrect ordering of rules in a firewall rulebase. This in turn completely prevents the execution of one or more firewall rules. Example of shadowed rules is placing deny rule below the rule which allows same access, which in turn makes deny rule useless.
(5)Rule specification errors – These are errors introduced during translation of business requirements into firewall rule definition. Example of rule specification errors is specifying the incorrect port for a service as interpreted from business requirements. (6)Data entry errors - These are errors introduced during converting a technical rule
definition into the firewall policy format and entering that rule into the firewall rulebase. Examples of data entry errors are mistyping a port number or incorrect source or destination.
With the growth of network complexity, it is very common to find firewall policies with thousands of rules. As changes add up, the firewall rule base becomes more complex. There is need for firewall rulebase review on periodic basis considering more rules will introduce more errors.
Some of the suggested decision-making process for firewall administrator is as below -
5
(2)Review existing rules to see if similar rule exists and a change can be made to an existing rule that would also satisfy the request. This will ensure that there will be no increase in the number of rules.
(3)Analyze whether the new rule should be specific or more general. There is always a trade-off between building more specific individual rules for better security and the corresponding management and performance issues that may arise due to increased complexity.
As compliance and regulation laws tighten up firewall configurations, more attention is paid in firewall rulebase to protect against non-compliance. Manual audits are expensive and they can often lead to errors, which further increases likelihood of leaks and inappropriate connections. As a result there is strong demand to optimize firewall rulebase to improve firewall performance.
IV. Framework for Rulebase reordering based on Traffic Conditions
With the increase in size of firewall rulebase, packets have to traverse more number of rules in order to arrive at matching conditions. Optimal reordering of rulebase based on traffic conditions will help in increasing probability of matching and hence improvement in firewall performance.
A. Suggested Approach
In order to improve firewall performance, authors proposed a framework to arrive at optimal reordering of rulebase based on traffic conditions. Two approaches which author considered to initially arrive at optimal rule ordering are as mentioned below.
1. Dividing rulebase into layers - Basic idea is to split the firewall policy into multiple layers of rules depending on size of firewall rulebase. The top layer consists of a small set of the most active rules (i.e., currently performs the most packet matching) ordered based on their traffic matching ratio to minimize the overall packet matching. The second layer usually contains a larger set of the remaining inactive rules that perform much less matching. The optimized rule ordering is constantly being updated in order to adapt to the new traffic statistics. However, firewall rule safety, i.e. semantic integrity, should be maintained, otherwise it could result into serious security flaws.
2. Divide rulebase into blocks based on filtering actions and then sort rules based on usage - In this method, classification of rules is done based on filtering actions in such a way that firewall semantic integrity is maintained. Ruleset is divided into different blocks with similar filtering actions (accept or deny block). All the new rules which will be entered will follow this and will be placed accordingly. Once blocks are created, firewall rules are further sorted based on traffic conditions. Authors recommend this method to form blocks based on filtering actions, which maintains firewall safety.
B. Algorithm for firewall rulebase reordering
6
Figure 2. Framework for Firewall rulebase reordering based on traffic conditions
A high level block diagram of proposed algorithm is presented in Figure 2. Various components / blocks are as explained below -
(1)Firewall logs
In most Industry known proprietary firewalls like Checkpoint, Cisco, Juniper, etc. the firewall logs its actions by writing records to a log file. Each record in the log file corresponds to a single connection that the firewall filtered. The log record contains many fields, such as – time stamp, rule identifier, source, destination, ports, protocol, state details, packet details etc.
Traffic can even be captured using Tcpdump utility which is powerful command-line packet analyser. The log file is analysed to get information on Rules utilization and corresponding traffic distribution is obtained by capturing log files for particular duration.
(2)Rule Usage
Rule usage value is between 0 and 1 and it gives relative indication on frequency of usage of particular rule. A rulebase of R firewall rules therefore comprises of R rules, each associated with R usage frequencies which will have value between 0 and 1.
(3)Rulebase Weight
Based on individual rule usage, overall rulebase weight is calculated which is summation of all individual rule usage.
Rulebase Weight for particular rule ordering = Summation of individual rule usage.
7 (4)Rule Swapping
Successive rules will be swapped repeatedly based on Rule Usage and new Rules Weight will be calculated. If its value is lower than earlier, then rules will be swapped. This will be repeated till no further swapping of rules is needed.
(5)Firewall Rule SAFETY
Changing the order of rules in a rulebase may result in firewall prone to security threats if not done properly. Moving a rule to an earlier location in the rule base, without maintaining safety, can easily change the action that is applied to certain IP connections which will further cause security breaching. A rule movement is considered to maintain semantic integrity, if the resulting rule-base causes the firewall to make exactly the same filtering actions which the firewall made with the rule-base before the rule movement. It is most important to reorder firewall policies based on traffic conditions, without losing semantic integrity.
V. Performance Testing and Results
Authors further carried out implementation of the above framework on OpenBSD Packet Filter (PF) Firewall in order to measure performance improvement. PF Firewall is chosen considering it being open source, available under BSD licenses and allowed changes to be made to source.
A. Performance Testing Setup
In order to characterize performance of firewall, the testing environment setup shown in Figure 3 is used. The firewall configurations, operating system and hardware details of OpenBSD firewall under test are mentioned in Table I.
Figure 3. Performance testing laboratory setup
8 TABLEI
SYSTEM UNDER TEST (FIREWALL)CONFIGURATIONS
Configurations OpenBSD PF
Hardware Platform HP DL 380
Operating System Open BSD 4.7 Product Architecture Multi-processor, Multi-core
Processing Cores 8
Gigabit Ethernet Interfaces 0 10 Gigabit Ethernet Interfaces 4
Traffic is captured through TCP dump utility. For PF Firewall, pfctl –sr –vvvv command is used to provide rule usage statistics. As shown in the Figure 4, traffic distribution is shown for the 284 rules in the rulebase. Rule Usage and further initial Rulebase Weight is calculated based on this distribution values.
Figure.4. Initial Traffic Distribution
B. Performance Testing Results
9 TABLEII
PERFORMANCE TESTING RESULTS
Key Performance Indicators (KPI)
System Under Test – OpenBSD PF Firewall
Performance Improvement Pre Rulebase
Reordering
Post Rulebase Reordering
TCP Throughput (Gbps)
(Object size = 512 KB) 9.4 Gbps 10.3 Gbps 9.57%
Concurrent Connections 420K 500K 11.9%
1) TCP Throughput - As per IETF RFC 1242, the standard definition of throughput is "The
maximum rate at which none of the offered frames are dropped by the device." The throughput is the maximum data frame forwarding rate without any packet loss. It is the maximum offered TCP load, expressed in either bits per second or packets per second, at which no packet loss is detected. This test will allow better understanding of how firewall will perform in highly transactional environments such as streaming media. Test included opening a TCP connection, transferring an object using HTTP and closing the TCP connection with object size 512 KB. The size of the throughput is mainly determined by the Ethernet cards and the efficiency of the programmed algorithm within the firewall. The goal of this test is to characterize the performance of the system under test before and after reordering of rulebase. As mentioned in Table 2, there is 9.57% improvement in TCP throughput post rulebase re-ordering.
(2) Concurrent Sessions - The number of concurrent connections is an important aspect to
evaluate the performance of the firewall. As per IETF RFC 2647, the number of concurrent connections is defined as the maximum number of connections established between the hosts through the firewall or between the host and the firewall at the same time. It is the aggregate number of simultaneous connections between hosts across system under test. It gives number of connections handled by firewall simultaneously. This is critical aspect of data centre firewall implementations, as it directly affects the ability to deploy large scale applications. Like the routing table which stores routing information from the router, the concurrent connection table stores the concurrent connection information from the firewall. It can dynamically allocate the memory space of the process after the firewall system is enabled. A larger concurrent connection table can increase the maximum number of concurrent connections of the firewall, and allows the firewall supporting more client terminals. As mentioned in Table 2, there is 11.09% improvement in number of concurrent connections post rulebase re-ordering.
C.Observations and Limitations
10
in firewall performance on different make and model of hardware. Performance test results obtained are specific to environment and firewall rulebase used in the setup.
(2)Setup and analysis is performed on OpenBSD PF firewall with 286 rules in the rulebase. The performance improvement results are based on the laboratory environment traffic conditions and rulebase complexity considered in laboratory setup. Performance improvement may vary based on rulebase complexity, rulebase length, filtering conditions, firewall resources and traffic conditions of one’s own setup.
(3)Current analysis has taken into account only packets which actually hits firewall rulebase. Disabled rules are not taken into account. Disable rules appear in firewall rulebase and will have rule number assigned. Since they are disabled, it will be taken as zero usage during analysis and will be processed accordingly.
(4)Some rules in the firewall have logging disabled. No Logs are generated for these rules which make rule usage tracking difficult. This will be limitation in current analysis as statistics are fetched from logs.
(5)Since PF firewall is stateful inspection firewall, packets whose state exist in firewall state table will not reach firewall rulebase. Current setup and analysis is only considering packets which actually hits firewall rulebase.
(6)There is no standard method of performance measurement. Even to test the same parameters, different manufacturers also have their own implementations and methods.
VI. Conclusions
11
References
i. A. El-Atawy, T. Samak, E. Al-Shaer and H.Li, (2007) “Using online traffic statistical matching for optimizing packet filtering performance,”IEEE Infocom’07, pp - 866-874.
ii. C. Sheth and R. Thakker (2011), “Performance Evaluation and Comparative Analysis of Network Firewalls,”Proc. IEEE Int’l Conf. on Devices and Communications (ICDeCom), pp. – 1-5, Feb 2011. iii. C. Sheth and R Thakker (2013), “Performance Evaluation and Comparison of Network Firewalls under
DDoS Attack, “Proc. International Journal of Computer Network and Information Security(IJCNIS), Vol. 5, No. 12, pp. - 60-67, Oct 2013.
iv. H. Acharya and M. Gouda (2010), “Projection and Di-vision: Linear-Space Verification of Firewalls,” Proc. IEEE International Conference on Distributed Computing Systems, pp. 736–743, 2010.
v. H. Hamed, A. El-Atawy, and E. Al-Shaer (2006a), “On Dynamic Optimization of Packet Matching in High-Speed Firewalls”, IEEE Journal on Selected Areas in Communications, Vol. 24, No.10, Oct 2006.
vi. H. Hamed, A. El-Atawy, and E. Al-Shaer (2006b),”Adaptive statistical optimization techniques for firewall packet filtering”, Proc IEEE Infocom'06, Apr 2006.
vii. Muhammad Abedin, Syeda Nessa, Latifur Khan, Ehab Al-Shaer, Mamoun Awad (2010), “Analysis of firewall policy rules using traffic mining techniques”, Proc. IJIPT 5(1/2): 3-22, 2010.
viii. P. Gupta, B. Prabhakar, and S. Boyd (2000), “Near Optimal Routing Lookups with Bounded Worst Case Performance,”IEEE Infocom 2000.
ix. PF: The OpenBSD Packet Filter - http://www.openbsd.org/faq/pf/
x. S. Acharya, J. Wang, Z. Ge, T. Znati, and A. Greenberg (2006), “Traffic-aware firewall optimization strategies,”Proc. IEEE International Conference on Communications, June 2006.
xi. S. Acharya, M. Abliz, B. Mills and T.F. Znati (2007), “Optwall: a hierarchical traffic-aware firewall”, Proc 14th Annual Network & Distributed System Security Symposium (NDSS), Feb 2007.
xii. Study by Incapsule, December 2013 -
http://www.incapsula.com/the-incapsula-blog/item/820-bot-traffic-report-2013.
xiii. TCPDUM P/ LIBPCAP public repository - ht tp:/ / w w w .tcpdump.org/.
