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

Fri Sep 23 21:39:54 UTC 2016

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

>
>> On Sep 23, 2016, at 5:24 PM, Hugo Slabbert <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
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160923/ca87d48a/attachment.sig>