SENSS Against Volumetric DDoS Attacks Sivaram Ramanathan 1 , Jelena - - PowerPoint PPT Presentation

▶
senss against volumetric ddos attacks
SMART_READER_LITE
LIVE PREVIEW

SENSS Against Volumetric DDoS Attacks Sivaram Ramanathan 1 , Jelena - - PowerPoint PPT Presentation

Oct 31, 2022 44 likes •609 views

SENSS Against Volumetric DDoS Attacks Sivaram Ramanathan 1 , Jelena Mirkovic 1 , Minlan Yu 2 and Ying Zhang 3 1 University of Southern California/Information Sciences Institute 2 Harvard University 3 Facebook 1 DDoS attacks Volumetric DDoS

slide-1
SLIDE 1

SENSS Against Volumetric DDoS Attacks

Sivaram Ramanathan1, Jelena Mirkovic1, Minlan Yu2 and Ying Zhang3

1University of Southern California/Information Sciences Institute 2Harvard University 3Facebook

1

slide-2
SLIDE 2

DDoS attacks

  • Volumetric DDoS can overwhelm

networks

  • Such attacks are hard to mitigate by

victim

  • Volume is too high for victim to handle –

need help of upstream ISPs

  • Legit traffic mixed with attack traffic –

need help to place imperfect filters near attack sources to minimize collateral damage

  • Need collaborative, distributed

response

  • But today’s internet lacks the

infrastructure for victim to ask peers

  • r remote networks for help

2 *Figure taken from Arbor Networks worldwide infrastructure security report, 2016

slide-3
SLIDE 3

Existing solutions at victim

Victim Attacker

Attacker

Attacker Attacker

  • Solutions such as Bro and Arbor

APS deployed at victim

  • Filters traffic based on

inspection and rules

  • Large attacks cannot be filtered

as the origin of attack is upstream from victim

Bro Arbor APS

3

slide-4
SLIDE 4

Existing solutions at first hop ISP

Victim Attacker

Attacker

Attacker Attacker First hop ISP

  • Collaboration with ISP via

human channels which are error prone and slow

  • Crude filtering such as remotely-

triggered blackhole saves ISP from attack but cuts victim from internet

  • Bohatei uses SDN + NFV to scale

defense on demand

  • Provides a fine grained traffic

control but is resource intensive

RTBH Bohatei

4

slide-5
SLIDE 5

Victim Attacker

Attacker

Attacker Attacker

Cloud Providers

Existing solutions at cloud

  • Cloud solutions are effective by

diverting all victim’s traffic towards themselves during an attack

  • Apply scrubbing algorithms to

remove attack traffic, send the rest to victim

  • Ability to handle heavy attacks

depends on extent of geo- replication, which is costly

Cloudflare Akamai

5

slide-6
SLIDE 6

What do we provide?

  • SENSS is a collaborative framework which allows victim under attack

to communicate with peers or remote networks

  • Design is simple
  • SENSS keeps the intelligence at the victim and has simple functionalities at ISP

which can be easily implemented in current ISP infrastructure

  • Victim drives decisions to monitor and taking necessary actions to mitigate

attacks

  • Victims can create versatile, evolvable and customizable defense for different

types of DDoS flavors

6

slide-7
SLIDE 7

Overview

  • Introduction
  • SENSS
  • Architecture
  • SENSS API
  • SENSS client programs
  • Security and robustness
  • Evaluation
  • Conclusion

7

slide-8
SLIDE 8

SENSS: Components

8

Attacker SENSS client SENSS server SENSS server Victim

slide-9
SLIDE 9

SENSS: Attack scenario

9

SENSS client SENSS server SENSS server Attacker Victim

slide-10
SLIDE 10

SENSS: Attack scenario

10

SENSS client SENSS server SENSS server Attacker Victim SENSS directory

slide-11
SLIDE 11

SENSS: Attack scenario

11

Traffic Monitor request Traffic Monitor request SENSS client SENSS server SENSS server Attacker Victim

slide-12
SLIDE 12

SENSS: Attack scenario

$ $

12

SENSS server authenticates requests SENSS client Attacker Victim

slide-13
SLIDE 13

SENSS: Attack scenario

$ $

13

SENSS server charges client SENSS client Attacker Victim

slide-14
SLIDE 14

SENSS: Attack scenario

Gather traffic stats Gather traffic stats

14

SENSS client Attacker Victim

slide-15
SLIDE 15

SENSS: Attack scenario

15

Return monitoring stats SENSS client SENSS server SENSS server Attacker Victim

slide-16
SLIDE 16

SENSS: Attack scenario

16

Devise mitigation strategy SENSS server SENSS server Attacker Victim

slide-17
SLIDE 17

SENSS: Attack scenario

17

Traffic control request SENSS client SENSS server Attacker Victim

slide-18
SLIDE 18

SENSS: Attack scenario

$

18

SENSS server authenticates requests SENSS client Attacker Victim

slide-19
SLIDE 19

SENSS: Attack scenario

$

19

SENSS server charges client SENSS client Attacker Victim

slide-20
SLIDE 20

SENSS: Attack scenario

Apply control request

20

SENSS client Attacker Victim

slide-21
SLIDE 21

SENSS: Attack blocked

Attack traffic blocked!

21

SENSS client Attacker Victim

slide-22
SLIDE 22

SENSS: Labor division

22

Intelligence at victim

slide-23
SLIDE 23

SENSS: Incentives for ISPs

$ $

With incentives!

23

Simple implementation at ISP

slide-24
SLIDE 24

SENSS: Secure

24

Queries only on client’s owned prefixes SENSS server verifies prefix

  • wnership

Communication secured by TLS

slide-25
SLIDE 25

SENSS API

Type Response from SENSS server Traffic Query Traffic stats matching predicates

25

slide-26
SLIDE 26

SENSS API

Type Response from SENSS server Traffic Query Traffic stats matching predicates Route Query AS paths from SENSS server to prefix

26

slide-27
SLIDE 27

SENSS API

Type Response from SENSS server Traffic Query Traffic stats matching predicates Route Query AS paths from SENSS server to prefix Traffic filter Adds filter matching predicate

27

slide-28
SLIDE 28

SENSS API

Type Response from SENSS server Traffic Query Traffic stats matching predicates Route Query AS paths from SENSS server to prefix Traffic filter Adds filter matching predicate Route demote Demotes AS path from SENSS server to prefix with certain path segment

28

slide-29
SLIDE 29

SENSS API

Type Response from SENSS server Traffic Query Traffic stats matching predicates Route Query AS paths from SENSS server to prefix Traffic filter Adds filter matching predicate Route demote Demotes AS path from SENSS server to prefix with certain path segment

29

Each traffic query/control consists of a predicate matching flow(s)

  • Supports various packet header fields
  • Different packet header fields can be combined using negation,

conjunction, disjunction and wildcard

slide-30
SLIDE 30

SENSS Server Implementation

  • Queries to SENSS server can be

implemented using Openflow or Netflow+ACL

  • SENSS server receives requests

from clients, authenticates and sends appropriate replies

  • SENSS server also co-ordinates

with various border routers within the same ISP and gathers statistics

SENSS Server SENSS ISP

30

slide-31
SLIDE 31

Overview

  • Introduction
  • SENSS
  • Architecture
  • SENSS API
  • SENSS client programs
  • Security and robustness
  • Evaluation
  • Conclusion

31

slide-32
SLIDE 32

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

32

Legit traffic from L1 and L2

slide-33
SLIDE 33

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

33

Periodic traffic query to S1, S2 and S3

slide-34
SLIDE 34

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

34

Replies S1: 1000 Mbps S2: 0 Mbps S3: 400 Mbps

slide-35
SLIDE 35

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

35

Attack from A

slide-36
SLIDE 36

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

36

More attack from B, C and D

slide-37
SLIDE 37

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

37

Periodic traffic query to S1, S2 and S3

slide-38
SLIDE 38

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

38

Replies S1: 1000 Mbps S2: 500 Mbps S3: 750 Mbps

slide-39
SLIDE 39

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

39

Replies S1: 1000 Mbps S2: 500 Mbps S3: 750 Mbps Replies S1: 1000 Mbps S2: 0 Mbps S3: 400 Mbps

slide-40
SLIDE 40

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

40

Replies S1: 1000 Mbps S2: 500 Mbps S3: 750 Mbps Unusual traffic from S2 and S3 Replies S1: 1000 Mbps S2: 0 Mbps S3: 400 Mbps

slide-41
SLIDE 41

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

41

Traffic filter at S3 Traffic filter at S2

slide-42
SLIDE 42

V S1 S2 S3 L1 L2 A B C D

DDoS without signature attack

42

Attack stopped at S2 and S3!

slide-43
SLIDE 43

Overview

  • Introduction
  • SENSS
  • Architecture
  • SENSS API
  • SENSS client programs
  • Security and robustness
  • Evaluation
  • Conclusion

43

slide-44
SLIDE 44

Securing communication

  • SENSS allows client to issue requests only to its own prefixes
  • SENSS client binds a proof of ownership certificate with every request
  • Proof can be created using RPKI Route Origin Authorization (ROA)

certificates

  • Alternatively we can issue custom certificates
  • Communication between SENSS client and SENSS server is secured

using TLS and occurs over HTTPS

  • If the privacy of key is compromised, SENSS server can purge all existing client

requests

44

slide-45
SLIDE 45

Challenges

  • Router’s TCAM space is limited
  • Coarse rules are enough to mitigate large volumetric attack
  • Finer rules can be prevented by SENSS ISP’s or discourage users by charging

higher prices

  • ISP’s privacy concerns
  • Traffic replies can contain anonymized ID’s to cover neighboring peers
  • ISP is in control
  • Can reject demote requests which may not be optimal

45

slide-46
SLIDE 46

Handling misbehavior

  • SENSS clients have low incentive to misbehave
  • Excessive requests are unlikely as clients need to pay for each request
  • Requests can be made only for their own prefixes
  • SENSS servers could lie about observations and/or fail to implement

control actions

  • Legacy: Lie about client’s traffic and make it look smaller, increasing the cost
  • f client but does not drop traffic
  • Dropper: Lie about client’s traffic and make it look larger causing client to

issue traffic control to drop traffic

  • But dropper liars are already on the path of traffic, SENSS does not make it worst

46

slide-47
SLIDE 47

Overview

  • Introduction
  • SENSS
  • Architecture
  • SENSS API
  • SENSS client programs
  • Security and robustness
  • Evaluation
  • Conclusion

47

slide-48
SLIDE 48

Evaluation objectives

  • Extent of SENSS adoption by ISP required for effective protection?
  • 0.7—3.8% deployment of SENSS in large ISPs can protect most customers
  • How will different customers benefit from SENSS adoption?
  • All direct single homed customers of SENSS ISPs are protected from direct

floods and reflector attacks

  • 90% of direct multi homed or remote customers are protected from floods

without signature and reflector attacks with just 1—3.8% of SENSS adoption

  • SENSS comparison with existing cloud solutions
  • SENSS outperforms all after 0.4% of top transit deployment

48

slide-49
SLIDE 49

Evaluation objectives

  • Extent of SENSS adoption by ISP required for effective protection?
  • 0.7—3.8% deployment of SENSS in large ISPs can protect most customers
  • How will different customers benefit from SENSS adoption?
  • All direct single homed customers of SENSS ISPs are protected from direct

floods and reflector attacks

  • 90% of direct multi homed or remote customers are protected from floods

without signature and reflector attacks with just 1—3.8% of SENSS adoption

  • SENSS comparison with existing cloud solutions
  • SENSS outperforms all after 0.4% of top transit deployment

49

slide-50
SLIDE 50

Evaluation objectives

  • Extent of SENSS adoption by ISP required for effective protection?
  • 0.7—3.8% deployment of SENSS in large ISPs can protect most customers
  • How will different customers benefit from SENSS adoption?
  • All direct single homed customers of SENSS ISPs are protected from direct

floods and reflector attacks

  • 90% of direct multi homed or remote customers are protected from floods

without signature and reflector attacks with just 1—3.8% of SENSS adoption

  • SENSS comparison with existing cloud solutions
  • SENSS outperforms all after 0.4% of top transit deployment

50

slide-51
SLIDE 51

Evaluation objectives

  • Extent of SENSS adoption by ISP required for effective protection?
  • 0.7—3.8% deployment of SENSS in large ISPs can protect most customers
  • How will different customers benefit from SENSS adoption?
  • All direct single homed customers of SENSS ISPs are protected from direct

floods and reflector attacks

  • 90% of direct multi homed or remote customers are protected from floods

without signature and reflector attacks with just 1—3.8% of SENSS adoption

  • SENSS comparison with existing cloud solutions
  • SENSS outperforms all after 0.4% of top transit deployment

51

slide-52
SLIDE 52

Evaluation

  • Conducted emulation and simulation over AS-level topology
  • Used two strategy for SENSS server deployment
  • Top: SENSS is deployed in top N ASes ordered in decreasing customer size
  • Random: SENSS is randomly deployed in N Ases
  • Two types of traffic
  • Uniform: Attack traffic are equally distributed among random ASes
  • Realistic: Attack traffic from only from residential network hosting Mirai

botnet

52

slide-53
SLIDE 53

DDoS without signature

  • SENSS is very effective in sparse

deployment

  • Deployment of 1.5% of top ASes

achieves 90% for direct/single homed customer

  • Deployment of 3.8% of top ASes

achieves 90% of multi homed customers and remote customers

20 40 60 80 100 0.01 0.1 1 10 % attack fltered % transit ASes deploying SENSS uni-dir-single real-dir-single uni-dir-multi real-dir-multi uni-remote real-remote

53

slide-54
SLIDE 54

Comparison of SENSS with cloud deployments

  • Estimate saved bandwidth by

SENSS and cloud deployment strategies

  • Saved bandwidth is the difference

between bandwidth consumed with and without defense strategy

  • Ideal solution would have 100% saved

bandwidth

  • Existing solution save 13—46%
  • For 10% deployment, SENSS saves

60% of bandwidth, 1.5—8 times more bandwidth than others

  • 54
slide-55
SLIDE 55

Overview

  • Introduction
  • SENSS
  • Architecture
  • SENSS API
  • SENSS client programs
  • Security and robustness
  • Evaluation
  • Conclusion

55

slide-56
SLIDE 56

Conclusion

  • SENSS is a collaborative defense where victims under volumetric

DDoS attacks can request help from upstream ISPs

  • SENSS API provides building blocks for clients to build custom defense

to mitigate attacks

  • SENSS servers are simple to deploy with monitory incentives to ISPs
  • SENSS is effective in sparse deployment
  • SENSS is more effective in saving bandwidth than other existing cloud

based defense

56