1 / 42

Gal Badishi, Idit Keidar, Amir Sasson

Exposing and Eliminating Vulnerabilities to Denial of Service Attacks in Secure Gossip-Based Multicast. Gal Badishi, Idit Keidar, Amir Sasson. Agenda. Overview of gossip-based multicast The problem Proposed solution Analysis and simulations Implementation and measurements Conclusions.

lolita
Download Presentation

Gal Badishi, Idit Keidar, Amir Sasson

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. Exposing and Eliminating Vulnerabilities to Denial of Service Attacks in SecureGossip-Based Multicast Gal Badishi, Idit Keidar, Amir Sasson Faculty of Electrical Engineering, Technion

  2. Agenda • Overview of gossip-based multicast • The problem • Proposed solution • Analysis and simulations • Implementation and measurements • Conclusions Faculty of Electrical Engineering, Technion

  3. Multicast • A group of members • At least one member is a source – generates messages • Messages should arrive to all of the group members in a timely fashion • Network level vs. application level (ALM) Faculty of Electrical Engineering, Technion

  4. Source Tree-Based Multicast • Use a spanning tree – most common solution • No duplicates (optimal BW when network-level) • Single points of failure Faculty of Electrical Engineering, Technion

  5. Gossip-Based Multicast • Progresses in rounds • Every round • Choose random partners (view ) • Send or receive messages • Discard old msgs from buffer • Probabilistic reliability • Trades latency and BW for redundancy • Two methods • Push • Pull Faculty of Electrical Engineering, Technion

  6. Push Source Faculty of Electrical Engineering, Technion

  7. Pull Source Faculty of Electrical Engineering, Technion

  8. Hostility over the Internet • Forgery/spoofing • Penetration • Denial of Service (DoS) Faculty of Electrical Engineering, Technion

  9. Denial of Service • Unavailability of service • Methods • Exploiting bugs • Exhausting resources • Remote attacks • Network level • Application level • Got little attention • No quantitative analysis of impact on application Faculty of Electrical Engineering, Technion

  10. Dollar Amount of Losses by Type Faculty of Electrical Engineering, Technion

  11. Valid Request Bogus Request Remote Application-Level DoS No Attack DoS Attack Faculty of Electrical Engineering, Technion

  12. Effects of DoS on Gossip • Reasonable to assume that source is attacked • Surprisingly, we show that naïve gossip is vulnerable to DoS attacks • Attacking a process in pull-based gossip may prevent it from sending messages • Attacking a process in push-based gossip may prevent it from receiving messages Faculty of Electrical Engineering, Technion

  13. Our Solution • Drum – a new gossip-based ALM protocol • Utilizes DoS-mitigation techniques • Separating and bounding resources • Combining both push and pull • Using random one-time ports to communicate • Proven robust using formal analysis and quantitative evaluation • Provides general methods for analyzing and quantitatively evaluating resistance to DoS-attacks Faculty of Electrical Engineering, Technion

  14. Round Duration Valid Request Bogus Request Bounding Resources • Motivation: prevent resource exhaustion • Each round process a random subset of the arriving messages and discard the rest Faculty of Electrical Engineering, Technion

  15. Combining Push and Pull • Attacking push cannot prevent receiving messages via pull (random ports) • Attacking pull cannot prevent sending via push Faculty of Electrical Engineering, Technion

  16. Random Ports • Any request necessitating a reply contains a random port number • “Invisible” to the attacker (e.g., encrypted) • The reply is sent to that random port • Assumption: attacking other ports does not affect the random port’s queue (i.e., there is no BW exhaustion) Faculty of Electrical Engineering, Technion

  17. Drum’s Push Mechanism • Alice sends Bob a push-offer • Bob replies with a digest of messages he has already received • Alice only sends Bob messages missing from his digest • Random ports Faculty of Electrical Engineering, Technion

  18. Evaluation Methodology • Compare 3 protocols • Push (push-based with bounded resources) • Pull (pull-based with bounded resources) • Drum • Under various DoS attacks • Fixed strength • Increasing strength • Source is always attacked • Evaluates combination of Push and Pull Faculty of Electrical Engineering, Technion

  19. Evaluation Methodology (cont.) • Measure propagation time – expected number of rounds it takes a message to reach all of the correct processes • 99% in the simulations and actual measurements • Use real implementation to measure actual latency and throughput Faculty of Electrical Engineering, Technion

  20. Analysis/Simulation Assumptions • Static group with complete connectivity • Processes have complete group knowledge • Propagation of a single message M • But simulate situation where all procs have msgs to send • M is never purged from local buffers • Rounds are synchronized • All round operations complete within the same round • All processes are correct (analysis) or 10% of them perform a DoS attack (simulation) Faculty of Electrical Engineering, Technion

  21. Validating Known Results • The propagation time of gossip-based multicast protocols is O(log n) [P87, KSSV00] Faculty of Electrical Engineering, Technion

  22. Faculty of Electrical Engineering, Technion

  23. Validating Known Results (cont.) • The performance of gossip-based multicast protocols degrades gracefully as failures amount [LMM00, GvRB01] Faculty of Electrical Engineering, Technion

  24. Faculty of Electrical Engineering, Technion

  25. Definitions • n – number of processes in the group • F – size of view, and max # of requests to process in a round (F = 4 ) •  – percentage of attacked processes • x – number of bogus messages an attacked process receives in a round • B – total attack strength (B = nx ) Faculty of Electrical Engineering, Technion

  26. Analysis – Increasing Strength • Lemma 1: Fix  and n. Drum’s propagation time is bounded from above by a constant independent of x • Proof idea • Define effective fan-in and effective fan-out • Both have an element independent of x • When x   this element is dominant • The effective fans are bounded from below Faculty of Electrical Engineering, Technion

  27. Analysis – Increasing Strength • Lemma 2: Fix  and n. The propagation time of Push grows at least linearly with x • Proof idea • Assume all non-attacked processes already have the message (and so does the source) • Bound the expected number of processes having M at round k from above • Find the minimal k in which all processes have M • Reaching all attacked processes takes at least a time linear in x Faculty of Electrical Engineering, Technion

  28. Analysis – Increasing Strength • Lemma 3: Fix  and n. The propagation time of Pull grows at least linearly with x • Proof idea • Denote by p the probability that the source reads a valid pull request in a round • # of rounds for M to leave the source is geometrically distributed with p • The expectation is 1/p • 1/p is at least linear in x Faculty of Electrical Engineering, Technion

  29. Faculty of Electrical Engineering, Technion

  30. Faculty of Electrical Engineering, Technion

  31. Analysis – Fixed Strength • Define c = B/nF (total attack strength divided by total system capacity) • Lemma 4: For c > 5, Drum’s expected propagation time is monotonically increasing with  • Proof idea • Effective fan-in and effective fan-out are monotonically decreasing with  Faculty of Electrical Engineering, Technion

  32. Faculty of Electrical Engineering, Technion

  33. Implementation and Measurements • Uses the Java programming language • Multithreaded processes • Operations are not synchronized • Rounds are not synchronized among processes • 50 machines on a 100Mbit LAN (Emulab) • One process per machine • 5 processes (10%) perform a DoS attack Faculty of Electrical Engineering, Technion

  34. Validating the Simulations • Evaluate the protocols in the same scenarios tested by simulation • High correlation shows that the simplifying assumptions have little effect on the results Faculty of Electrical Engineering, Technion

  35. Faculty of Electrical Engineering, Technion

  36. Faculty of Electrical Engineering, Technion

  37. High-Throughput Experiments • Single source • Creates 40 messages (50 bytes long) per second • Total of 10,000 messages • Round duration = 1 second • Messages are purged after 10 rounds • Each process sends at most 80 data messages to another process in a round • Throughput and latency are measured at the 44 correct receiving processes Faculty of Electrical Engineering, Technion

  38. Faculty of Electrical Engineering, Technion

  39. Faculty of Electrical Engineering, Technion

  40. Faculty of Electrical Engineering, Technion

  41. Conclusions • DoS attacks are a real problem • Gossip-based protocols have no single points of failure • However, naïve gossip-based protocols are vulnerable to targeted DoS attacks • Drum uses simple techniques to mitigate the effects of DoS attacks • Evaluations show Drum’s resistance to DoS • The most effective attack against Drum is a broad one • General DoS-mitigation techniques: random ports and neighbor-selection • Analysis and quantitative evaluation techniques may be applicable to other systems as well Faculty of Electrical Engineering, Technion

  42. The End Faculty of Electrical Engineering, Technion

More Related