Transcript Intrusion Tolerance Using Masking, Redundancy

Aegis Research Corporation
Intrusion Tolerance Using
Masking, Redundancy and Dispersion
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Janet Lepanto
William Weinstein
The Charles Stark Draper Laboratory, Inc.
Aegis Research Corporation®
Aegis Research Corporation
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 1
Overview
Aegis Research Corporation
•
Objectives and Assumptions
•
System Design
– Fingerprint Masking
– Transaction Assignment
– Configuration Management
•
Tolerance Modeling
•
Status and Near-Term Plans
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 2
Objectives and Assumptions
Aegis Research Corporation
•
Objectives
– Apply fault-tolerant design concepts to support intrusion tolerance
– Minimize loss of data confidentiality and integrity in the face of a successful
attack on one of the servers
– Tolerate attacks whose specific signatures are not known a priori
– Employ only a small set of trusted components to protect a large set of untrusted
unmodified COTS servers and databases
– Employ redundancy for both intrusion tolerance and performance
•
Assumptions
– Attacker desires stealth so transaction rates will be relatively low
– Attacks employing high transaction rates and recognizable signatures will be
addressed by front-end firewalls and/or other intrusion detection mechanisms
– Exploitation of latent vulnerabilities will require more than a single transaction
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 3
Aegis Research Corporation
System Design
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 4
Basic Architecture
Aegis Research Corporation
Configuration
Manager
Gateway
Server
(1)
Server
(2)
Switched IP
External
Firewall
Switched IP
External WAN
Authentication
Server
Transaction
Mediator
Data
Base
Server
(N)
Trusted
COTS
Other
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 5
Technical Approach
Aegis Research Corporation
•
Mask fingerprints of gateway and origin servers so that an attacker
cannot probe over network to determine
– OS of gateway, or origin servers
– Implementation of any origin server
•
Distribute each client’s transactions among origin servers such that
the client cannot predict which server will handle a transaction
•
Periodically inspect each origin server for configuration anomalies
that might indicate that attack transactions have occurred
– Reconfigure server to “clean” state if anomalies are detected
•
Log transactions to back-end database so that data written by a
compromised origin server can be reconstructed
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 6
Basic Architecture-Phase 1
Aegis Research Corporation
Configuration
Manager
Gateway
Server
(1)
Server
(2)
Server
(N)
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Switched IP
External
Firewall
Switched IP
External WAN
Authentication
Server
Transaction
Mediator
Data
Base
Trusted
COTS
Other
Slide 7
Front-End Operations
Aegis Research Corporation
Evaluates origin server config
& provides status to Gateway
Assigns
transactions
to Origin
Servers
Masks Origin
Server fingerprints
External
Client
Ext
H/W
Port
Supports CM in server
evaluation process
Gateway
Configuration Manager
Origin Server
Gateway
Control
Daemon
Configuration
Management
Routines
CM Agent
Int
H/W
Port
Operating
System
Proxy
Proxy
Proxy
Daemons
Daemons
HTTP Server
Operating
System
Operating
System
Daemons
Modified Open BSD
masks OS fingerprint
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Gateway is dual-homed: one port for the external
network, the other port for the internal network
Slide 8
Masking of Gateway Op Sys
Aegis Research Corporation
TCP Initial Window Size
Drop Packets with
Primary feature used by fingerprinting tools
Reduce IWS (randomly)
Source routing
IP options
SYN, FIN, URG and PSH
Insufficient length
Non-routable addresses
Gateway
Allow
Operating System
- OpenBSD 2.7 -
HTTP, FTP, Telnet, Echo,
Mail, SSH, DNS
Any outbound connections
OpenBSD
Firewall
Drop
Everything else
TCP Window Size on RST
Meaning of window size undefined in this case
Generate arbitrary window size
TCP Option Ordering
Randomize option ordering
ICMP Error Quote
Replicate the normally invalid IPLEN field in
“port unreachable” response
(Not expected unless firewall misconfigured)
ICMP Error Quote Length
Modified Kernel
Increase quote size
Initial Testing
nmap correctly identified unmodified kernel as OpenBSD 2.6-2.7
nmap, Siphon, p0f failed to identify modified kernel
over several tests using randomized parameters
Possible Future Kernel Modifications
Randomize Time-To-Live
Set “Don’t Fragment Flag”
Set TOS to 0x00
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 9
Masking of Origin Server Application
Aegis Research Corporation
Process requests – normalize content to mitigate probes
Respond directly to client if request method is not supported by system
Respond directly to client if request contains inconsistencies
(e. g., undefined combinations of headers)
Edit out client-proposed capabilities that are not supported across all origin
servers before forwarding request to a server
Gateway
HTTP Masking
Algorithm
External
Client
Attacker can ID origin server by
exploiting latitude in RFC 2616
By actively probing a server with crafted
requests
Force a capability not supported on all
servers
Force an error response via
inconsistencies
By observing format and content of server
responses to both normal and crafted
requests
Proxy
Daemon
HTTP Server
Process responses – normalize format and content so servers appear identical
Remove non-functional (information only) headers (e. g., Server)
Replace “reason phrase” with canonical text for each status code
Assure common header ordering
Edit certain header parameters to remove indications of capabilities not common to all origin servers
Flush response entirely and respond to client with an appropriate status code
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 10
Transaction Assignment
Aegis Research Corporation
Accepts assignment requests from proxy daemons
These contain client IP address and destination port from client request
Decides which server should handle each request
Based on current server status, and
Recent history of assignments to that client
Transaction is assigned randomly to an
active origin server other than the one
which last serviced a request for that
particular client IP/port combination
Returns IP address of target server to requesting proxy
Accepts and processes transaction disposition from proxy
Forward transaction failure information to Configuration Manager
Maintains history of client assignments to each server
History is reset when server is returned to active status following inspection
Gateway
Assignment
Algorithm
External
Client
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Gateway
Control
Daemon
Proxy
Daemon
Gets server assignment from control daemon
Forwards client request to that origin server
Processes origin server response
Reports disposition to control daemon
HTTP Server
Slide 11
Configuration Management
Aegis Research Corporation
Modes Gateway operation
Determines servers in active set
Continually checks for agent integrity
Hash of CM Agent code
Controls local IP switch
Functions as a client only
Controls server utilization by updating “use/don’t
use” status in Gateway
Periodically makes each server inactive
and inspects it for anomalies
Via CM agent on that server
Gateway
Config Manager
Origin Server
Gateway
Control
Daemon
Configuration
Management
Routines
CM Agent
Origin Server
Configuration
Templates
Structure of file system directory hierarchy
Existence of specific files in specific directories
Hash integrity check of specific files
Configuration data is dependent on server OS
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Agent is daemon, tailored to origin server OS
Gathers server config info as requested by CM
Executes algorithms on origin server,
(directory searches, hash calculations, etc.)
Transfers anomalous files to CM when requested
Slide 12
Aegis Research Corporation
Modeling Attack Tolerance
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 13
Quantitative Metrics
Aegis Research Corporation
•
Empirical Metrics
– Percent of successful Red Team attacks
– Impact of ITS mechanisms on system performance
•
Predictive Metrics
– Effectiveness of dispersion mechanism
• Probability of successful attack against a given vulnerability as a function
of attack rate, server cleaning rate, number of transactions required, and
number of servers
– Effectiveness of rollback mechanism
• Probability of data recovery given a successful attack
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 14
Assumptions
Aegis Research Corporation
•
Gateway is “trusted” and not vulnerable to TCP/IP level attacks
•
Gateway provides a proxy between the external client and the Origin Servers, so
– TCP level attacks should not propagate to Origin Servers
– Attacks on Origin Servers must originate within proxied application-level protocols
– While Gateway may “clean up” inbound messages at the application level as part of
server “whitening”, it does not attempt to detect attack signatures
•
Initial system implementation will support HTTP/1.1
– Origin Servers contain a web server, static HTML pages and CGI scripts for
create web pages dynamically and communicating with a back-end database
– Attacks against Origin Servers must begin at the application level, against
web server or CGI scripts
•
Attacker may learn the theory and general structure of the system via side channels
– However, attacker cannot determine specific state of system at any time,
and thus cannot predict which server will handle a given request
•
Attacker desires stealth so transaction rates will be relatively low
– Attacker is nonetheless persistent, and will continue to attempt
to compromise system over a long period of time
– Attacks employing high transaction rates and recognizable signatures will be
addressed by front-end firewalls and/or other intrusion detection mechanisms
•
Exploitation of latent vulnerabilities on a server will require multiple transactions
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 15
Attack State Model
Aegis Research Corporation
M ordered transactions must occur on a given vulnerable server within time T
Servers
clean
0
Server x with
transaction 1
1
Transaction 1
• • •
Server x with
transactions 1 –> (M-1)
Server x with
transactions 1 –> M
M1
M
Transaction M
Clean Server
Clean Server
0
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Time
T
Slide 16
Combinatorial Approach
Aegis Research Corporation
Servers
clean
0
Server x with
transactions 1 –> i - 1
Server x with
transactions 1 –> i
i-1
i
• • •
Transaction i
Server x with
transactions 1 –> M
• • •
M
Clean Server
Clean Server
 n  1Tri CN 

P state i state i-1  

• P state i-1
1  



n


Where:
Tri = rate of “ith” transaction
N = number of servers in the active set
C = average time to check a server for anomalies and clean it up (if necessary)
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 17
Markov Approach (1)
Aegis Research Corporation
1 of a set of N servers is vulnerable to specific attack
P(successful attack) = P(state M at time t ≤ C•N)
Servers
(clean)
0
Server i with
transaction 1
Tr1•1/N
1
1/(C•N)
Server i with
Server i with
transactions 1 –> (M-1) transactions 1 –> M
TrM-1•1/N
M1
TrM•1/N
M
1/(C•N)
Model parameters
Tri = rate of “ith” transaction
N = number of servers in the active set
C = average time to check a server for anomalies and clean it up (if necessary)
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 18
Markov Approach (2)
Aegis Research Corporation
K of a set of N servers are vulnerable to specific attack
P(successful attack) = P(state M at time t ≤ C•N)
Servers
(clean)
Server 1 with
transaction 1
1/(C•N)
11
Tr1•1/N
Server 1 with
transactions 1 –> (M-1)
TrM-1•1/N
Server 1 with
transactions 1 –> M
M-11
TrM•1/N
1/(C•N)
0
M
1/(C•N)
Tr1•1/N
1/(C•N)
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
TrM•1/N
1k
TrM-1•1/N
M-1k
Slide 19
Modeling Issues
Aegis Research Corporation
•
•
Distribution of transaction arrival times
Sequence of attack transactions
– Feedback to attacker from transaction responses
• At what point in required sequence does the response from a transaction provide
useful feedback w.r.t. that transaction
– Impact of out-of-order transactions on attack culmination
• Case 1 – Occurrence of transaction j > i prior to transaction i behaves like a noop
• Case 2 – Occurrence of transaction j > i prior to transaction i impacts attack
• At what point in sequence is order of transactions arbitrary
•
•
•
Mathematical representation of cleaning process
Multiple identical servers
Bounding modeling errors
– Need to calibrate approaches against an event-based simulation
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 20
Aegis Research Corporation
Summary
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 21
Status and Near-Term Plans
Aegis Research Corporation
•
OS masking
– Coded and tested stand-alone
•
Gateway proxy, control daemon, and HTTP masking
– Coded
•
Configuration Manager
– Code expected mid-March
•
Integrated test planned for March 2001
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001
Slide 22