Towards an Integrated Multimedia Service Hosting Overlay   Dongyan Xu , Xuxian Jiang Department of Computer Sciences  Cent...
Outline <ul><li>Motivation </li></ul><ul><li>MSODA architecture  </li></ul><ul><li>MSODA components </li></ul><ul><li>Virt...
Motivation <ul><li>Proliferation of value-added and function-rich media services </li></ul><ul><ul><li>Pervasive media sou...
Motivation <ul><li>Service oriented architectures </li></ul><ul><ul><li>Users don’t have to know </li></ul></ul><ul><ul><u...
Motivation <ul><li>Service  providers  meet service  host </li></ul>Service providers: Have no infrastructure  For deploym...
Challenges <ul><li>Decoupling  service  management from  hosting platform  management </li></ul><ul><li>Isolating manageme...
Our Solution: MSODA  (Media Service On-Demand Architecture)   <ul><li>Infrastructure: MSODA hosts in wide-area network  </...
MSODA Architecture Service  gateway MSODA host Service  Instance (VM)
MSODA Host  <ul><li>Two-level architecture </li></ul><ul><ul><li>Host  </li></ul></ul><ul><ul><li>Virtual machines  </li><...
MSODA Gateway <ul><li>Interface to service clients </li></ul><ul><ul><li>Service composition </li></ul></ul><ul><ul><li>Se...
MSODA Gateway <ul><li>Service composition and configuration </li></ul><ul><ul><li>User-centric customization </li></ul></u...
Media Service Cloud  <ul><li>A virtual network of service instances (VMs) </li></ul><ul><ul><li>Based on network virtualiz...
Media Service Cloud <ul><li>Advantages </li></ul><ul><ul><li>Protection of MSODA infrastructure </li></ul></ul><ul><ul><ul...
Media Service Cloud <ul><li>Multicast and anycast group for each media service </li></ul><ul><ul><li>Multicast group: conv...
Media Service Cloud <ul><li>Dynamic service cloud evolution </li></ul><ul><ul><li>Service instance resource scaling </li><...
MSODA Prototype <ul><li>Service instances (VMs) enabled by User-Mode Linux (UML) </li></ul><ul><li>Service cloud (virtual ...
Related Work <ul><li>Service composition frameworks </li></ul><ul><ul><li>Ninja, SAHARA, CANS, SPY-Net, SpiderNet </li></u...
Conclusions <ul><li>MSODA: an integrated media service hosting platform for service composition </li></ul><ul><li>Virtual ...
Thank you. For more information: Email:  {d xu,  jiangx}@cs.purdue.edu URL:  www.cs.purdue.edu/~dxu Google:  “ Purdue SODA...
Upcoming SlideShare
Loading in...5
×

MSODA.ppt

564

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
564
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hello, everyone. I am going to present a virtual-machine-based architecture for network attack detention center called Collapsar. My name is Xuxian Jiang from Purdue University. This is joint work with my advisor, Dr. Dongyan Xu. We are also affiliated with CERIAS, a center for education and research in information assurance and security.
  • This is the outline of my talk: First, I will talk of the motivation for Collapsar? Next, I will present the Collapsar architecture and show its unique features by comparing with current approaches to attack containement ; I will then talk about detailed design and implement Collapsar, which is followed by its performance measurement; We have also deployed Collapsar in a local Lab environment and have successfullly captured a number of attack incidents. Finally, I will present .
  • In recent years, we have observed different kinds of attack incidents, like blaster worm in last August, Sasser worm in this April and May. It was also reported in last November that the open-source Debian Project servers were hacked. In last December, some of Planetlab nodes were compromised. All of these incidents have reminded us how serious the problem is and motivated research efforts in designing systems or testbeds for capturing, monitoring, analyzing, and ultimately preventing network attacks.
  • Among the most notable techniques, honeypot has emerged as an effective tool to provide insights to these network attacks. Honeypot can be useful to capture attack tools used by intruders and understand motivations/tactics behind the intrusions. The reason why honeypot is effective is that it is able to generate a highly concentrated and less noisy datasets. These datasets has a very low false-positive and false negative. Furthermore, it has been shown in year 2001 that honeypot is able to discover unknown vulnerabilities like the subprocess control daemon in solaris CDE environment.
  • However, in current operation, honeypots are usually individually deployed and managed. Whether they are successful or not are largely dependent on security expertise of honeypot managers. Also each individual honeypot only provides a limited local view of network attack. In order to have a broader and more diverse view, it is natural to deploy honeypots in different sites and then share the log generated by these honeypots. However, such simple honeypot federation may lead to following problems: 1) One is the difficulties in distributed management, especially for honeypot management.; 2) Another one is the lack of security expertise in every site; 3) The third problem is the inconsistency in security &amp; management policy among different honeypot operators.
  • To solve these problems, we present our solutions, Collapsar is proposed to address these problems and is able to achieve two seemingly conflicting goals: distributed honeypot presence and centralized honeypot operation. Collapsar leverages ununsed IP addresses in each network or site and diverts the traffic for these IP addresses to a Colapsar Center. Inside the Collapsar Center, high-interaction virtual honeypots are deployed. These honeypots response to these traffic and appear to remote intruders as typical systems in corresponding networks.
  • This is the overall architecture of Collapsar. Collapsar has a scattered collection of unused IP addresses from different participating networks. One redirector will be installed in each such network and these redirectors will forward traffic for these unused IP addresses to the Collapsar Center, more specifically, the Collapsar Front-End. Inside the Collapsar Center, there are a bunch of high performance nodes which run different VM instances. Each VM contains specified honeypot services and will response to the dispatched traffic from Front-End. The redirector, front-end, and VM create a virtual presence of honepyot in the production network However, this honeypot is physically located inside Collapsar center.
  • Collapsar is different from current approaches. In overlay based approach like NetBait or Domino Overlay, honeypots are deployed in different networks. Log information generated by these honeypots are securely aggregated so that advanced date mining techniques can be applied. However, those attacks still happen within those sites.
  • Sinkhole network provides an interesting window to monitor network abuse or sense Internet motions. CAIDA has used a class A network to monitor the propagation of blaster worm. However, they usually rely on a contiguous large address block. Once this address block is known, it could be avoided by intruders or worm programmers. Also due to the consideration for scalability, they need to limit the interaction levels w/ intruders.
  • Honeyd is one of the most comparable work to Collapsar. They also have advanced traffic redirection mechanisms. The fundamental difference between honeyd and Collapsar is the interaction level w/ intruders. In honeyd, since vulnerable services are emulated, it is difficult to emulate a service w unknown vulnerability. Thus it would be hard for honeyd to capture the 0-day worms In summary, Collapsar complements these approaches and has its own unique features which are not available in current systems.
  • Collapsar involves: functional components and assurance modules. There are three functional components, i.e., redirector, Collapsar Front-End, virtual honeypot, which are necessary for a working Collapsar system. In order to mitigate security risks associated with each honeypot, different assurance modules are also necessary. In this work, we mainly focus on the functional components.
  • A redirector is running in each participating network and will listen to traffic for unused IP addresses. Once these traffic are detected, they are redirected to Collapsar Front-End. There are two main mechanisms to achieve transparent traffic redirection. One is Proxy-ARP-based end system approach, which may introduce additional network latency. Another is the GRE tunneling based network approach. Though it achieves better network performance, it involves additional complexity in router configuration and may miss attack traffic from inside domain.
  • The following two components are physically located in Collapsar Center. Collapsar Front-End receives redirected traffic from individual redirectors and dispatches them to different honeypots. In order to mitigate associated security risks, outgoing traffic needs to be inspected, possibly filtered, or even replaced. In current prototype, the front-end is implemented as UML VM, which functions as a transparent bridge and firewall. Some assurance modules are further applied here.
  • MSODA.ppt

    1. 1. Towards an Integrated Multimedia Service Hosting Overlay Dongyan Xu , Xuxian Jiang Department of Computer Sciences Center for Education and Research in Information Assurance and Security (CERIAS) Purdue University ACM Multimedia 2004
    2. 2. Outline <ul><li>Motivation </li></ul><ul><li>MSODA architecture </li></ul><ul><li>MSODA components </li></ul><ul><li>Virtualization of service hosting overlay </li></ul><ul><li>Related work </li></ul><ul><li>Conclusions </li></ul>
    3. 3. Motivation <ul><li>Proliferation of value-added and function-rich media services </li></ul><ul><ul><li>Pervasive media sources: live cam, TV, radio… </li></ul></ul><ul><ul><li>Content-based processing: tracking, enhancement, mix-reality… </li></ul></ul><ul><ul><li>User-specific media service composition: </li></ul></ul><ul><ul><ul><li>Surveillance cams  image recognition  scene correlation </li></ul></ul></ul><ul><ul><ul><li>Home video  jitter elimination  music mixing  mixed-reality rendering </li></ul></ul></ul>Image Repair Summarization Music Mixing
    4. 4. Motivation <ul><li>Service oriented architectures </li></ul><ul><ul><li>Users don’t have to know </li></ul></ul><ul><ul><ul><li>Service implementation details </li></ul></ul></ul><ul><ul><ul><li>Service instance locations </li></ul></ul></ul><ul><ul><ul><li>Service-level routing decisions </li></ul></ul></ul><ul><ul><li>Service providers have more flexibility in </li></ul></ul><ul><ul><ul><li>Implementation </li></ul></ul></ul><ul><ul><ul><li>Deployment strategy: placement, replication, migration, resource scaling, coalition </li></ul></ul></ul><ul><ul><ul><li>Management: upgrade, troubleshooting, recovery </li></ul></ul></ul>
    5. 5. Motivation <ul><li>Service providers meet service host </li></ul>Service providers: Have no infrastructure For deployment Service host (e.g. Yahoo, MSN): Needs rich services to serve customers A service-oriented “marketplace”: Hosts a large variety of media services for customer access and composition
    6. 6. Challenges <ul><li>Decoupling service management from hosting platform management </li></ul><ul><li>Isolating management of different media services </li></ul><ul><li>Protecting hosting platform from untrusted media services </li></ul><ul><li>Enabling agile media service workflow optimization </li></ul><ul><ul><li>On-demand service capacity scaling </li></ul></ul><ul><ul><li>Service instance replication and re-location </li></ul></ul>
    7. 7. Our Solution: MSODA (Media Service On-Demand Architecture) <ul><li>Infrastructure: MSODA hosts in wide-area network </li></ul><ul><li>Media service instances : virtual machines in MSODA hosts </li></ul><ul><li>Media service cloud : virtual network of service instances </li></ul><ul><li>Service gateways : edges of service cloud and interface to customers </li></ul>
    8. 8. MSODA Architecture Service gateway MSODA host Service Instance (VM)
    9. 9. MSODA Host <ul><li>Two-level architecture </li></ul><ul><ul><li>Host </li></ul></ul><ul><ul><li>Virtual machines </li></ul></ul><ul><li>Host domain MSODA daemons </li></ul><ul><ul><li>Resource allocation </li></ul></ul><ul><ul><li>Network monitoring </li></ul></ul><ul><ul><li>Traffic tunneling </li></ul></ul><ul><ul><li>Service routing </li></ul></ul>An MSODA host Host OS … … … Guest OS Guest OS S 1 S 2 MSODA daemons
    10. 10. MSODA Gateway <ul><li>Interface to service clients </li></ul><ul><ul><li>Service composition </li></ul></ul><ul><ul><li>Service configuration </li></ul></ul><ul><li>Edge of service cloud </li></ul><ul><ul><li>Bridging service instances (virtual machines) to client machines: limited and controlled access </li></ul></ul>MSODA gateway Client Service instance (VM) Composite service request Service path signaling Service data/stream
    11. 11. MSODA Gateway <ul><li>Service composition and configuration </li></ul><ul><ul><li>User-centric customization </li></ul></ul><ul><ul><li>Resource conservation </li></ul></ul>S 1 S 2 512Kbps S 2 256Kbps 256Kbps S 1 S 2
    12. 12. Media Service Cloud <ul><li>A virtual network of service instances (VMs) </li></ul><ul><ul><li>Based on network virtualization technique (VIOLIN) </li></ul></ul><ul><ul><ul><li>VN for VMs </li></ul></ul></ul><ul><ul><ul><li>Using MSODA hosts as underlying carrier (layer-2 on UDP) </li></ul></ul></ul><ul><ul><ul><li>Emulating advanced network protocols (e.g., IP multicast) </li></ul></ul></ul><ul><ul><li>IP-compliant, with its IP address space </li></ul></ul><ul><ul><li>Isolation from underlying Internet </li></ul></ul>
    13. 13. Media Service Cloud <ul><li>Advantages </li></ul><ul><ul><li>Protection of MSODA infrastructure </li></ul></ul><ul><ul><ul><li>Service traffic volume control </li></ul></ul></ul><ul><ul><ul><li>Service instance reachability control </li></ul></ul></ul><ul><ul><li>Decoupling of </li></ul></ul><ul><ul><ul><li>Media service function (by service developer) </li></ul></ul></ul><ul><ul><ul><li>Service provisioning and composition mechanisms (by MSODA developer) </li></ul></ul></ul>
    14. 14. Media Service Cloud <ul><li>Multicast and anycast group for each media service </li></ul><ul><ul><li>Multicast group: convenient service management (e.g., asking all instances of a service to report current load/QoS/most popular content…) </li></ul></ul><ul><ul><li>Anycast group: service composition routing (e.g., specifying the next service in the service delivery workflow) </li></ul></ul><ul><li>Simple APIs for easy media service implementation </li></ul><ul><li>Actual operations performed by underlying MSODA hosts </li></ul>
    15. 15. Media Service Cloud <ul><li>Dynamic service cloud evolution </li></ul><ul><ul><li>Service instance resource scaling </li></ul></ul><ul><ul><li>Service instance replication </li></ul></ul><ul><ul><li>Service instance re-location </li></ul></ul>Resource scaling Service instance replication S 1 S 1 S 1 S 2 S 2 S 2 Time
    16. 16. MSODA Prototype <ul><li>Service instances (VMs) enabled by User-Mode Linux (UML) </li></ul><ul><li>Service cloud (virtual network) enabled by VIOLIN </li></ul><ul><ul><li>Acceptable network performance degradation </li></ul></ul><ul><ul><li>Automatic service instance creation and re-location </li></ul></ul><ul><ul><li>Centralized computation of service delivery paths </li></ul></ul><ul><li>Local and wide-area (PlanetLab-based) testbeds </li></ul><ul><li>Virtual private Grids for dynamic scientific applications </li></ul>
    17. 17. Related Work <ul><li>Service composition frameworks </li></ul><ul><ul><li>Ninja, SAHARA, CANS, SPY-Net, SpiderNet </li></ul></ul><ul><li>Service overlay networks </li></ul><ul><ul><li>SOI (Service-Oriented Internet) </li></ul></ul><ul><ul><li>Opus (Overlay Peer Utility Service) </li></ul></ul><ul><li>Overlay networking </li></ul><ul><ul><li>RON, OverQoS, Narada, Overcast, I3 </li></ul></ul><ul><li>Resource virtualization </li></ul><ul><ul><li>Virtual machine: Denali, VMware, UML, Xen </li></ul></ul><ul><ul><li>Virtual network: VNET, VIOLIN </li></ul></ul><ul><ul><li>Virtual environment: In-VIGO </li></ul></ul>
    18. 18. Conclusions <ul><li>MSODA: an integrated media service hosting platform for service composition </li></ul><ul><li>Virtual machine as granularity for service instance management and manipulation </li></ul><ul><li>Virtual service cloud network </li></ul><ul><ul><li>Platform-independent media service development and management </li></ul></ul><ul><ul><li>Maximum manipulability for dynamic service instance scaling, replication, and re-location </li></ul></ul><ul><ul><li>Strong protection of MSODA platform from untrusted media services/clients </li></ul></ul>
    19. 19. Thank you. For more information: Email: {d xu, jiangx}@cs.purdue.edu URL: www.cs.purdue.edu/~dxu Google: “ Purdue SODA friends ”
    1. ¿Le ha llamado la atención una diapositiva en particular?

      Recortar diapositivas es una manera útil de recopilar información importante para consultarla más tarde.

    ×