Transcript Ranga Ramanujan - Tolerant Systems

Randomized Failover IntrusionTolerant Systems (RFITS)
Ranga Ramanujan, Maher Kaddoura, Carla Marceau,
Clint Sanders, Doug Harper, David Baca
Architecture Technology Corporation (ATC)
ATC-NY (formerly Odyssey Research Associates)
DARPA OASIS PI Meeting
August 20, 2002
Project Introduction



Objective
 Demonstrate viability of randomized failover concept for building
survivable network applications
What is randomized failover?
 Approach for system survivability based on the notion that
attackers can be thwarted by making the failover process
invoked by the system upon detection of an attack appear
unpredictable or “random”
 large failover space makes it difficult for attacker to acquire
knowledge of system state needed to adapt attack
Focus on network borne denial-of-service attacks
 Flooding (packet, service request)
 Host takedown
Project Introduction (Cont’d)

Accomplishment to date
 Developed handbook of survivability design patterns
 Survivable information transport services
 Survivable server groups
 Applied selected design patterns to develop VPNshield
 Completed prototype implementation of VPNshield
 Demo at DARPAtech 2002
 Network 2002 paper
 Completed initial prototype of FlowShield
 Developed design of DoS-resistant JMS
 Participated in Peer Review Validation of VPNshield
FlowShield Design Goals

Site 2
Protect mission-critical
information flows from flooding
DoS attacks
 protection on per packet flow
basis
 guaranteed share of access
link bandwidth for protected
packet flows
 application transparent
 no changes to existing core
network infrastructure
Flow 1
Internet
Flow 3
Site 1
Flow 2
Access Link

Site 3
Supplement infrastructure
based DDoS defenses
FlowShield Approach Overview

Attackers
FEP 2
X1
X2
PER 3
PER 4
PER 2
Internet


= Flow Shield
endpoint (FEP)
PER 1
= PE Router

= Attack traffic source
FEP 1
Packet flows are uniquely
identified by their flow labels (
source IP addr., dest. IP
address)
For each protected flow, the
FlowShield endpoint reserves a
fraction of the access link
bandwidth
Upon detection of a flooding
attack, FlowShield endpoints
“transmute” the label of the
protected flow
Access link reservation for old
flow label is canceled.
Reservation installed for new
label
FlowShield: Appliance Based
Implementation
FS POP
(Client)
Server
FS POP
(Client)
Client
Local
Network
CE Router
FS Appliance
Internet
PE Router
PE Router
Local
Network
CE Router
FS Appliance
Client
FS POP
(Server
)

FS POP
(server
)
FlowShield appliance at boundary of edge network embeds mechanisms for
 detection of flooding attacks
 flow label transformation and link re-provisioning
FlowShield: Appliance Based
Implementation (Cont’d)
FS POP
(server
)
FS POP
(Server
)
Serve
r
Client
Local
Network
FS Appliance
CE Router
PE Router
Internet
PE Router
Local
Network
CE Router
FS Appliance
FS look-up
service
FS POP
(Client)
Tunnel: Client to server
FS POP
(Client)
Tunnel: server to Client

FlowShield POP appliance(s) associated with each edge appliance
 serves as tunnel concatenation device
Assumptions About Threat Environment



Flooding attacks are launched from the edge of the
shared, public network. Attacker does not have access to
core of the shared network.
Shared secrets between FlowShield appliances are
adequately protected against compromise
Volume of traffic may be sufficient to inundate access
link but not sufficient to disrupt operation of service
provider network
Applying RFITS Techniques to Protect
JMS from Flooding Attacks



The Java Message Service (JMS) specification defines a messaging
interface for Java applications.
 It supports both queuing and publish/subscribe.
Message-based applications are vulnerable to denial of service
attacks at the messaging level.
 Attacker can flood message service with spurious messages.
 Prevents application from acting on real messages.
Such attacks may not be visible at the network level
 “Life-cycle” attacks
 Rogue JMS client planted by insider

Access control may not prevent attacks
 Programming errors
Example JMS Implementation
J
N
D
I
JMS Client
Application
J
M
S
Service
Provider
Service Center
JVM
Client Host
Provider Host
JMS Denial of Service Attack
Clients
C1
C2
C3
C4
C5
Message
flood
Topic
Service Center
JMS Channel Partitioning
Clients
C1
C2
C3
C4
C5
T1
T2
T3
T4
T5
Topic
aliases
Topic
T
Service Center
JMS Channel Partitioning

To survive DOS attack by client
When client requests topic for “T” through JNDI interface, assign
alias topic Tk instead of T itself.
 Maintain the Tk  T partition mapping at the service center.
 If client launches DOS attack on topic Tk, invalidate topic Tk and
refuse new topic requests from client host associated with topic
Tk.

Other message service clients continue to function
 Clients communicating through other aliases for T
 New clients requesting topic for “T” from other hosts

Why does this work?
 Each client is segregated into a distinguishable topic, which can
be invalidated selectively.

This defense is also effective for message queues.
Distributed JMS with Local Topic Aliases
Message
to T
C1
Service Center
X
T
Y manages
topic T
Service Center
Y
T2
C2
Message
to T2
C3
Service Center
Z
T4
C4
Delivered
from T4
C5
Conclusion and Future Plans

Demonstrated application of RFITS survivability design
patterns to protect information flows at different levels of
granularity
 aggregated flows (VPNshield)
 individual flows (FlowShield)
 pub/sub messaging (DoS-resistant JMS)

Planned work
 Prototype implementation of FlowShield appliances
 FlowShield customization for CECOM SMS
 Refine and extend design of DoS-resistant JMS