Domain and Type Enforcement Firewalls

1. 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

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

3. 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!

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

5. 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

6. DTE Firewall Concept

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

8. Controlling Exported Services Specific to the protocol Attributes assigned by Firewall Non-DTE Determines if Comm. Is allowed

9. Proxy Algorithm • Extract Client Attributes • Attributes are available in each IP message • Optionally Authenticate • If non-DTE, uses configured method • If DTE, may trust UID • Connect to Server • Pass Data and DTE attributes bidirectional • May choose to block data based upon attributes

10. Controlling Imported Services 1.) Prevents attack on client 2.) labels data with trust identifier Relays DTE attributes

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Raw Performance in Seconds

18. 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

19. NFS Test Results Larger numbers indicate better performance

20. 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

21. 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

22. 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