Transcript ppt

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 tableoriented 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 nonDTE hosts
Controlling Exported Services
Attributes
assigned by
Firewall
Non-DTE
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
1.) Prevents attack on client
2.) labels data with trust
identifier
Relays
DTE
attributes
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 lowperformance 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: manuallyadministered 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