DATA SECURITY IN LOCAL NETWORK USING DISTRIBUTED FIREWALL

A SEMINAR REPORT

Submitted by ANAND KUMAR

in partial fulfillment of requirement of the Degree of

Bachelor of Technology (B.Tech) IN
COMPUTER SCIENCE AND ENGINEERING

SCHOOL OF ENGINEERING

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY KOCHI- 682022

AUGUST 2008

DIVISION OF COMPUTER SCIENCE AND ENGINEERING SCHOOL OF ENGINEERING COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY

KOCHI-682022

Certificate
Certified that this is a bonafide record of the seminar entitled

“DATA SECURITY IN LOCAL NETWORK USING DISTRIBUTED FIREWALL” presented by the following student ANAND KUMAR
of the VII semester, Computer Science and Engineering in the year 2008 in partial fulfillment of the requirements in the award of Degree of Bachelor of Technology in Computer Science and Engineering of Cochin University of Science and Technology.

Ms. Latha R. Nair. Seminar Guide

Dr. David Peter S. Head of Division

Date :

Acknowledgement

Many people have contributed to the success of this. Although a single sentence hardly suffices, I would like to thank Almighty God for blessing us with His grace. I extend my sincere and heart felt thanks to Dr. David Peter, Head of Department, Computer Science and Engineering, for providing us the right ambience for carrying out this work. I am profoundly indebted to my seminar guide, Ms. Latha R. Nair for innumerable acts of timely advice, encouragement and I sincerely express my gratitude to her.

I express my immense pleasure and thankfulness to all the teachers and staff of the Department of Computer Science and Engineering, CUSAT for their cooperation and support.

Last but not the least, I thank all others, and especially my classmates who in one way or another helped me in the successful completion of this work.

ANAND KUMAR

ABSTRACT
Today, computer and networking are inseparable. A number of confidential transactions occur every second and today computers are used mostly for transmission rather than processing of data. So Network Security is needed to prevent hacking of data and to provide authenticated data transfer. Network Security can be achieved by Firewall. Conventional firewalls rely on the notions of restricted topology and controlled entry points to function. Restricting the network topology, difficulty in filtering of certain protocols, End-to-End encryption problems and few more problems lead to the evolution of Distributed Firewalls.

Distributed firewalls secure the network by protecting critical network endpoints, exactly where hackers want to penetrate. It filters traffic from both the Internet and the internal network because the most destructive and costly hacking attacks still originate from within the organization. They provide virtually unlimited scalability. In addition, they overcome the single point-of-failure problem presented by the perimeter firewall.

Some problems with the conventional firewalls that lead to Distributed Firewalls are as follows.      Depends on the topology of the network. Do not protect networks from the internal attacks. Unable to handle protocols like FTP and RealAudio. Have single entry point and the failure of this leads to problems. Unable to stop spoofed transmissions (i.e., using false source addresses).

Distribute firewall solves these problems and protecting critical network end points where hackers want to penetrate. It filters the traffic from both the internal network and internet because most destructive and costly hacking attacks still originate within organization.

3 Policy Daemon 5. Title LIST OF FIGURES Page ii 1 Introduction Policy and Identifiers Distributed Firewall 3.TABLE OF CONTENTS Chapter No.1 Standard Firewall Example 3.1 Kernel Extensions 5. 2 Policy Device 5.4 Example Scenario 15 5 20 21 24 25 27 6 Work in Development Related Work Conclusion References 28 7 30 8 32 9 35 i .2 Distributed Firewall Example 1 2 5 3 6 10 13 4 KeyNote Implementation 5.

LIST OF FIGURES NO: 1 2 3 4 5 6 7 8 9 10 NAME Architecture of Distributed Firewall Architecture of standard firewall PAGE 7 10 11 12 13 14 15 16 21 22 Connection to the Web Server in standard firewall Connection to the Intranet in standard firewall Distributed Firewall Connection to the Web Server distributed firewall Connection to the Intranet in distributed firewall Interactions with KeyNote Graphical representation with all components Filtering connect( ) and accept( ) system calls ii .

it is desirable that telecommuters’ systems comply with the corporate security policy. While this model worked well for small to medium size networks. telecommuting. and that anyone on the other side is. such solutions are viewed as architecturally “unclean” and in some cases too invasive. and new protocols are designed. an enemy. because the latter lacks certain knowledge that is readily available at the endpoints. Department of Computer Science. on the other hand. several trends in networking threaten to make it obsolete:  Due to the increasing line speeds and the more computation intensive protocols that a firewall must support (especially IPsec). while computers (and hence firewalls) are getting faster. The vastly expanded Internet connectivity in recent years has called that assumption into question.SOE. Although there exist application-level proxies that handle such protocols.  There exist protocols. at least potentially. for example.Data Security in Local network Using Distributed Firewall 1. they rely on the assumption that everyone on one side of the entry point--the firewall--is to be trusted. etc. firewalls tend to become congestion points. the traditional notion of a security perimeter can no longer hold unmodified. This gap between processing and networking speeds is likely to increase. FTP and RealAudio are two such protocols. the combination of more complex protocols and the tremendous increase in the amount of data that must be passed through the firewall has been and likely will continue to outpace Moore’s Law. So-called "extranets" can allow outsiders to reach the "inside" of the firewall.).  The assumption that all insiders are trusted has not been valid for a long time. Introduction Conventional firewalls rely on the notions of restricted topology and control entry points to function. Consequently.CUSAT 1 . at least for the foreseeable future. that are difficult to process at the firewall. More precisely. Specific individuals or remote networks may be allowed access to all or parts of the protected infrastructure (extranets. telecommuters' machines that use the Internet for connectivity need protection when encrypted tunnels are not in place.

recently standardized by the IETF that provides network-layer security services such as packet confidentiality. as a result. failover. and dial-up access methods allow individuals to establish backdoor access that bypasses all the security mechanisms provided by traditional firewalls. it has become trivial for anyone to establish a new. data integrity. there is a tension between internal needs for more connectivity and the difficulty of satisfying such needs with a centralized firewall. Furthermore. both from a practical point of view and with regard to policy consistency. many sites employ internal firewalls to provide some form of compartmentalization. and automated key management. as it prevents them from looking at the packet fields necessary to do filtering. wireless. This is an artifact of firewall deployment: internal traffic that is not seen by the firewall cannot be filtered. authentication. since no unified and comprehensive management mechanism exists.  Large (and even not-so-large) networks today tend to have a large number of entry points (for performance.  End-to-end encryption can also be a threat to firewalls. IPsec is a protocol suite. While firewalls are in general not intended to guard against misbehavior by insiders. Allowing end-to-end encryption through a firewall implies considerable trust to the users on behalf of the administrators. This makes administration particularly difficult. If firewalls were placed everywhere. there is an increasing need for finer-grained (and even application specific) access control which standard firewalls cannot readily accommodate without greatly increasing their complexity and processing requirements. 2 . internal users can mount attacks on other users and networks without the firewall being able to intervene. Various forms of tunnels. replay protection. Worse yet. this would not be necessary.  Finally. and other reasons). unauthorized entry point to the network without the administrator’s knowledge and consent.

they permit a site's administrator to set a policy on external access. They offer the advantage of filtering traffic from both the Internet and the internal network. This enables them to prevent hacking attacks that originate from both the Internet and the internal network. More subtly. a firewall can enforce an external security policy. routers. to secure. Furthermore. The key reason that firewalls are still useful is that they provide an obvious. proposed the concept of a distributed firewall. older protocols (and their implementations) are more difficult. since the firewall generally does not have the necessary keys to peek through the encryption. often impossible. While newer protocols typically have some provisions for security. Just as file permissions enforce an internal security policy. The extent of mutual trust between endpoints is specified by the policy Distributed firewalls are host-resident security software applications that protect the enterprise network's servers and end-user machines against unwanted intrusion. some machines need more access to the outside than do others. firewalls are a mechanism for policy control. 3 . etc. but only with difficulty.Other trends are also threatening firewalls. For example. That is. Policy distribution may take various forms. security policy is defined centrally but enforced at each individual network endpoint (hosts. For example. firewalls provide a convenient first-level barrier that allows quick responses to newly-discovered bugs. In distributed firewalls. firewalls are still useful in providing some measure of security. especially as internal IP addresses change. End-to-end encryption is another threat. This is important because the most costly and destructive attacks still originate from within the organization. or it may be provided to the users in the form of credentials that they use when trying to communicate with the hosts or it may be a combination of both. For legacy applications and networks. it may be pushed directly to the end systems that have to enforce it. Conventional firewalls can do this.). they are the only mechanism for security. mechanism for enforcing network security policy. To address the shortcomings of firewalls while retaining their advantages. Despite their shortcomings. mostly hassle-free. The system propagates the central policy to all endpoints.

according to both the policy and the cryptographically-verified identity of each sender. A compiler translates the policy language into some internal format. it is desirable to use an extensible system (so other types of applications and security checks can be specified and enforced in the future).. or some other protocol. The language and resolution mechanism should also support credentials. This may be the IPsec key management protocol when possible. either through the communication protocol or as part of the policy object description ( e. policies in a distributed firewall are functionally equivalent to packet filtering rules.Distributed firewalls rest on three notions: (a) a policy language that states what sort of connections are permitted or prohibited. such as Microsoft's SMS or ASD and (c) IPSEC. To implement a distributed firewall. three components are necessary:  A language for expressing policies and resolving requests. (b) any of a number of system management tools. The integrity of the policies transferred must be guaranteed. And incoming packets are accepted or rejected by each "inside" host.  A mechanism for safely distributing security policies. which provides a single. However. extensible language for expressing policies and credentials. providing the enforcement part.g.  A mechanism that applies the security policy to incoming packets or connections. This is by no means a universal trait. they may be digitally signed). and even today there are protocols designed with no security review. The system management software distributes this policy file to all hosts that are protected by the firewall. In their simplest form. Credentials 4 . for delegation of rights and authentication purposes. the network-level encryption mechanism for TCP/IP. The basic idea is simple. Our prototype implementation uses the KeyNote trust-management system.

setting up a proxy or login server on some other port. including file-oriented schemes similar to Firmato. the overall security policy relevant to a particular user and a particular end host is the composition of the security policy “pushed” to the end host. the mechanism is split in two parts. any credentials given to the user.. etc. policies may be distributed from a central location when a policy update is performed. or through some other protocol). protect traffic. for the different departments or even individual systems). Finally. giving away their password. 5 . thus simple file-transfer protocols may be used for policy distribution. Since KeyNote allows delegation. the GUIs that are found on most modern commercial firewalls. In our implementation. Thus. and any credentials stored in a central location and retrieved ondemand.500 directory. it is better to allow for some flexibility in the system. Although this may initially seem counterintuitive (after all. The distribution of credentials and user authentication occurs are part of the Internet Key Exchange (IKE) [12] negotiation. we implement the mechanism that enforces the security policy in a TCP-connection granularity. X. firewalls embody the concept of centralized control). We also make use of the IPsec stack in the OpenBSD system to authenticate users. though clearly the language must be powerful enough to express the desired policy. and general policy languages such as KeyNote. A sample is shown in Figure.in KeyNote are signed. usually by the most insecure and destructive way possible ( e.). Policies and Identifiers Many possible policy languages can be used. The exact nature is not crucial. Also note that it is possible to “turn off” delegation. Thus. 2. in our experience users can almost always bypass a firewall’s filtering mechanisms. decentralized administration becomes feasible (establishing a hierarchy or web of administration. or they may be fetched as-needed (from a webserver. Alternatively. Users are also able to delegate authority to access machines or services they themselves have access to. as long as the users follow the overall policy. one residing in the kernel and the other in a user-level process.g. and distribute credentials.

individuals are not necessarily the administrators of the computers they use. a license server or a security clearance server can be asked if a certain communication should be permitted. to simplify system administration and to permit some level of central control. but it lacks important knowledge about the context of the request. new software distributed. We abandon this notion (but see Section). ownership of a certificate is not easily spoofed. Today's firewalls rely on topology. to control a distributed firewall. In a different sense. Our preferred identifier is the name in the cryptographic certificate used with IPSEC. Instead. A second common host designator is IP address. though with a reduced level of security. policies can be "pulled" dynamically by the end system. etc. Distributed firewalls can use IP addresses for host identification. thus. Distributed Firewalls In a typical organizational environment. 3. and what their security levels might be. which are likely present in any event. "DMZ". a system management package is used to administer individual machines. etc. We use the same mechanisms. End systems may know things like which files are involved. etc. Certificates can be a very reliable unique identifier. those privileges can apply regardless of where the machine is located physically. Patches can be installed. A conventional firewall could do the same. furthermore. "outside". able to receive incoming mail from the Internet. If a machine is granted certain privileges based on its certificate. but only by adding complexity. since distributed firewalls are independent of topology. network interfaces are designated "inside". Such information could be carried over a network protocol. They are independent of topology. 6 . For example. That is. a specified IP address may be fully trusted.What is important is how the inside hosts are identified.

they can launch attacks on hosts that they would not 7 . In the latter case. If so. Policy enforcement is especially useful if the peer host is identified by a certificate. but policies and enforcement can equally Fig. compiled to some convenient internal format) is then shipped out. The security administrator--who is no longer necessarily the "local" administrator. all hosts on the inside are in some sense equal. This policy file is consulted before processing incoming or outgoing messages. to verify their compliance. since we are no longer constrained by topology--defines the security policy in terms of host identifiers. If any such machines are subverted. much like any other change. though not necessarily. the local host has a much stronger assurance of its identity than in a traditional firewall. some sites might wish to force local Web browsers to disable Java or JavaScript.Policy is enforced by each individual host that participates in a distributed Security firewall.1: Architecture of Distributed Firewall well apply to the application layer. The resulting policy (probably. It is most natural to think of this happening at the network or transport layers. For example.

The most obvious is that there is no longer a single chokepoint. however. such spoofing is not possible. each host's identity is cryptographically assured. as identified by its certificate. an incoming TCP packet is sometimes presumed legitimate if it has the "ACK" bit set. possibly by impersonating trusted hosts for protocols such as rlogin. though. This is most easily understood by contrasting it to traditional packet filters. Thus. access to other internal hosts would be blocked. access to port 25 is unrestricted. A second advantage is more subtle. they have to rely on externally-visible features of assorted protocols. that redundancy is purchased only at the expense of an elaborate (and possibly insecure) firewall-to-firewall protocol. in many cases. similarly. Instead. Consider the problem of electronic mail. They in turn will relay the mail to internal mail servers. Because of a long-standing history of security problems in mailers. The mail gateway permits anyone to connect to that port. since such a packet can only be legitimate if it is part of an ongoing conversation--a conversation whose initiation was presumably allowed by the firewall. Distributed firewalls have other advantages as well. though. On the inside of the firewall. other internal machines. Some sites attempt to solve these problems by using multiple firewalls. permit contact only from the mail gateway. Throughput is no longer limited by the speed of the firewall. though. this is a major benefit. But spoofed ACK packets can be used as part of "stealth scanning".normally talk to. it 8 . Traditional firewalls would express this by a rule that permitted SMTP (port 25) connections to the internal mail gateways. Today's firewalls don't have certain knowledge of what a host intends. Note how much stronger this protection is: even a subverted internal host cannot exploit possible mailer bugs on the protected machines. there is no longer a single point of failure that can isolate an entire network. all machines have some rule concerning port 25. most sites with firewalls let only a few. designated hosts receive mail from the outside. Similarly. With a distributed firewall. From both a performance and an availability standpoint. With a distributed firewall.

With a distributed firewall. And no triangle routing is needed. By default. an operation that is generally not permitted through a firewall. and can reject random probes. regardless of whether or not a tunnel is set up. Corporate packets. This advantage is even clearer when it comes to protocols such as FTP. however. 9 . and hence legal. FTP clients use the PORT command to specify the port number used for the data channel. such use is often in violation of corporate guidelines. or if they are incoming attacks. Today's firewalls--even the stateful packet filters--generally use an application-level gateway to handle such commands. is that distributed firewalls can protect hosts that are not within a topological boundary. knows. though.is hard for firewalls to treat UDP packets properly. But that requires that generic Internet use be tunneled into the corporate network and then back out the Internet. The most important advantage. are granted more privileges. Furthermore. there is no protection whatsoever when the tunnel is not set up. the host itself knows when it is listening for a particular data connection. authenticated by IPSEC. How should this machine be protected? A conventional approach can protect the machine while tunneled. The sending host. because they cannot tell if they are replies to outbound queries. this port is for an incoming call that should be permitted. Consider a telecommuter who uses the Internet both generically and to tunnel in to a corporate net. By contrast. a distributed firewall protects the machine all of the time. Apart from efficiency considerations. Relying on the host to make the appropriate decision is therefore more secure. packets from random Internet hosts can be rejected.

1 STANDARD FIREWALL EXAMPLE 10 .3.

firewall. web server. intranet web server. there is two hosts. web server and intranet web server are also connected to the network. In internal part of network. one is trusted (Internal host 1) and other one is untrusted (Internal host 2). Both hosts are connected to the corporate network. Example contains internal and external host. Then network connected to the internet and between network and internet. there is firewall. network. 11 . internet.Fig 2: Architecture of standard firewall This is the example of architecture of standard firewall. There is also a external host which is connected to the internet.

It is not important that they are trusted or not.Fig 3: Connection to the Web Server In this figure. 12 . firewall allowed to connect with the web server. For external host. we can see that when internal hosts want to connected with web server. So external host will connect to web server. they can connect.

intranet web server is blocked by this firewall. But for external host. Internal hosts are allowing to connect with the intranet web server.Fig 4: Connection to the Intranet In this figure. It is not also important that they are trusted or not. Here we can see that the disadvantage this conventional firewall. External hosts are not allowed to connect with the intranet web server. we can see that internal hosts are connected to the intranet web server (company private). 13 . Here there is no blocking rule for internal hosts. but here one host is untrusted. Here.

intranet web server. Example contains internal and external host. Here firewall policy is distributed to all the systems and web server. Both hosts are connected to the corporate network. Then network connected to the internet and 14 . In internal part of network. internet. network. and a internal host on other side of network which is communicating through telnet. one is trusted (Internal host 1) and other one is untrusted (Internal host 2).3. web server.2 DISTRIBUTED FIREWALL EXAMPLE Fig 5: Distributed Firewall This figure is the example of architecture of Distributed firewall. there are two hosts. web server and intranet web server are also connected to the network. then only they connect. If firewall policy allowed connecting with server or systems.

Fig 6: Connection to Web Server In this figure. There is also an external host and internal host using telecommuting which is connected to the internet. Because they are allowed to connect with the server.between network and internet. Although internal host of external side of network and external host can connect to the web server. we can see that when internal hosts want to connected with web server. they can connect. 15 . there is firewall.

Fig 7: Connection to Intranet In this figure. Because only these two are trusted. other are untrusted. Here it gives the advantage of protecting the systems from internal untrusted hosts. we can see that only internal host 1 and internal host of external side is connected to the intranet web server (company private). So here it is not necessary that internal host will connect to private server. KEYNOTE 16 . If firewall policy allowed only then they can connect. 4.

which serve the role of “certificates. the local policy. trust management dispenses with unique names as an indirect means for performing access control. it uses a direct binding between a public key and a set of authorizations. Policies and credentials contain predicates that describe the trusted actions permitted by the holders of specific public keys (otherwise known as principals). Signed credentials. The Requester is typically a user that authenticates through some application-dependent protocol.” have the same syntax as policy assertions. as shown in Figure 8. different 17 . as represented by a safe programming language. It is also responsible for acting upon KeyNote’s response. It is responsible for providing to KeyNote all the necessary information. Instead. One instance of a trust-management system is KeyNote. Making use of public key cryptography for authentication. KeyNote provides a simple notation for specifying both local security policies and credentials that can be sent over an untrusted network. This results in an inherently decentralized authorization system with sufficient impressibility to guarantee flexibility in the face of novel authorization scenarios Figure 8: Application Interactions with KeyNote. and optionally provides credentials. However.Trust Management is a relatively new approach to solving the authorization and security policy problem. Applications communicate with a “KeyNote evaluator” that interprets KeyNote assertions and returns results to applications. The Verifier needs to determine whether the Requester is allowed to perform the requested action. but are also signed by the entity delegating the trust. and any credentials.

Also. The KeyNote evaluator can return values other than simply true and false. UNIX daemon. called an “action environment. if there is any subset that would cause the request to be approvedthen the complete set will also cause the request to be approved. more generally. etc. or to port 22 (ssh) 18 . For example. In the example of a single host. and a set of attributes. It is worth noting here that although KeyNote uses cryptographic keys as principal identifiers. depending on the application and the action environment definition.hosts and environments may provide a variety of interfaces to the KeyNote evaluator (library. usernames may be used to identify principals inside a host. other types of identifiers may also be used. similar to the mechanisms used for transferring credentials in Unix or in capability-based systems.). This greatly simplifies both request resolution (even in the presence of conflicts) and credential management. in trust management) is “monotonicity”. An important concept in KeyNote (and. the identifier of the principal requesting an action must be securely established.” that describes a proposed trusted action associated with a set of public keys (the requesting principals). The KeyNote evaluator determines whether proposed actions are consistent with local policy by applying the assertion predicates to the action environment. kernel service. the operating system can provide this information. Monotonicity is enforced by the KeyNote language (it is not possible to write non-monotonic policies). A KeyNote evaluator accepts as input a set of local policy and credential assertions. In this environment. delegation must be controlled by the operating system (or some implicitly trusted application). This simply means that given a set of credentials associated with a request. KeyNote-Version: 2 Authorizer: "POLICY" Licensees: "rsa-hex:1023abcd" Comment: Allow Licensee to connect to local port 23 (telnet) from Internal addresses only. in the absence of cryptographic authentication.

091. local_port == "22" && protocol == "tcp" -> "true". KeyNote does not allow rights amplification.001" && local_port == "22") -> "true".006. field Conditions: (local_port == "23" && protocol == "tcp" && remote_address > "158.130. That user then delegates to two other users (keys) the right to connect to SSH from one specific address.from anywhere. end hosts (as identified by their IP address) are also considered principals when IPsec is not used to secure communications. Since this is a policy. This allows local policies or 19 . Conditions: (remote_address == "139. if coming from a specific address.001. or to the SSH port from any address.007.000" && remote_address < "158. no signature is required. Note that the first key can effectively delegate at most the same rights it possesses. The local policy allows a particular user (as identified by their public key) connect access to the telnet port by internal addresses.255) -> "true". KeyNote-Version: 2 Authorizer: "rsa-hex:1023abcd" Licensees: "dsa-hex:986512a1" || "x509-base64:19abcd02==" Comment: Authorizer delegates SSH connection access to either of the Licensees. In our prototype. Signature: "rsa-md5-hex:f00f5673" Example 1: Example KeyNote Policy and Credential. any delegation acts as refinement.130.

Credentials that specify. could be delivered under any of the distribution schemes described in Section 2.g. e.. or refinement. The only known solution to this is the use of cryptographic protocols to secure communications. getsockopt(2) calls). of local policy. In KeyNote. hosts. Naturally.In the context of the distributed firewall. Perhaps of more interest. Since KeyNote allows multiple policy constraints.) that are not present in KeyNote. KeyNote allows us to use the same. the union of all policy and credential assertions is the overall network security policy. services. being signed. and made available to the end application through some OS-specific mechanism (e. credentials may be viewed as parts of a hypothetical access matrix. In that respect. credentials may be considered as an extension. This higher-level language would provide grouping mechanisms and network-specific abstractions (for networks. in the form of intersection (conjunction) and union (disjunction) of the component sub-policies. End hosts may specify their own security policies. it is possible to “merge” policies from different administrative entities and process them unambiguously.g. [2]) or GUI to specify correspondingly higher-level policy and then have this compiled to a set of KeyNote credentials.. An administrator would use a higher-level language (e. This merging can be expressed in the KeyNote language.credentials issued by administrative keys to specify policies similar to current packet filtering rules. The latter. or to layer them in increasing levels of refinement. our ultimate goal is to use it as an interoperability layer language that “ties together” the various applications that need access control services. such policies or credentials implicitly trust the validity of an IP address as an identifier.g. or do anything in between these two ends of the spectrum. simple language for both policy and credentials. Java applet permissions. potentially for different applications. they are equivalent to standard packet filtering. may be distributed over an insecure communication channel. or they may depend exclusively on credentials from the administrator. Alternately. it is trivial to support applicationspecific credentials. etc. Using KeyNote as the middle language offers a number of benefits: 20 . Although KeyNote uses a human-readable format and it is indeed possible to write credentials and policies that way.. to be contained in the same assertion.

KeyNote. Provides built-in delegation. Allows for incremental or localized policy updates (as only the relevant credentials need to be modified. active code content. Our system is comprised of three components: a set of kernel extensions. OpenBSD provides an attractive platform for developing security applications because of the well-integrated security features and libraries (an IPsec stack. similar implementations are possible under other operating systems.130. Example 2 shows an example of a key delegating to an IP address. which is used for two-way communication between the kernel and the policy daemon. Our prototype implementation totals approximately 1150 lines of C code. 5. allowing for more comprehensive and mixedlevel policies (e. and a device driver.141" Conditions: (@remote_port < 1024 && @local_port == 22) -> "true". thus allowing for decentralized administration. covering email. each component is roughly the same size. which implements the distributed firewall policies. policy and a (signed) credentials.6. KeyNote-Version: 2 Authorizer: "rsa-hex:1023abcd" Licensees: "IP: 158. produced. IPsec.).g. which implement the enforcement mechanisms.). etc. Signature: "rsa-sha1-hex: bee11984" 21 . or revoked).. SSL. Example 1 shows two sample KeyNote assertion. However.It can handle a variety of different applications (since it is applicationindependent but customizable). a userlevel daemon process. etc. IMPLEMENTATION For our development platform we decided to use the OpenBSD operating system.

the distributed firewall must search for such credentials or must be provided with them when policy is generated/updated.Example 2: An example credential where an (administrative) key delegates to an IP address. Figure 9: The Figure shows a graphical representation of the system. with all its components. The policy specification and processing unit lives in user space inside the policy daemon process. The core of the enforcement mechanism lives in kernel space and is comprised of the two modified system calls that interest us. if the connection is coming from a privileged port. connect(2) and accept(2). The two units communicate via a loadable pseudo device driver interface. Messages travel from the system call layer to the user level daemon and back using the policy context queue 22 . This would allow the specified address to connect to the local SSH port. Since the remote host has no way of supplying the credential to the distributed firewall through a security protocol like IPsec.

A user level approach.. This filtering should be based on a policy that is set by the administrator. However. for unreliable protocols.. some form of reply caching is desirable to improve performance. and thus does not require any changes to the kernel code. with all its components. and how they interact with each other.1 Kernel Extensions For our working prototype we focused our efforts on the control of the TCP connections. their functionality. Since any user has access to these system calls. e. Similar principles can be applied to other protocols. requires each application of interest to be linked with a library that provides the required security mechanisms. 23 . a modified libc. Each has its advantages and disadvantages. In the following three subsections we describe the various parts of the architecture. some “filtering” mechanism is needed. Filters can be implemented either in user space or inside the kernel. 4. This has the advantage of operating system-independence. potentially leading to a major security problem.Figure 9 shows a graphical representation of the system. as depicted in Figure 10. such a scheme does not guarantee that the applications will use the modified library.g. In the UNIX operating system users create outgoing and allow incoming TCP connections using the connect(2) and accept(2) system calls respectively.

There is no limit as to the kind or amount of information we can associate with a context. We can. the application is blocked waiting for the policy daemon reply. associated with that connection. 24 . Any credentials acquired through IPsec may also be added to the context at this stage. This restricts us to open source operating systems like BSD and Linux. we create what we call a policy context (see Example 3). As we mentioned previously. After this. The main advantage of this approach is that the additional security mechanisms can be enforced transparently on the applications. The commit operation adds the context to the list of contexts the policy daemon needs to handle. In the case of the connect(2). While this approach offers considerable flexibility. as shown in the left side of Figure 9. The only difference is that we now also include the source address and port. include the time of day or the number of other open connections of that user. When a connect (2) is issued by a user application and the call traps into the kernel. the two system calls we need to filter are connect (2) and accept (2).Figure 10: Wrappers for filtering the connect(2) and accept(2) system calls are added to a system library. the destination address and port. we allocate a new context which we fill in similarly to the connect (2) case. The policy context is a container for all the information related to that specific connection. if we want them to be considered by our decision–making strategy. A kernel level approach. we commit that context. for example. We associate a sequence number to each such context and then we start filling it with all the information the policy daemon will need to decide whether to permit it or not. Once all the information is in place. Accepting a connection works in a similar fashion. and the process blocks waiting for a reply from the policy daemon. it blocks until an incoming connection request arrives. The context is then enquired. Upon receipt. requires modifications to the operating system kernel. it suffers from its inability to guarantee the enforcement of security policies. this includes the ID of the user that initiated the connection. etc. as applications might not link with the appropriate library. When accept (2) enters the kernel.

void policy_add_ipv4addr (policy_context *. void policy_add_int(policy_context *. policy_context *policy_create_context (void). typedef struct policy_context policy_context. void policy_destroy_context (policy_context *). policy_context *policy_context_next. void policy_add_string (policy_context *. char *. char data[POLICY_DATA_SIZE]. 25 . int length. }. char *reply. in_addr_t *). u_int32_t sequence. }. char *. struct policy_mbuf { policy_mbuf *next. char *. char *). These are appended to a queue from which the policy daemon will receive and process them. Example 3: The connect(2) and accept(2) system calls create contexts which contain information relevant to that connection. struct policy_context { policy_mbuf *p_mbuf. The policy daemon will then return to the kernel a decision on whether to accept or deny the connection. int).typedef struct policy_mbuf policy_mbuf. void policy_commit_context (policy_context *).

This increases the functionality of our system even more. /dev/policy that serves as a communication path between the user–space policy daemon. we have implemented the device driver as a loadable module. The write(2) is responsible for returning the policy daemons decision to the blocked connection call. on whether to allow or deny connections. Closing the device will free any allocated resources and disable the distributed firewall. When reading from the device the policy daemon blocks until there are requests to be served. by discarding the current policy context and dropping the associated connection. All subsequent connect(2) and accept(2) calls will go through the procedure described in the previous section.2 Policy Device To maximize the flexibility of our system and allow for easy experimentation.3 Policy Daemon The third and last component of our system is the policy daemon. without needing to recompile the whole kernel. based on policies that are specified by some administrator and credentials retrieved remotely or provided by the kernel. since we can add functionality dynamically. and the modified system calls in the kernel. we decided to make the policy daemon a user level process.4. and then waking it up. we implemented a pseudo device driver. and writes back a reply. It should be noted that both the device and the associated messaging protocol are not tied to any particular type of application. we have included an ioctl(2) call for “house–keeping”. no connection filtering is done. To support this architecture. read(2). This allows the kernel and the policy daemon to re–synchronize in case of any errors in creating or parsing the request messages. If no policy daemon has opened /dev/policy. and may in fact be used without any modifications by other kernel components that require similar security policy handling. It is a user level process responsible for making decisions. Our device driver supports the usual operations (open(2). Finally. 26 . and ioctl(2)). Furthermore. close(2). Opening the device activates the distributed firewall and initializes data structures. The policy daemon handles the policy resolution messages from the kernel. 4. write(2).

It is possible to remove old policies and add new ones dynamically. are initially read in from a file. it can be used to provide policy resolution services for many different applications. the daemon itself has no awareness of the specific application. as shown in Example 1. The daemon receives each request (see Example 4) from the kernel by reading the device. literally without any modifications. u_int32_t N. A very simple approach to that is fetching the credentials via HTTP from a remote web server. While the information received in a particular message is applicationdependent (in our case. Finally the daemon writes the reply back to the kernel and waits for the next request. When using a remote repository server. or with the local or remote IP address (such credentials may look like the one in Example 2). if such functionality is required. and a decision to accept or deny it is reached.Policies. The credentials are stored by user ID and IP address. relevant to the distributed firewall). u_int32_t uid. and provided to anyone requesting them. If credential “privacy” is a requirement. using the policy device. one could secure this connection using IPsec or SSL. u_int32_t l[N]. /* Sequence Number */ /* User Id */ /* Number of Fields */ /* Lengths of Fields */ /* Fields */ 27 . Communication between the policy daemon and the kernel is possible. such policy changes only affect new connections. In Section 5 we will discuss how these changes can potentially be made to affect existing connections. the daemon can fetch a credential based on the ID of the user associated with a connection. In the current implementation. Processing of the request is done by the daemon using the KeyNote library. The request contains all the information relevant to that connection as described in Section 4. Thus.1. the policy daemon is not subject to the connection filtering mechanism. char *field[N]. To avoid potential deadlocks. as we mentioned earlier. u_int32_t seq.

In the case of a connection coming in over IPsec.Example 4: The request to the policy daemon is comprised of the following fields: a sequence number uniquely identifying the request. KeyNote-Version: 2 Authorizer: "POLICY" Licensees: ADMINISTRATIVE_KEY Example 5: End-host local security policy. the kernel will construct the appropriate context as discussed in Section 4. and has a local policy as shown in Example 5. The local host where the connection is coming is part of a distributed firewall. the fact that the connection is protected by IPsec. Once the TCP connection is received. the lengths of those fields. This context will contain the local and remote IP addresses and ports for the connection. In our particular scenario. a KeyNote credential as shown in Example 6 is provided to the local host. the policy simply states that some administrative key will specify our policy. 4. the number of information fields that will be included in the request. The lack of a Conditions field means that there are no restrictions imposed on the policies specified by the administrative key. we discuss the course of events during two incoming TCP connection requests. one of which is IPsec–protected. 28 . in the form of one or more credentials.1. As part of the IKE exchange. and finally the fields themselves. the ID of the user the connection request belongs to.4 Example Scenario To better explain the interaction of the various components in the distributed firewall. the remote user or host will have established an IPsec Security Association with the local host using IKE.

more specifically. the policy daemon will try to acquire relevant credentials by contacting a remote server where these are stored. This information along with the credential acquired via IPsec will be passed to the policy daemon. we use a web server as the credential repository. The policy daemon will perform a KeyNote evaluation using the local policy and the credential. the connection is ultimately denied. (app_domain == 29 .. and will determine whether the connection is authorized or not. which will then permit the TCP connection to proceed. In our current implementation. i. In our case. The policy daemon uses the public key of the remote user (when it is known. KeyNote-Version: 2 Authorizer: ADMINISTRATIVE_KEY Licensees: USER_KEY Conditions: (app_domain == "IPsec policy" && encryption_algorithm == "3DES" && local_address == "158.130. Note that more credentials may be provided during the IKE negotiation (for example.141") -> "true". a distributed/replicated database could be used instead. etc.006. In a large-scale network. If KeyNote does not authorize the connection. when IPsec is in use) and the IP address of the remote host as the keys to lookup credentials with. These are then used in conjunction with the information provided by the kernel to re-examine the request. credentials where the user’s public key or the remote host’s address appears in the Licensees field are retrieved and cached locally (Example 2 lists an example credential that refers to an IP address).the time of day.e. the positive response will be sent back to the kernel. If it is again denied. a chain of credentials delegating authority).

it adds the overhead of cross domain calls between user space and kernel.." distributed firewall " && @local_port == 23 && encrypted == "yes" && authenticated == "yes") -> "true". Since IPsec also enforces some form of access control on packets. This design maximizes the flexibility of our system and allows for easy experimentation. The distributed firewall is an important component in the STRONGMAN architecture. we could simply merge the two clauses (the IPsec policy clause could specify that the specific user may talk to TCP port 23 only over that SA). WORK IN DEVELOPMENT There are a number of possible extensions that we plan to work on in the process of building a more general and complete system. An alternate design 30 . we could simplify the overall architecture by skipping the security check for TCP connections coming over an IPsec tunnel. Example 6: A credential from the administrator to some user. we are examining the application of higher-level security policy languages to large-scale network management. the policy daemon runs as a user level process that communicates with the kernel via a device driver. authorizing that user to establish an IPsec Security Association (SA) with the local host and to connect to port 23 (telnet) over that SA. 5..3. To do this. Unfortunately. KeyNote is used as a common language for expressing policies that can be distributed in different applications and systems. As we described in Section 4. In that case. As part of the STRONGMAN project at the University of Pennsylvania. This is a subject of ongoing research. Signature: . we use the fact that multiple expressions can be included in a single KeyNote credential.

there also exist a number of ethernet cards with built-in support for IPsec. e.g. we invoke the policy daemon only the first time we encounter a new type of packet. The cost of always-encrypted communication is less than one might think: PCI cards that cost less than US$300 retail (year 2000 prices) can easily achieve 100Mbps sustained throughput while encrypting/decrypting. The decision of the policy daemon may be cached (subject to policy) in the filtering mechanism. However. we can update the policies of the daemon dynamically.3. it is also possible to statically analyze the policies and credentials and derive in advance the necessary packet filtering rules. The policy daemon will then have direct access to the policy context queue. a packet based implementation would also limit the types of “scanning” that an attacker might perform. We should note here that in our view most communications should be secured end-to-end (via IPsec or other similar mechanism). In order to avoid the high overhead of such an approach we plan to use “policy caching. We plan to expand our implementation by adding an IP filter-like mechanism for a more fine grained control (perhaps based on some existing filtering package.” With policy caching. Another point to address is policy updates. eliminating the system call overhead.. policing.would be to run the policy daemon inside the kernel. In the event of a policy change. thus. like IPF). This approach can potentially scale much better than initializing or updating packet filters at the same time policy is updated. As we mentioned in Section 4. potentially allowing for even higher throughput and much lower cost. Given the simplicity of the KeyNote language. policy updates do not 31 . and any other packets of the same type will be treated accordingly. Apart from protecting applications based on UDP. This will allow per-packet. Our current system focuses on controlling TCP connections. most hosts would have a minimal set of filtering entries established at boot time. The rest of the rules would be established dynamically through the key exchange (or policy discovery) mechanisms in IPsec (or equivalent protocol). as opposed to per-connection. much like nfssvc(2). we can simply flush the cache. as a form of pre-caching. a packet belonging to a new connection. This however imposes greater demands on the credentialdistribution mechanism.

the kernel then walks the list of TCP connections and sends a policy resolution request to the policy daemon. We have already mentioned that KeyNote may be used to express applicationspecific policies. Connections that do not comply with the changes will be terminated by the kernel. These credentials will then be added to any policy context requests associated with the socket. One final point to address is credential discovery. although it is mostly targeted to RMI environments like CORBA. Described different approaches to host-based enforcement of security policy. These mechanisms depend on the IP addresses for access control. We would like to add a revocation mechanism that goes through the list of all the connections and re-applies the policies. as it is possible to do very fine-grained access control by appropriately mixing these. The Napoleon system [18] defines a layered group-based access control scheme that is in some ways similar to the distributed firewall concept we have described. Policies are compiled 32 .affect already existing connections in the current implementation. The interaction between application-specific and lower-level (such as those equivalent to packet filtering) policies is of particular interest. RELATED WORK A lot of work has been done over the previous years in the area of (traditional) firewalls. although they could potentially be extended to support some credential-based policy mechanism similar to what we describe in our paper. 6. The policy daemon can then process these credentials along with the request. and the relevant credentials may be distributed over the same channels (IPsec.). web server. pretending the connection was just initiated. One obvious method of doing so is by adding an ioctl(2) call that notifies the kernel of a policy update. etc. Users need a way to discover what credentials they (might) need to supply to the system along with their request for a connection. A simple way of adding this capability is by using the already existing setsockopt (2) system call. This approach requires minimal modifications in our existing system.

Perhaps the most relevant work is that of [2]. allow. 33 . Connections to protected ports are reported to a local security manager which decides whether to drop. since. based on the ACLs. Permit delegation.509-based authentication to provide applications with a library that allows centralized rights management.g. The STRONGMAN project at the University of Pennsylvania is aiming at simplifying security policy management by providing an application-independent policy specification language that can be compiled to application-specific KeyNote credentials.to Access Control Lists (ACLs) appropriate for each application (in our case. rather than just packet filtering rules.g. Policies are compiled to ACLs and distributed to the various hosts in the secured network. The approach there is use of a “network grouping” language that is customized for each managed firewall at that firewall. policies of the type “email has to either be signed in the application layer or delivered over an IPsec SA that was authenticated with a credential matching the user in the From field of the email”). hosts. that would be each end host) and pushed out to them at policy creation or update time. or forward them (using DCE RPC) to a remote host. 3. 2. Allows incremental and asynchronous policy updates.. and the actual mechanisms enforcing policy. 4. through use of wrapper modules that understand the application specific protocols.. Snare Work [9] is a DCE-based system that can provide transparent security services (including access control) to end-applications. although a pull-based method can also be used. Express Mixed-layer policies ( e. This allows us to: 1. and end users and used in an integrated policy framework. only those relevant to a specific firewall). These credentials can then be distributed to applications. Express multi-application policies. an intermediate level language (KeyNote) used by the mechanisms. we introduce a three-layer system: a high-level policy language (equivalent in some sense to that used in Firmato). when policy changes. In our approach. The Adage/Pledge system uses SSL and X. The language used is independent of the firewalls and routers used. only the relevant KeyNote credentials need to be updated and distributed ( e. which enables decentralized management (since KeyNote allows building arbitrary hierarchies of trust).

telecommuters. 34 . the burden placed on the traditional firewall is lessened significantly. since it delegates a lot of the filtering to the end hosts. Security policy is specified using KeyNote policies and credentials.g. is left up to the hosts in the protected network. also do not create windows of vulnerability.e. a web server.  The number of outside connections the protected network is no longer a cause for administration nightmares.. CONCLUSION We have discussed the concept of a distributed firewall..  Since we no longer solely depend on a single firewall for protection. or some other protocol) to the users and hosts in the network. extranets). the end host. Alternately. i.” which can easily be extended to safely include remote hosts and networks ( e. “Backdoor” connections set up by users.g. network security policy specification remains under the control of the network administrator. a directory-like mechanism. we eliminate a performance bottleneck. since all the relevant information is present at the decision point. This allows considerable flexibility in defining the “security perimeter. Under this scheme. either intentionally or inadvertently. and is distributed (through IPsec.. various shortcomings of traditional firewalls are overcome:  Security is no longer dependent on restricting the network topology. however. Adding or removing links has no impact on the security of the network. FTP) which was difficult when done on a traditional firewall.8. becomes significantly easier. Its enforcement. Since enforcement occurs at the endpoints.  Filtering of certain protocols ( e.

 Denial-of-service attack mitigation is more effective at the network ingress points (depending on the particular kind of attack). End-to-end encryption is made possible without sacrificing security. In fact. Also. which may be very large for large networks (e. and does not require each host/ firewall to maintain the complete set of policies. as was the case with traditional firewalls. other than potential performance degradation. distributed firewall architecture requires high quality administration tools. already. even if traditional firewalls are utilized. the AT&T phone network). large networks with a modest number of perimeter firewalls are becoming difficult to manage manually.g. note that the introduction of a distributed firewall infrastructure in a network does not completely eliminate the need for a traditional firewall. Note that this is mostly an implementation issue. We believe that this is an inevitable trend however. Furthermore. that is.  Application-specific policies may be made available to end applications over the same distribution channel. This significantly eases the task of policy updating. The latter is still useful in certain tasks:  It is easier to counter infrastructure attacks that operate at a level lower than the distributed firewall. there is no reason why a distributed firewall cannot operate at arbitrarily low layers. policies and their distribution scales much better with respect to the network size and user base than a more tightly-coupled and synchronized approach would. and de facto places high confidence in them.. end-to-end encryption greatly improves the security of the distributed firewall.  Filtering (and other policy) rules are distributed and established on an as-needed basis. On the other hand. 35 . only the hosts that actually need to communicate need to determine what the relevant policy with regard to each other is.

 The traditional firewall may protect end hosts that do not (or cannot) support the distributed firewall mechanisms. The two main differences between the two approaches lie in the granularity of “internal” protection (which also depends on the protected subnet topology. a traditional firewall may simply act as a fail-safe security mechanism. Since most of the security enforcement has been moved to the end hosts. Integration with the policy specification and distribution mechanisms is especially important here.g. and scalability of this architecture. 36 . from an administrative point of view. We have demonstrated the feasibility of the distributed firewall by building a working prototype. The interactions between traditional (and. even more interesting. The mechanism we have already described may be used in both environments. switched or broadcast) and the end-to-end security guarantees (better infrastructure support is needed to make IPsec work through a firewall. efficiency. A final point is that. a fully distributed firewall architecture is very similar to a network with a large number of internal firewalls. where complete traffic information is available. alternately. We hope that our work will stimulate further research in this area. transparent firewalls may be used ).. the task of a traditional firewall operating in a distributed firewall infrastructure is significantly eased. Intrusion detection systems are more effective when located at a traditional firewall.  Finally. to avoid duplicated filters and windows of vulnerability. transparent) and distributed firewalls are a subject for future research. e. Further experimentation is needed to determine the robustness.

Computer Networking A Top-Down Approach Featuring The Internet 37 .net  www. REFERENCES  http://news.cs.edu/~smb/papers/distfw.com  http://www.9.interhack.columbia.html  Kurose and Ross .zdnet.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.