1
Implementing a Distributed Firewall
Sotiris IoannidisAngelos D. Keromytis
Steve M. BellovinJonathan M. Smith
Presented ByJim Michaud
2
Outline
• Intro to Security and Firewalls• Problems with Current Firewalls• Distributed Firewall Concept• Distributed Firewall Implementation• Conclusions
*Dieter Gollman, Computer Security, p 9 3
Intro to Security
• Computer/Network Security - The prevention and detection of unauthorized actions by users of computer systems*
• But what does “unauthorized” mean?• It depends on the system’s “security
policy”
4
Security Policy
• A “security policy” defines the security rules of a system.
• Without a defined security policy, there is no way to know what access is allowed or disallowed
• An example policy: (simple)– Allow all connections to the web server– Deny all other access
5
Firewalls
• In most systems today, the firewall is the machine that implements the “security policy” for a system
• A firewall is typically placed at the edge of a system and acts as a filter for unauthorized traffic
• Filters tend to be simple: source and destination addresses, source and destination ports, or protocol (tcp, udp, icmp)
6
Firewall Example
Internet
Company 2
Company 4
Company 1
Company 3
Firewall
FirewallFirewall
Firewall
7
Firewall Drawbacks
• Firewalls can become a bottleneck• Certain protocols (FTP, Real-Audio) are
difficult for firewalls to process• Assumes inside users are “trusted”• Multiple entry points make firewalls hard
to manage
8
Distributed Firewall Concept
• Security policy is defined centrally• Enforcement of policy is done by
network endpoint(s)
9
Standard Firewall Example
C o r p o r a t e N e t w o r kC o r p o r a t eF i r e w a l l
I n t e r n e t
I n t e r n a lE x t e r n a l
E x t e r n a lH o s t
I n t e r n a lH o s t
1
I n t e r n a lH o s t
2( u n t r u s t e d )
W e b s e r v e r
I n t r a n e tW e b s e r v e r( c o m p a n y
p r i v a t e )
10
Standard Firewall Example Connection to web server
C o r p o r a t e N e t w o r kC o r p o r a t eF i r e w a l l
I n t e r n e t
I n t e r n a lE x t e r n a l
E x t e r n a lH o s t
I n t e r n a lH o s t
1
I n t e r n a lH o s t
2( u n t r u s t e d )
W e b s e r v e r
I n t r a n e tW e b s e r v e r( c o m p a n y
p r i v a t e )
11
Standard Firewall Example Connection to intranet
C o r p o r a t e N e t w o r kC o r p o r a t e
F i r e w a l lI n t e r n e t
I n t e r n a lE x t e r n a l
E x t e r n a lH o s t
I n t e r n a lH o s t
1
I n t e r n a lH o s t
2( u n t r u s t e d )
W e b s e r v e r
I n t r a n e tW e b s e r v e r( c o m p a n y
p r i v a t e )
b l o c k e d b yf i r e w a l l c o n n e c t i o n
a l l o w e d ,b u t s h o u l d
n o t b e
12
Distributed Firewall Example
C o r p o r a t e N e t w o r kI n t e r n e t
I n t e r n a lE x t e r n a l
E x t e r n a lH o s t
I n t e r n a lH o s t
1
I n t e r n a lH o s t
2( u n t r u s t e d )
W e b s e r v e r
I n t r a n e tW e b s e r v e r( c o m p a n y
p r i v a t e )
I n t e r n a lH o s t
( t e l e c o m m u t i n g )
13
Distributed Firewall Example to web server
C o r p o r a t e N e t w o r kI n t e r n e t
I n t e r n a lE x t e r n a l
E x t e r n a lH o s t
I n t e r n a lH o s t
1
I n t e r n a lH o s t
2( u n t r u s t e d )
W e b s e r v e r
I n t r a n e tW e b s e r v e r( c o m p a n y
p r i v a t e )
I n t e r n a lH o s t
( t e l e c o m m u t i n g )
14
Distributed Firewall Example to intranet
C o r p o r a t e N e t w o r kI n t e r n e t
I n t e r n a lE x t e r n a l
E x t e r n a lH o s t
I n t e r n a lH o s t
1
I n t e r n a lH o s t
2( u n t r u s t e d )
W e b s e r v e r
I n t r a n e tW e b s e r v e r( c o m p a n y
p r i v a t e )
I n t e r n a lH o s t
( t e l e c o m m u t i n g )
15
Distributed Firewall Implementation
• Language to express policies and resolving requests (KeyNote system)
• Mechanisms to distribute security policies (web server)
• Mechanism that applies security policy to incoming packet (Policy daemon and kernel updates)
16
KeyNote• A language to describe security policies (RFC 2704)• Fields in an “assertion”:
– KeyNote Version – Must be first field, if present
– Authorizer – Mandatory field, identifies the issuer of the assertion
– Comment– Conditions – The conditions under which the Authorizer trusts the Licensee
– Licensees – Identifies the authorized, should be public key, but can be IP address
– Local-Constants – Similar to environment variable
– Signature – Must be last, if present
• All field names are case-insensitive• Blank lines not permitted within an assertion
17
KeyNote Policies and Credentials
• Policies and Credentials have same basic syntax
• Policies are “local”• Credentials are “delegated” and MUST
be signed
18
KeyNote Example 1
19
KeyNote Example 2
KeyNote-Version: 2Authorizer: “rsa-hex:1023abcd”Licensee: “IP:158.130.6.141”Conditions: (@remote_port < 1024 &&
@local_port == 22 ) -> “true”;Signature: “rsa-sha1-hex:bee11984”
Note that this credential delegates to an IP address,
20
Distributed Firewall Implementation
• Not a complete solution, only a prototype
• Done on OpenBSD• Filters done in kernel space• Focused on TCP connections only
– connect and accept calls– When a connect is issued, a “policy
context” is created
21
User Space
• This design was not chosen because of the difficulty in “forcing” an application to use the modified library
• For example, “telnetd”, “ftpd”
22
Policy Context• Policy context contains all the information that the
Policy Daemon will need to decide whether to allow or disallow a packet
• No limit to the kind of data that can be associated with the context
• For a connect, context will include ID of user that initiated the connection, the destination address and destination port.
• For an accept, context will include similar data to connect, except that the source address and source port are also included
23
Implementation Design
24
Policy Daemon• User level process that makes all the decisions
based on policies• Initial policies are read from a file• Current implementation allows changes to policies
but changes only affect “new” connections• A host that does not run this daemon is not part of
the “distributed firewall”
25
Policy Device
• /dev/policy – pseudo device driver• Communication path between the Policy
Daemon and the “modified” kernel• Supports standard operations: open, close, read, write, ioctl
• Independent of type of application
26
Example of Connection to a Distributed Firewall
• local host security policy:KeyNote-Version: 2
Authorizer: “POLICY”
Licensees: ADMINISTRATIVE_KEY
• Assumes an IPSEC SA between hosts
27
Example of Connection to a Distributed Firewall
• Credential provided to local host during IKE exchange
KeyNote-Version: 2
Authorizer: ADMINISTRATIVE_KEYLicensees: USER_KEYConditions:
(app_domain == "IPsec policy" &&encryption_algorithm == "3DES" &&local_address == "158.130.006.141")
-> "true";(app_domain == "Distributed Firewall" &&@local_port == 23 &&encrypted == "yes" &&authenticated == "yes") -> "true";
Signature: ...
28
Example of Connection to a Distributed Firewall
R e m o t e H o s t
lo c a l h o s t1 5 8 .1 3 0 .6 .1 4 1
( r u n n in g P o l ic yD a e m o n )
IP S E C S A
T C P c o n n e c t ( 2 3 )c o n t e x t c r e a t e d
lo c a l p o r t = 2 3e n c r y p t e d = " y e s "
a u t h e n t ic a t e d = " y e s "
P o l ic y D a e m o nc h e c k s c o n t e x t
v s .c r e d e n t ia l
c o n t i n u e T C Ps e s s i o n
R e t u r n s T R U E
29
Conclusions• Distributed firewalls allows the network security policy
to remain the control of the system administrators• Insiders may no longer be unconditionally treated as
“trusted”• Does not completely eliminate the need for traditional
firewalls• More research is needed in this area to determine
robustness, efficiency, and scalability
30
Future Work
• High quality administration tools NEED to exist for distributed firewalls to be accepted
• Allow per-packet scanning as opposed to per-connection scanning
• Policy updating and revocation• Credential discovery
31
Questions
Top Related