[AusNOG] NTP Reflection coming in over Equinix IX

[James Braunegg]

Dear All



For those interested I updated my DDoS NTP attack info page with additional information regarding NTP attack packet sizes as per Roland's information and also included an NTP DDoS attack graph showing mitigation via edge packet filtering.



Updates can be found here - http://www.micron21.com/ddos-ntp/



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: Monday, February 17, 2014 3:15 PM
To: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] NTP Reflection coming in over Equinix IX





On Feb 14, 2014, at 7:43 AM, James Braunegg <james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>> wrote:



>  I'll email you the pcap file for an off line discussion would be interesting to see if different version of wire shark show different data...



James and I've already corresponded, here's what's apparently going on - the ntp RFCs state that ntp packets should be padded with 0s in order to fit a 64-bit boundary, and different attack tools/mechanisms perform differing amounts of padding.



Here's a breakdown in terms of observed monlist packet sizes:



ntp attack tool used in this most recent spate of attacks - 50 bytes, per James' weblog post.



ntpdos.py - 60 bytes



ntp_monlist.py = 234 bytes



monlist, sysstat, et. al. from ntpdc/ntpq - 234 bytes



So, the monlist packet-size varies based upon the amount of padding implemented by each tool author.



The one constant I've found is that regular ntp time-sync requests are ~90 bytes in size.  So, blocking traffic at the relevant edges destined for UDP/123 with a size of 50 byes, 60 bytes, and 234 bytes appears to be a non-destructive way of dropping level-6/-7 admin commands whilst still allowing time-sync to function.  Be sure and pilot this prior to general deployment, though.



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

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/20140217/659588d5/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/20140217/659588d5/attachment.jpg>