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

[Mel Beckman <mel () beckman org>]

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 () slabnet com<mailto:hugo () slabnet com>> wrote:


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


On Sep 23, 2016, at 5:24 PM, Hugo Slabbert <hugo () slabnet com<mailto:hugo () 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 () slabnet com<mailto:hugo () slabnet com>
pgp key: B178313E   | also on Signal