Down the Black Hole: Dismantling Operational Practices of ...effective mitigation strategy. Only 27%...

Down the Black Hole: Dismantling Operational Practices of BGP

Blackholing at IXPs

Marcin Nawrocki, Jeremias Blendin, Christoph Dietzel,Thomas C. Schmidt, Matthias Wählisch

The Internet suffers

DDoSThe problem!

BlackholingThe solution?

2

Common (mis) belief

Blackholing is an effective measure

to mitigate DDoS

3

Common (mis) belief

Blackholing is an effective measure

to mitigate DDoS

4

?

?

Our results. In a nutshell.

Blackholing drops only 50% of unwanted traffic.

Fine-grained blacklisting of attack signatures is an effective mitigation strategy.

Only 27% of Blackhole Events correlate with DDoS.

Other use cases exist for Blackholing but are very rare.

5

Efficiency Use Cases

Agenda

RecapHow does BGP Blackholing work at IXPs?

Deployment StatusHow well deployed is Blackholing in the real world?

Future EnhancementsHow should we configure fine-grained filtering?

7

I. How does BGP Blackholing work at IXPs?

8

https://en.wikipedia.org/wiki/Black_hole#/media/File:Black_hole_-_Messier_87_crop_max_res.jpg

Remotely-Triggered Blackholing at IXPs

9

IXP

Routeserver

Peer AS1

Peer AS3

Peer AS2Peering platform

WebserverVictim AS


10

IXP

Routeserver

Peer AS1

Peer AS3


WebserverVictim AS

DDoS Traffic

Legitimate Traffic


11

IXP

Routeserver

Peer AS1

Peer AS3


WebserverVictim AS

Blackhole

BGP Signal:RTBH for 1.2.3.4/32

IP: 1.2.3.4


12

IXP

Routeserver

Peer AS1

Peer AS3


WebserverVictim AS

Blackhole

BGP Signal:RTBH for /32That's the simple case.

BGP policies apply in the real world.

Remotely-Triggered Blackholing and BGP Policies

13

IXP

Routeserver

Peer AS1

Peer AS3


Webserver


Victim AS

BGP Rejection Policy

Remotely-Triggered Blackholing and BGP Policies

14

IXP

Routeserver

Peer AS1

Peer AS3


WebserverVictim AS

BGP Rejection Policy

Blackhole

II. How well deployed is BGP Blackholing in the real world?

15

https://www.deutschlandfunk.de/media/thumbs/9/94864ed50859e6db43efb6c572614a3av1_max_755x424_b3535db83dc50e27c1bb1392364c95a2.jpg?key=2814f7

Our measurement approach

One of the worlds-largest IXPs as a central vantage point

Wholistic view: >100 days, all related data - no exceptions!

16




BGP data

• All RTBH messages from all route-servers

• RTBH announcements identifiable by BGP community and next-hop-IP

17





Flow data

• All packets from/to prefixes, which have been blackholed at least once

• All packets which traverse the public switch-fabric (Sampling: 1/10000)

• Dropped packets identifiable by special MAC-address

18

DDoS Traffic

Legitimate Traffic




Flow data

• All packets from/to prefixes, which have been blackholed at least once

• All packets which traverse the public switch-fabric (Sampling: 1/10000)

• Dropped packets identifiable by special MAC-address

BGP data

• All RTBH messages from all route-servers

• RTBH announcements identifiable by BGP community and next-hop-IP

19

We verified: Time is in sync!

Do all IXP member accept RTBH announcements ?

20

Successful mitigation depends on the announced RTBH prefix length

21


22


23

/32-RTBHs have a mean drop rate of 50%.But they cover 99% of the to-be-blackholed traffic.

How fast do IXP members react to DDoS events?

24

Measurement challengeMultiple RTBHs cover the same attack

25


26


27

Multiple RTBHs!


28

Time-based clustering of RTBHs


29

What happens before RTBH Events?

Analysis of 72 hours before an RTBH Event

Use a sliding window algorithm (EWMA) to infer whether one of the monitored features exhibits an anomalous peak:

i. number of packets

ii. number of unique destination ports

iii. number of flows

iv. number of unique source IP addresses

v. number of non-TCP flows

30

Analysis of 72 hours before an RTBH Event

31

TCP SYN Attacks

GRE Floods

Amplification Attacks

Use a sliding window algorithm (EWMA) to infer whether one of the monitored features exhibits an anomalous peak:

i. number of packets

ii. number of unique destination ports

iii. number of flows

iv. number of unique source IP addresses

v. number of non-TCP flows

Most anomalies occur up to 10 minutes before an RTBH Event

32

Most anomalies occur up to 10 minutes before an RTBH Event

33

This short reaction time indicates automatic DDoS mitigation.

But: Anomalies before RTBH are uncommon!

34

Traffic ≤ 72 hours Anomaly ≤ 10 min % RTBH Events

✓ ✓ 27%

✓ ✗ 27%

✗ - 46%

WHY?

35

Other use-cases?

36

Prefix Squatting Protection

Prevent hijacking of address space that is assigned but not announced.

Prefix squatting is easy to deploy because there is no competitive announcement.

Deploy censorship by blackholing traffic to content servers.

Block malicious clients, e.g., port & vulnerability scanners.

ContentBlocking


37

Pre

fix

Len

gth

[b

its]

RTB

H E

ven

ts (l

og1

0)

Other use-cases?

38


Prevent hijacking of address space that is assigned but not announced.

Prefix squatting is easy to deploy becausethere is no competitive announcement.

Deploy censorship by blackholing traffic to content servers.

Block malicious clients, e.g., port & vulnerability scanners.

ContentBlocking

New use-cases are infrequent.70% of RTBH Events still inexplicable.

Vantage point bias?

1. Packet sampling and private-network-interconnections hide traffic.

39https://de.wikipedia.org/wiki/Datei:Iceberg.jpg

Vantage point bias?


2. ASes might announce RTBHs at all point-of-presence despite local attacks.

40https://de.wikipedia.org/wiki/Datei:Iceberg.jpg

Vantage point bias?


2. ASes might announce RTBHs at all point-of-presence despite local attacks.

But: Related work [IMC'18] using distributedmeasurements reached similar results!

41https://de.wikipedia.org/wiki/Datei:Iceberg.jpgJonker et al, A First Joint Look at DoS Attacks and BGP Blackholing, IMC 2018

III. How should we configure fine-grained filtering?

43

https://st.depositphotos.com/1021779/4520/i/950/depositphotos_45205477-stock-photo-three-ducklings-in-a-pond.jpg

RTBH - Pro and Con

RTBHs drop DDoS traffic early in the network.

RTBHs complete the attack, the victim is unreachable.

44

THE GOOD THE UGLY

RTBH - Pro and Con

RTBHs drop DDoS traffic early in the network.

RTBHs complete the attack, the victim is unreachable.

45

THE GOOD THE UGLY

Fine-grained filtering would keep a service reachable.

Whitelisting vs. blacklisting of ports

46

IXP

Routeserver

Peer AS1

Peer AS3


WebserverVictim AS

Blackhole

IP: 1.2.3.4Legitimate Traffic: Port 80 and 443

Challenge

We cannot whitelist client traffic, because client traffic is highly variable.

47

RadVizProjection

48

Visualizing multidimensional port information allows a classification into clients and servers

https://de.wikipedia.org/wiki/Datei:Jahn-Bergturnfest_2006_tug_of_war.jpg

RadVizProjection

49

number of different source ports

number of different destination ports

https://de.wikipedia.org/wiki/Datei:Jahn-Bergturnfest_2006_tug_of_war.jpg

Visualizing multidimensional port information allows a classification into clients and servers

Many blackholed IP addresses exhibit high port fluctuations

50

Many blackholed IP addresses exhibit high port fluctuations

51

Most of the protected IP addresses are clients.

Cross-validation using PeeringDB

52

Cross-validation using PeeringDB

53

Most clients located in DSL networks.PeeringDB supports our classification.

Potentials of fine-grained whitelisting?

Clients are often affected by BGP Blackholing.

Whitelisting of regular, expected traffic patterns is not an option.

54

Can we easily improve by blacklisting attack traffic?

55

Most RTBH traffic is UDP traffic

• >90% of RTBH Events (with packets and a preceding anomaly) contain almost exclusively UDP amplification traffic

• Multi-vector attacks are common, but usually do not utilize more than three amplification vectors:

56

Fine-Grained Blacklisting

Fine-grained filtering based on source-ports is very effective and potentially saves legitimate traffic!

Filter example: CharGEN/19, DNS/53, NTP/123

57

Summary. Advices for operators.

1. Check BGP policies.Accept more specific prefixes, in particular /32, in case of RTBH announcements.

2. Check routing tables for RTBH 'zombies'.Routing tables may contain many unnecessary/inexplicable RTBH entries. Contact peers to understand the RTBH use cases.

3. Consider fine-grained filtering.Majority of DDoS attacks are still not complex. Simple port-based blacklisting (ACLs, BGP Flowspec) can be very effective.

58

BACKUP SLIDES

Prefix Lengths and Traffic Share

60

AS Drop Consistency

61

RTBH Propagation Filter

62

Maximum RTBH Distance Δ

63

Attack Visibility and Sampling

• Median DDoS attack size in mid 2018 was 1287 Mbps

• Dividing by a MTU of 1500 Bytes, this corresponds up to 100k packets per second

• We expect to observe attacks despite sampling!

64

List of Amplification Protocols

65

Share of UDP Amplification Traffic

66

Sources of amplification attacks

67

EWMA and Anomaly Amplification Factor

68

Port Variance vs Port Stability

69

Challenges of Quantifying Collateral Damage

1. Servers and clients are victims of DDoS

2. Passive inference of services is biased by scans and spoofed traffic

3. Very sparse data outside of RTBH Events

4. Attack traffic might be also present outside of RTBH Events

5. Legitimate traffic pattern change during an attack

70

Collateral Damage for Servers

Classification Result

72

Down the Black Hole: Dismantling Operational Practices of ...effective mitigation strategy. Only 27%...

Documents

Transcript of Down the Black Hole: Dismantling Operational Practices of ...effective mitigation strategy. Only 27%...