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. Dr. David Peter S.

Seminar Guide 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.
 TABLE OF CONTENTS

Chapter No. Title Page

LIST OF FIGURES ii

1 Introduction 1

2 Policy and Identifiers 5

3 Distributed Firewall 6
3.1 Standard Firewall Example 10
3.2 Distributed Firewall Example 13

4 KeyNote 15

5 Implementation 20
5.1 Kernel Extensions 21
5. 2 Policy Device 24
5.3 Policy Daemon 25
5.4 Example Scenario 27

6 Work in Development 28

7 Related Work 30

8 Conclusion 32

9 References 35

i
 LIST OF FIGURES

NO: NAME PAGE

1 Architecture of Distributed Firewall 7

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

ii
Data Security in Local network Using Distributed Firewall

1. Introduction
Conventional firewalls rely on the notions of restricted topology and control
entry points to function. More precisely, they rely on the assumption that everyone on
one side of the entry point--the firewall--is to be trusted, and that anyone on the other side
is, at least potentially, an enemy. The vastly expanded Internet connectivity in recent
years has called that assumption into question. So-called "extranets" can allow outsiders
to reach the "inside" of the firewall; on the other hand, telecommuters' machines that use
the Internet for connectivity need protection when encrypted tunnels are not in place.
While this model worked well for small to medium size networks, 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), firewalls tend to become
congestion points. This gap between processing and networking speeds is likely to
increase, at least for the foreseeable future; while computers (and hence firewalls)
are getting faster, 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.

 There exist protocols, and new protocols are designed, that are difficult to process
at the firewall, because the latter lacks certain knowledge that is readily available
at the endpoints. FTP and RealAudio are two such protocols. Although there
exist application-level proxies that handle such protocols, such solutions are
viewed as architecturally “unclean” and in some cases too invasive.

 The assumption that all insiders are trusted has not been valid for a long time.
Specific individuals or remote networks may be allowed access to all or parts of
the protected infrastructure (extranets, telecommuting, etc.). Consequently, the
traditional notion of a security perimeter can no longer hold unmodified; for
example, it is desirable that telecommuters’ systems comply with the corporate
security policy.

Department of Computer Science,SOE,CUSAT 1

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

 End-to-end encryption can also be a threat to firewalls, as it prevents them from

looking at the packet fields necessary to do filtering. Allowing end-to-end
encryption through a firewall implies considerable trust to the users on behalf of
the administrators.

 Finally, 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
 Other trends are also threatening firewalls. For example, some machines need more
access to the outside than do others. Conventional firewalls can do this, but only with
difficulty, especially as internal IP addresses change. End-to-end encryption is another
threat, since the firewall generally does not have the necessary keys to peek through the
encryption.

More subtly, firewalls are a mechanism for policy control. That is, they permit a site's
administrator to set a policy on external access. Just as file permissions enforce an
internal security policy, a firewall can enforce an external security policy.

Despite their shortcomings, firewalls are still useful in providing some measure of
security. The key reason that firewalls are still useful is that they provide an obvious,
mostly hassle-free, mechanism for enforcing network security policy. For legacy
applications and networks, they are the only mechanism for security. While newer
protocols typically have some provisions for security, older protocols (and their
implementations) are more difficult, often impossible, to secure. Furthermore, firewalls
provide a convenient first-level barrier that allows quick responses to newly-discovered
bugs.
To address the shortcomings of firewalls while retaining their advantages, proposed
the concept of a distributed firewall. In distributed firewalls, security policy is defined
centrally but enforced at each individual network endpoint (hosts, routers, etc.). The
system propagates the central policy to all endpoints. Policy distribution may take various
forms. For example, it may be pushed directly to the end systems that have to enforce it,
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. 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. 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. This is important because the most costly and destructive attacks still
originate from within the organization.

3
 Distributed firewalls rest on three notions: (a) a policy language that states what sort of
connections are permitted or prohibited, (b) any of a number of system management
tools, such as Microsoft's SMS or ASD and (c) IPSEC, the network-level encryption
mechanism for TCP/IP.

The basic idea is simple. A compiler translates the policy language into some internal
format. The system management software distributes this policy file to all hosts that are
protected by the firewall. And incoming packets are accepted or rejected by each "inside"
host, according to both the policy and the cryptographically-verified identity of each
sender.

To implement a distributed firewall, three components are necessary:

 A language for expressing policies and resolving requests. In their simplest form,
policies in a distributed firewall are functionally equivalent to packet filtering
rules. However, it is desirable to use an extensible system (so other types of
applications and security checks can be specified and enforced in the future). The
language and resolution mechanism should also support credentials, for
delegation of rights and authentication purposes.

 A mechanism for safely distributing security policies. This may be the IPsec key
management protocol when possible, or some other protocol. The integrity of the
policies transferred must be guaranteed, either through the communication
protocol or as part of the policy object description ( e.g., they may be digitally
signed).

 A mechanism that applies the security policy to incoming packets or connections,

providing the enforcement part.

This is by no means a universal trait, and even today there are protocols designed
with no security review.
Our prototype implementation uses the KeyNote trust-management system, which
provides a single, extensible language for expressing policies and credentials. Credentials

4
in KeyNote are signed, thus simple file-transfer protocols may be used for policy
distribution. We also make use of the IPsec stack in the OpenBSD system to authenticate
users, protect traffic, and distribute credentials. The distribution of credentials and user
authentication occurs are part of the Internet Key Exchange (IKE) [12] negotiation.
Alternatively, policies may be distributed from a central location when a policy update is
performed, or they may be fetched as-needed (from a webserver, X.500 directory, or
through some other protocol).
Since KeyNote allows delegation, decentralized administration becomes feasible
(establishing a hierarchy or web of administration, for the different departments or even
individual systems). Users are also able to delegate authority to access machines or
services they themselves have access to. Although this may initially seem counter-
intuitive (after all, firewalls embody the concept of centralized control), in our experience
users can almost always bypass a firewall’s filtering mechanisms, usually by the most
insecure and destructive way possible ( e.g., giving away their password, setting up a
proxy or login server on some other port, etc.). Thus, it is better to allow for some
flexibility in the system, as long as the users follow the overall policy. Also note that it is
possible to “turn off” delegation.
Thus, 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, any credentials
given to the user, and any credentials stored in a central location and retrieved on-
demand. Finally, we implement the mechanism that enforces the security policy in a
TCP-connection granularity. In our implementation, the mechanism is split in two parts,
one residing in the kernel and the other in a user-level process.

2. Policies and Identifiers

Many possible policy languages can be used, including file-oriented schemes

similar to Firmato, the GUIs that are found on most modern commercial firewalls, and
general policy languages such as KeyNote. The exact nature is not crucial, though clearly
the language must be powerful enough to express the desired policy. A sample is shown
in Figure.

5
 What is important is how the inside hosts are identified. Today's firewalls rely on
topology; thus, network interfaces are designated "inside", "outside", "DMZ", etc. We
abandon this notion (but see Section), since distributed firewalls are independent of
topology.

A second common host designator is IP address. That is, a specified IP address

may be fully trusted, able to receive incoming mail from the Internet, etc. Distributed
firewalls can use IP addresses for host identification, though with a reduced level of
security.

Our preferred identifier is the name in the cryptographic certificate used with
IPSEC. Certificates can be a very reliable unique identifier. They are independent of
topology; furthermore, ownership of a certificate is not easily spoofed. If a machine is
granted certain privileges based on its certificate, those privileges can apply regardless of
where the machine is located physically.

In a different sense, policies can be "pulled" dynamically by the end system. For
example, a license server or a security clearance server can be asked if a certain
communication should be permitted. A conventional firewall could do the same, but it
lacks important knowledge about the context of the request. End systems may know
things like which files are involved, and what their security levels might be. Such
information could be carried over a network protocol, but only by adding complexity.

3. Distributed Firewalls

In a typical organizational environment, individuals are not necessarily the

administrators of the computers they use. Instead, to simplify system administration and
to permit some level of central control, a system management package is used to
administer individual machines. Patches can be installed, new software distributed, etc.
We use the same mechanisms, which are likely present in any event, to control a
distributed firewall.

6
 Policy is enforced by each individual host that participates in a distributed
Security
firewall. The security administrator--who is no longer necessarily the "local"
administrator, since we are no longer constrained by topology--defines the security policy
in terms of host identifiers. The resulting policy (probably, though not necessarily,
compiled to some convenient internal format) is then shipped out, much like any other
change. This policy file is consulted before processing incoming or outgoing messages, to
verify their compliance. It is most natural to think of this happening at the network or
transport layers, but policies and enforcement can equally

Fig.1: Architecture of Distributed Firewall

well apply to the application layer. For example, some sites might wish to force local
Web browsers to disable Java or JavaScript.

Policy enforcement is especially useful if the peer host is identified by a

certificate. If so, the local host has a much stronger assurance of its identity than in a
traditional firewall. In the latter case, all hosts on the inside are in some sense equal. If
any such machines are subverted, they can launch attacks on hosts that they would not

7
normally talk to, possibly by impersonating trusted hosts for protocols such as rlogin.
With a distributed firewall, though, such spoofing is not possible; each host's identity is
cryptographically assured.

This is most easily understood by contrasting it to traditional packet filters.

Consider the problem of electronic mail. Because of a long-standing history of security
problems in mailers, most sites with firewalls let only a few, designated hosts receive
mail from the outside. They in turn will relay the mail to internal mail servers. Traditional
firewalls would express this by a rule that permitted SMTP (port 25) connections to the
internal mail gateways; access to other internal hosts would be blocked. On the inside of
the firewall, though, access to port 25 is unrestricted.

With a distributed firewall, all machines have some rule concerning port 25. The
mail gateway permits anyone to connect to that port; other internal machines, however,
permit contact only from the mail gateway, as identified by its certificate. Note how
much stronger this protection is: even a subverted internal host cannot exploit possible
mailer bugs on the protected machines.

Distributed firewalls have other advantages as well. The most obvious is that
there is no longer a single chokepoint. From both a performance and an availability
standpoint, this is a major benefit. Throughput is no longer limited by the speed of the
firewall; similarly, there is no longer a single point of failure that can isolate an entire
network. Some sites attempt to solve these problems by using multiple firewalls; in many
cases, though, that redundancy is purchased only at the expense of an elaborate (and
possibly insecure) firewall-to-firewall protocol.

A second advantage is more subtle. Today's firewalls don't have certain

knowledge of what a host intends. Instead, they have to rely on externally-visible features
of assorted protocols. Thus, an incoming TCP packet is sometimes presumed legitimate if
it has the "ACK" bit set, 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. But spoofed ACK packets can be used as part of "stealth scanning". Similarly, it

8
is hard for firewalls to treat UDP packets properly, because they cannot tell if they are
replies to outbound queries, and hence legal, or if they are incoming attacks. The sending
host, however, knows. Relying on the host to make the appropriate decision is therefore
more secure.

This advantage is even clearer when it comes to protocols such as FTP. By

default, FTP clients use the PORT command to specify the port number used for the data
channel; this port is for an incoming call that should be permitted, an operation that is
generally not permitted through a firewall. Today's firewalls--even the stateful packet
filters--generally use an application-level gateway to handle such commands. With a
distributed firewall, the host itself knows when it is listening for a particular data
connection, and can reject random probes.

The most important advantage, though, is that distributed firewalls can protect
hosts that are not within a topological boundary. Consider a telecommuter who uses the
Internet both generically and to tunnel in to a corporate net. How should this machine be
protected? A conventional approach can protect the machine while tunneled. But that
requires that generic Internet use be tunneled into the corporate network and then back
out the Internet. Apart from efficiency considerations, such use is often in violation of
corporate guidelines. Furthermore, there is no protection whatsoever when the tunnel is
not set up. By contrast, a distributed firewall protects the machine all of the time,
regardless of whether or not a tunnel is set up. Corporate packets, authenticated by
IPSEC, are granted more privileges; packets from random Internet hosts can be rejected.
And no triangle routing is needed.

9
3.1 STANDARD FIREWALL EXAMPLE

10
 Fig 2: Architecture of standard firewall

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

11
 Fig 3: Connection to the Web Server

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

12
 Fig 4: Connection to the Intranet

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

13
3.2 DISTRIBUTED FIREWALL EXAMPLE

Fig 5: Distributed Firewall

This figure is the example of architecture of Distributed firewall. Example contains

internal and external host, internet, network, web server, intranet web server, and a
internal host on other side of network which is communicating through telnet. Here
firewall policy is distributed to all the systems and web server. If firewall policy allowed
connecting with server or systems, then only they connect. In internal part of network,
there are two hosts, one is trusted (Internal host 1) and other one is untrusted (Internal
host 2). Both hosts are connected to the corporate network; web server and intranet web
server are also connected to the network. Then network connected to the internet and

14
between network and internet, there is firewall. There is also an external host and internal
host using telecommuting which is connected to the internet.

Fig 6: Connection to Web Server

In this figure, we can see that when internal hosts want to connected with web server,
they can connect. Although internal host of external side of network and external host can
connect to the web server. Because they are allowed to connect with the server.

15
 Fig 7: Connection to Intranet

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

4. KEYNOTE

16
 Trust Management is a relatively new approach to solving the authorization and
security policy problem. Making use of public key cryptography for authentication, trust
management dispenses with unique names as an indirect means for performing access
control. Instead, it uses a direct binding between a public key and a set of authorizations,
as represented by a safe programming language. 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. The Requester is typically a user

that authenticates through some application-dependent protocol, and optionally
provides credentials. The Verifier needs to determine whether the Requester is
allowed to perform the requested action. It is responsible for providing to KeyNote
all the necessary information, the local policy, and any credentials. It is also
responsible for acting upon KeyNote’s response.

One instance of a trust-management system is KeyNote. KeyNote provides a

simple notation for specifying both local security policies and credentials that can be sent
over an untrusted network. Policies and credentials contain predicates that describe the
trusted actions permitted by the holders of specific public keys (otherwise known as
principals). Signed credentials, which serve the role of “certificates,” have the same
syntax as policy assertions, but are also signed by the entity delegating the trust.
Applications communicate with a “KeyNote evaluator” that interprets KeyNote
assertions and returns results to applications, as shown in Figure 8. However, different

17
hosts and environments may provide a variety of interfaces to the KeyNote evaluator
(library, UNIX daemon, kernel service, etc.).
A KeyNote evaluator accepts as input a set of local policy and credential
assertions, and a set of attributes, called an “action environment,” 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. The KeyNote
evaluator can return values other than simply true and false, depending on the application
and the action environment definition. An important concept in KeyNote (and, more
generally, in trust management) is “monotonicity”. This simply means that given a set of
credentials associated with a request, if there is any subset that would cause the request to
be approvedthen the complete set will also cause the request to be approved. This greatly
simplifies both request resolution (even in the presence of conflicts) and credential
management. Monotonicity is enforced by the KeyNote language (it is not possible to
write non-monotonic policies).
It is worth noting here that although KeyNote uses cryptographic keys as principal
identifiers, other types of identifiers may also be used. For example, usernames may be
used to identify principals inside a host. In this environment, delegation must be
controlled by the operating system (or some implicitly trusted application), similar to the
mechanisms used for transferring credentials in Unix or in capability-based systems.
Also, in the absence of cryptographic authentication, the identifier of the principal
requesting an action must be securely established. In the example of a single host, the
operating system can provide this information.

KeyNote-Version: 2
Authorizer: "POLICY"
Licensees: "rsa-hex:1023abcd"
Comment: Allow Licensee to connect to local port 23
(telnet) from Internal addresses only, or to port 22 (ssh)

18
from anywhere. Since this is a policy, no signature field
is required.
Conditions: (local_port == "23" && protocol == "tcp" &&
remote_address > "158.130.006.000" &&
remote_address < "158.130.007.255) -> "true";
local_port == "22" && protocol == "tcp" -> "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, if coming from a specific address.
Conditions: (remote_address == "139.091.001.001" &&
local_port == "22") -> "true";
Signature: "rsa-md5-hex:f00f5673"

Example 1: Example KeyNote Policy and Credential. The local policy allows a
particular user (as identified by their public key) connect access to the telnet port by
internal addresses, or to the SSH port from any address. That user then delegates to
two other users (keys) the right to connect to SSH from one specific address. Note
that the first key can effectively delegate at most the same rights it possesses.
KeyNote does not allow rights amplification; any delegation acts as refinement.

In our prototype, end hosts (as identified by their IP address) are also considered
principals when IPsec is not used to secure communications. This allows local policies or

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

20
 It can handle a variety of different applications (since it is application-
independent but customizable), allowing for more comprehensive and mixed-
level policies (e.g., covering email, active code content, IPsec, etc.).
Provides built-in delegation, thus allowing for decentralized administration.
Allows for incremental or localized policy updates (as only the relevant
credentials need to be modified, produced, or revoked).
Example 1 shows two sample KeyNote assertion, policy and a (signed) credentials.
Example 2 shows an example of a key delegating to an IP address.

5. IMPLEMENTATION
For our development platform we decided to use the OpenBSD operating system.
OpenBSD provides an attractive platform for developing security applications because of
the well-integrated security features and libraries (an IPsec stack, SSL, KeyNote, etc.).
However, similar implementations are possible under other operating systems.
Our system is comprised of three components: a set of kernel extensions, which
implement the enforcement mechanisms, a userlevel daemon process, which implements
the distributed firewall policies, and a device driver, which is used for two-way
communication between the kernel and the policy daemon. Our prototype
implementation totals approximately 1150 lines of C code; each component is roughly
the same size.

KeyNote-Version: 2
Authorizer: "rsa-hex:1023abcd"
Licensees: "IP: 158.130.6.141"
Conditions: (@remote_port < 1024 &&
@local_port == 22) -> "true";
Signature: "rsa-sha1-hex: bee11984"

21
 Example 2: An example credential where an (administrative) key delegates to
an IP address. This would allow the specified address to connect to the local SSH
port, if the connection is coming from a privileged port. Since the remote host has
no way of supplying the credential to the distributed firewall through a security
protocol like IPsec, the distributed firewall must search for such credentials or must
be provided with them when policy is generated/updated.

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

23
 Figure 10: Wrappers for filtering the connect(2) and accept(2) system calls are
added to a system library. While this approach offers considerable flexibility, it
suffers from its inability to guarantee the enforcement of security policies, as
applications might not link with the appropriate library.

A kernel level approach, as shown in the left side of Figure 9, requires

modifications to the operating system kernel. This restricts us to open source operating
systems like BSD and Linux. The main advantage of this approach is that the additional
security mechanisms can be enforced transparently on the applications.
As we mentioned previously, the two system calls we need to filter are connect
(2) and accept (2). When a connect (2) is issued by a user application and the call traps
into the kernel, we create what we call a policy context (see Example 3), associated with
that connection.
The policy context is a container for all the information related to that specific
connection. 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. In the case of the connect(2), this includes the ID of the user that initiated the
connection, the destination address and port, etc. Any credentials acquired through IPsec
may also be added to the context at this stage. There is no limit as to the kind or amount
of information we can associate with a context. We can, for example, include the time of
day or the number of other open connections of
that user, if we want them to be considered by our decision–making strategy.
Once all the information is in place, we commit that context. The commit
operation adds the context to the list of contexts the policy daemon needs to handle. After
this, the application is blocked waiting for the policy daemon reply.
Accepting a connection works in a similar fashion. When accept (2) enters the
kernel, it blocks until an incoming connection request arrives. Upon receipt, we allocate a
new context which we fill in similarly to the connect (2) case. The only difference is that
we now also include the source address and port. The context is
then enquired, and the process blocks waiting for a reply from the policy daemon.

24
 typedef struct policy_mbuf
policy_mbuf;
struct policy_mbuf
{
policy_mbuf
*next;
int length;
char data[POLICY_DATA_SIZE];
};
typedef struct policy_context policy_context;
struct policy_context {
policy_mbuf
*p_mbuf;
u_int32_t
sequence;
char *reply;
policy_context *policy_context_next;
};
policy_context *policy_create_context (void);
void policy_destroy_context (policy_context *);
void policy_commit_context (policy_context *);
void policy_add_int(policy_context *, char *, int);
void policy_add_string (policy_context *, char *, char *);
void policy_add_ipv4addr (policy_context *, char *, in_addr_t *);

Example 3: The connect(2) and accept(2) system calls create contexts which
contain information relevant to that connection. These are appended to a queue
from which the policy daemon will receive and process them. The policy daemon
will then return to the kernel a decision on whether to accept or deny the
connection.

25
4.2 Policy Device
To maximize the flexibility of our system and allow for easy experimentation, we
decided to make the policy daemon a user level process. To support this architecture, we
implemented a pseudo device driver, /dev/policy that serves as a communication path
between the user–space policy daemon, and the modified system calls in the kernel. Our
device driver supports the usual operations (open(2), close(2), read(2), write(2), and
ioctl(2)). Furthermore, we have implemented the device driver as a loadable module. This
increases the functionality of our system even more, since we can add functionality
dynamically, without needing to recompile the whole kernel.
If no policy daemon has opened /dev/policy, no connection filtering is done.
Opening the device activates the distributed firewall and initializes data structures. All
subsequent connect(2) and accept(2) calls will go through the procedure described in the
previous section. 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. The policy daemon handles the policy resolution messages from the kernel,
and writes back a reply. The write(2) is responsible for returning the policy daemons
decision to the blocked connection call, and then waking it up. It should be noted that
both the device and the associated messaging protocol are not tied to any particular type
of application, and may in fact be used without any modifications by other kernel
components that require similar security policy handling.
Finally, we have included an ioctl(2) call for “house–keeping”. This allows the
kernel and the policy daemon to re–synchronize in case of any errors in creating or
parsing the request messages, by discarding the current policy context and dropping the
associated connection.

4.3 Policy Daemon

The third and last component of our system is the policy daemon. It is a user level
process responsible for making decisions, based on policies that are specified by some
administrator and credentials retrieved remotely or provided by the kernel, on whether to
allow or deny connections.

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

u_int32_t seq; /* Sequence Number */

u_int32_t uid; /* User Id */
u_int32_t N; /* Number of Fields */
u_int32_t l[N]; /* Lengths of Fields */
char *field[N]; /* Fields */

27
 Example 4: The request to the policy daemon is comprised of the following
fields: a sequence number uniquely identifying the request, the ID of the user the
connection request belongs to, the number of information fields that will be included
in the request, the lengths of those fields, and finally the fields themselves.

KeyNote-Version: 2
Authorizer: "POLICY"
Licensees: ADMINISTRATIVE_KEY

Example 5: End-host local security policy. In our particular scenario, the

policy simply states that some administrative key will specify our policy, in the form
of one or more credentials. The lack of a Conditions field means that there are no
restrictions imposed on the policies specified by the administrative key.

4.4 Example Scenario

To better explain the interaction of the various components in the distributed
firewall, we discuss the course of events during two incoming TCP connection requests,
one of which is IPsec–protected. The local host where the connection is coming is part of
a distributed firewall, and has a local policy as shown in Example 5.
In the case of a connection coming in over IPsec, the remote user or host will
have established an IPsec Security Association with the local host using IKE. As part of
the IKE exchange, a KeyNote credential as shown in Example 6 is provided to the local
host. Once the TCP connection is received, the kernel will construct the appropriate
context as discussed in Section 4.1. This context will contain the local and remote IP
addresses and ports for the connection, the fact that the connection is protected by IPsec,

28
the time of day, etc. This information along with the credential acquired via IPsec will be
passed to the policy daemon. The policy daemon will perform a KeyNote evaluation
using the local policy and the credential, and
will determine whether the connection is authorized or not. In our case, the positive
response will be sent back to the kernel, which will then permit the TCP connection to
proceed. Note that more credentials may be provided during the IKE negotiation (for
example, a chain of credentials delegating authority).
If KeyNote does not authorize the connection, the policy daemon will try to
acquire relevant credentials by contacting a remote server where these are stored. In our
current implementation, we use a web server as the credential repository. In a large-scale
network, a distributed/replicated database could be used instead. The policy daemon uses
the public key of the remote user (when it is known, i.e., when IPsec is in use) and the IP
address of the remote host as the keys to lookup credentials with; more specifically,
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). These are then used in conjunction with the information
provided by the kernel to re-examine the request. If it is again denied, the connection is
ultimately denied.

KeyNote-Version: 2
Authorizer: ADMINISTRATIVE_KEY
Licensees: USER_KEY
Conditions:
(app_domain == "IPsec policy" &&
encryption_algorithm == "3DES" &&
local_address == "158.130.006.141")
-> "true";
(app_domain ==

29
 " distributed firewall " &&
@local_port == 23 &&
encrypted == "yes" &&
authenticated == "yes") -> "true";
Signature: ...

Example 6: A credential from the administrator to some user, authorizing

that user to establish an IPsec Security Association (SA) with the local host and to
connect to port 23 (telnet) over that SA. To do this, we use the fact that multiple
expressions can be included in a single KeyNote credential. Since IPsec
also enforces some form of access control on packets, we could simplify the overall
architecture by skipping the security check for TCP connections coming over an
IPsec tunnel. In that case, 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).

5. 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.
As part of the STRONGMAN project at the University of Pennsylvania, we are
examining the application of higher-level security policy languages to large-scale
network management. KeyNote is used as a common language for expressing policies
that can be distributed in different applications and systems. The distributed firewall is an
important component in the STRONGMAN architecture. This is a subject of ongoing
research.
As we described in Section 4.3, the policy daemon runs as a user level process
that communicates with the kernel via a device driver. This design maximizes the
flexibility of our system and allows for easy experimentation. Unfortunately, it adds the
overhead of cross domain calls between user space and kernel. An alternate design

30
would be to run the policy daemon inside the kernel, much like nfssvc(2). The policy
daemon will then have direct access to the policy context queue, eliminating the system
call overhead.
Our current system focuses on controlling TCP connections. 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, like IPF).
This will allow per-packet, as opposed to per-connection, policing. Apart from
protecting applications based on UDP, a packet based implementation would also limit
the types of “scanning” that an attacker might perform. In order to avoid the high
overhead of such an approach we plan to use “policy caching.” With policy caching, we
invoke the policy daemon only the first time we encounter a new type of packet, e.g., a
packet belonging to a new connection. The decision of the policy daemon may be cached
(subject to policy) in the filtering mechanism, and any other packets of the same type will
be treated accordingly. In the event of a policy change, we can simply flush the cache.
Given the simplicity of the KeyNote language, it is also possible to statically analyze the
policies and credentials and derive in advance the necessary packet filtering rules, as a
form of pre-caching. This however imposes greater demands on the credential-
distribution mechanism.
We should note here that in our view most communications should be secured
end-to-end (via IPsec or other similar mechanism); thus, 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). This approach can potentially scale much better than
initializing or updating packet filters at the same time policy is updated. 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; there also exist a number of ethernet cards with built-in
support for IPsec, potentially allowing for even higher throughput and much lower cost.
Another point to address is policy updates. As we mentioned in Section 4.3, we
can update the policies of the daemon dynamically. However, policy updates do not

31
affect already existing connections in the current implementation. We would like to add a
revocation mechanism that goes through the list of all the connections and
re-applies the policies. Connections that do not comply with the changes will be
terminated by the kernel. One obvious method of doing so is by adding an ioctl(2) call
that notifies the kernel of a policy update; the kernel then walks the list of TCP
connections and sends a policy resolution request to the policy daemon, pretending
the connection was just initiated. This approach requires minimal modifications in our
existing system.
We have already mentioned that KeyNote may be used to express application-
specific policies, and the relevant credentials may be distributed over the same channels
(IPsec, web server, etc.). The interaction between application-specific and lower-level
(such as those equivalent to packet filtering) policies is of particular in-
terest, as it is possible to do very fine-grained access control by appropriately mixing
these.
One final point to address is credential discovery. Users need a way to discover
what credentials they (might) need to supply to the system along with their request for a
connection. The policy daemon can then process these credentials along with the request.
A simple way of adding this capability is by using the already ex-
isting setsockopt (2) system call. These credentials will then be added to any policy
context requests associated with the socket.

6. RELATED WORK
A lot of work has been done over the previous years in the area of (traditional)
firewalls.
Described different approaches to host-based enforcement of security policy.
These mechanisms depend on the IP addresses for access control, although they could
potentially be extended to support some credential-based policy mechanism similar to
what we describe in our paper.
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,
although it is mostly targeted to RMI environments like CORBA. Policies are compiled

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

33
8. CONCLUSION
We have discussed the concept of a distributed firewall. Under this scheme, network
security policy specification remains under the control of the network administrator. Its
enforcement, however, is left up to the hosts in the protected network. Security policy is
specified using KeyNote policies and credentials, and is distributed (through IPsec, a web
server, a directory-like mechanism, or some other protocol) to the users and hosts in the
network. Since enforcement occurs at the endpoints, various shortcomings of traditional
firewalls are overcome:
 Security is no longer dependent on restricting the network topology. This allows
considerable flexibility in defining the “security perimeter,” which can easily be
extended to safely include remote hosts and networks ( e.g., telecommuters,
extranets).

 Since we no longer solely depend on a single firewall for protection, we eliminate

a performance bottleneck. Alternately, the burden placed on the traditional
firewall is lessened significantly, since it delegates a lot of the filtering to the end
hosts.

 Filtering of certain protocols ( e.g., FTP) which was difficult when done on a
traditional firewall, becomes significantly easier, since all the relevant
information is present at the decision point, i.e., the end host.

 The number of outside connections the protected network is no longer a cause for
administration nightmares. Adding or removing links has no impact on the
security of the network. “Backdoor” connections set up by users, either
intentionally or inadvertently, also do not create windows of vulnerability.

34
  End-to-end encryption is made possible without sacrificing security, as was the
case with traditional firewalls. In fact, end-to-end encryption greatly improves the
security of the distributed firewall.

 Application-specific policies may be made available to end applications over the

same distribution channel.

 Filtering (and other policy) rules are distributed and established on an as-needed
basis; that is, only the hosts that actually need to communicate need to determine
what the relevant policy with regard to each other is. This significantly eases the
task of policy updating, and does not require each host/ firewall to maintain the
complete set of policies, which may be very large for large networks (e.g., the
AT&T phone network). Furthermore, 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.
On the other hand, distributed firewall architecture requires high quality administration
tools, and de facto places high confidence in them. We believe that this is an inevitable
trend however, even if traditional firewalls are utilized; already, large networks with a
modest number of perimeter firewalls are becoming difficult
to manage manually.
Also, note that the introduction of a distributed firewall infrastructure in a
network does not completely eliminate the need for a traditional firewall. 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. Note that this is mostly an implementation issue; there is no
reason why a distributed firewall cannot operate at arbitrarily low layers, other
than potential performance degradation.

 Denial-of-service attack mitigation is more effective at the network ingress points

(depending on the particular kind of attack).

35
  Intrusion detection systems are more effective when located at a traditional
firewall, where complete traffic information is available.

 The traditional firewall may protect end hosts that do not (or cannot) support the
distributed firewall mechanisms. Integration with the policy specification and
distribution mechanisms is especially important here, to avoid duplicated filters
and windows of vulnerability.

 Finally, 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, the task of a
traditional firewall operating in a distributed firewall infrastructure is significantly eased.
The interactions between traditional (and, even more interesting, transparent) and
distributed firewalls are a subject for future research.
A final point is that, from an administrative point of view, a fully distributed firewall
architecture is very similar to a network with a large number of internal firewalls. The
mechanism we have already described may be used in both environments. The two main
differences between the two approaches lie in the granularity of “internal” protection
(which also depends on the protected subnet topology, e.g., switched or broadcast) and
the end-to-end security guarantees (better infrastructure support is needed to make IPsec
work through a firewall; alternately, transparent firewalls may be used ).
We have demonstrated the feasibility of the distributed firewall by building a working
prototype. Further experimentation is needed to determine the robustness, efficiency, and
scalability of this architecture. We hope that our work will stimulate further research in
this area.

36
9. REFERENCES
 http://news.zdnet.com

 http://www.interhack.net

 www.cs.columbia.edu/~smb/papers/distfw.html

 Kurose and Ross - Computer Networking A Top-Down

Approach Featuring The Internet

37