Krebs on Security booted off Akamai network after DDoS attack proves pricey

Fri Sep 23 22:00:31 UTC 2016

A similar GRE attack was used against the Olympics:

"Once the Olympics got under way, LizardStresser along with a few other botnets ramped up their attack against organizations affiliated with the Olympics. The DDoS campaign launched attack traffic using the lesser-known IP protocol Generic Routing Encapsulation (GRE).”

 -mel

On Sep 23, 2016, at 2:39 PM, Hugo Slabbert <hugo at slabnet.com<mailto:hugo at slabnet.com>> wrote:

On Fri 2016-Sep-23 17:29:59 -0400, Jared Mauch <jared at puck.nether.net<mailto:jared at puck.nether.net>> wrote:

On Sep 23, 2016, at 5:24 PM, Hugo Slabbert <hugo at slabnet.com<mailto:hugo at slabnet.com>> wrote:

Please tell me why I can't spoof source IPs on a stateless protocol like GRE. If he specifically meant you can't spoof a source, hit a reflector, and gain amplification, sure, but I see zero reason why GRE can't have spoofed source IPs. It bothered me sufficiently that I wrote up some spit-balling ideas about reflecting GRE using double encapsulation[2]. Very rough and untested, but apparently I got a bee in my bonnet...

my guess is the GRE traffic was harder to filter because many providers use GRE to deliver ‘clean’ traffic back to origin sites.

But those tunnels generally wouldn't terminate on addresses within the protected block.  If I'm protecting 192.0.22.0/24 for you, things would get confused if my GRE tunnel dest is somewhere in 192.0.22.0/24 because I would have a route for 192.0.22.0/24 across the GRE tunnel (either static or more conventionally learned via BGP).  I'd bank it on either a provider touchdown or another unprotected block, otherwise I'd have a recursive routing issue where the tunnel destination would get routed through the GRE tunnel.  I've been there with bouncy-bouncy tunnels on service turn-up when that was flubbed.

Alternatively, I could pin /32s for the tunnel destinations and still learn the shorter protected block, but even so I should then know which source (my) and dest (customer's) IPs to exclude explicitly from the GRE filtering.

If the attackers were hitting the GRE tunnel destination and spoofing the tunnel source that would make things harder, but that's starting to get into rather intimate knowledge of the scrubber's and customer's setup.  I could still probably filter on e.g. TTLs or drop GRE further up to the northern edge on input rather than output, but agreed that is starting to get trickier...

- Jared

--
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com<mailto:hugo at slabnet.com>
pgp key: B178313E   | also on Signal