FACE: A Firewall Analysis and Configuration Engine

1. Introduction
Firewalls are one of the most important components in an organizations security setup. Traditionally a firewall has been deployed only at the organizations gateway to the Internet. However, this deployment scenario has many shortcomings- both security and administration wise. Firstly, the firewall-at-gateway scenario does not offer any protection from internal threats since internal traffic never crosses the firewall. Secondly, it is very hard to keep the firewalls configuration up to date with the desired policy at each endhost in the organization. In practice, the gateway firewall ends up being either too restrictive and blocks legitimate traffic, or it ends up being too open and lets in potentially malicious traffic. The shortcomings of a single firewall architecture have led to the distributed firewall model [2, 8]. In a distributed firewall, every machine in the network gateway, router, server or PC can run a firewall. The distributed firewall is very flexible as the total set of firewalls in the network can be configured to implement the filtering policy at each end-host. Allowing users or departments within an organization to configure their own firewalls leads to better distribution of administrative workload. The problem with distributed firewalls is manageability. In the firewall-at-gateway scenario, there is a single firewall to configure and maintain. In a distributed firewall, there are multiple firewalls that have to be managed. Moreover, firewalls cannot be configured in isolation their dependence on routing policies, network topology and other firewalls has to be taken into account. Two things are needed to aid the administrator in managing a distributed firewall: Automated rule generation: Writing firewall rules that correctly implement organizational policy is hard and prone to errors. It is very desirable to have a tool that can automatically generate rule-sets to implement the desired policy within the specified network topology. Analysis tool: It would be very useful for administrators to have a tool to answer firewall related queries such as what traffic is permitted or denied. Analysis can be used to understand and finetune firewall rules. To avoid human introduced errors (which is easy to do while working with

firewall rules) and to reduce administrator workload, the analysis tool needs to be as automated as possible. Automatically configuring a distributed firewall is not straightforward. In this paper, we show several situations where stated security policies cannot be correctly implemented because of potential packet spoofing. FACE generates firewall configurations to implement the specified policy whenever it is possible to realize the policy. When it is not possible to realize the specified policy, FACE points out why it is so and suggests measures that can make implementation of the policy possible. Suggestions include changes to trust assumptions and setting up IPSec connections. The rest of this paper is organized as follows. In Section 2 we introduce relevant terminology. Section 3 describes our objectives including including the FACE threat model. Section 4 discusses relevant research. Section 5 describes the FACE firewall and network model, Sections 6 and 7 describe the configuration and analysis algorithms respectively. Section 8 concludes the paper and discusses some opportunities for future work.

2. Terminology
In this section, we define the terms and concepts that we refer to in later sections. Organizational firewall policy: In this paper, organizational firewall policy defines what traffic is permitted on each machine in the network. The work in this paper is restricted to policies that drop all traffic by default and specify only what is allowed. Firewall configuration: For a stand-alone firewall, its configuration is defined as its rule-set. For a network with multiple firewalls, firewall configuration refers to the locations and configurations of its individual firewalls.

3. Objectives
We classify our objectives into two categories configuration and analysis. A key objective of FACE is to configure firewalls so as to not allow spoofed traffic in the network from specified nodes. Spoofed traffic consists of packets that originate from a different machine than their claimed source. Attackers employ spoofed traffic to mask the true location of the packet source to cover their tracks or gain unauthorized access to services. Man-in-the-middle attacks and Smurf distributed denial of service attacks [14] are well-known attacks that employ IP

Packet spoofing. According to Howard, these attacks increased by 50 percent per year between 1989 and 1995 [7] and, more recently, Smurf attacks have become increasingly frequent [14]. Such attacks often use compromised hosts within corporations. Once a companys security perimeter is breached, compromised machines can be used to find other services on an internal network. Unfortunately, packet spoofing is inherent in the Internet since the Internet Protocol (IP) does not provide any assurance about the true source of a packet. Firewalls, if appropriately deployed, are an important part of a networks security and can limit flow of spoofed packets. An important goal of FACE is to provide help in configuring firewalls in an organizations internal network so as to reject packets that may be spoofed. Threat Model The threat model in FACE is defined in terms of whether or not a network node (a machine or a set of machines) is trusted to not generate any spoofed traffic; such a node is called a trusted node. We note that if an untrusted node is connected to a single router, egress filtering at the router is enough to prevent spoofing from the untrusted node. However, if multiple routers connect to an untrusted node to trusted nodes, the untrusted node must not be used to route traffic that is from another node; otherwise the untrusted node can also spoof IP addresses that are routed via the node. FACE firewall rules are designed to disallow traffic that is routed via untrusted nodes. Firewall trust assumption: FACE assumes that each firewall in the network correctly filters traffic according to its rule-set, as well as does not generate any spoofed traffic. Trusted path: A path in the network is trusted if it consists only of trusted nodes. Implementable policy: A firewall policy is implementable if it is possible to configure firewall rules so that the desired policy is realized under the given trust assumptions and network topology. Configuration Goals Correctly configuring multiple firewalls to implement the desired organizational policy is not trivial. Misconfiguration of rules at any firewall can lead to policy violations. Some nodes may not be in a position to implement the action desired of them. Manually keeping track of the entire network topology while configuring firewalls is difficult for administrators in all but the most simple networks. In some cases, it is possible that

the organizational policy is not realizable through the use of firewalls alone, but requires establishment of IPSec tunnels. Our objective is to be able to automatically determine if the desired policy is implementable and to generate firewall rules (with due consideration to the topology and the locations of firewalls in the network). serve to check if the existing firewall rules correctly implement the required policy. If not, what are the implicit trust assumptions being made. Correctness of generated rule-sets: If the specified organizational policy is implementable, generated rule-sets must correctly implement it, i.e. the desired traffic must be permitted, while all undesired traffic must be blocked. Bandwidth efficiency: Generated rule-sets should minimize network traffic. Specifically, traffic that will be ultimately dropped should not be propagated.

Figure - Using the configuration tool Using the automated configuration generator is an iterative process (as depicted in Figure 3). The initial policy specified by the administrator might be unimplementable under the given

trust assumptions and network topology. The administrator will then need to tweak the policy, trust assumptions or network topology and run configuration generator until the desired policy becomes implementable and the corresponding firewall rule-sets are generated. To facilitate this iterative process, the configuration tool should output why the current policy is not implementable and suggestions that can make the policy implementable.

3.2. Firewall Analysis

The firewall analyzer tool should be able to answer queries about the firewalls and the permitted/blocked traffic. Some of these queries are: I. II. III.
IV.

given a source, destination and set of services, which of the services at are accessible from the source

the destination

given a source, destination and packet list, which packets can reach the destination from the source given a destination and packet list, which hosts in the network can send the specified packets to the given destination compare different firewall configurations for equivalence (two configurations are equivalent if they enforce the same policy) which rules in a given firewall rule-set are redundant or never matched (note that never matched redundant, but redundant- never matched) which hosts a given node can spoof what effect disabling/enabling of a firewall will have what effect a node compromise will have what would be the effect of a new node/link in the network (for example, a visitor with a laptop that connects to the wireless network) what changes need to be made to a given configuration to correctly implement organizational policy

V.

VI.
VII.

VIII. IX. X.

4. Related Work
We are not aware of any work that tries to leverage distributed firewalls to prevent packet spoofing. However, there has been quite a bit of work on firewall analysis and firewalls themselves, We describe some of that in this section.

There are two types of approaches towards firewall analysis: active analysis and passive analysis. Active analysis tools work by actively injecting traffic into the network and studying its reaction to the injected traffic. Thus, it tests the network as is rather than as it is expected to be. Specifically, active analysis is useful in discovering buggy/non-standard firewall implementations. There are a number of active analysis tools available [12, 13]. Due to its nature, active analysis cannot be employed to test a configuration before it is deployed. We do not consider such analysis further, as it is beyond the scope of our work. Passive analysis techniques for firewall analysis take static information and use that for offline analysis [11, 3, 6]. Inputs to static analysis include firewall configuration files, network topology data, and other static data. Static analysis algorithms process the input data and produce analysis results as output. FANG [11] is a firewall analysis tool that uses graph algorithms to determine what packets are allowed between two points in the network. The user is presented with a graphical front end and can initiate queries. A notable feature of FANG is that it is able to determine the impact of IP spoofing. Constraint Logic Programming in Eclipse (a Prolog based environment) has been used to analyze the given firewall configuration [3]. The tool requires a knowledge base of rules that describe the network topology, packet formats, firewall rules, etc. Queries can be made to the system using predicates such as incoming-tcp (host,port) (true if host accepts connections to port). Unification and constraint satisfaction are used to find all possible values for uninstantiated variables in query predicates. Boolean Decision Diagrams (BDD) can be used to efficiently represent and analyze firewall configurations [6]. The use of BDDs significantly reduces the memory required to store a rule-set. In addition to being efficient, it is also possible to answer a number of interesting questions about a firewall rule-set within the described framework. For example, it is possible to check a rule-set for redundancy and compare equivalence of rule-sets as well as to answer queries about permitted traffic. Though the described algorithms have do not analyze multiple firewalls, they answer a number of questions regarding independent firewall rulesets that are also answered by our analysis algorithm.

A number of tools that generate the firewall rule-set for a single host exist [5, 10, 15, 16]. However, none of these is intended for use with multiple firewalls. Though it might be possible to configure multiple firewalls in the network by repeated application of these tools, the process is tedious, and the resulting rule-sets would fail to utilize knowledge about network topology and organizational (as opposed to host) policy. Firmato [1] is a firewall configuration and analysis toolkit. Firmato allows administrators to specify a high level organizational policy and a description of the network topology. It generates firewall configuration files to implement the specified policy. A key concept introduced in the paper is that of a role, which encapsulates the capabilities of hosts. The use of such high level concepts greatly eases the task of writing firewall rules. Given a policy, the Firmato configures firewalls by setting up ACCEPT rules on every path between all source-destination pairs. This approach is vulnerable to spoofing attacks.

5. Firewall and Network Model

This section describes the firewall model and network model used in FACE. 5.1. Firewall Model The firewall model is motivated by the structure of Iptables [9]. Figure 4 shows the points at which a packet can interact with the firewall. When a packet reaches a node, the node checks whether it is the packet destination. If so, INPUT rules at the node are applied to the packet. If the rules accept the packet, it is passed up to the application, otherwise it is dropped. If the node is not the destination and the node is a router, the packet is forwarded on after passing it through the FORWARD rule-set. OUTPUT rules are applied only to locally generated packets. 5.2. Network Objects This section lists the objects used to represent the network in our implementation. IPAddressSet represents a range of Internet Protocol addresses. For example, 10.10.10.1010.10.11.255 represents the IP Address range from 10.10.10.10 to 10.10.11.255 (including both). PacketSet provides a compact representation for a set of packets. It can be used to represent a set of TCP, UDP, ICMP, or Undefined protocol packets. The fields of a Packet- Set are: protocol (TCP/UDP/ICMP/Undefined), source and destination addresses (IPAddressSet), connection state (new, established, related, undefined), source and destination port ranges (for TCP/UDP only),

TCP flags (SYN, ACK, RST, FIN, URG, PSH), type and code (for ICMP only). Some PacketSet examples are given below: 1. The most general PacketSet is represented by setting protocol to Undefined, both source and destination address ranges to 0.0.0.0-255.255.255.255 and state to Undefined. 2. TCP SYN packets to port 80 (http) on the CSE Webserver (see Figure 2) are represented by setting protocol to TCP, source address to 0.0.0.0-255.255.255.255, destination address to 200.10.10.10-200.10.10.10, source port range to 0-65535, destination port range to 8080, and TCP flags to SYN=1, ACK=0, RST=0, FIN=0, PSH=Undefined, URG=Undefined. The PacketSet representation can compactly represent an extremely large set of packets. This enables FACE to efficiently simulate traversal of packets through the network. Node represents an entity (end host, LAN, or router) in the network. In our implementation, there are three types of Nodes: lan, host and router as described below. lan: this identifies a set of machines on a local area network or a collection of machines not under the organizations administration (for example, the Internet).We assumethat any packet sent to a lan can be read by all hosts in the corresponding LAN.We also assume that hosts in a lan can spoof each other unless some other mechanisms such as IPSec connections are set up. host: the end hosts (for example, workstations) in the network. router: a routing device that inter-connects multiple lans and hosts. Only Nodes of type host and router can be firewalls. The Node structure contains a flag indicating whether it is a firewall or not. If the Node is a firewall, its filtering rules are specified as a list. As depicted in Figure 4, there are three sets of filtering rules associated with each Node: INPUT, OUTPUT, and FORWARD. Each Node object contains a flag that indicates whether it is trusted. A firewall node that is not trusted will not apply any packet filtering rules. All packets that reach it are assumed to be passed. Nodes that are not trusted can generate traffic with any source address and send it over links connected to the Node. Our current implementation of FACE further assumes that a firewall can be placed on all trusted nodes. Firewalls are available for common operating systems. Many routers also have an ability to selectively drop packets or can be augmented by firewalls. So, the assumption is not entirely unreasonable in the future. If that is not the case, FACE can still be used to configure rules on firewalls that do exist, though some of the guarantees on preventing flow of traffic via spoofed nodes may not hold.

Link identifies an interconnection between Nodes. In our implementation, Links are unidirectional and thus each interconnection is represented by two Link objects. Each Link stores information about the its local and remote Nodes and their network address. Host addresses are associated with links rather than Nodes to allow for multi-homed nodes. Internal Gateway as its remote endpoint and 200.10.10.0-200.10.10.255 as its address. Links do not always need to correspond to physical interconnections between Nodes they can represent virtual connections (like IPSec tunnels) as well. Rule represents a firewall rule. It defines the action to be taken when a matching packet is encountered. In our implementation, a rule is a 4-tuple of (Action, Inlink, Outlink, PacketSet). The Action is ACCEPT or DROP. Inlink/Outlink specify the incoming/outgoing interface respectively. PacketSet identifies the set of packets that match the rule. For example, to allow all HTTP traffic for the CSE Webserver to pass through the CSE Gateway, the Action is set to Accept, inlink is set to any (i.e. undefined), outlink is set to the name of the CSE Gateway CSE interface, and PacketSet is set to the most general TCP packet for port 80 as described earlier.

6. Distributed Firewall Configuration

This section describes the configuration tool in detail inputs, outputs, algorithms and properties of the generated configurations. 6.1. Inputs The configuration algorithm requires as input the network topology, organizational policy and trust assumptions. We elaborate on each of these here. Network Topology specifies the underlying network (Nodes and Links) including the location of firewalls. As mentioned earlier, the current FACE algorithms assume that all trusted nodes have the ability to apply firewall rules to input and forwarded traffic. Organizational Policy is specified by enumerating the PacketSets permitted at each Node. For example, the policy at the CSE Admin server in Figure 2, is that only packets for established and related connections should be permitted. This policy essentially means that the machine only allows connections set up by the machine itself it does not

accept any connections from outside. This policy is specified by enumerating two PacketSets both with Undefined protocol, the entire IPv4 source address range, and state Established and Related respectively. Trust Assumptions specify whether a node is trusted or not. A trusted node is assumed to not generate any spoofed traffic. 6.2. Algorithm Implementability Check. FACE implements an algorithm to identify whether a policy is implementable or not. The algorithm checks if there is a trusted path between every source-destination between which traffic is permitted by policy. If a trusted path does not exist between any such node pair, the policy is unimplementable. Otherwise, the policy is implementable. The algorithm follows the steps below: Step 1. Generate the list of all source-destination pairs between which traffic is permitted by policy. Since the policy enumerates traffic permitted at each node, this list is easily derived from the policy. Step 2. For each source node, find all nodes reachable from it via trusted paths. This is achieved by performing a depth first search on the network topology with the source node as the DFS root. Untrusted paths are pruned out by not expanding the tree from an untrusted node. Step 3. Check if there is any source-destination pair in the list from Step 1 for which the destination is not reachable from the source (from Step 2). If there is such a pair, the policy is unimplementable due to spoofing threats. Firewall Configuration. For every source-destination node pair, the firewall configuration algorithm generates firewall rules for all nodes along the trusted path between the source node and destination node. The configuration algorithm assumes a firewall to be present at each trusted node (corresponding to host or router in our implementation). The source nodes do not have to be trusted. The destination nodes are assumed to have the capability to have a firewall, but do not have to be trusted. The algorithm follows the steps below: Step 1. Compute the set of nodes reachable from the source node via trusted paths. Lets call this set Rs. Step 2. Compute the set of nodes that can reach the destination via trusted paths. Lets call this set Rd.

Step 3. Note that every node N in both Rs and Rd lies on some trusted path between the source node and the destination node. If N is an intermediate node and has a firewall, install filtering rules to allow the policy permitted traffic from the source to the destination in the FORWARD chain on N. If N is the destination node, install filtering rules in the INPUT chain. Since the organizational firewall policy specifies only what traffic to permit at each node, the firewall rule-sets installed by this algorithm will be such that they drop all traffic by default and specify only what traffic to permit. Also note that the installed rules will be sourcedestination specific. The source address field of the rule will exactly be the set of addresses assigned to the source node. Similarly the destination address field of the rule will exactly be the set of addresses assigned to the destination node. While rules are installed to allow traffic only along trusted paths, it is possible that the routing rules direct traffic along an untrusted path. In such a situation, given the generated firewall rules from FACE and the routing rules, it is possible to detect such a problem. 6.3. Handling Unimplementable Policies If an organizational firewall policy is unimplementable (because of lack of a trusted path between a pair of nodes between which traffic is to be permitted), it is desirable to assist administrators in revising the inputs so that the security policy can be implemented. We investigate how FACE assists in this. FACE can provide the following information to help with diagnosis and rectification of the problem: List all source-destination pairs between which no trusted path exists. This is a basic level of information to assist administrators in figuring out what is wrong and how to correct it. If there is no trusted path between a source and destination, FACE can provide candidates for the setup of IPSec connections that would make the policy implementable. This is done by determining the set of nodes reachable via trusted paths from the source (Rs) and the set of nodes that can reach the destination via trusted paths (Rd). A secure tunnel from a node in Rs to a node in Rd will ensure that a trusted path exists between the source and destination. FACE can also suggest changes to the trust assumptions by deeming more nodes trusted. 6.4. Configuration Properties

Correctness of generated rule-sets: Correctness requires that desired traffic (as defined by policy) be allowed, while undesired traffic be disallowed. Claim: Configurations generated for implementable policies are correct. Proof: We prove the above claim using two lemmas. Lemma 1: If the policy is implementable, then for every pair of source-destination nodes <S, D>, all traffic permitted by policy is also permitted along each trusted path between them. Proof: The configuration algorithm described above configures all firewalls that lie on a trusted path between any pair of source-destination nodes. The firewalls are configured to allow only policy permitted desired traffic from S to D. Therefore the lemma is true. Lemma 2: On every trusted path between two nodes S and D, all disallowed (including spoofed) traffic is dropped. Proof: Since we use a default drop firewall configuration, all traffic other than what is explicitly permitted is dropped. First, we note that on every trusted path there is at least one firewall the firewall at the path destination. Second, we note that since the path is trusted, no node on the path sends spoofed traffic to any other node. Thus, it suffices to filter traffic assuming that the source address in a packet is authentic. The above two observations imply that the firewall rules installed to filter traffic from S to D will not permit any disallowed traffic. Finally, we note that since all installed firewall rules are source-destination specific, a firewall rule for some other source-destination pair <S_, D_> (at least one of S_ and D_ differ from S and D respectively) will not permit any traffic flow from S to D. Thus the lemma is true. Lemmas 1 and 2 directly prove the claim. Bandwidth efficiency: Lemma 2 implies that all disallowed traffic will be dropped at the first firewall it encounters. Thus, our rule-sets are bandwidth efficient.

7. Distributed Firewall Analysis

The distributed firewall analyzer uses two basic queries to answer questions about the network. The two basic queries are: Given a set of packets and its node of origin, what packets are accepted at every other node?.We call this the source-reach query.

Given a destination node and a set of packets, what subset of the packets are accepted at the destination from every other node?.We call this the destinationreach query.

7.1. Algorithms In order to perform the basic queries, the analyzer simulates packet traversal in the network. We describe the algorithms for both the basic queries below. Source-reach Query: The source-reach query takes as input a Node object (the origin) and a Packet list (the set of packets injected into the network). It outputs the subset of packets that are accepted at every other node. The algorithm performs an event-based simulation of packet traversal through the network. An event is the arrival of a packet at a node. As state, the algorithm maintains the set of packets that have reached each node at any given instant. For controlling packet flow, a packet is propagated out of a node only the first time it reaches the node. The termination condition for the algorithm is that no events (packet arrivals) remain to be processed. At the end, INPUT filtering rules are applied to the set of packets reached at each node to determine the set of accepted packets. Destination-reach Query: The destination-reach query takes a Node object (the destination) and Packet list. It outputs the sets of packets from every node in the network that are accepted at the destination node. The algorithm is identical to source-reach query except that it traverses links in the backward direction. 7.2. Analyzer Capabilities In this section, we describe how the source-reach query and the destination-reach query can be used to answer queries listed in section 3.2. Equivalence of configurations: To check the equivalence of two firewall configurations, the source-reach query is iteratively made for all nodes. The packet list for the source reach query is set to be the most general PacketSet possible (i.e. a PacketSet with protocol set to Undefined, and the entire IPv4 address space as the source and destination). This is done for both firewall configurations. For each query, if the traffic reaching every node is the same for both configurations, they are equivalent, otherwise they are not. Check redundancy of a rule: In order to check if a rule is redundant, a copy of the network is created without the rule. If the new firewall configuration is equivalent to the earlier one, the rule

is redundant .We note that it is possible to create a minimal firewall configuration (one in which no rules are redundant) in this manner. Which hosts can a node N spoof: It is possible to answer this question by running the sourcereach query with the node of interest as the origin. The packet list for the source reach query is set to be the most general PacketSet possible. Nodes that permit traffic with a source address different from that of N are susceptible to packet spoofing by N. Note that our algorithm identifies precisely what the spoofed traffic of concern would be. Effect of disabling/compromise of a firewall F: In order to establish the effect of disabling a firewall F or its compromise, a copy of the input topology in which F does not filter any traffic is created. To figure out the additional traffic source node S can send, the source-reach query is run for origin S in both topologies. The packet list for the source-reach query is set to be the most general Packet-Set possible. The differences in accepted traffic at all destination nodes is the additional traffic allowed from S. To determine what additional traffic is accepted at a destination D, the destination-reach query is run for destination D in both topologies. By iteratively running these queries for each node in the network, the effect of disabling or compromising F is determined. Effect of a new node/link: A new network topology is created that includes the additional node/link. Source-reach or destination-reach algorithms with the most general PacketSet are run in both topologies to give the differences in permitted traffic.

8. Conclusion and Future Work

This paper presents FACE, a tool to configure and analyze distributed firewalls. Firewall configuration in FACE focuses on using firewalls to prevent packet spoofing. The firewall analyzer component of FACE efficiently answers a number of interesting questions about the network, including the feasibility of implementing the specified firewall policy under a specified threat model in which some nodes may spoof traffic. Current version of the FACE tool is publicly available from the FACE project webpage [4]. The model assumed by FACE is at present fairly restrictive. FACE only deals with filtering input traffic, not outbound traffic. The algorithms do not completely handle situations where destinations or trusted nodes do not have the ability to filter traffic. Thus, we consider FACE to be only the start of promising and important research into automatic generation of distributed firewall rules from a common

organization policy; substantial further work is required to generalize the results to handling arbitrary networks.

Acknowledgments
We are grateful to the NSF for financially supporting this work. We are thankful to Alok Manchanda (currently at Microsoft) for his contributions to the FACE project while at the University of Michigan.

References
i.

Yair Bartal, Alain J.Mayer, Kobbi Nissim, and AvishaiWool. Firmato: A Novel FirewallManagement Toolkit. In Proceedings of IEEE Symposium on Security and Privacy, 1999.

ii.
iii.

Steven M. Bellovin. Distributed Firewalls. ;login, November 1999. Pasi Eronen and Jukka Zitting. An expert system for analyzing firewall rules. In Proceedings of the 6th Nordic Workshop on Secure IT Systems (NordSec 2001), 2001. FACE ProjectWebpage. http://www.eecs.umich.edu/pverma/face/. Firewall Builder. http://www.fwbuilder.org. Scott Hazelhurst, Raymond Sinnappan, and Adi Attar. Algorithms for Improving the Dependability of Firewall and Filter Rule Lists, June 2000. John Howard. An Analysis of Security Incidents on the Internet. PhD thesis, Carnegie Mellon University, August 1998. Sotiris Ioannidis, Angelos D. Keromytis, Steven M. Bellovin, and JonathanM. Smith. Implementing a Distributed Firewall. In Proceedings of ACM Conference on Computer and Communication Security, November 2000.

iv.
v.

vi.
vii.

viii.

ix. x.
xi.

Netfi lter/Iptables Project. http://www.netfi lter.org. A Java based GUI for ipchain rule generation.http://freshmeat.net/projects/jfwadmin/. Alain Mayer, Avishai Wool, and Elisha Ziskind. Fang: A Firewall Analysis Engine. In IEEE Computer Society Symposium on Security and Privacy, May 2000. Nessus - A Free, powerful, up-to-date and easy to use remote security scanner. http://www.nessus.org. Nmap network mapper. http://www.insecure.org/nmap/.

xii.

xiii.

xiv.

Computer Emergency Response Team. CERT advisory ca-98.01 "smurf" IP denial-ofservice attacks, January 1998. Tiny Personal Firewall. http://www.tinysoftware.com. Zone Alarm Firewall. http://www.zonelabs.com.

xv.

xvi.