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



Overview

• Objectives and Assumptions

• System Design– Fingerprint Masking

– Transaction Assignment

– Configuration Management

• Tolerance Modeling

• Status and Near-Term Plans



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



System Design



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



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



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



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



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



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



Transaction Assignment

Gateway


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



Configuration Management

Config Manager Origin Server

CM AgentConfiguration Management

Routines

Gateway


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



Modeling Attack Tolerance



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



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



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



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



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)



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)



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



Summary



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

darpa oasis pi meeting – norfolk – february 13-16, 2001slide 1 aegis research corporation...

Documents