Reactive firewalls—a new technique

Reactive firewalls—a new technique

Ray Hunta,*, Theuns Verwoerdb

aDepartment of Computer Science, University of Canterbury, Private Bag 4800, Christchurch, New ZealandbAllied 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 firewalls are configured according to a

set of static rules based upon a policy. To date, development in firewall architectures which can react to attacks such as those demonstrated by

the Nimda virus are very limited. Yet it is essential that firewalls are able to cope with and react to such attacks. The idea of a firewall

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 filter; Application proxy; Stateful packet filter; Firewall architecture; Conditional firewall 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. Fre-

quently, owing to cost, a firewall is the only effective

security measure used in smaller networks, and is relied

upon to implement the entire security policy for that

network.

Traditional firewall systems can be categorised into three

major techniques: packet filtering, stateful packet filtering

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 filtering inspects each packet that traverses the

firewall, 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 fine-grained

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 fine-

grained protocol control, content filtering and detailed

logging. However, the use of two data connections, one on

either side of the firewall, and the associated flow 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 filtering lies somewhere between appli-

cation proxies and simple packet filtering. In its simplest

form, stateful filtering functions as a packet filter 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 filters 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

Computer Communications 26 (2003) 1302–1317

www.elsevier.com/locate/comcom

0140-3664/03/$ - see front matter q 2003 Elsevier Science B.V. All rights reserved.

doi:10.1016/S0140-3664(03)00111-7

E-mail addresses: [email protected] (T.

Verwoerd); [email protected] (R. Hunt).

* Corresponding author. Tel.: þ64-3-3642347; fax: þ64-3-3642569.1 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].

http://www.elsevier.com/locate/comcom

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 connec-

tion, is highly limited. This is because conventional

stateful packet filters cannot represent concepts outside of

the data flow (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

modifications, 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 filter, 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 filtering and application proxies,

while possibly capable of recognising the attack, have no

means of storing this information short of modifying the

firewall configuration. Basically a firewall policy is a

specification for the implementation of a static rule set and

there is currently no flexible method of either recording or

adapting to past behaviour.

There has been some limited development in mutable

firewall configurations. Some firewalls 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

defined 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.

† 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 firewall/router

configuration is modified to exclude the host involved.

† Checkpoint [5] has an API which allows it to accept

firewall rule modification from an external IDS. Should a

compatible IDS detect an attack it could modify the

firewall configuration to exclude the attacker.

† Guardian [6] is a security program which operates by

automatically updating firewall rules based upon alerts

generated by Snort [7] and blocking all incoming data

from the IP address of the attacking machine.

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 firewall 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 company’s DNS server,

the firewall 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 firewalling

systems, we would like to propose an extension to the

semantics of (stateful) packet filtering systems that would

allow data to be recalled, used and shared amongst packet

filtering rules and applications.

Fig. 1. OSI layer v connection state for existing and new firewall systems.

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

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 1302–1317 1303

Stateful Packet Filtering only carries out single connec-

tion tracking and only cares about past behaviour of a

specific 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 Rules’2 are illustrated by the

introduction of a third dimension in Fig. 1 and would allow

considerable flexibility in implementing packet filtering

rules3 and proxies, ranging from elegant support for

excluding attackers, to the ability to define complex traffic

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 firewall

implementation for a University firewall in Section 2.

Following this, we discuss the semantics of a packet filtering

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 firewall rules including IDS

interaction and traffic shaping systems, followed by a final

conclusion and description of further work in Section 6.

2. Policy and implementation of a conventional firewall

The University of Canterbury has a relatively simple, but

typical firewall configuration forming a link between a

132.181.0.0/16 internal network and a pair of 20 Mbps

connections to the Internet. Inside this firewall, 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 firewall. 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

specified set of servers must therefore be allowed.

3. Outgoing access through the firewall is allowed if any of

the following apply:

a The internal host is listed as a public server, which

includes the University proxy server.

b General access to external services is passed

through the proxy server.

c The internal host has been authenticated to the

firewall. 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 University’s SMTP

server to scan incoming email for viruses, and on hosts for

local file system scans.

Appendix A outlines one possible implementation of

this firewall policy, using the Linux iptables packet filter

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 firewall. This ruleset modification is typical of

unconditional firewalling, and creates the potential for

abuse or failure.

This firewall configuration 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

firewalls, however, the Nimda worm4 [10] succeeded in

infecting internal HTTP servers, and started generating

probes from these systems. The Nimda program’s scanning

technique is extremely aggressive—so much so that the

handful of infected hosts rapidly generated more than

24,000 concurrent connections outbound through the fire-

wall. 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

firewall—preventing a timely automated response. In this

paper we propose a modification of the current security

policy to incorporate the concept of a responsive firewall

which is designed to provide protection from attacks such as

Nimda and others.

3. Iptables [11] packet filtering

A packet filter is simply a sequence of rules against

which all packets traversing a firewall 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

2 Various terms can be used to describe a firewall which changes its rules

based upon external conditions. Such terms include: conditional, adaptive,

mutable, responsive or reactive firewalls.3 In this paper we concentrate on packet filtering but the techniques

discussed here are equally applicable, with minor modifications, to stateful

packet filters and proxies. NAT is also omitted from this discussion for

simplicity, however, the techniques discussed here are also as applicable in

a NAT system.

4 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 filtering evaluates the initial part of a session, applying

the verdict to all future packets.

R. Hunt, T. Verwoerd / Computer Communications 26 (2003) 1302–13171304

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 fields

(IP addressing, protocol, TCP/UDP ports and flags, 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 special-

purpose kernel modules and firewall ruleset modifications.

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 filtering rules and applications.

3.1. The -cond match/target

In addition to the basic rule definition capabilities

outlined above, the iptables framework allows the definition

of new match or verdict modules. Using this framework, we

implemented a new set of modules (named cond) which

support the testing and modification of variables in packet

filtering 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 0—if 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 final

variable label. Each variable is then translated to an integer

value—either 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 flexibility in the definition of rules that

incorporate details from observed packets with state

information. In addition, the ability to manipulate variables

Fig. 3. The University of Canterbury network.

6 A token bucket is a method of limiting data flow while supporting

bursty traffic. 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 remain—after this point traffic is limited to

the token generation rate. This technique is used extensively in traffic

shaping and QoS—refer to Refs. [12,13].

7 In addition to common C operators, ‘[‘ (min) and ‘]’ (max) operators are

defined. The special ‘,’ operator clears the processing stack, allowing

multiple expressions to be used independently in a single rule.


from userspace8 processes allows unlimited flexibility in the

context that can be represented.

3.2. The kernel bag

In order to ensure that variables used in packet filtering

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 filtering

rule structures—such 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.

† 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

bag—reducing the average number of operations needed

per packet.

4. The University firewall: a case study in reactive

firewall 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

configuration, but from the limitations of a traditional firewall

architecture. To prevent similar future occurrences, a number

of new schemes have been proposed. Implementing the

following six proposals using a conventional packet filtering

system would be difficult or impossible but will be demon-

strated using the new extensions described in Section 3.2.

1. Monitor the traffic generated by each department in the

network. Should the output of any department exceed 50%

of the external link capacity,11 a tracing flag is set and

the traffic is throttled.

2. In theperiodwhentheSophosdownloadisactive,5%ofthe

total external link capacity should be reserved. All other

traffic should be throttled. At other times, the full capacity

should be made available.

Fig. 4. Structure of an iptables append command.

Fig. 5. A simple token bucket using cond.

Table 1

Iptables cond match/target expansion tokens

Token expression Expansion

@s Source address in hexadecimal, network order

@d Destination address in hexadecimal, network order

@sp Source TCP or UDP port

@dp Destination TCP or UDP port

@p Packet size, including all headers

@t Packet kernel timestamp, in Unix time to

ms resolution

@sn/## Source IP address with /## mask applied

@dn/## Destination IP address with /## mask applied

@@ Literal @

8 Packet filtering, for performance reasons, typically forms part of the

operating system (or kernel). Programming at this level is difficult, since

performance and reliability problems are magnified 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 flexibility.9 Overlaid on the linked list is a balanced index structure, allowing rapid

access to individual or ranges of entries.

10 In contrast, the first 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.


3. To protect the network against external flooding attacks,

anyexternalclassCsizedsegment thatgeneratesmorethan

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 defined

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 traffic are exempt. In

addition, to reduce false positive rates (e.g. as a result of

spoofing), only full (duplex) connection-based attacks will

be considered.12

In the remainder of this section, we demonstrate the

reactive firewall 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

firewall configuration, a simple networking testbed was

constructed. Shown in Fig. 6, this essentially consists of

two Linux hosts (Source and Linux A, acting as traffic

generators), separated by a Linux firewall (Linux B)

configured with our reactive firewalling extensions. In

addition, a Watchguard firewall (WG, configured with an

empty security policy) and an additional monitoring

station (Admin) were added to observe the resulting

traffic flow.

The traffic 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 traffic requests. The combination of

these two tools allowed a small number of processes

(typically two clients and a server) to saturate the link

between hosts. The statistical pattern of this simulated traffic

generator and its conformance to real world traffic is the

subject of ongoing research.13

4.2. Implementing the proposed solutions

The implementation of a firewall that includes items 1–6

of the proposed solution and listed in Section 4 above,

consists of a number of specific 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 identified in our solution:

(1) Preparation—removing old configurations, setting

the policy to a fail-safe stance, allowing trusted access to the

firewall, preparing auxiliary chains and dividing traffic into

incoming and outgoing directions. This also includes setting

up the ingress and egress filers.

(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 traffic 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

traffic attempts to raise the bandwidth usage above a certain

percentage (determined by the value of sophos_reserva-

tion), that traffic 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 traffic (which is explicitly removed

from this chain), and Sophos updates (which are handled

before this check) are exempt.

In addition to the packet filter, 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 traffic over this limit is

dropped. However, for a short time after a counter reset,

traffic estimates are unreliable—during 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.

Table 2

Bagclient commands and parameters

Parameters Effect

S kkeylkvaluel Set the variable named kkeyl to a value of kvaluelI kkeyl kvaluel Sets kkeyl to the minimum of kkeyl and kvaluelA kkeyl kvaluel Sets kkeyl to the maximum of kkeyl and kvaluelF kkey prefixl Flush (delete) all variables that start with kkey prefixlZ kkey prefixl Zero all variables that start with kkey prefixl– Read commands (one per line) from stdin

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

13 We are currently extending this concept to provide tools capable of

simulating realistic complex application-level protocol traffic and this will

be the subject of a future paper.


(6) Similar to the external traffic 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 traffic 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 figure 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 notification part of the solution,

an external process is required that monitors the value of the

overload_ variables and responds when such a flag 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 filter 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 traffic 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 firewall rule set-instead of modifying rules, the

value of authentication variables are modified. 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

firewall, however, this server does not require the capability

to modify the firewall or a specialised filtering 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

traffic 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

classifications—in this example, including public and

University holidays.

(10) Finally, each packet that is allowed through the

firewall contributes to a general traffic 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 first packet

after that time (in seconds). Over a reasonable period, with

non-trivial traffic rates, this gives a good approximation.

This approximation breaks down if either the time period

or the traffic 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 Implication

0 No suspicious activities or new peer

2 Single-packet probe, may be spoofed

4 Single-packet attack, may be spoofed

6 Duplex (connection-based) probe

8 Duplex (connection-based) attack

10 Administratively blocked

An alternative, bit flag-based system would allow greater flexibility, but

would complicate the examples used.

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


network testbed (described in Section 4.1). Firewall

throughput was then monitored, based on a continuous

traffic flow between genclient and genserver processes,

with different threshold values in place in the traffic

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 traffic in terms of % Network Utilisation,

or Total bytes received per second (scaled by 1024).

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

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


5.1. Performance overhead

The first test performed involved comparing the

maximum throughput possible for this testbed and software

configuration. This forms an upper range against which

further results can be compared. Fig. 7 shows the throughput

of the firewall (the upper line representing network

utilisation, the lower line representing traffic rates):

† With no firewall ruleset in place (before point A)

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

Fig. 10. 100 Kbps limiting for 1–4 traffic segments.


† With the basic firewall ruleset (described in Section 2) in

place (between points A and B; the drop in traffic follows

from the time taken to reconfigure the firewall)

† With the complete conditional firewall (described in

Section 4.1) in place (after point B). The marked drop in

traffic at point B represents the configuration and

learning time of the conditional ruleset. Note that the

traffic flow here is such that none of the rate limiting rules

are yet taking effect, though they are being tested.

The basic testbed configuration is capable of fully

utilising the 10 Mbps network links used, as shown in the

first section of this test. A simple packet filtering firewall has

minimal performance impact, while our conditional firewall

implementation increases the processing load on the firewall

markedly (from around 60% to around 80%, as reported by

top on a Pentium-166 system). In spite of the increased load,

the firewall is still capable of saturating the 10 Mbps

network links.

Maintaining and testing the traffic 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 firewall implementation does not adversely

affect overall throughput in our test environment.

5.2. Sophos bandwidth reservation

The first, and simplest, traffic shaper included in the

conditional firewall configuration 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 figure shows a normal traffic flow, 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 traffic (all traffic 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 firewall 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 band-

width usage and external network throughput limiters

were tested. As shown in Fig. 9, applying a 30% limit to

traffic originating from a single department (indicated by

the horizontal line, shown relative to a fixed 10 Mbps

capacity) forces the average throughput to approximately

30%, but introduces cyclical variations in the actual

throughput.

Similarly, limiting traffic from external networks to

100 Kbps per class C network introduces significant

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 traffic load estimation

techniques used in this implementation introduce quite

significant (and additive) variations in throughput. Con-

ditional firewalling rule sets can produce powerful capa-

bilities in a firewall system, but great care must be taken

when building such configurations. A method for presenting

smooth, continuous bandwidth estimations inside the

conditional firewall framework is a subject for further

research.

6. Conclusion

In Ref. [14] we introduced the concept of conditional

firewall 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 firewalling.

Based on this work, it is clear that conditional firewall

rules are not only feasible, but offer vastly improved

flexibility in firewall configuration and extension beyond

traditional approaches. This paper demonstrates some of

the advanced techniques made possible by the use of

conditional rules, notably including flexible traffic shap-

ing, fine-grained traffic accounting, and extending the

firewall to incorporate external (userspace) information

sources.

Further work currently underway includes development

tools which will enable the generation of complex

application-level protocol traffic. Beyond this, further

work remains to be carried out in the area of exploring

alternative applications of conditional firewalling (mainly

when combined with stateful packet filtering, proxies and

NAT), further performance enhancement, and the possi-

bility of kernel-driven trigger notification.

Appendix A. The University firewall implemented using

iptables

Lines starting with a ‘#’ character denote comments,

which further explain the rules involved



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





References

[1] B. Aboba, W. Dixon, IPsec-NAT Compatibility Requirements, draft-

ietf-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 Network-

ing 8 (2) (2000) 146–157. ftp://ftp.cs.arizona.edu/reports/1998/

TR98-01.ps.

[3] Watchguard Technologies, Watchguard Network Security Handbook-

Version 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/guar-

dian, March 2002.

[7] Snort—The 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 netfilter/iptables

project, http://netfilter.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 Traffic Control HOWTO,

December 2001, http://www.linux.org/docs/ldp/howto/Adv-Routin-

g-HOWTO.

[14] R. Hunt, T. Verwoerd, Policy and implementation of an adaptive

firewall, Proceedings of the 10th IEEE International Conference on

Networks, Singapore August (2002).


ftp://ftp.cs.arizona.edu/reports/1998/TR98-01.ps

ftp://ftp.cs.arizona.edu/reports/1998/TR98-01.ps

http://www.psionic.com/abacus/portsentry/

http://www.psionic.com/abacus/portsentry/

http://www.checkpoint.com/opsec/partners/downloads/panda_white_paper.pdf



http://www.chaotic.org/guardian

http://www.chaotic.org/guardian

http://www.snort.org/

http://www.snort.org/

http://www.linuxsecurity.com/feature_stories/ids-active-response.html

http://www.linuxsecurity.com/feature_stories/ids-active-response.html

http://www.sophos.com/products/software/antivirus/

http://www.sophos.com/products/software/antivirus/

http://www.caida.org/dynamic/analysis/security/nimda/index.html

http://www.caida.org/dynamic/analysis/security/nimda/index.html

http://netfilter.samba.org/

http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO

http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO

Documents

Reactive firewalls—a new technique