[AusNOG] NTP Reflection coming in over Equinix IX

[James Braunegg]

Dear Roland



In our hands in the wild we have seen the inbound request packet being 50 bytes in length.



Have a read here for more information - http://www.micron21.com/ddos-ntp  would value your input on the wire shark capture which is "wild" attack traffic.



Kindest Regards


James Braunegg
P:  1300 769 972  |  M:  0488 997 207 |  D:  (03) 9751 7616
E:   james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>  |  ABN:  12 109 977 666
W:  www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection>   T: @micron21


[Description: Description: Description: Description: M21.jpg]
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

-----Original Message-----
From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Dobbins, Roland
Sent: Friday, February 14, 2014 1:23 AM
To: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] NTP Reflection coming in over Equinix IX





On Feb 13, 2014, at 11:51 AM, James Braunegg <james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>> wrote:



> If you can filter on packet size you should find the attack request for the inbound NTP request is 50bytes in size, i



FWIW, regular ntp sync requests and responses are ~90 bytes in size on an Ethernet network (i.e., a bit of framing overhead, plus IP and UDP); non-sync requests (i.e., monlist, et. al.) seem to be ~234 bytes in size on Ethernet networks, with the responses of course being much larger.



You have to be careful when filtering with ACLs or flowspec on the reflector/amplifier - target leg of the attack, because the bulk of the attack payload is non-initial UDP fragments, and you have to have some understanding of what apps/services the attack target is running/using in order to figure out how to deal with that.



One way to do it is to permit all UDP/53-sourced traffic to the target, drop all UDP/123 larger than, say, 200 bytes (just to give a bit of overhead), and then to drop UDP non-initial fragments to the target.  The potential problem with this is breaking large, fragmented EDNS0/DNSSEC responses, and/or any other UDP apps/services in use by the target which utilize large UDP messages which may well be fragmented.



For a lot of targets, that won't matter, as they aren't directly accessing DNS servers across the public Internet (they're using local recursors, for example, which aren't targeted in the attack and are southbound of the mitigation filtering), or other UDP stuff which uses large, potentially-fragmented UDP messages.  But for some, it will matter, and so that's why knowledge of the target details is necessary in order to figure out how to provide the best possible partial service recovery quotient during an attack.



Filtering UDP/123-destined packets of ~234 bytes in length (the source ports are generally ephemeral, as these commands are actually generated by non-privileged client utilities like ntpdc and ntpq) is one way to prevent level-6/-7 commands used to stimulate reflection/amplification on the attack-source - reflector/amplifier leg of the attack from ever reaching the reflectors/amplifiers.



-----------------------------------------------------------------------

Roland Dobbins <rdobbins at arbor.net<mailto:rdobbins at arbor.net>> // <http://www.arbornetworks.com>



                  Luck is the residue of opportunity and design.



                                       -- John Milton



_______________________________________________

AusNOG mailing list

AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>

http://lists.ausnog.net/mailman/listinfo/ausnog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140214/472c7d6d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2683 bytes
Desc: image001.jpg
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140214/472c7d6d/attachment.jpg>