DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001Slide 1 Aegis Research Corporation...
-
Upload
jean-marshall -
Category
Documents
-
view
216 -
download
0
Transcript of DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001Slide 1 Aegis Research Corporation...
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 1
Aegis Research Corporation
Intrusion Tolerance UsingMasking, 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 CorporationAegis Research Corporation
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 2
Aegis Research Corporation
Overview
• 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 3
Aegis Research Corporation
Objectives and Assumptions
• 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 4
Aegis Research Corporation
System Design
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 5
Aegis Research Corporation
Basic ArchitectureE
xter
nal
WA
N
ExternalFirewall
DataBase
TransactionMediator
Gateway
Sw
itch
ed I
P
Server(1)
Server(N)
Server(2)
Configuration Manager
Authenti-cationServer
Sw
itch
ed I
P
COTS
Trusted
Other
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 6
Aegis Research Corporation
Technical Approach
• 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 7
Aegis Research Corporation
Basic Architecture-Phase 1E
xter
nal
WA
N
ExternalFirewall
DataBase
TransactionMediator
Gateway
Sw
itch
ed I
P
Server(1)
Server(N)
Server(2)
Configuration Manager
Authenti-cationServer
Sw
itch
ed I
P
COTS
Trusted
Other
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 8
Aegis Research Corporation
ProxyDaemons
ProxyDaemons
Front-End Operations
Configuration Manager Origin ServerGateway
CM AgentConfiguration Management
Routines
Gateway Control Daemon
ExtH/WPort
IntH/WPort
HTTP ServerExternal Client
ProxyDaemons
Gateway is dual-homed: one port for the external network, the other port for the internal network
Modified Open BSD masks OS fingerprint
Operating System
Operating System
Masks Origin Server fingerprints
Assigns transactions to Origin Servers
Evaluates origin server config& provides status to Gateway
Supports CM in server evaluation process
Operating System
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 9
Aegis Research Corporation
Masking of Gateway Op Sys
Gateway
Operating System - OpenBSD 2.7 -
Modified Kernel
OpenBSDFirewall
Drop Packets withSource routingIP optionsSYN, FIN, URG and PSHInsufficient lengthNon-routable addresses
AllowHTTP, FTP, Telnet, Echo,
Mail, SSH, DNSAny outbound connections
DropEverything else
TCP Initial Window SizePrimary feature used by fingerprinting toolsReduce IWS (randomly)
TCP Window Size on RSTMeaning of window size undefined in this caseGenerate arbitrary window size
TCP Option OrderingRandomize option ordering
ICMP Error QuoteReplicate the normally invalid IPLEN field in
“port unreachable” response(Not expected unless firewall misconfigured)
ICMP Error Quote LengthIncrease 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 ModificationsRandomize Time-To-LiveSet “Don’t Fragment Flag”Set TOS to 0x00
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 10
Aegis Research Corporation
Masking of Origin Server Application
Gateway
HTTP ServerExternalClient
ProxyDaemon
HTTP Masking Algorithm
Process requests – normalize content to mitigate probesRespond directly to client if request method is not supported by systemRespond 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
Process responses – normalize format and content so servers appear identicalRemove non-functional (information only) headers (e. g., Server)Replace “reason phrase” with canonical text for each status codeAssure common header orderingEdit certain header parameters to remove indications of capabilities not common to all origin serversFlush response entirely and respond to client with an appropriate status code
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
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 11
Aegis Research Corporation
Transaction Assignment
Gateway
Gateway Control Daemon
HTTP ServerProxy
Daemon
Accepts assignment requests from proxy daemonsThese contain client IP address and destination port from client request
Decides which server should handle each requestBased on current server status, andRecent history of assignments to that client
Returns IP address of target server to requesting proxyAccepts and processes transaction disposition from proxy
Forward transaction failure information to Configuration Manager
Maintains history of client assignments to each serverHistory is reset when server is returned to active status following inspection
Gets server assignment from control daemonForwards client request to that origin serverProcesses origin server responseReports disposition to control daemon
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
Assignment Algorithm
ExternalClient
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 12
Aegis Research Corporation
Configuration Management
Config Manager Origin Server
CM AgentConfiguration Management
Routines
Gateway
Gateway Control Daemon
Agent is daemon, tailored to origin server OSGathers server config info as requested by CM
Executes algorithms on origin server,(directory searches, hash calculations, etc.)
Transfers anomalous files to CM when requested
Continually checks for agent integrityHash of CM Agent code
Controls local IP switchFunctions as a client only
Modes Gateway operationDetermines servers in active set
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
Origin Server Configuration
Templates
Structure of file system directory hierarchyExistence of specific files in specific directoriesHash integrity check of specific filesConfiguration data is dependent on server OS
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 13
Aegis Research Corporation
Modeling Attack Tolerance
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 14
Aegis Research Corporation
Quantitative Metrics
• 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 15
Aegis Research Corporation
Assumptions
• 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 16
Aegis Research Corporation
Attack State Model
M ordered transactions must occur on a given vulnerable server within time T
Clean Server
Serversclean
Server x with transaction 1
Server x with transactions 1 –> (M-1)
0
M-11
M
Server x with transactions 1 –> M
Clean Server
Transaction 1 Transaction M• • •
TimeT0
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 17
Aegis Research Corporation
Combinatorial Approach
P statei statei-1 1 n 1
n
TriCN
• P statei-1
Where:Tri = rate of “ith” transactionN = number of servers in the active setC = average time to check a server for anomalies and clean it up (if necessary)
Clean Server
Serversclean
Server x with transactions 1 –> i - 1
Server x with transactions 1 –> i
0 ii - 1
M
Server x with transactions 1 –> M
Clean Server
• • • • • •Transaction i
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 18
Aegis Research Corporation
Markov Approach (1)
Model parametersTri = rate of “ith” transactionN = number of servers in the active setC = average time to check a server for anomalies and clean it up (if necessary)
Tr1•1/N
1/(C•N)
Servers(clean)
Server i with transaction 1
Server i with transactions 1 –> (M-1)
TrM-1•1/N
1/(C•N)
TrM•1/N0
M-11
M
Server i with transactions 1 –> M
1 of a set of N servers is vulnerable to specific attack
P(successful attack) = P(state M at time t ≤ C•N)
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 19
Aegis Research Corporation
Markov Approach (2)
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
Server 1 with transactions 1 –> (M-1)
Server 1 with transactions 1 –> M
Tr1•1/N
1/(C•N)
Tr1•1/N
1/(C•N)
0
1k
11
M-1k
M-11
M
TrM-1•1/N
TrM-1•1/N
TrM•1/N
TrM•1/N1/(C•N)
1/(C•N)
DARPA OASIS PI Meeting – Norfolk – February 13-16, 2001 Slide 20
Aegis Research Corporation
Modeling Issues
• 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 no-op
• 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 22
Aegis Research Corporation
Status and Near-Term Plans
• 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