domain and type enforcement firewalls karen oostendorp, lee badger, christopher vance, wayne...

Domain and Type Enforcement Firewalls

Karen Oostendorp, Lee Badger, Christopher Vance, Wayne Morrison, Michael Petkac, David

Sherman, Daniel SterneTrusted Information Systems Inc.

The Annual Computer Security Applications Conference (ACSAC) December, 1997

Presented byChris Dion

Outline For Tonight

• Introduction• Domain and Type Enforcement review• DTE Firewall design and mechanisms• Evaluation of DTE firewall security• Related work/Future Directions• Conclusions

Internet Firewalls

• Conventional firewalls use simplistic inside vs. outside model

• Incompatible with business practices that require trust outside the firewall

• No protection from inside attacks and do not protect sensitive data

• We need a better way to protect inside networks!

What are DTE’s?

• An enhanced form of type enforcement (a table-oriented mandatory access control mechanism)

• Split logically into two categories:– Passive entities: files or network packets

• Associated with a type

– Active entities: processes• Associated with a domain, protected user identifier (UID)

• Access control decisions are made by consulting database to determine access

What are DTE’s?

• To extend protection across networks, DTE uses 3 attributes (carried in IP option)– The DTE Type of the information– Domain of the source process– DTE-protected User ID of the source process

• For non-DTE system compatibility, packets are assigned based upon source IP address

DTE Firewall Concept

DTE Firewall Concept

• As with a ‘normal’ firewall, DTE firewall intercepts network traffic between internal/external hosts

• If end host is DTE:– Passing along communication attributes

• For non DTE hosts:– Performs access control on behalf of the non-

DTE hosts

Controlling Exported Services

Non-DTE

Attributes assigned by Firewall

Determines if Comm. Is allowed

Specific to the protocol

Proxy Algorithm

1. Extract Client Attributes• Attributes are available in each IP message

2. Optionally Authenticate• If non-DTE, uses configured method• If DTE, may trust UID

3. Connect to Server4. Pass Data and DTE attributes bidirectional

• May choose to block data based upon attributes

Controlling Imported Services

Relays DTE attributes

1.) Prevents attack on client

2.) labels data with trust identifier

Network Services Evaluation• Evaluation of several network services running through a DTE

firewall:– rlogin– TELNET– Mail– FTP– NFS– HTTP

• Evaluation criteria considered:– Security– Preservation of functionality– Compatibility with non-DTE hosts– Performance

Security Evaluation

• Effectiveness of attacks is reduced if programs execute with the minimum access rights required

• Three primary areas where program auth. are reduced by DTE:– Confined proxies in a separate domain for each– Protected servers on the firewall

• Services can run on DTE firewall safely because of access rights

– Defense in depth• Prevent clients from tricking interior services into access

Functionality Evaluation

• For Importing services, functionality is rarely affected– User authentication can be supplied by the client DTE

system• For Exported services functionality increases

– No longer have to run server outside firewall– Can run behind firewall with the additional security of

running a server in a domain restricted according to trust level

Compatibility Evaluation

• Can operate either with DTE or non-DTE systems• Few changes to applications to function with DTE

firewalls, with the exception of the NFS server (kernel-resident in UNIX)

• Some services required administrative configuration– NFS clients must explicitly name the firewall host as

the server whose file systems behind firewall

Performance Evaluation

• Testbed setup:– 3 Pentium 166Mhz machines on isolated net– Running BSD/OS 2.0 with DTE prototype– Configuration is a triple (client, firewall,

server)• (n,y,n) indicates firewall running DTE, client and

server are non-DTE

Performance Evaluation

• For rlogin, TELNET, and FTP, use Expect script to authenticate a pass traffic (20 iterations)– Performance was at worst 13% degradation– Actually better when client running DTE, which passes

UID instead of authentication (except for FTP, which has its own)

• For HTTP, used ZeusBench which connects, retrieves web page, and disconnects– Approx. 50% slower in worst case due to a low-

performance implementation of DTE

Raw Performance in Seconds

NFS Performance

• Used two widely known benchmark packages (Iozone and NFSstones)

• Performance of writes moderately affected• Reads dominate NFS performance, with a

slowdown of 38% max.• Largely due to dual domain combination

and manipulation of additional file handles

NFS Test Results

Larger numbers indicate better performance

Related Work• 3 types of firewalls

– Packet-filtering– Circuit gateway (force TCP connections to go through

intermediary)– Application gateway (per-protocol basis)

• DTE can be added to all three, but incorporated into application gateways because of the protocol interaction

• Type enforcement is implemented on a number of systems, such as DTOS, XENIX, and Secure Ada Target

Future Directions

• This paper address first-phase: manually-administered DTE firewall

• Second phase is to allow dynamic updates to DTE modules and support interactions between non-identical policies

• Third phase will allow for a central administration of security policies

Conclusions

• Firewall perimeter security is relatively weak• DTE supports role-based policies that relate

resource access to individual responsibilities • Showed functionality stayed the same (and

increased for NFS), with performance hits that can be eliminated through optimization techniques

• Administrative costs are still an open issue