TA904 - NTP process_private: INFO_ERR_FMT: test 1 failed

[bama]

I've got a TA904 (and probably soon others) running T900G2A-A5-03-00-E.biz that are being flooded with the following output in the console.

2014.02.11 17:05:20 NTP process_private: INFO_ERR_FMT: test 1 failed, pkt from 185.28.23.29

2014.02.11 17:05:21 NTP process_private: INFO_ERR_FMT: test 1 failed, pkt from 185.28.23.29

2014.02.11 17:05:21 NTP process_private: INFO_ERR_FMT: test 1 failed, pkt from 185.28.23.29

2014.02.11 17:05:21 NTP process_private: INFO_ERR_FMT: test 1 failed, pkt from 185.28.23.29

The router is not configured to act as a time server so that's probably why it's failing.  I did upload T900G2A-R10-8-0-E.biz to the router but I can't reboot it until after midnight tonight.    Is there a preferred way to defend a TA900 from this type of attack?  Currently I've null routed the traffic at the edge of my network but I would prefer to find a better way to drop this. 

[jayh]

There are widespread DDoS attacks on the Internet within the last few weeks relating to NTP.  The bad guys are looking for NTP servers that respond to a small packet with a large amount of return traffic, referrred to as amplification.  Because NTP is UDP based, the object is to spoof the victim's source address and send a flood of small trigger packets to several vulnerable servers which then flood the victim with massive amounts of data, overwhelming the ultimate target network. 

I'm not sure of the exact interpretation of the Adtran error message.  It may mean that the TA904 is receiving the results of an attack directed towards it, or that it or a device behind it is being probed for vulnerability.

You can query your network for vulnerable servers here, substituting your network's IP for x.x.x.x.   http://openntpproject.org/search2.cgi?botnet=yessir&search_for=x.x.x.x

This will respond with a list of known vulnerable devices within the /22 of the IP in question.

More info:

http://www.kb.cert.org/vuls/id/348126

https://isc.sans.edu/forums/diary/NTP+reflection+attack/17300

Bottom line, unless you need a device on your network to act as a time server to outside hosts (and you probably don't), deny inbound UDP traffic with a destination port of 123 from entering your network. 

[Anonymous]

Bama,

Thanks for posting.  Just to add Jay's response above, we do have a feature which may be beneficial to you.  In all firmware versions, we should be able to block NTP using an access-policy or an access-group on the interface.  However, in versions R10.7.0 and higher, we have an NTP access class.  Below is an example configuration.

ip access-class standard NTP_Servers

  permit host x.x.x.x

!

ntp ip access-class NTP_Servers in

This will restrict NTP inbound to the unit to only those IP addresses specified in the ACL.

Thanks!

David

[Anonymous]

I think the first line should be:

ip access-list standard NTP_Servers

---

Does this also help SNTP server attacks? I did not see any AOS option for "sntp ip access-class"