Ramanujan by jizhen1947


									Randomized Failover Intrusion-
Tolerant 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
l   Objective
     ä Demonstrate viability of randomized failover concept for building
       survivable network applications
l   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”
        n large failover space makes it difficult for attacker to acquire

          knowledge of system state needed to adapt attack
l   Focus on network borne denial-of-service attacks
     ä Flooding (packet, service request)
     ä Host takedown
Project Introduction (Cont’d)

l   Accomplishment to date
    ä Developed handbook of survivability design patterns
       n Survivable information transport services

       n Survivable server groups

    ä Applied selected design patterns to develop VPNshield
    ä Completed prototype implementation of VPNshield
       n Demo at DARPAtech 2002

       n Network 2002 paper

    ä Completed initial prototype of FlowShield
    ä Developed design of DoS-resistant JMS
    ä Participated in Peer Review Validation of VPNshield
FlowShield Design Goals

                   l   Protect mission-critical
                       information flows from flooding
                       DoS attacks
                        ä protection on per packet flow
                        ä guaranteed share of access
                          link bandwidth for protected
                          packet flows
                        ä application transparent
                        ä no changes to existing core
                          network infrastructure
                   l   Supplement infrastructure
                       based DDoS defenses
FlowShield Approach Overview
                    l   Packet flows are uniquely
                        identified by their flow labels (
                        source IP addr., dest. IP
                    l   For each protected flow, the
                        FlowShield endpoint reserves a
                        fraction of the access link
                    l   Upon detection of a flooding
                        attack, FlowShield endpoints
                        “transmute” the label of the
                        protected flow
                    l   Access link reservation for old
                        flow label is canceled.
                        Reservation installed for new
FlowShield: Appliance Based

l   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)

l   FlowShield POP appliance(s) associated with each edge appliance
     ä   serves as tunnel concatenation device
Assumptions About Threat Environment

l   Flooding attacks are launched from the edge of the
    shared, public network. Attacker does not have access
    to core of the shared network.
l   Shared secrets between FlowShield appliances are
    adequately protected against compromise
l   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
l   The Java Message Service (JMS) specification defines a messaging
    interface for Java applications.
     ä It supports both queuing and publish/subscribe.
l   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.
l   Such attacks may not be visible at the network level
     ä “Life-cycle” attacks
     ä Rogue JMS client planted by insider
        n   Access control may not prevent attacks
    ä Programming errors
    Example JMS Implementation

JMS Denial of Service Attack

JMS Channel Partitioning
JMS Channel Partitioning
l   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
l   Other message service clients continue to function
    ä Clients communicating through other aliases for T
    ä New clients requesting topic for “T” from other hosts
l   Why does this work?
    ä Each client is segregated into a distinguishable topic, which can
      be invalidated selectively.
l   This defense is also effective for message queues.
Distributed JMS with Local Topic Aliases

                    Message               Y manages
                    to T                  topic T

     to T2

                              from T4
Conclusion and Future Plans

l   Demonstrated application of RFITS survivability design
    patterns to protect information flows at different levels of
    ä aggregated flows (VPNshield)
    ä individual flows (FlowShield)
    ä pub/sub messaging (DoS-resistant JMS)
l   Planned work
    ä Prototype implementation of FlowShield appliances
    ä FlowShield customization for CECOM SMS
    ä Refine and extend design of DoS-resistant JMS

To top