[191626] in North American Network Operators' Group
Re: Krebs on Security booted off Akamai network after DDoS attack
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Fri Sep 23 21:00:28 2016
X-Original-To: nanog@nanog.org
Date: Fri, 23 Sep 2016 14:24:53 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: nanog@nanog.org, Sven-Haegar Koch <haegar@sdinet.de>,
Mike <mike-nanog@tiedyenetworks.com>
In-Reply-To: <alpine.DEB.2.20.1609232114400.25723@aurora.sdinet.de>
Errors-To: nanog-bounces@nanog.org
------2WKPPOUPJM9HJ9YGAGA1JCP4SI8IA9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On September 23, 2016 12:15:26 PM PDT, Sven-Haegar Koch <haegar@sdinet=2Ed=
e> wrote:
>On Fri, 23 Sep 2016, Mike wrote:
>
>> On 09/23/2016 11:30 AM, Seth Mattinen wrote:
>> > On 9/23/16 10:58, Grant Ridder wrote:
>> > > Didn't realize Akamai kicked out or disabled customers
>> > >
>http://www=2Ezdnet=2Ecom/article/krebs-on-security-booted-off-akamai-netw=
ork-after-ddos-attack-proves-pricey/
>
>> > >=20
>> > > "Security blog Krebs on Security has been taken offline by host
>Akamai
>> > > Technologies following a DDoS attack which reached 665 Gbps in
>size=2E"
>> >=20
>> >=20
>> > So ultimately the DDoS was successful, just in a different way=2E
>> >=20
>> > ~Seth
>> >=20
>> >=20
>> More technical information about the characteristics of these attacks
>would be
>> very interesting such as the ultimate sources of the attack traffic
>> (compromised home pc's?), the nature of the traffic (dns / ssdp
>> amplification?), whether it was spoofed source (BCP38-adverse), and
>whether
>> the recent takedown the vDOS was really complete or if it's likely
>someone
>> else gained control of the C&C servers that controlled it's assets?
>
>At least for the OVH case there is a bit of info:
>
>https://twitter=2Ecom/olesovhcom/status/779297257199964160
>
>"This botnet with 145607 cameras/dvr (1-30Mbps per IP) is able to send=20
>>1=2E5Tbps DDoS=2E Type: tcp/ack, tcp/ack+psh, tcp/syn=2E"
Krebs said it was mostly GRE=2E Pulling from the archive=2Eorg copy of his=
post[1]:
"Preliminary analysis of the attack traffic suggests that perhaps the bigg=
est chunk of the attack came in the form of traffic designed to look like i=
t was generic routing encapsulation (GRE) data packets=2E=2E=2E"
This bothered me, though:
"McKeay explained that the source of GRE traffic can=E2=80=99t be spoofed =
or faked the same way DDoS attackers can spoof DNS traffic=2E"
Please tell me why I can't spoof source IPs on a stateless protocol like G=
RE=2E If he specifically meant you can't spoof a source, hit a reflector, a=
nd gain amplification, sure, but I see zero reason why GRE can't have spoof=
ed source IPs=2E It bothered me sufficiently that I wrote up some spit-ball=
ing ideas about reflecting GRE using double encapsulation[2]=2E Very rough =
and untested, but apparently I got a bee in my bonnet=2E=2E=2E
>c'ya
>sven-haegar
>
>--=20
>Three may keep a secret, if two of them are dead=2E
>- Ben F=2E
--=20
Hugo Slabbert=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | email, xmpp/jabber: hu=
go@slabnet=2Ecom
pgp key: B178313E=C2=A0=C2=A0 | also on Signal
[1] https://web=2Earchive=2Eorg/web/20160922021000/http://krebsonsecurity=
=2Ecom/2016/09/krebsonsecurity-hit-with-record-ddos/
[2] http://blog=2Eslabnet=2Ecom/post/gre-reflection/
------2WKPPOUPJM9HJ9YGAGA1JCP4SI8IA9
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
iQI+BAABCgAoIRxIdWdvIFNsYWJiZXJ0IDxodWdvQHNsYWJuZXQuY29tPgUCV+Wd
pQAKCRBbJ4QQG9ipgKHJD/sHIJqNugqY61rhtMCBauB2+hYgiEGhkhuPyxXyFMYc
Qz99S9ya/AXekX3TfboSVF10Q3J2R/MK+nb0sMWokXxcrVGWYraMgb/sPbfOt3Ps
eQWygCD7RvGIvyHK+K0vDNEWtLOVNa5RV6Zhdvr8h36jOlZ6vWXKgavPMrZYEJSF
uHCJW+B/LVnnCwMflGfL0P/qWU39GPB62ZYo6ZaPuTg3cI9clpJ69sl+FrRVDoQg
nlvQiWvwn8tiszJhVga4qEPqCofsu5IFjHTbstiNjnyNylh5uHVszsc9MUAkLxx8
TFgrYqOR1CoOyNqoiWdWm9obNf80WwpMkzL5WWFAwNGjsRsT8LFXHVl0TLpGRDev
E/jPia+rs3Wvg84916Np+DvV1j/YCAfVJptvi0eIuPl3ajSh2P5ZHKXaIAxywYNh
lC13gV0Aks0UuAOH07fzr9lMxz8Ut4raOKFVNnP7oeWIHuNR4Mg/BqOSyJxgzP52
n90eJ0PwcEmCqgCcdjP7xrNA6BtsJ7TTtCR+GRNy8fD1yhMwCsFoAo/OFXQlO1iu
hCokB//T5fZKCoLDYRJ10B8NQYIQrVfGIsCC6FxBdxcQpge0cAbAIgKr6pJHGlfT
4fZXWgbT6S0tI9s/B87lO07ctK3Q/QqOnJ/kNhSbpUR2GSUKIjzOa/13vgnsULKl
uw==
=PrrV
-----END PGP SIGNATURE-----
------2WKPPOUPJM9HJ9YGAGA1JCP4SI8IA9--
