Exposing And Eliminating Vulnerabilities To Denial Of Service Attacks In Secure

461 views

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
461
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Exposing And Eliminating Vulnerabilities To Denial Of Service Attacks In Secure

  1. 1. Exposing and Eliminating Vulnerabilities to Denial of Service Attacks in Secure Gossip-Based Multicast Gal Badishi, Idit Keidar, Amir Sasson
  2. 2. Agenda <ul><li>The problem </li></ul><ul><li>Overview of gossip-based multicast </li></ul><ul><li>Proposed solution - Drum </li></ul><ul><li>Analysis and simulations </li></ul><ul><li>Implementation and measurements </li></ul><ul><li>More DoS-mitigation techniques </li></ul><ul><li>Conclusions </li></ul>
  3. 3. Denial of Service (DoS) <ul><li>Unavailability of service </li></ul><ul><ul><li>Exhausting resources </li></ul></ul><ul><li>Remote attacks </li></ul><ul><ul><li>Network level </li></ul></ul><ul><ul><ul><li>Solutions do not solve all application problems </li></ul></ul></ul><ul><ul><li>Application level </li></ul></ul><ul><ul><ul><li>Got little attention </li></ul></ul></ul><ul><ul><ul><li>Quantitative analysis of impact on application and identification of vulnerabilities needed </li></ul></ul></ul>
  4. 4. Dollar Amount of Losses by Type
  5. 5. Remote Application-Level DoS No Attack DoS Attack Valid Request Bogus Request
  6. 6. Challenges <ul><li>Quantify the effect of DoS at the application level </li></ul><ul><li>Expose vulnerabilities </li></ul><ul><li>Find effective DoS-mitigation techniques </li></ul><ul><ul><li>Prove their usefulness using the found metric </li></ul></ul>
  7. 7. Multicast <ul><li>A group of members </li></ul><ul><li>At least one member is a source – generates messages </li></ul><ul><li>Messages should arrive to all of the group members in a timely fashion </li></ul><ul><li>Network level vs. application level (ALM) </li></ul>
  8. 8. Tree-Based Multicast <ul><li>Use a spanning tree – most common solution </li></ul><ul><li>No duplicates (optimal BW when network-level) </li></ul><ul><li>Single points of failure </li></ul>Source
  9. 9. Gossip-Based Multicast <ul><li>Progresses in rounds </li></ul><ul><li>Every round </li></ul><ul><ul><li>Choose random partners ( view ) </li></ul></ul><ul><ul><li>Send or receive messages </li></ul></ul><ul><ul><li>Discard old msgs from buffer </li></ul></ul><ul><li>Probabilistic reliability </li></ul><ul><li>Uses redundancy to achieve robustness </li></ul><ul><li>Two methods </li></ul><ul><ul><li>Push </li></ul></ul><ul><ul><li>Pull </li></ul></ul>
  10. 10. Push Source
  11. 11. Pull Source
  12. 12. Effects of DoS on Gossip <ul><li>Reasonable to assume that source is attacked </li></ul><ul><li>Surprisingly, we show that naïve gossip is vulnerable to DoS attacks </li></ul><ul><li>Attacking a process in pull-based gossip may prevent it from sending messages </li></ul><ul><li>Attacking a process in push-based gossip may prevent it from receiving messages </li></ul>
  13. 13. Drum <ul><li>A new gossip-based ALM protocol </li></ul><ul><li>Utilizes DoS-mitigation techniques </li></ul><ul><ul><li>Using random one-time ports to communicate </li></ul></ul><ul><ul><li>Combining both push and pull </li></ul></ul><ul><ul><li>Separating and bounding resources </li></ul></ul><ul><li>Eliminates vulnerabilities to DoS </li></ul><ul><li>Proven robust using formal analysis and quantitative evaluation </li></ul>
  14. 14. Random Ports <ul><li>Any request necessitating a reply contains a random port number </li></ul><ul><ul><li>“Invisible” to the attacker (e.g., encrypted) </li></ul></ul><ul><li>The reply is sent to that random port </li></ul><ul><li>Assumption: attacking other ports does not affect the random port’s queue (i.e., there is no BW exhaustion) </li></ul>
  15. 15. Combining Push and Pull <ul><li>Attacking push cannot prevent receiving messages via pull (random ports) </li></ul><ul><li>Attacking pull cannot prevent sending via push </li></ul><ul><li>Each process has some control over the processes it communicates with </li></ul>
  16. 16. Bounding Resources <ul><li>Motivation: prevent resource exhaustion </li></ul><ul><li>Each round process a random subset of the arriving messages and discard the rest </li></ul><ul><li>Separate resources for orthogonal operations </li></ul>Valid Request Bogus Request Round Duration
  17. 17. Drum’s Push Mechanism <ul><li>Alice sends Bob a push-offer </li></ul><ul><li>Bob replies with a digest of messages he has already received </li></ul><ul><li>Alice only sends Bob messages missing from his digest </li></ul><ul><li>Random ports </li></ul>
  18. 18. Evaluation Methodology <ul><li>Compare 3 protocols </li></ul><ul><ul><li>Push (push-based with bounded resources) </li></ul></ul><ul><ul><li>Pull (pull-based with bounded resources) </li></ul></ul><ul><ul><li>Drum </li></ul></ul><ul><li>Under various DoS attacks </li></ul><ul><ul><li>Increasing strength (shows trend under DoS) </li></ul></ul><ul><ul><li>Fixed strength (exposes vulnerabilities) </li></ul></ul><ul><li>Source is always attacked </li></ul><ul><li>Evaluates combination of Push and Pull </li></ul><ul><li>Separately evaluate the other two techniques </li></ul>
  19. 19. Evaluation Methodology (cont.) <ul><li>Measure propagation time – expected number of rounds it takes a message to reach all of the correct processes </li></ul><ul><ul><li>99% in the simulations and actual measurements </li></ul></ul><ul><li>Use real implementation to measure actual latency and throughput </li></ul>
  20. 20. Analysis/Simulation Assumptions <ul><li>Static group with complete connectivity </li></ul><ul><li>Processes have complete group knowledge </li></ul><ul><li>Propagation of a single message M </li></ul><ul><ul><li>But simulate situation where all procs have msgs to send </li></ul></ul><ul><li>M is never purged from local buffers </li></ul><ul><li>Rounds are synchronized </li></ul><ul><li>All round operations complete within the same round </li></ul><ul><li>All processes are correct (analysis) or 10% of them perform a DoS attack (simulation) </li></ul>
  21. 21. Validating Known Results <ul><li>The propagation time of gossip-based multicast protocols is O(log n) [P87, KSSV00] </li></ul>
  22. 23. Validating Known Results (cont.) <ul><li>The performance of gossip-based multicast protocols degrades gracefully as failures amount [LMM00, GvRB01] </li></ul>
  23. 25. Definitions <ul><li>n – number of processes in the group </li></ul><ul><li>F – size of view , and max # of requests to process in a round ( F = 4 ) </li></ul><ul><li> – percentage of attacked processes </li></ul><ul><li>x – number of bogus messages an attacked process receives in a round </li></ul><ul><li>B – total attack strength ( B =  nx ) </li></ul>
  24. 26. Analysis – Increasing Strength <ul><li>Lemma 1: Fix  < 1 and n . Drum’s propagation time is bounded from above by a constant independent of x </li></ul><ul><li>Proof idea </li></ul><ul><ul><li>Define effective fan-in and effective fan-out </li></ul></ul><ul><ul><li>Both have an element independent of x </li></ul></ul><ul><ul><li>When x   this element is dominant </li></ul></ul><ul><ul><li>The effective fans are bounded from below </li></ul></ul>
  25. 27. Analysis – Increasing Strength <ul><li>Lemma 2: Fix  and n . The propagation time of Push grows at least linearly with x </li></ul><ul><li>Proof idea </li></ul><ul><ul><li>Assume all non-attacked processes already have the message (and so does the source) </li></ul></ul><ul><ul><li>Bound the expected number of processes having M at round k from above </li></ul></ul><ul><ul><li>Find the minimal k in which all processes have M </li></ul></ul><ul><ul><li>Reaching all attacked processes takes at least a time linear in x </li></ul></ul>
  26. 28. Analysis – Increasing Strength <ul><li>Lemma 3: Fix  and n . The propagation time of Pull grows at least linearly with x </li></ul><ul><li>Proof idea </li></ul><ul><ul><li>Denote by p the probability that the source reads a valid pull request in a round </li></ul></ul><ul><ul><li># of rounds for M to leave the source is geometrically distributed with p </li></ul></ul><ul><ul><li>The expectation is 1/p </li></ul></ul><ul><ul><li>1/p is at least linear in x </li></ul></ul>
  27. 31. Analysis – Fixed Strength <ul><li>Define c = B/nF (total attack strength divided by total system capacity) </li></ul><ul><li>Lemma 4: For c > 5, Drum’s expected propagation time is monotonically increasing with  </li></ul><ul><li>Proof idea </li></ul><ul><ul><li>Effective fan-in and effective fan-out are monotonically decreasing with  </li></ul></ul>
  28. 33. Implementation and Measurements <ul><li>Multithreaded processes in Java </li></ul><ul><li>Operations are not synchronized </li></ul><ul><li>Rounds are not synchronized among processes </li></ul><ul><li>50 machines on a 100Mbit LAN (Emulab) </li></ul><ul><li>One process per machine </li></ul><ul><li>5 processes (10%) perform a DoS attack </li></ul>
  29. 34. Validating the Simulations <ul><li>Evaluate the protocols in the same scenarios tested by simulation </li></ul><ul><li>High correlation shows that the simplifying assumptions have little effect on the results </li></ul>
  30. 37. High-Throughput Experiments <ul><li>Single source </li></ul><ul><li>Creates 40 messages per second </li></ul><ul><li>Round duration = 1 second </li></ul><ul><li>Messages are purged after 10 rounds </li></ul><ul><li>Each process sends at most 80 data messages to another process in a round </li></ul><ul><li>Throughput and latency are measured at the 44 correct receiving processes </li></ul>
  31. 41. Evaluating Random Ports <ul><li>Analyze Drum using simulations </li></ul><ul><li>Assume pull-replies are returned to a well-known port </li></ul><ul><ul><li>Different than the port for pull-requests </li></ul></ul><ul><ul><li>Both ports are now being attacked </li></ul></ul><ul><ul><li>Original attack on pull channels is equally divided between these ports </li></ul></ul>
  32. 43. Evaluating Resource Separation <ul><li>Analyze Drum using actual measurements </li></ul><ul><li>Merge all bounds on reception of control messages </li></ul><ul><ul><li>Push-offers, push-replies, pull-requests </li></ul></ul><ul><ul><li>Originally, allow reception of F/2 (= 2) messages/round on each listening control msgs port </li></ul></ul><ul><ul><li>Now, allow reception of 3F/2 (= 6) messages/round in total, for all control messages </li></ul></ul>
  33. 45. Summary <ul><li>Gossip-based protocols are very robust, but… </li></ul><ul><ul><li>naïve gossip-based protocols are vulnerable to targeted DoS attacks </li></ul></ul><ul><li>Drum uses simple techniques to mitigate the effects of DoS attacks </li></ul><ul><li>Evaluations show Drum’s resistance to DoS </li></ul><ul><li>The most effective attack against Drum is a broad one </li></ul>
  34. 46. General Principles <ul><li>DoS-mitigation techniques: </li></ul><ul><ul><li>random ports </li></ul></ul><ul><ul><li>neighbor-selection by local choices </li></ul></ul><ul><ul><li>separate resource bounds </li></ul></ul><ul><li>Design goal: eliminate vulnerabilities </li></ul><ul><ul><li>The most effective attack is a broad one </li></ul></ul><ul><li>Analysis and quantitative evaluation of impact of DoS </li></ul>
  35. 47. The End

×