Domain and Type Enforcement Firewalls Karen Oostendorp, Lee Badger, Christopher Vance, Wayne Morrison, Michael Petkac, David Sherman, Daniel Sterne Trusted Information Systems Inc. The Annual Computer Security Applications Conference (ACSAC) December, 1997 Presented by Chris 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

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 Server 4.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