Blackholing from a_providers_perspektive_theo_voss

Blackholing from a Provider’s perspectiveTheo Voss / Network Engineer SysEleven GmbH (AS25291)

DE-CIX Technical MeetingFrankfurt, 29.06.2016

Who is SysEleven?

Managed Hoster and Upstream-Provider, founded in 2007.300+ customers, PoPs in Berlin, Frankfurt, Amsterdam.

2

DDoS attacks3

Source: https://www.reddit.com/r/pics/comments/2a22zd/server_blessing_in_poland/

Providers perspectiveUpstreams

Blackholing at upstreams

We’ve turned it on, but…

6

Blackholing at upstreams

Generally works, but:

not enabled by default

no common community

65535:666(https://tools.ietf.org/id/draft-ymbk-grow-blackholing-01.txt)

7

Providers perspectiveInternet Exchange Points

Blackholing at IXPs9

Blackholing at IXPs

But peers still do NOT accept..

• more-specifics for /24 & /48.

• rewrite of the next-hop

10

Blackholing at IXPs

DE-CIX supports it, let’s make it more successful. Modify your policy, accept blackhole announcements!

term IMPORT-DECIX-BLACKHOLE { from { next-hop 80.81.193.66; prefix-list-filter $PEER orlonger; route-filter 0.0.0.0/0 prefix-length-range /32-/32; } then { community add no-export; accept; } }

11

Unwanted Traffic Removal Servicehttps://www.cymru.com/jtk/misc/utrs.html

Source: https://www.team-cymru.org/UTRS

UTRS

Route-server based blackhole relay

13

announce /32 no-export 64496:0 receiving /32

with NH 192.0.2.1

UTRS

• RIPEstat API for route validation

• 142 networks connected • 9500 announcements yearly

14

SysEleven:

inet.0: 594972 destinations, 4408624 routes (591272 active, 0 holddown, 7418 hidden) Prefix Nexthop MED Lclpref AS path * 37.44.0.1/32 192.0.2.1 64496 25291 I

UTRS participant:

37.44.0.1/32 *[BGP/170] 02:23:40, localpref 200, from 154.35.**.** AS path: 64496 25291 I, validation-state: unverified Discard

UTRS

Implementation is easy. policy-statement 4-CYMRU-UTRS-OUT { term BLACKHOLE { from { community SYS11_BLACKHOLE; route-filter 0.0.0.0/0 prefix-length-range /32-/32; } then { community add CYMRU-UTRS_BLACKHOLE; community add no-export; next-hop 192.0.2.1; accept; } }

15

policy-statement 4-CYMRU-UTRS-IN { term BLACKHOLE { from { community CYMRU-UTRS_BLACKHOLE; route-filter 0.0.0.0/0 prefix-length-range /32-/32; } then { community add SYS11_BLACKHOLE; community add no-export; next-hop discard; accept; } }

Providers perspective

DDoS attack detection

FastNetMon

• Open-Source DDoS attack detection

• Based on user-defined thresholds • Uses NetFlow, sFlow, IPFIX & more.. • Support for Graphite, ExaBGP & more..

https://github.com/pavel-odintsov/fastnetmon

17

FastNetMon

In case of attack script will be triggered:

/usr/local/bin/notify_about_attack.sh

19

Providers perspective

Blackholing in case of attack


If there’s a DDoS detected: tvoss@router1# show | compare [edit routing-options flow] + route 109.68.230.206/32 { + match { + destination 109.68.230.206/32; + protocol udp; + port [ 0 4444 ]; + } + then { + discard; + }

21


If there’s a DDoS detected:

tvoss@router2> show route table inetflow.0

inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 109.68.230.206,*,proto=17,port=0,=4444/term:1 (1 entry, 1 announced) *BGP Preference: 170/-101 Next hop type: Fictitious Announcement bits (1): 0-Flow Communities: traffic-rate:0:0 Accepted Validation state: Accept, Originator: 37.44.7.60 Via: 109.68.230.0/24, Active

22


If we can’t handle the attack bandwidth:

23

Announce /24to Upstreams & DE-CIX

Start /32 blackholing toUpstreams, DE-CIX & UTRS

route 37.44.0.0/24 { next-hop $nexthop; community 25291:555; }

route 37.44.0.1/32 { discard; community 25291:666; }

route 37.44.0.0/24 { next-hop $nexthop; community 25291:444; }

Stop announcing/24 at DE-CIX

Blackholing in case of attack24

Upstreams more-specific attracts traffic

/32 will be discarded

/32 discard in sourcenetwork by UTRS

Source Networks

X

X

Thanks!