• Save
Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

nanog nanog Presentation Transcript

  • How to Mitigate a 300G DDoSTom PasekaNetwork Engineertom@cloudflare.com
  • 2www.cloudflare.comBackground…
  • 3www.cloudflare.comBackground…
  • 4www.cloudflare.comScrubbing….• The Beginning
  • 5www.cloudflare.com• Spamhaus were under attack• They didn’t have resources to keep their website online• Spamhaus moved to CloudFlare• Attack was approximately 75Gbps• Website back online!• Attack vector was very simple to mitigate• DNS Amplification / Reflection.• Easy to filter… If you have the capacityThe Start
  • 6www.cloudflare.comAfter a bit of thisThe Start
  • 7www.cloudflare.comI was feeling a bit like thisThe Start
  • Then…. It happened
  • 9www.cloudflare.com• The Attackers realised the volume and method of attackwouldn’t bring the website offline• They went after CloudFlare’s infrastructure directly.• They would traceroute to www.spamhaus.org• Direct the attack to the last routable IP beforewww.spamhaus.org• This was our upstream point-to-point interfaces and otherinfrastructure• Volume reached >300GbpsIncreased Volume
  • 10www.cloudflare.com• Ouch.• But, it can be mitigated.• After some time speaking to the NOC’s of our upstreams theygave us some• Re-numbered and or filtered the IP space• Some to point-to-points were renumbered to RFC-1918address space• Others placed filters at their edges• Others blackholed the P2P IPsIncreased Volume
  • 11www.cloudflare.com• Attackers saw this was no longer effective• The attackers traceroutes showed they could reach us via AMS-IX,DE-CIX, LINX, Equinix SG and HKIX.• Their attacks were directed towards our IP’s on the exchange fabric• Ouch.• We can’t renumber these interfaces [easily].• We can’t filter these interfaces upstream.• Only mitigation tactic for us was to disable the ports.Change of Tactic
  • 12www.cloudflare.com• After leaving the port out of action for a few hours, the attack wouldstop• Attackers were monitoring our routing, if they saw we activated peerson the exchange, they’d begin attacking again.• We reached out to peers, exchange point operators to see whatcould be done.• Some exchange points were originating/announcing the fabric IPspace to the default free zone, and attracting the attack traffic• Other peers on the fabric also originating/announcing exchange IPspaceOngoing attacks
  • What you should do?
  • 14www.cloudflare.comWhat you should do?• Consider the numbering if your infrastructure• If it’s non-routable, its more difficult to attack it.• Proper infrastructure ACLs• Have good upstream providers• They should all support BGP signaling for black-holing• Ability to push firewall rules quickly• We use and love flowspec (even if we hit bugs)• Don’t announce Internet Exchange IP space to the internet• Don’t even carry it in your backbone if you can!(set next-hop self)
  • 15www.cloudflare.comWhat you should do?BCP-38If your network allows spoofing, you should fix it right now.Then, hang your head in shame.Check if the network your attached to supports spoofing by installing testfrom: http://spoofer.cmand.org/
  • 16www.cloudflare.comWhat you should do?
  • 17Questions?
  • 18Thank You