Computer Communications 26 (2003) 13021317 www.elsevier.

com/locate/comcom

Reactive rewallsa new technique

Ray Hunta,*, Theuns Verwoerdb
a

Department of Computer Science, University of Canterbury, Private Bag 4800, Christchurch, New Zealand b Allied Telesyn Research, 27 Nazareth Avenue, P.O. Box 8011, Christchurch, New Zealand Received 15 April 2002; revised 12 January 2003; accepted 24 January 2003

Abstract Firewalls are a well-established and integral part of network security. However, in most situations rewalls are congured according to a set of static rules based upon a policy. To date, development in rewall architectures which can react to attacks such as those demonstrated by the Nimda virus are very limited. Yet it is essential that rewalls are able to cope with and react to such attacks. The idea of a rewall changing or adapting its rules in the face of adverse situations is proposed and demonstrated by way of a prototype in this paper. This new concept of rule adaptation permits security management beyond conventional stateful connection tracking, and incorporates the overall system state as well as the effects of multiple connections. q 2003 Elsevier Science B.V. All rights reserved.
Keywords: Network security; Packet lter; Application proxy; Stateful packet lter; Firewall architecture; Conditional rewall rules; Token bucket; Iptables

1. Introduction Firewalls form a fundamental part of current network security practice by providing the demarcation point between networks with differing levels of trust. Frequently, owing to cost, a rewall is the only effective security measure used in smaller networks, and is relied upon to implement the entire security policy for that network. Traditional rewall systems can be categorised into three major techniques: packet ltering, stateful packet ltering and application proxies. Fig. 1 shows these three existing techniques in relation to their OSI layer, the complexity of sessions supported and their operation over the duration of the connection. Packet ltering inspects each packet that traverses the rewall, determining whether to forward or discard the packet based on the contents of protocol headers. It is extremely fast, applies equally to different high-level protocols and has a minimal memory overhead, but is capable only of simple decisions and lacks ne-grained
* Corresponding author. Tel.: 64-3-3642347; fax: 64-3-3642569. E-mail addresses: theuns.verwoerd@alliedtelesyn.co.nz (T. Verwoerd); ray@cosc.canterbury.ac.nz (R. Hunt).

control. Further, it takes no account of the higher-layer contents of the packet. Application proxies act as agents and forward high-level protocol data. Through their access to this data, proxies are capable of a wide variety of complex tasks, including negrained protocol control, content ltering and detailed logging. However, the use of two data connections, one on either side of the rewall, and the associated ow control overhead, means that this technique is relatively slow.1 A further complication with application proxies lies with its inability to handle encrypted connections although this is the subject of some recent active research [1]. Stateful packet ltering lies somewhere between application proxies and simple packet ltering. In its simplest form, stateful ltering functions as a packet lter applied to connections as a whole (rather than to individual packets)it recognises and handles packets belonging to the same connection in a similar manner. In addition, stateful packet lters may have further insight into higher-level protocol content, allowing more informed decisions although fundamentally they still act at a packet level. This technique is fast and allows limited
This performance issue can be alleviated somewhat through the use of cut-through proxies, where the two connections are melded at the TCP level after some initial setup has occurred at the proxy level [2].
1

0140-3664/03/$ - see front matter q 2003 Elsevier Science B.V. All rights reserved. doi:10.1016/S0140-3664(03)00111-7

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

1303

Port Sentry [4] monitors unused ports. Any attempt to access such ports are indicative of port scanning attacks or other probes. On detection, the local rewall/router conguration is modied to exclude the host involved. Checkpoint [5] has an API which allows it to accept rewall rule modication from an external IDS. Should a compatible IDS detect an attack it could modify the rewall conguration to exclude the attacker. Guardian [6] is a security program which operates by automatically updating rewall rules based upon alerts generated by Snort [7] and blocking all incoming data from the IP address of the attacking machine.
Fig. 1. OSI layer v connection state for existing and new rewall systems.

application level comprehension, but requires complex programming to incorporate new protocols. These three techniques differ in the level of control and comprehension that they can offer to the protocols carried. Even the decision to allow or restrict a connection which relies upon both the content and context of the connection, is highly limited. This is because conventional stateful packet lters cannot represent concepts outside of the data ow (connection state, OSI layer). Even application proxies, while capable of arbitrary complexity, rarely share information between multiple connection instances. Perhaps one of the most severe limitations of these techniques is that they cannot take account of, or adapt to, new attack techniques without structural modications, and this limitation has been the impetus for this research. For example, consider the case where an HTTP request is recognisable as an attempted attack. A packet lter, in addition to being unable to recognise attacks directly, has no mechanism for incorporating the knowledge of an attack short of explicitly blocking that protocol or the source address. Stateful packet ltering and application proxies, while possibly capable of recognising the attack, have no means of storing this information short of modifying the rewall conguration. Basically a rewall policy is a specication for the implementation of a static rule set and there is currently no exible method of either recording or adapting to past behaviour. There has been some limited development in mutable rewall congurations. Some rewalls might appear to change their rule set in the face of an attack but the results are frequently very limited, cumbersome or even harmful. For example: Watchguard [3] watches for attempted access to services dened as sensitive as well as other policy violations. When such a violation is detected the source is submitted to a preprocessor which discards all further packets involving that host before any other processing takes place.

As an example to illustrate the problem presented by these various autoblocking behaviours described above, consider the case of a company that uses an external DNS server. Their rewall is capable of recognising policy violations such as probes to sensitive services, and responds by blacklisting (autoblocking) the source of such probes. Thus subsequent packets from that source are discarded before any further processing takes place. Should an attacker be aware of this behaviour and spoof a probe so that it appears to originate from the companys DNS server, the rewall will respond by blacklisting the apparent source-effectively creating a Denial of Service condition! (See Fig. 2). The Guardian example (above) does, however, have a whitelist of sites which must not be blocked (e.g. DNS) but such an all or nothing approach suffers from the risks of blocking on false positives or on signatures that can be spoofed [8]. To resolve these shortcomings in current rewalling systems, we would like to propose an extension to the semantics of (stateful) packet ltering systems that would allow data to be recalled, used and shared amongst packet ltering rules and applications.

Fig. 2. Autoblocking leading to a Denial of Service condition.

1304

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

Stateful Packet Filtering only carries out single connection tracking and only cares about past behaviour of a specic connection. The concept that we would like to introduce implements the tracking of multiple connections and incorporates a global view including the history of such connections. Such Conditional Firewall Rules2 are illustrated by the introduction of a third dimension in Fig. 1 and would allow considerable exibility in implementing packet ltering rules3 and proxies, ranging from elegant support for excluding attackers, to the ability to dene complex trafc and state-tracking systems. This is further illustrated by a Case Study in Section 4. In the remainder of this paper we will describe the implementation of our prototype Reactive Firewall system. The paper commences by presenting a conventional rewall implementation for a University rewall in Section 2. Following this, we discuss the semantics of a packet ltering rule, together with our proposed extension, in greater detail in Section 3. Section 4 presents a case study of the application of these techniques in practice. Section 5 presents some simple applications of reactive rewall rules including IDS interaction and trafc shaping systems, followed by a nal conclusion and description of further work in Section 6.

General access to external services is passed through the proxy server. c The internal host has been authenticated to the rewall. Per-host usage should be tracked for authenticated hosts, for accounting purposes. 4. An automated process polls the Sophos [9] server periodically to check for updated virus signatures. These signatures are used on the Universitys SMTP server to scan incoming email for viruses, and on hosts for local le system scans. Appendix A outlines one possible implementation of this rewall policy, using the Linux iptables packet lter which is further described in Section 3. Of particular interest are the rules that allow access for authenticated clients as detailed in item 3c above. Since the set of authenticated clients is not static, they cannot be fully outlined in this ruleset. In order to provide access for these clients, the authentication process must also add rules to the rewall. This ruleset modication is typical of unconditional rewalling, and creates the potential for abuse or failure. This rewall conguration and policy, while relatively simple, has in most cases proven successful in protecting the internal network from attack. In a recent incident that demonstrates the problems associated with conventional rewalls, however, the Nimda worm4 [10] succeeded in infecting internal HTTP servers, and started generating probes from these systems. The Nimda programs scanning technique is extremely aggressiveso much so that the handful of infected hosts rapidly generated more than 24,000 concurrent connections outbound through the rewall. Due to this overload, the automated process to download a new set of virus signatures (including a signature for Nimda) was unable to pass through the rewallpreventing a timely automated response. In this paper we propose a modication of the current security policy to incorporate the concept of a responsive rewall which is designed to provide protection from attacks such as Nimda and others.

2. Policy and implementation of a conventional rewall The University of Canterbury has a relatively simple, but typical rewall conguration forming a link between a 132.181.0.0/16 internal network and a pair of 20 Mbps connections to the Internet. Inside this rewall, a number of independent networks are connected to a common Gigabit backbone, with each of these networks (one per department) potentially having one or more public servers (as shown in Fig. 3). The University security policy can be summarised as follows: 1. All access to hosts inside the University network must pass through the rewall. No secondary links are allowed. 2. Due to the wide distribution of public servers, a single DMZ network is not feasible. Incoming access to a specied set of servers must therefore be allowed. 3. Outgoing access through the rewall is allowed if any of the following apply: a The internal host is listed as a public server, which includes the University proxy server.
2 Various terms can be used to describe a rewall which changes its rules based upon external conditions. Such terms include: conditional, adaptive, mutable, responsive or reactive rewalls. 3 In this paper we concentrate on packet ltering but the techniques discussed here are equally applicable, with minor modications, to stateful packet lters and proxies. NAT is also omitted from this discussion for simplicity, however, the techniques discussed here are also as applicable in a NAT system.

3. Iptables [11] packet ltering A packet lter is simply a sequence of rules against which all packets traversing a rewall are matched.5 Each rule takes the form of a series of conditions (or matches), representing packet attributes that must match for this rule to be applicable, and a verdict representing an action to be taken on the packet (e.g. accept, drop, reject, branch to another chain, or log). For every rule
A network worm is a self-propagating piece of software that spreads itself over a network by exploiting weak access controls or other security problems. 5 Stateful packet ltering evaluates the initial part of a session, applying the verdict to all future packets.
4

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

1305

Fig. 3. The University of Canterbury network.

that the packet matches, the verdict is applied and, if necessary, subsequent rules in the current chain are considered (Fig. 4). Existing iptables matches include packet header elds (IP addressing, protocol, TCP/UDP ports and ags, MAC addresses), the ingress and egress interfaces, and session state (new, established, related to an existing session). Some contextual representation is supported (e.g. the iptables LIMIT token-bucket scheme6), but these require specialpurpose kernel modules and rewall ruleset modications. In order to address the issues outlined above, we have implemented special match and verdict modules, allowing the use of persistent globally shared variables and expressions in packet ltering rules and applications. 3.1. The -cond match/target In addition to the basic rule denition capabilities outlined above, the iptables framework allows the denition of new match or verdict modules. Using this framework, we
6 A token bucket is a method of limiting data ow while supporting bursty trafc. It has two parameters: a rate at which new tokens are generated, and a token capacity. Packets are allowed to pass (each destroying one token) until none remainafter this point trafc is limited to the token generation rate. This technique is used extensively in trafc shaping and QoSrefer to Refs. [12,13].

implemented a new set of modules (named cond) which support the testing and modication of variables in packet ltering rules. Fig. 5 illustrates an example of cond in action: this rule (which is appended to the OUTPUT chain) checks whether the current value in the bucket variable is greater than 0if so, it deducts one and accepts the packet. As can be seen, cond supports expressions using C-style operators7 in reverse Polish notation (RPN). In addition to resolving an expression, a cond rule can also include any of the built-in verdicts. A packet matches if the match RPN expression resolves to a non-zero value. A variable in a conditional expression can take the form of a simple text label, an integer value, or an expression containing replacement tokens of the form @(token) (refer to Table 1). These replacement tokens are replaced with values extracted from the current packet to form a nal variable label. Each variable is then translated to an integer valueeither directly, or by looking up in the global variable space (i.e. kernel bag as discussed in Section 3.2). This combination of simple operations and replacement tokens allows great exibility in the denition of rules that incorporate details from observed packets with state information. In addition, the ability to manipulate variables
In addition to common C operators, [ (min) and ] (max) operators are dened. The special , operator clears the processing stack, allowing multiple expressions to be used independently in a single rule.
7

1306

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317 Table 1 Iptables cond match/target expansion tokens Fig. 4. Structure of an iptables append command. Token expression @s @d @sp @dp @p @t @sn/## @dn/## @@ Expansion Source address in hexadecimal, network order Destination address in hexadecimal, network order Source TCP or UDP port Destination TCP or UDP port Packet size, including all headers Packet kernel timestamp, in Unix time to ms resolution Source IP address with /## mask applied Destination IP address with /## mask applied Literal @

Fig. 5. A simple token bucket using cond.

from userspace8 processes allows unlimited exibility in the context that can be represented. 3.2. The kernel bag In order to ensure that variables used in packet ltering rules are always readily available and globally shared, a dictionary of key:value pairs is kept inside the operating system kernel. In addition, access routines are provided for retrieving and setting these values from inside the kernel or via userspace applications. Each variable is stored as a combination of a text label and a 64-bit integer, organised into a sorted linked list.9 Any variable that is absent from this list is implicitly 0. Our prototype system also includes a simple command line client capable of extracting, setting and clearing the content of the kernel bag, as shown in Table 2. Through the use of this userspace client, any information that is available on a system can be used in packet ltering rule structuressuch as complex timing information, the state of remote systems, or the output of complex components (such as IDS software). 3.3. Performance optimisations Looking up values in the kernel bag and interpreting complex expressions is relatively processing-intensive. Therefore, a number of performance optimisations have been implemented: cond expressions are stored in reverse Polish notation, allowing the use of a simple stack-based interpreter. Expressions are interpreted to a binary code during rule creation, eliminating the need for tokenisation and parsing during packet processing. Literal values (cond variables that consist of a single replacement token) are stored internally as numeric values, avoiding the need for a useless bag lookup on such values.
8 Packet ltering, for performance reasons, typically forms part of the operating system (or kernel). Programming at this level is difcult, since performance and reliability problems are magnied and complex component interactions are present. In contrast, userspace processes (which run on top of the operating system) are simple to implement, and allow great exibility. 9 Overlaid on the linked list is a balanced index structure, allowing rapid access to individual or ranges of entries.

Token expansions are represented in hexadecimal, reducing key length and translation complexity. Multiple operations can be expressed using a single rule, allowing fewer rules to represent complex decision structures.10 Kernel bag values are accessed via a balanced index structure, reducing the need for linear searches while retaining absolute ordering. Derived values (such as the available bandwidth for rate limiters as demonstrated in Appendix B) are recalculated only when changed, otherwise being stored in the kernel bagreducing the average number of operations needed per packet.

4. The University rewall: a case study in reactive rewall architecture As described in Section 2, the current University security policy was found to be vulnerable during the course of the Nimda attack. This limitation did not result from inadequate conguration, but from the limitations of a traditional rewall architecture. To prevent similar future occurrences, a number of new schemes have been proposed. Implementing the following six proposals using a conventional packet ltering system would be difcult or impossible but will be demonstrated using the new extensions described in Section 3.2. 1. Monitor the trafc generated by each department in the network. Should the output of any department exceed 50% of the external link capacity,11 a tracing ag is set and the trafc is throttled. 2. In the period when the Sophos download is active, 5% of the total external link capacity should be reserved. All other trafc should be throttled. At other times, the full capacity should be made available.
10 In contrast, the rst prototype version of cond [14] allowed only a single operator per rule match or target. 11 To simplify management, this is implemented as a running maximum of the observed link capacity. Regularly halving this value (ideally during peak load) and allowing it to rebuild allows automatic detection of reduced capacities.

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317 Table 2 Bagclient commands and parameters Parameters S kkeylkvaluel I kkeyl kvaluel A kkeyl kvaluel F kkey prexl Z kkey prexl Effect Set the variable named kkeyl to a value of kvaluel Sets kkeyl to the minimum of kkeyl and kvaluel Sets kkeyl to the maximum of kkeyl and kvaluel Flush (delete) all variables that start with kkey prexl Zero all variables that start with kkey prexl Read commands (one per line) from stdin

1307

between hosts. The statistical pattern of this simulated trafc generator and its conformance to real world trafc is the subject of ongoing research.13 4.2. Implementing the proposed solutions The implementation of a rewall that includes items 1 6 of the proposed solution and listed in Section 4 above, consists of a number of specic parts. Refer to Appendix B for more detail, where square-bracketed numbers correspond to the list below. In, particular, the following major components can be identied in our solution: (1) Preparationremoving old congurations, setting the policy to a fail-safe stance, allowing trusted access to the rewall, preparing auxiliary chains and dividing trafc into incoming and outgoing directions. This also includes setting up the ingress and egress lers. (2) Calculate mon_tdiff: the time difference between when the counters were last initialised and the timestamp of the current packet. Also generation of bps_factor, which allows for the direct conversion of bit counter values into an approximation for bits per second (bps). (3) Allow Sophos virus signature updates. This is included early in the rule set to exempt this trafc from later rate limiters. When a Sophos update is about to start, the update client should set the value of sophos_active to 1 (and reset it to 0 when the update is complete). If any other trafc attempts to raise the bandwidth usage above a certain percentage (determined by the value of sophos_reservation), that trafc is dropped-preventing the Sophos update from being drowned out. (4) Suspicion checks. Packets from a data source that has been implicated in a serious policy breach are shunted into a special chain. Only DNS trafc (which is explicitly removed from this chain), and Sophos updates (which are handled before this check) are exempt. In addition to the packet lter, an external monitoring process is required to detect suspicious behaviour. For this purpose we used snort [7], a free publicly available IDS. Activity logged by snort is mapped to one of the severities listed in Table 3, and the suspicion_@s variable for that source elevated accordingly. (5) No external class C network is allowed more than 100 Kbps at any one time. Any trafc over this limit is dropped. However, for a short time after a counter reset, trafc estimates are unreliableduring this period the limit is not enforced, but is compensated for afterwards. Counter resets occur every few seconds (normally every 4 s, via an external process), to limit the memory of counter estimates. This ensures that the counter values, and derived statistics (such as the available capacity), closely mirror the current network conditions.
We are currently extending this concept to provide tools capable of simulating realistic complex application-level protocol trafc and this will be the subject of a future paper.
13

3. To protect the network against external ooding attacks, any external class C sized segment that generates more than 100 Kbps (5% of the total link capacity at the moment) should be throttled. 4. Similarly, no more than 20 incoming ICMP echo request packets should be allowed per second. 5. A variety of protocols in current use (including IRC, telnet etc.) are of limited academic value, and should only be allowed outside of working hours (unless allowed by another rule). For this purpose, working hours are dened as 07:00 19:00 weekdays, except University and public holidays. 6. An Intrusion Detection System (IDS) should be implemented and any host (local or remote) implicated in an attempted attack should be blocked. To prevent the Denial of Service condition described in Section 1 from occurring, DNS and Sophos update trafc are exempt. In addition, to reduce false positive rates (e.g. as a result of spoong), only full (duplex) connection-based attacks will be considered.12 In the remainder of this section, we demonstrate the reactive rewall rules as proposed in this paper by way of a prototype. 4.1. The network testbed In order to evaluate the effectiveness of the reactive rewall conguration, a simple networking testbed was constructed. Shown in Fig. 6, this essentially consists of two Linux hosts (Source and Linux A, acting as trafc generators), separated by a Linux rewall (Linux B) congured with our reactive rewalling extensions. In addition, a Watchguard rewall (WG, congured with an empty security policy) and an additional monitoring station (Admin) were added to observe the resulting trafc ow. The trafc used was generated using two locally developed utilities: genclient which generates TCP streams from an arbitrary source and genserver which generates responses to these client trafc requests. The combination of these two tools allowed a small number of processes (typically two clients and a server) to saturate the link
12

This corresponds to suspicion level 8 or higher, using Table 3.

1308

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

Fig. 6. A rewall testbed simulating the University network.

(6) Similar to the external trafc limiting approach used in point (5) above, each department is constrained to use no more than a given fraction (typically 50%) of the total bandwidth. Any trafc over this limit is dropped. Since the effective and nominal capacity of network links rarely correspond, the real available bandwidth is estimated as being the maximum of all observed bandwidth usage. Whenever this gure changes, a new threshold for the bandwidth allowed to a department is also calculated, reducing the per-packet calculations which would otherwise be required. In order to implement the notication part of the solution, an external process is required that monitors the value of the overload_ variables and responds when such a ag is set. (7) The policy requires that no more than 20 ICMP echo requests are allowed into the network each second. To enforce this, the packet lter checks how many ICMP echo request packets it has already passed during this second-if this matches the threshold, the new request is dropped. As with trafc counters, these token counters must be cleared periodically (in this case, every second) to replenish the token bucket. (8) As in Section 2, authenticated hosts must be allowed access. With the use of conditional rules, however, it becomes possible to include this access control in an unchanging rewall rule set-instead of modifying rules, the value of authentication variables are modied. Similarly, per-host accounting is simple to implement. As is the case in many of these examples, a userspace supporting application is required. In this case, a server that maintains the value of auth_@s (refer to Table 1) and logs accounting information is required. Unlike the existing rewall, however, this server does not require the capability to modify the rewall or a specialised ltering module. (9) During off-peak times, a number of other services are also supported. In this rule set, we have used telnet as an example of such a service. The off-peak chain drops all

trafc during peak times-where such peak times depend on the value of general state variables. These variables are set from userspace applications, allowing arbitrarily complex classicationsin this example, including public and University holidays. (10) Finally, each packet that is allowed through the rewall contributes to a general trafc counter, which is used to maintain bandwidth limits. The current bandwidth usage is estimated as the total number of bits seen since the last counter reset, divided by the time since the rst packet after that time (in seconds). Over a reasonable period, with non-trivial trafc rates, this gives a good approximation. This approximation breaks down if either the time period or the trafc rate is very low. Therefore a hold time has been set after each counter reset, during which bandwidth estimates are invalid. In addition, bandwidth limit values are calculated for the departmental and Sophos limiters, to reduce overall processing overhead.

5. Experimental results To test the effectiveness of the rules described in Section 4.2, the rule set was implemented on our
Table 3 Suspicion level ratings Level 0 2 4 6 8 10 Implication No suspicious activities or new peer Single-packet probe, may be spoofed Single-packet attack, may be spoofed Duplex (connection-based) probe Duplex (connection-based) attack Administratively blocked

An alternative, bit ag-based system would allow greater exibility, but would complicate the examples used.

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

1309

Fig. 7. Testbed throughput: no, static and conditional rewalls.

network testbed (described in Section 4.1). Firewall throughput was then monitored, based on a continuous trafc ow between genclient and genserver processes, with different threshold values in place in the trafc shaper components.

Test output is presented in the form of screen shots from a Microsoft Performance Monitor instance, running on the Admin host (Figs. 7 10). Typically, these screen shots show the observed trafc in terms of % Network Utilisation, or Total bytes received per second (scaled by 1024).

Fig. 8. The effect of a 50% Sophos bandwidth reservation.

1310

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

Fig. 9. Limiting trafc to 30% of the link capacity.

5.1. Performance overhead The rst test performed involved comparing the maximum throughput possible for this testbed and software conguration. This forms an upper range against which

further results can be compared. Fig. 7 shows the throughput of the rewall (the upper line representing network utilisation, the lower line representing trafc rates): With no rewall ruleset in place (before point A)

Fig. 10. 100 Kbps limiting for 1 4 trafc segments.

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

1311

With the basic rewall ruleset (described in Section 2) in place (between points A and B; the drop in trafc follows from the time taken to recongure the rewall) With the complete conditional rewall (described in Section 4.1) in place (after point B). The marked drop in trafc at point B represents the conguration and learning time of the conditional ruleset. Note that the trafc ow here is such that none of the rate limiting rules are yet taking effect, though they are being tested. The basic testbed conguration is capable of fully utilising the 10 Mbps network links used, as shown in the rst section of this test. A simple packet ltering rewall has minimal performance impact, while our conditional rewall implementation increases the processing load on the rewall markedly (from around 60% to around 80%, as reported by top on a Pentium-166 system). In spite of the increased load, the rewall is still capable of saturating the 10 Mbps network links. Maintaining and testing the trafc shaping components of this system is relatively processing intensive (due to the number of checks traversed for each packet). In addition, the greater complexity of the rule set (and the increased number of rules) contribute to the greater processing load observed. The conditional rewall implementation does not adversely affect overall throughput in our test environment. 5.2. Sophos bandwidth reservation The rst, and simplest, trafc shaper included in the conditional rewall conguration is intended to reserve some portion of the available bandwidth for a Sophos Antivirus signature download. Fig. 8 shows an example of this process in action, where 50% of the available bandwidth (learned by the system as the maximum of all throughput observations, corresponding to the upper horizontal line) is reserved. This gure shows a normal trafc ow, the reservation coming into effect, and the reservation being removed. The lower horizontal line represents 50% of the available bandwidth. The ruleset implemented attempts to force all non-Sophos trafc (all trafc shown) to, on average, not exceed this level. The highly variable throughput observed is an artifact of the bandwidth calculation method used. Calculating the throughput of the rewall via a userspace application, allowing more complex calculations and contiguous estimations could alleviate this effect. 5.3. Departmental and external network limiting Finally, the effectiveness of the departmental bandwidth usage and external network throughput limiters were tested. As shown in Fig. 9, applying a 30% limit to trafc originating from a single department (indicated by the horizontal line, shown relative to a xed 10 Mbps

capacity) forces the average throughput to approximately 30%, but introduces cyclical variations in the actual throughput. Similarly, limiting trafc from external networks to 100 Kbps per class C network introduces signicant periodic variations in the actual throughput. In Fig. 10 the throughput corresponding to 1, 2, 3 and 4 links to separate class C networks are shown, with horizontal lines indicating the target throughput. While effective in limiting the average utilisation or throughput to a set level, the trafc load estimation techniques used in this implementation introduce quite signicant (and additive) variations in throughput. Conditional rewalling rule sets can produce powerful capabilities in a rewall system, but great care must be taken when building such congurations. A method for presenting smooth, continuous bandwidth estimations inside the conditional rewall framework is a subject for further research.

6. Conclusion In Ref. [14] we introduced the concept of conditional rewall rules. In this paper, we discuss and demonstrate a more mature version of these concepts, featuring full RPN expressions in rules and improved performance for conditional rewalling. Based on this work, it is clear that conditional rewall rules are not only feasible, but offer vastly improved exibility in rewall conguration and extension beyond traditional approaches. This paper demonstrates some of the advanced techniques made possible by the use of conditional rules, notably including exible trafc shaping, ne-grained trafc accounting, and extending the rewall to incorporate external (userspace) information sources. Further work currently underway includes development tools which will enable the generation of complex application-level protocol trafc. Beyond this, further work remains to be carried out in the area of exploring alternative applications of conditional rewalling (mainly when combined with stateful packet ltering, proxies and NAT), further performance enhancement, and the possibility of kernel-driven trigger notication.

Appendix A. The University rewall implemented using iptables Lines starting with a # character denote comments, which further explain the rules involved

1312

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

1313

Appendix B. The University rewall implementation code for prototype reactive rewall

1314

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

1315

1316

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 13021317

1317

References
[1] B. Aboba, W. Dixon, IPsec-NAT Compatibility Requirements, draftietf-ipsec-nat-reqts-01.txt, Internet Engineering Task Force, March 2003. [2] O. Spatscheck, J.S. Hansen, J.H. Hartman, L.L. Peterson, Optimizing TCP forwarder performance, IEEE/ACM Transactions on Networking 8 (2) (2000) 146 157. ftp://ftp.cs.arizona.edu/reports/1998/ TR98-01.ps. [3] Watchguard Technologies, Watchguard Network Security HandbookVersion 5.0, 2002. [4] Psionic Technologies, Psionic PortSentry, 2002, http://www.psionic. com/abacus/portsentry/ [5] Check Point, Panda Antivirus for CVP Firewalls, August 2001, http:// www.checkpoint.com/opsec/partners/downloads/panda_white_paper. pdf. [6] Guardian Active Response for Snort, http://www.chaotic.org/guardian, March 2002. [7] SnortThe Open Source Network Intrusion Detection System, http:// www.snort.org/.

[8] A. Chuvakin, Intrusion Detection Response, http://www. linuxsecurity.com/feature_stories/ids-active-response.html, April 2002. [9] Sophos, Sophos Anti-Virus, 2002, http://www.sophos.com/products/ software/antivirus/. [10] Caida, Dynamic Graphs of the Nimda Worm, Caida.org, September 2001, http://www.caida.org/dynamic/analysis/security/nimda/index. html. [11] R. Russel, M. Boucher, J. Morris, H. Welte, The netlter/iptables project, http://netlter.samba.org/. [12] G. Huston, Internet Performance Survival Guide, Wiley, New York, 2000, pp 226-234, ISBN 0-471-37808-9. [13] B. Huber, G. Maxwell, R. van Mook, M. van Oosterhont, P. Schroeder, J. Spaans, Linux Advanced Routing and Trafc Control HOWTO, December 2001, http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO. [14] R. Hunt, T. Verwoerd, Policy and implementation of an adaptive rewall, Proceedings of the 10th IEEE International Conference on Networks, Singapore August (2002).