Implementing a Distributed Firewall - Computer...

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


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




1



W e b s e r v e r


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




1



W e b s e r v e r


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




1



W e b s e r v e r


p r i v a t e )


( t e l e c o m m u t i n g )

13

Distributed Firewall Example to web server





1



W e b s e r v e r


p r i v a t e )



14

Distributed Firewall Example to intranet





1



W e b s e r v e r


p r i v a t e )



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


• 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


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

Implementing a Distributed Firewall - Computer...

Documents

Transcript of Implementing a Distributed Firewall - Computer...