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 DTEs?

• 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 DTEs?

• 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
Relays DTE attributes
1.) Prevents attack on client 2.) labels data
with trust identifier
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