Distributed Firewalls

Robert Stepanek, [email protected]

Abstract

Distributed firewalls allow enforcement of security policies on a network with- out restricting its topology on an inside or outside point of view. Use of a policy language and centralized delegating its semantics to all members of the networks domain support application of firewall technology for organizations, which network devices communicate over insecure channels and still allow a logical separation of hosts in- and outside the trusted domain. We introduce the general concepts of such distributed firewalls, its requirements and implications and introduce its suitability to common threats on the Internet, as well as give a short discussion on contemporary implementations.

1 Introduction

This paper discusses the use of distributed firewall technology, its application fields and current implementations. Firewall technology in general is of vital interest for any orga- nization which deploys one or more machines connected to a network, which is regarded "as unsafe", meaning that the existence of malicious software or adversaries must be as- sumed and aims at preventing damage by deploying a certain security policy. Conventional firewall systems fulfill these requirements by the use of a collection of components which filter network traffic between two networks, usually regarded as a trusted network and an untrusted one. The notion of these systems relies on a certain topology of these networks, in a way that a specific, physical border between the trusted and untrusted domain can be singled out and security policies are enforced at the connecting components.

With the advent of the concept of distributed firewalls the topological constraints are weak- ened and a decentralized use of traffic filters as well as components facilitating security requirements as authentication and integrity is favored over one using few special nodes in the overall network. While the security policies are deployed in a decentralized way their management is not, allowing system administrators to set policies from a central host and therefore still fulfill the requirements of efficient system and network administration.

1.1 Organization of the following sections

In section 2 we will introduce the terminology which enables us to discuss the concept of distributed firewalls in a general way and aims to emphasize criteria for the evaluation

1 HUTTML2001 T-110.501SeminaronNetworkSecurity of certain implementations, however note that we will introduce the concept informally. Subsequently we will lay out the basic components which compromise a firewall of such kindandintroducedifferentmodelswhichmeetouroverallrequirementsinoneortheother way. Having introduced the concept generally we will present already available products which meet our requirements and introduce their peculiarities and additions to the overall concept in section 3. In section 4 we will discuss common threats encountered on computer networks and the suitability of distributed firewalls to provide protection. Finally we will give a brief summary over the paper in section 5.

2 The distributed approach

2.1 Basic definitions and terminology

Discussing distributed firewalls in the following sections we will lay our argumentation on the general requirements which compose the basic notions of firewall technology: On any communication traffic entering or leaving a network policy domain, firewall technology enforces the network domain security policy. Any instance of these mechanisms is called a firewall system, or shortly firewall [24]. Moreover we will assume that for any host inside the network policy domain we can single out one or more identifiers, which are unique to this network component. Note that with this layout we have not made any assumptions about the actual topology of the network, more explicit we will not require that any network component can be seen as a single entry and exit point of communication traffic between the network policy domain and any other untrusted network. Setting a policy on external accesses, that is any access on components inside the network policy domain will be called policy control throughout the rest of this paper, the mechanism for deciding if a given item of communication traffic is legal will be called the policy verifier.

2.2 Components of a distributed firewall

A distributed firewall is a mechanism to enforce a network domain security policy through the use of a policy language, a policy distribution scheme enabling policy control from a central point and certificates, enabling the identification of any member of the network policy domain [2]. Whereas conventional firewalls usually use the network components IP address as a unique identifier and enforcing policies on it is based on the decision if the component can be identified as being inside the trusted network or outside, we will use cryptographic certificates which detach the identifying mechanism from its reliance on any physical location of the component and minimize the danger of spoofed identities (however, as will be shown in section 2.3 use of cryptographic authentication schemes is not inherent in the general definition of a distributed firewall).

The policy language defines which inbound and outbound connections on any component of the network policy domain are allowed, and can affect policy decisions on any layer of the network, being it at rejecting or passing certain packets or enforcing policies at the ap- plication layer. The requirements of such a language are more specifically to allow explicit definition of security or authentication schemes, which have to be met before allowing the

2 HUTTML2001 T-110.501SeminaronNetworkSecurity communication traffic to pass the enforcing mechanisms. The policy language in itself should therefore support credentials and it is expected to be as generous as possible, al- lowing definitions for an arbitrary number of applications as well as it should not enforce implicit policies and trust relations [4]. Usually such a language is compiled to an internal format, although this is not a general requirement [3].

Using a policy distribution scheme the chosen security policy is delegated to members of the network in question, according to one or more of the following distribution schemes [12]:

Policies as well as credentials can be pushed to every single end point in the policy domain. This requires every member of the domain to be available to the delegating node, a criteria which most likely will not be met by mobile workstations and the like.

Policies and credentials can be pulled from a trusted repository during initialization of the policy verifier and periodically during operation. This circumvents the re- quirement of enduring availability of every member of the network domain but as in the previous solution end points may be confronted with a potentially large amount of credentials which need to be stored. Additionally the repository and the network may be subject to excessive resource consumption due to simultaneous initializing nodes.

Policies are pulled during initialization of the policy verifier whereas credentials for authentication mechanisms remain on a trusted repository and are requested when- ever communication traffic is reaching a node from a yet unknown host. Although this scheme allows a more balanced distribution procedure it must be stated that re- liance on the availability of the trusted repository leads to the threat of Denial of Service Attacks, a problem which will be discussed more in detail in section 4.

Using certificates enables the policy verifier making decisions without knowledge of the physical location of the node which communication requests are subject to the examina- tion. Public-key cryptography mechanisms are most often applied in contemporary imple- mentations and were deployed in the reference model in [12] through the use of IPSEC [13], [16]. In general the credentials associated with a connection requesting node have to provide unambiguous information about its identity which enables the policy verifier to give a simple yes or no answer, given the encoded security policy. Most likely an encoding of the nodes network address in any of the policies is not desirable given the distributed grade of the networks organization. Combining the policy distribution scheme and the use of credentials furthermore enables transmission of certificates over insecure channels, assuming that evidence of the repositories integrity is given [5].

2.3 Variations of distributed firewalls

In practice the criteria mentioned in section 2.2 is not always met by organizations de- ploying distributed firewalls, different layouts and variations most often combine concepts

3 HUTTML2001 T-110.501SeminaronNetworkSecurity of conventional with distributed firewall mechanisms and lead to hybrid firewalls [2]. Al- though the possible variations are large in number we will focus on the most common combinations which can be found in available products as well.

2.3.1 Host-addresses as a credential

Some hybrid firewalls do not make use of cryptographic credentials and the like as dis- cussed and hence still rely on topological properties of the underlying network through inspection of the connecting nodes network address. This layout does not address spoofing attacks but is useful in combination with a router, discarding traffic from local addresses entering the network from the untrusted outside. Although policies are now enforced on the end-points of the network and allow distributed policy control the overall requirements of a distributed firewall are not met by the models dependence on the networks structure. Still this solution is supported by one provider of firewall technology and applies well in small or medium sized organizations where constraints on the networks layout to do not show up as a problem [19].

2.3.2 Roadwarriors and conventional firewalls

Another combination of conventional and distributed firewalls deploys both security en- forcing mechanisms at the same time. The scenario includes one or more major sites, which are protected by conventional firewalls at the networks perimeter, additionally there are telecommuter machines, so called road warriors[10], in the untrusted outside. Commu- nication traffic between machines in the trusted network domain is unencrypted, whereas connections from inside to the road warriors (and vice-versa) are protected through the use of cryptographic facilities. What makes the difference between this layout and a classical virtual private network solution is the fact, that roadwarriors are subject to policy control even when they are communicating within the untrusted network, thus centrally defined and delegated firewall policies are deployed on the telecommuter machine not only in re- spect to their communication with the organizations network but in their network activity in general.

2.3.3 Triangle Routing and distributed firewalls

Although most of the communication traffic is handled in a distributed way by policy verifiers on the network domains end points, certain application still rely on a central application-level proxy unavailable locally on every node. In that case most of the traf- fic will be handled in a distributed manner, whereas policy enforcement for the specific applications will be done on the proxy and therefore applying a triangular way of routing for communication traffic involving these applications. Use of this concept in excess yields the same properties as conventional firewalls with encrypted communication traffic.

4 HUTTML2001 T-110.501SeminaronNetworkSecurity

2.3.4 Personal Firewalls

Increasing use of cable and DSL modems and other technologies which allow enduring connections to the internet by private customers and small companies has risen need for the deployment of firewall technology on single workstations[27]. Although this concept does lack the notion of protecting a network of hosts, that is the trusted network domain only has one or a few members policy enforcement is done in a way similar to the criteria discussed and can be seen as a special form of distributed firewalls. Additionally current implementations do not take encrypted communication with trusted hosts in respect but given a modular implementation such systems might be extended easily for networked environments and a harsher requirement on authentication mechanisms ([20], [18], [26]).

3 Related work and current implementations

Ongoing development and research in the field of firewall technology have shown a contin- ually addition of features and services to conventional firewall systems as well as applying the concepts of distributed firewalls from the bottom up in new products. Deployment of cryptographic mechanisms in gateway-to-gateway communication has become widely accepted in enterprise sized firewall technologies and lay the foundations of a desirable, authentication based enforcement of security policies when extended to the networks end- points. Standards like IPSEC [13], promise a wide acceptance in the developer community, although implementations of virtual private network technology and the like still show defi- ciencies in compatibility which might prevent the appliance of their mechanisms in heavily heterogenous networks. In addition to the general layout which has been discussed in section 2.2 the problem of dis- tributed logging of potentially attacking activity under a central examining mechanism has been addressed by some of the products discussed below and allows for proper response decisions using intrusion detection systems. Examples of implementations that illustrate the current availability of distributed firewalls can provide therefore deeper insight in prob- lems which arise in everyday use of such systems, and have been chosen by the author of this document without any affiliation to the commercial vendors or developers of such products:

1. Reference implementations:

In accordance with the concept of distributed firewalls introduced in [2], a reference implementation using IPSec, the KeyNote Policy language [6] and additions to the OpenBSD [21] has been worked out [12]. Using KeyNote and IPSec allows control of mixed-level policies (e.g. possibly malicious code transfers in emails, java applets, etc.) whereas authentication mechanisms may be applied through the use of public-key cryptographic certificates but can be based on conventional network address authentication in the absence of it. Fur- ther changes in the operating systems network code have lead to implemen- tation of a policy verifying mechanism which can be requested by inserting credentials and the packet or resource request in question into a special file /dev/policy. Based on the policy definitions available such a mechanism can return simple

5 HUTTML2001 T-110.501SeminaronNetworkSecurity

yes,no answers but also allows finer granularity for choosing the appropriate action, depending on the application needs, which is implemented in the refer- ence implementation as a policy daemon in the operating system’s user space.

2. Commercial products:

Employing host-based firewall systems in its CyberWall PLUS firewall prod- uct, Network-1 Security Solutions has shown up with a firewall solution which can be classified as a hybrid model of distributed firewalls as discussed in sec- tion 2.3.1. In addition to the overall requirement of distributed policy con- trol and enforcement on the network domain’s end-points the product allows stateful inspection of network connections and single packets, facilitating in the handling of malicious single packets which appear to be part of a already agreed legitimate connection. Supported network protocols include TCP, UDP, SNMP, IPX, AppleTalk and others and show a variety of supported applica- tion level inspection mechanisms, as well as handling port-scans and allowing a central gathering of audit logs for later examination or statistics collection. The products validation mechanisms are operating in kernel mode and reside between the protocol binding mechanisms and the network device drivers [19].

As addition to its product line of virtual private network and policy distribution scheme implementations F-Secure provides a distributed firewall which meets, in combination with other tools available trough the vendor the requirements laid out before. Similar to CyberWall PLUS in addition to the mixed-level policy enforcement, multiple protocols are supported, as well as the processing of audit logs either locally or on a central host. Active responses to possible attacks however do not seem to be subject of their implementation, support of cryptographic file systems contents on the telecommuters harddrives as well as integration of malicious code detection systems allows fine granularity on content-based decisions [11].

Sygate Technologies, Inc. provides a distributed firewall through the combi- nation of three interacting modules, combined under the bundle Sygate Secure Enterprise. The policy language allows definition of rules including param- eters, such as user, device, application, protocol, time, and others, whereas organization of policy groups according to the corresponding end points in the network domain can be imported from NT Domains, LDAP or be defined from scratch. No information about the policy distribution scheme is given, but a pulling mechanism seems plausible. In combination with the policy enforce- ment entity, Sygate Security Agent, and an optional use of cryptography at the network layer, Sygate VPN Enforcer, the product meets the requirements of section 2.2, in addition centralized audit log management and intrusion de- tection capabilities are supported. Moreover policies can be controlled from several hosts, allowing a more distributed scheme of policy management in large networks [25].

6 HUTTML2001 T-110.501SeminaronNetworkSecurity

4 Protection from common threats

4.1 The reference model for further analysis

Distributed firewalls both have their advantages and disadvantages over conventional fire- wall systems. To learn more about their deficiencies it is useful to inspect possible reac- tions to actual attacks from adversaries originating outside and inside the network policy domain. We will discuss a variety of common threats which network devices are exposed to probably quite heavily when there is no protection mechanism between them and an untrusted network. Furthermore, our observation is based on a special case of a distributed firewall, that is, although we make no restrictions on the networks topology in the general case, we can analyze our results more thoroughly when compared to conventional fire- walls and discuss the case where each of these two firewall systems could be applied, that is, when the network topology allows for physical separation of the trusted and untrusted network domain.

4.2 Denial of Service Attacks

There is a variety of DOS attacks, and not all can be handled by either concept of firewall systems [14]. Although there can be made no restrictive assumptions about the overall network topology it is most likely that a set of hosts inside the network policy domain will be located physically near to each other and thus use the same connection to the untrusted network. Neither a conventional firewall, nor a distributed one can prevent DOS attacks on the networks perimeter efficiently, although we could emphasize the intentional spread of mission critical hosts on physically separated networks to make such an attack more difficult to an adversary [7]. On the other side, distributed firewalls can behave quite well on DOS attacks which depend on IP spoofing mechanisms, given the assumption that the authorization mechanisms do not rely on IP addresses as credentials [8]. On contrary, with the use trusted repository for either credentials, policies or both, it should be clear that the network devices employing these mechanisms will be subject to extensive attacks, given the overall dependence of end points on its availability.

4.3 IP spoofing

As discussed in section 2.2, reliance on network addresses is not a favored concept. Using cryptographic mechanisms most likely prevents attacks based on forged source addresses, under the assumption that the trusted repository containing all necessary credentials has not been subject to compromise in itself [9]. These problems can be solved by conventional firewalls with corresponding rules for discarding packets at the network perimeter but will not prevent such attacks originating from inside the network policy domain.

4.4 Malicious software

With the spread use of distributed object-oriented systems like CORBA, client-side use of Java and weaknesses in mail readers and the like there is a wide variety of threats residing

7 HUTTML2001 T-110.501SeminaronNetworkSecurity in the application and intermediate level of communication traffic. Firewall mechanisms at the perimeter can come useful by inspecting incoming emails for known malicious code fingerprints, but can be confronted with complex, thus resource-consuming situations when making decisions on other code, like Java [15]. Using the framework of a distributed firewall and especially considering a policy language which allows for policy decision on the application level can circumvent some of these problems, under the condition that contents of such communication packets can be inter- preted semantically by the policy verifying mechanisms. Stateful inspection of packets shows up to be easily adapted to these requirements and allows for finer granularity in decision making [22]. Furthermore malicious code contents may be completely disguised to the screening unit at the network perimeter, given the use of virtual private networks and enciphered communication traffic in general and can completely disable such policy enforcement on conventional firewalls.

4.5 Malicious hosts "inside"

Given the natural view of a conventional firewall on the networks topology as consisting of an inside and outside, problems can arise, once one or more members of the policy network domain have been compromised. Perimeter firewalls can only enforce policies between distinct networks and show no option to circumvent problems which arise in the situation discussed above. Given a distributed firewalls independence on topological con- straints supports the enforcement of policies whether hosts are members or outsiders of the overall policy domain and base their decisions on authenticating mechanisms which are not inherent characteristics of the networks layout. Moreover, compromise of an end- point either by an legitimate user or intruder will not weaken the overall network in a way that leads directly to compromise of other machines, given the fact that the deployment of virtual private networks prevents sniffing of communication traffic in which the attacked machine is not involved. On the other side, on the end-point itself nearly the same problems arise as in conventional firewalls: Assuming that a machine has been taken over by an adversary must lead to the conclusion that the policy enforcement mechanisms them self may be broken. The instal- lation of backdoors on this machine can be done quite easily once the security mechanisms are flawed and in the lack of a perimeter firewall, there is no trusted entity anymore which might prevent arbitrary traffic entering or leaving the compromised host. Additionally use of tools like SSH and the like allow tunneling of other applications communication and can not be prevented without proper knowledge of the decrypting credentials, moreover given the fact that in case an attack has shown up successfully the verifying mechanisms in them self may not be trusted anymore.

5 Conclusions

Distributed firewall can solve some known and thoroughly discussed problems which arise with the use of conventional firewalls residing at the networks perimeter. It’s independence on topological constraints reflect the change in enterprise and other organizations network organization more accurately but demand fundamental changes in the network end-points operating systems. Given that fact the author of this paper sees most of the problems arising

8 HUTTML2001 T-110.501SeminaronNetworkSecurity with the employment of distributed firewall mechanisms in the fact, that standardization of integral properties of such systems, such as a policy language, cryptographic encryption of the communication traffic and verifying entities still lacks necessary research and leads to unsuitability for heavily heterogenous networks. The concept of distributed firewalls is rather new and few reference implementations are available ([1],[12]). Current implementations of such systems are rare at this point in time and show up the fact, that the overall concept of distributed firewalls in subject to quite different interpretation, moreover does not include requirements as central administration of audit logs and other properties which have been presented in section 3. Reflecting the outcomes of section 4, a combined version of conventional as well as distributed firewalls seems to fulfill most requirements of system administrators and network security engineers and most likely reflect the layout of networks found currently in practice, consisting of con- glomerates of end-points at the same physical locations, connected via untrusted channels and accessed by telecommuters and mobile workstations.

References

[1] Y. Bartal & A. Mayer & K. Nissim & A. Wool. Firmato: A Novel Firewall Manage- ment Toolkit. In Proceedings of the IEEE Computer Society Symposium on Security and Privacy, 1999.

[2] S.M.Bellovin. Distributed Firewalls.;login: magazine, special issue on security, November 1999.

[3] M.Blaze & J.Feigenbaum & J.Lacy. Decentralized Trust Management. In Proc. of the 17th Symposium on Security and Privacy, pages 164-173. IEEE Computer Society Press, Los Alamitos, 1996.

[4] M. Blaze & J. Feigenbaum & J. Ioannidis & A.D. Keromytis. The Role of Trust Man- agement in Distributed Systems Security. Secure Internet Programming: Issues in Dis- tributed and Mobile Object Systems. Lecture Notes on Computer Science, Springer- Verlag, Berlin Heidelberg New York, 1999.

[5] M. Blaze & J. Ioannidis & A. D. Keromytis. Trust Management for IPsec. In Proceed- ings of the Internet Society Symposium on Network and Distributed Systems Security (SNDSS) 2001, pages 139-151, San Diego, CA, February 2001.

[6] M. Blaze & J. Feigenbaum & J. Ioannidis. The KeyNote Trust-Management System Version 2. Request for Comments (Proposed Standard) 2704, Internet Engineering Task Force, September 1999 [referred 5.10.2001] (http://www.ietf.org/rfc/rfc2704.txt).

[7] CERT ¡ c Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks. [referred 15.10.2001] (http://www.cert.org/advisories/CA-1998-01.html)

[8] P. Ferguson & D. Senie. Network Ingress Filtering: Defeating Denial of Service At- tacks which employ IP Source Address Spoofing. Request for Comments (Best Cur- rent Practice) 2827, Internet Engineering Task Force, May 2000 [referred 5.10.2001] (http://www.ietf.org/rfc/rfc2827.txt)

9 HUTTML2001 T-110.501SeminaronNetworkSecurity

[9] N. Ferguson & B. Schneier. A Cryptographic Evaluation of IPsec. Counterpane Labs, Counterpane Internet Security, [referred 15.10.2001] (http://www.counterpane.com/publish-2000.html)

[10] FreeS/WAN Project [referred 16.10.2001] (http://www.freeswan.org/)

[11] F-Secure Distributed Firewall, F-Secure Corporation. [referred 16.10.2001] (http://www.fsecure.com/products/)

[12] S. Ioannidis & A.D. Keromytis & S.M. Bellovin & J.M. Smith. Implementing a Dis- tributed Firewall. In Proceedings of Computer and Communications Security (CCS) 2000, November, 2000.

[13] S. Kent & R. Atkinson. Security Architecture for the Internet Protocol. Request for Comments (Proposed Standard) 2401, Internet Engineering Task Force, November 1998 [referred 29.9.2001] (http://www.ietf.org/rfc/rfc2401.txt).

[14] F. Lau & S. H. Rubin & M. H. Smith & Lj. Trajkovic. Distributed denial of service attacks. In Proceedings of the 2000 IEEE International Conference on Systems, Man, and Cybernetics, pages 2275-2280, Nashville, TN, October 2000.

[15] D.M. Martin Jr. & S. Rajagopalan & A.D. Rubin. Blocking Java Applets at the Fire- wall. In Proceedings of the Symposium on Network and Distributed System Security, pages 203-221, Baltimore, MD, Summer 1989.

[16] D. Maughan & M. Schertler & M. Schneider & J. Turner. Internet Security As- sociation and Key Management Protocol (ISAKMP). Request for Comments (Pro- posed Standard) 2408, Internet Engineering Task Force, November 1998 [referred 29.9.2001] (http://www.ietf.org/rfc/rfc2408.txt).

[17] PGPFire ASP, Networks Associates Technology, Inc. [referred 15.10.2001] (http://www.pgp.com/products/pgpfire-asap/default.asp)

[18] McAfee Firewall, McAfee Consumer Products, Network Associates, Inc. [referred 5.11.2001] (http://www.mcafee-at-home.com/products/firewall/)

[19] Network-1, Security Solutions, Inc. Host-Resident Firewalls: Defending Win- dows NT/2000 Servers and Desktops from Network Attacks. [referred 15.10.2001] (http://www.network-1.com/products/defend_windows.pdf)

[20] BlackICE Defender, Network ICE Corporation. [referred 5.11.2001] (http://www.networkice.com/products/soho_solutions.html)

[21] The OpenBSD Project. [referred 15.10.2001] (http://www.openbsd.org/)

[22] U. Roedig & R. Ackermann & C. Rensing & R. Steinmetz. A Distributed Firewall for Multimedia Applications. In Proceedings of the Workshop "Sicherheit in Netzen und Medienströmen, pages 3-16, 2000.

[23] C.L. Schuba & I.V. Krsul & M.G. Kuhn & E.H. Spafford & A. Sundaram & D. Zamboni. Analysis of a Denial of Service Attack on TCP. In Proceedings of the 1997 IEEE Symposium on Security and Privacy, pages 208-223, May 1997.

10 HUTTML2001 T-110.501SeminaronNetworkSecurity

[24] C.L. Schuba & E.H. Spafford. A Reference Model for Firewall Technology. In Pro- ceedings of the 13th Annual Computer Security Applications Conference (ACSAC), IEEE Computer Society, pages 133-145. San Diego, California, December 1997.

[25] Sygate Technologies, Inc. Sygate Secure Enterprise. [referred 16.10.2001] (http://www.sygate.com/products/sse/enterprise_security.htm)

[26] Norton Personal Firewall, Symantec Corporation. [referred 5.11.2001] (http://www.symantec.com/sabu/nis/npf/)

[27] Tina Zych. Personal Firewalls: What are they, how do they work ?. Sans Institue, [referred 5.11.2001] (http://www.sans.org/infosecFAQ/homeoffice/personal_fw.htm)

11