1 / 45

Stopping Worm/Virus Attacks

Stopping Worm/Virus Attacks . Chiu Wah So (Kelvin). Worms. Replicate worms over a computer network Perform malicious action Grow Exponentially Double in a few seconds to hours. Two Papers on stopping worms. Potemkin Virtual Honeyfarm:

urit
Download Presentation

Stopping Worm/Virus Attacks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Stopping Worm/Virus Attacks Chiu Wah So (Kelvin)

  2. Worms • Replicate worms over a computer network • Perform malicious action • Grow Exponentially • Double in a few seconds to hours

  3. Two Papers on stopping worms • Potemkin Virtual Honeyfarm: • Scalability, fidelity, and containment in worm detection using honeypots. • Vigilante: • End-to-end worm containment strategy, which includes worm detection, alert propagation, and local response.

  4. Background on HoneyPot • Definition: • An information system resource whose value lies in unauthorized or illicit use of that resource • Carefully monitored and frequently left unprotected to detect and analyze intrusions • Analyzed intrusions for • Antivirus/worm signatures • Disinfection algorithm • Criminal investigation and persecution

  5. Low-interaction honeypots • Minimal interactions with the attackers (at most network layer interaction) • Passively monitors inbound packets • Simply transmits a SYN/ACK sequence to TCP SYN • Advantage: high scalability - up to millions • Disadvantage: low fidelity (Doesn’t execute the kernel or application code)

  6. High-interaction honeypots • Execution environment identical or similar to a real host • Advantage: high fidelity • Disadvantage: low scalability (each system monitors one IP address) • Can use VM to multiplex such that each machine can monitor more IP addresses

  7. Containment Strategies • Prevent compromised honeypots from attacking other machines • Disallow outbound messages • Problems with “phone home” to receive updates • Forward outbound packets sent in response to inbound packets • Problems with DNS query • Result low fidelity (impossible to understand the native behavior of a malware)

  8. Goal of Potemkin Virtual Honeyfarm • To implement scalable high-interactive honeypots with • High fidelity – running common operating system and application software • High scalability • High containment

  9. Observations High-interactive honeypots • Most of a honeypot’s processor cycles are wasted idling (given IP address is rarely accessed) • Most of a honeypot’s memory is idle • Different honeypot servers in a honeyfarm replicate the same environment, and duplicate the effort.

  10. Main Ideas • Use gateway router • Dynamically bind IP addresses to physical servers, • Containment policies. • Use Virtual Machine Monitor (Xen) create lightweight virtual machines • Flash cloning (create VM from reference image) • Delta virtualization (copy-on-write)

  11. Architecture

  12. Gateway Router • Direct inbound traffic to individual honeyfarm servers • Manage the containment of outbound traffic • Implement long-term resource management • Interface with detection, analysis and user-interface components

  13. Gateway Router: Inbound traffic • Attracts traffic: routing (BGP) and tunneling • Sends IP packets for which there is no active VM to a non-overloaded honeyfarm server • Type map: illusion that a given IP address hosts a particular software configuration • Assigns to the same VM if the same IP • Scan filter: reduces inbound traffic

  14. Gateway Router: Outbound traffic • Containment Policies implemented on the gateway • Track communication patterns • Proxy standard outbound service • Internal Reflection – redirect the unsafe outbound packet back into honeyfarm • Avoid resource starvation • Avoid cross-containment

  15. Cross Containment (1) • Yellow = contaminated by worm Wx • Blue = contaminated by worm Wy

  16. Cross Containment (2) • Yellow = contaminated by worm Wx • Blue = contaminated by worm Wy • Green = contaminated by worm Wx and Wy

  17. Cross Containment (3) • Green = contaminated by worm Wx and Wy

  18. Solution for Cross Containment • Each packet is extended with a universe identifier (src, dest, src port)that identifies a unique virtual IP address space • New universe identifier is created for each transaction • Packets can only forward to hosts within the same universe

  19. Gateway Router: Resource Allocation • Reclaim uncompromised VM if it is not receiving inbound traffic • Allow compromised VM to persist for further analysis • When resource is low, prioritize VM

  20. Virtual Machine Monitor • Active IP addresses are an order of magnitude smaller • Each server only uses small subset of hardware • Therefore, VMs are created on request to multiplex a lot of machines • One VM per IP address per universe

  21. VMM: Flash Cloning • Reduces speed to instantiate a new clone

  22. VMM: Delta Virtualization • Reduces memory overhead • Shares VM pages and supports copy-on-write operation

  23. Evaluation: Question to address • How many honeypot VMs are necessary? • How many VMs can a machine spawn? • How many connections can a gateway support?

  24. Multiplexing Address Space • /16 network • VM aggressively recycled after 500 ms • Average number of active VMs = 58 • Peak = 13614

  25. Multiplexing Honeyfarm Servers

  26. Statistics • Delta Virtualization: 128MB for 116 clones • Flash Cloning: 521.2ms to clone and 315.5ms to tear down • CPU usage < 0.01% for HTTP request • Gateway traffic: 160,000 packets / sec (hitting flow cache), 28,000 packets /sec (random traffic) • Gateway Memory: 256 bytes per flow

  27. Limitations • Attracting Attacks • Tends to only receive traffic from randomly targeted attacks • Honeypot Detection • Detects honeypot and evades honeypot • Denial-of-Service attack

  28. Next Paper: Vigilante • What do we do after we detect a worm? • Generate worm signatures by human. • Too slow? Usually generating worm signatures by human takes days to weeks. • And worm doubles in seconds to hours. Therefore, we need an end to end worm containment solution.

  29. Vigilante • An automatic end to end worm containment with negligible false positive rate • Detection • Propagation • Response

  30. Current Worm Containment Strategies • Network level approach (doesn’t have enough information, and has false positives) • Host-based detection (not end-to-end solution) • Host-based architecture (uses heuristic to correct the vulnerable service)

  31. Vigilante architecture • Use honeypot for worm detection, and generate self-certifying alert • Propagate alert on overlay network • Install filter in local host

  32. Self-certifying alert • Remove the trust between hosts • Prove the existence of a vulnerability • Can be verified inexpensively • Automatically generate, verify, and distribute SCAs.

  33. Alerts types • Arbitrary Execution Control: contains the address of a code to execute • Arbitrary Code Execution: contains the code to execute • Arbitrary Function: contains the value of argument of critical functions Format: id of the vulnerable service, id of the alert type, verification information, and the messages

  34. Worm detection • Use Honeypots • Two different worm detections engines: • Non-executable pages • Non-execute protection on stack and heap to prevent code injection attack • Dynamic dataflow analysis • Data received from the network is dirty, and propagate the dirty bit whenever data is moved

  35. Alert generation • Log all the network messages for some threshold time • When worm is detected, use all the network messages in the log to generate candidate SCAs. • Run verification procedure for each candidate. • If verification succeeds, generate SCA.

  36. Alert Verification • Verification is run in sandbox, virtual machine. • Service is instrumented according to alert type with the verified function.

  37. Properties of SCA Verification • Fast – Overhead of virtual machine is small • Simple and generic • No false positives • Some drawbacks • Doesn’t describe the scheduling order for the threads

  38. Alert Distribution • Distribution must be fast, secure and reliable • Use of secure Pastry overlay to broadcast • To avoid DOS: • Don’t forward already seen or blocked SCAs • Only forward verifiable SCAs • Limit rate of SCAs received on each neighbors • Use super-peers: they only have overlay code and VMs with vulnerability services for verification

  39. Filter generation • Use dataflow and control flow analysis to generate filter • Use two filters: general filters and specific filters to reduce false negatives

  40. Evaluation • Three real worms • Slammer: 75,000 MS SQL Servers infected, 8.5 seconds to double • CodeRed: 360,000 MS IIS Servers infected, 37 mins to double • Blaster: 500,000 MS Windows infected, rate of growth similar to CodeRed

  41. Alert generation and verification

  42. Alert Distribution

  43. Filter generation and CPU overhead

  44. End-to-end experiments • 5 host vigilante networks • One detector, three super-peers for SCA distribution overlay, and one vulnerable host • Results • Slammers: 79ms • Blaster: 305ms • CodeRed: 3044ms

  45. Conclusion • Is it possible to incorporate Potemkin Virtual Honeyfarm into the worm detection of Vigilante to make it a more scalable solution? • Different aspects of worm containment: • Potemkin Virtual Honeyfarm talks about salability, fidelity, and containment of honeypots • Vigilante is an end-to-end worm containment strategy

More Related