Transcript Intrusion Tolerance Using Masking, Redundancy

Aegis Research Corporation
Intrusion Tolerance Using
Masking, Redundancy and Dispersion
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Janet Lepanto
William Weinstein
The Charles Stark Draper Laboratory, Inc.
Aegis Research Corporation®
Aegis Research Corporation
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 1
Overview
Aegis Research Corporation
•
Objectives and Assumptions
•
System Design
–
–
–
–
•
•
•
Overview
Server Configuration Policy
Configuration Monitoring
Transaction Mediator
Testing
Demonstration
Status and Near-Term Plans
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
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 presence 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 – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 3
Aegis Research Corporation
System Design Overview
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 4
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 – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 5
Basic Architecture-Phase 2
Aegis Research Corporation
Configuration
Manager
Gateway
Server
(2)
Server
(N)
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Switched IP
External
Firewall
Switched IP
External WAN
Server
(1)
Transaction
Mediator
Data
Base
Trusted
COTS
Other
Slide 6
Configuration Management
Aegis Research Corporation
Manages Gateway operation
Determines servers in active set
Manages operation of CM Agent
Controls local IP switch
Functions as a client only
Controls server utilization by updating “use/don’t
use” status in Gateway
Config Manager
Origin Server
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 – Santa Fe – July 24–27, 2001
Daemon, tailored to origin server OS
Monitors server config info as directed by CM
Executes algorithms on origin server,
(directory searches, hash calculations, etc.)
Reports status and transfers requested data to CM
Not for Public Release
Slide 7
Origin Server Configuration Policy
Aegis Research Corporation
•
Explicitly bind the http daemon and the CM agent to the external interface
– Don’t allow direct access from localhost to either one of the ports
– This prevents an attacker from hijacking the server port without killing the
existing server daemon
•
Run HTTP daemon as “nobody” (or the equivalent)
– Don’t run daemon as root
– Don’t allow “nobody” shell access
– This prevents an attacker from gaining immediate root privileges
•
Run CM Agent daemon as root
– It needs most root privileges anyway, and giving it an account name would
potentially make it easier to find
•
Configure server-side scripts (cgi-bins) as read/execute only
•
Don’t allow execution from the temp directory
•
Don’t allow user-level processes to access RAM directly
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 8
Server -Side Scripting Policy
Aegis Research Corporation
•
All operational data is maintained on the back-end database server
– All origin servers must remain functionally equivalent
– No client transaction data can persist on an origin server outside the duration of
the transaction
– Because server-side scripts are constrained this way, they have no need to invoke
root-level functions
•
Server-side scripts
– Will move data to and from the back-end servers via Transaction Monitor proxies
• File operations
• ODBC commands
– Access and user authentication
• Via web server
• Via native database access management
•
Back-end server administration
– Done directly on servers
– Mediator can be configured to block administrative database operations
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 9
CM Agent – Data Flows
Aegis Research Corporation
Monitor & Control Flags
and Reference Data
Commands &
reference data
from CM
Other info between
Exec and Monitors
CM Agent on Origin Server
MUTEX
Executive
Thread
Input
Buffer
Heartbeat msg
Shared Buffer
Shared
Memory
Other Exec
msgs to CM
CM Interface
Thread
MUTEX
MUTEX
Output
Buffer
Config
Man
Tier 1 Monitor
Thread
Shared
Memory
Tier 2a Monitor
Thread
Shared
Memory
Tier 2b Monitor
Thread
Shared
Memory
Tier 3 Monitor
Thread
Shared
Memory
Configuration
check results
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 10
Tier 1 Monitor
Aegis Research Corporation
•
Origin server active
Period ≈ 1 second
Checks
– Selected processes for proper name, status and PID value
• Use process config file to specify which process must be present (normal http daemon, agent
daemon, and maybe others) and which other processes are allowed
• Use direct invocation of system calls for process ID, status checks and running privileges
(this also validates that the server is running as “nobody”)
•
Response to check fail
– Specified in tier 1 config file (per each process) — responses include
• Leave server operating, invoke tier 2b check directly
• Take server off-line, invoke tier 3 check
•
Rationale
– Attempts to subvert the web server daemon or the monitoring agent processes will be
detected rapidly, before additional transactions occur that could allow further
exploitation
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 11
Tier 2a Monitor
Aegis Research Corporation
•
Checks
– Certain portions of the directory structure
•
•
•
•
•
Origin server active
Period ≈ 10 seconds
Server-side script files, html server files, certain system files
All necessary files present, no extraneous files present
Verify mod times on files
Verify server configuration parameters
– Server-side scripts are read/executable only
– Temp directory scripts are read/write only
Response to failure check
– Take off-line and check logs to see if config changes were made by sys admin
•
Rationale
– Monitors for most likely points of exploitation and also picks up inadvertent
configuration changes by a system administrator
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 12
Tier 2b Monitor
Aegis Research Corporation
Origin server active
Period ≈ 5-10 minutes
•
Checks
– Hash of core files from Tier 2a
– Verify server configuration parameters
• Binding of http parent daemon to external interface
• User “nobody” has no shell access
•
Response to failure check
– Take off-line and do full tier 3 checks
•
Rationale
– Fairly frequent and thorough check of critical files for subtle changes
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 13
Tier 3 Monitor
Aegis Research Corporation
Origin server inactive
Period ≈ 1 hour or more
•
Checks
– Full forensics, memory and file checkout
• Hash check all files
• Dump and check memory
•
Response to failure check
– Determine whether database might need recovery
– Scrub the platform
•
Rationale
– Detect whether a sophisticated attack has occurred and what damage
might have been done
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 14
Back-end Operations
Aegis Research Corporation
COTS
Configuation Manager
OASIS Developed
User Developed
Origin Server
Comms interface to Trans Monitor
App
Server
Interface
Proxy
File
Server
Interface
Proxy
Comms interface
to Origin Servers
& Config Man
Back-end
App Server
Interface
ODBC
Manager
Interface
Proxy
Back-end App Servers
Applications
Back-end File Servers
Back-end
File Server
Interface
File System
Monitor
Proxy
Web Content
Static
Web
Pages
Transaction Mediator
Back-end Databases
Scripts
Web Server
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Transaction
Log
Database
ODBC
Driver X
SQL Database
(Brand X)
ODBC
Driver Y
SQL Database
(Brand Y)
ODBC
Manager
Not for Public Release
Slide 15
Proxying ODBC
Aegis Research Corporation
ODBC Manager
interface proxy
provides normal
ODBC manager
interface to CGI
scripts
Provides back half of ODBC
manager proxy—Manages
operation of mediator
COTS
Config Manager
OASIS Developed
User Developed
Origin Server
Transaction Mediator
Comms interface to
Trans Monitor
ODBC Manager
Interface Proxy
Comms interface
to Origin Servers
& Config Man
ODBC
Driver for
Brand X
Monitor
Proxy
ODBC
Manager
Transaction Log
Database
ODBC
Driver for
Brand Y
Back-end Databases
SQL Database
Server
(Brand X)
Web Content
Static
Web
Pages
Scripts
Web Server
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
CGI scripts produce SQL command
strings to access back-end database—
SQL flavor used depends on DB
product accessed (same as if Origin
Server accessed DB directly)
Not for Public Release
SQL Database
Server
(Brand Y)
Supports traceability of
ODBC commands to
Origin servers and backend database rollback
Slide 16
Multi-Tier Database Connectivity Standards
Aegis Research Corporation
•
Standard SQL: International Standards Organization (ISO) and
National Committee for Information Technology Standards (NCTIS)
recognize a standard dialect of SQL known as SQL-92, published under
similar and parallel standards ISO/IEC 9075-1992 and ANSI/NCTIS
X3.135, respectively. Sub-levels of compliance exist within SQL-92
(Entry, Standard, Advanced).
•
Call Level Interface: Call Level Interface (CLI) dates from 1995, and
provides a standard set of API bindings for compiling languages (C,
COBOL, Fortran, etc.) to guarantee portable execution of many SQL
commands. A product of the Open Group, CLI is now an ISO standard
extension of SQL (ISO/IEC 9075.3-1995).
•
Microsoft’s Open Database Connectivity (ODBC) extends most of the
features defined under CLI.
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 17
Aegis Research Corporation
System Testing
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 18
Verification Testing Approach
Aegis Research Corporation
•
Subject the system to known scanning tools to determine if the
mechanisms to thwart those scans are implemented properly
•
Subject the system to known attacks to evaluate how it reacts to
various types of attacks (e. g., measuring the relative time to
success for an attack directly on server X vs. the same attack on
server X operating in our OASIS architecture).
•
Subject the system to modifications of known attacks developed to
exploit knowledge of the architecture and operation of the system
•
Setup system as a honeypot to observe character of real attacks
and system response to those attacks
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 19
Verification Testing Status
Aegis Research Corporation
•
TCP/IP masking verification (Gateway and Origin Servers)
– Fingerprinting attempts unsuccessful (nmap, queso, p0f, siphon)
– Fingerprinting attempts using ICMP errors unsuccessful (ICMP Port
Unreachables)
•
Proxy Scrubbing Verification
– HTTP header cleanup successful
– Exception: Basic parameters of the HTTP request were cleaned,
except for the HTTP Version (HTTP/1.0)
•
Web page error documents
– Intentional requests for non existent documents (404 Errors) allows
enumeration of origin servers
•
Common Hacks Unsuccessful
– Whisker (Times out due to the transaction dispersion algorithm)
– Win NT Unicode Exploit (Due to a patched server)
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 20
Verification Testing Plans
Aegis Research Corporation
•
•
Explore other ICMP techniques to discover the OS
Explore Reaction to Common Hacks
– Whisker (We are modifying to ignore time settings and server
identification responses)
– WIN NT ISAPI Overflows
• Index Server/Unicode Overflow Variant (Currently developed to stop
http process, will be modified to gain privileges)
• Print Server (Can overflow stack, being modified to initiate outbound
trojan connections)
•
Explore attacks against content
– Content will be added to allow for a real world scenario test
– CGI scripts will be evaluated as a means of gaining access
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 21
Demonstration
Aegis Research Corporation
Gateway
Switched IP
OASIS
Santa Fe
Internet
Solaris 2.7
Apache 1.3.19
Windows 2000
Apache 1.3.19
Open BSD 2.8
Apache 1.3.19
Macintosh OS 9.1
Personal Web Server
•
•
Transaction Dispersion
HTTP Whitening
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 22
Program Status and Near-Term Plans
Aegis Research Corporation
•
Gateway w/redundant servers operating
–
–
–
–
•
Accessible over the Internet
Independent sniffer monitoring traffic between Internet and Gateway
Aegis conducting attack testing
Plan to make system available as a target (to other OASIS projects)
Server agents
– Common structure is designed
– Coding underway for Unix and NT versions
•
Transaction Monitor
– Basic structure designed
– ODBC proxy mechanism being implemented
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 23
Task Schedule
Aegis Research Corporation
Task Name
Phase 1 – Basic Architecture
CY 2000
7
10
CY 2001
1
4
7
CY 2002
10
1
4
7
CY 2003
10
1
4
7
10
12
1.1 Dev & Implmt Fingerprint Masking
1.2 Dev & Implmt Dynamic Assign
1.3 Dev & Implmt Config Evalution
1.4 Integration & Experimentation
1.5 Program Management
2.1 Dev & Implmt Transaction Mediator
2.2 Dev & Implmt Assess & Rollback
2.3 Integration & Experimentation
2.4/3.6 Dev Sync of Redundant Databases
2.5 Program Management
Phase 2 – Extended Architecture
3.1 Refine Fingerprint & Dynam Assign
3.2 Implement Sync & Voting
3.3 Refine Config Assessment
3.4 Integration & Experimentation
3.5 Program Management
4.1 Refine Sync & Voting
4.2 Implmt Distribution of Servs & DBs
4.3 Integration & Experimentation
4.5 Program Management
DARPA OASIS PI Meeting – Santa Fe – July 24–27, 2001
Not for Public Release
Slide 24