ntp allow mode control

[jason.menningen]

Hi all,

  Like many I am trying to stop the DOS attacks using ntp mode 6 control.  We do have ACLs configured to guard against this attack however, the vulnerability scanner that our organization uses still shows it as an open.  I know there is the command "no ntp allow mode control" which I believe would stop the vulnerability, but obviously that isn't a desired route of action or this would have been put to bed long ago.  What I can not find is how allowing or disabling the ntp mode control actually effects the operational ntp.  Can someone answer or direct me to some article that clearly defines what effect the commands "ntp allow mode control' and "no ntp allow mode control" does?   

[balaji.bandi]

is the router expose to internet ? then ACL is best way to prevent and allow only required destination to sync with NTP as source.

what is the device here, what code running, what is now confiogure, post the config will help to understand the issue.

[jason.menningen]

Hi Balaji,

                Thank you for your response.  The devices in question are our external routers, CISCO3945-CHASSIS, utilizing a C3900-SPE150/K9 Performance Engine and running IOS 15.7(3)M8.  Below are my redacted NTP configs.

sho run all | i ntp

ntp max-associations 100

 permit udp host XXX.XXX.XXX.YYY any eq ntp

 permit udp host XXX.XXX.XXY.YYY any eq ntp

 permit udp host XXX.XXX.XYY.YYY any eq ntp

 deny   udp any any eq ntp log-input

access-list AAA permit udp host XXX.XXX.XXX.YYY any eq ntp log

access-list AAA permit udp host XXX.XXX.XXY.YYY any eq ntp log

access-list AAA permit udp host XXX.XXX.XYY.YYY any eq ntp log

access-list AAA deny   udp any any eq ntp log

ntp logging

ntp allow mode control 3

ntp leap-handle

ntp authentication-key AA md5 XXXXXXXXXXXXXXXXXXXXXXXXX

ntp authentication-key BB md5 XXXXXXXXXXXXXXXXXXXXXXXXXXX

ntp authentication-key CCC md5 XXXXXXXXXXXXXXXXXXXXXXXXX

ntp authenticate

ntp trusted-key AA

ntp trusted-key BB

ntp trusted-key CCC

ntp mindistance 1

ntp maxdistance 8

ntp source Loopback0

ntp master 2

ntp update-calendar

ntp server XXX.XXX.XXX.YYY key BB maxpoll 10 minpoll 6 prefer version 4 burst iburst

ntp server XXX.XXX.YYY.YYY key CCC maxpoll 10 minpoll 6 version 4 burst iburst

ntp server XXX.XXX.XYY.YYY key BB maxpoll 10 minpoll 6 version 4 burst iburst

[Georg Pauwen]

Hello,

here is how I understand it to work:

ntp allow mode control 0 --> causes the device to respond to mode 6 packet without delay (not recommended)
ntp allow mode control 3 --> causes the device to respond to mode 6 packet with a delay of 3 seconds, hence rate limiting and being considered not vulnerable (recommended)
no ntp allow control mode --> drops any mode 6 packet received

[jason.menningen]

Hi Georg,

  Thank you for your response.  That is exactly what I am seeing in my research of this problem.  My question though is: If this can be remedied by simply inputting the command "no ntp allow control mode", then why is it still an issue?  What are the benefits/disadvantages to enabling/disabling control mode?  How do the ntp control packets actually effect the operation of ntp?

These are the answers that I am trying to find to make a educated suggestion to my leadership.

[Georg Pauwen]

Hello,

as far as I understand it, the NTP control packets are necessary for NTP to function at all. Without, NTP won't work. I don't know if that is correct to be honest, I don't have a device to test this on. What if you configure 'no ntp allow mode control', then run a 'debug ntp all', is there any output ?

[jason.menningen · Accepted solution]

Hello All,

                Thank you to Georg Pauwen and balaji.bandi for trying to help me find my answer.  It took me a long time to find this and now that I have I’m a little upset and despondent that others haven’t found the same.  I hope others with the same issue find this so they can use it.

                NTP Control Messages (mode) 6 were historically used with the Network Time Protocol before the advent of more modern control and management approaches.  These control messages have been used to monitor and control the Network Time Protocol application running on any IP network attached device.  This facilitates the specification and implementation of simple management tools in the absence of fully evolved network-management facilities.

                NTP mode 6 control messages are usually small UDP packets.  Fast-scanning tools like ZMap can be used to spray the entire (potentially reachable) Internet with these messages within hours to identify vulnerable hosts.  To make things worse, these attacks can be extremely low-rate, only requiring a control query for reconnaissance and a spoofed response to shift time on vulnerable clients.  The mode 6 and 7 messages are vulnerable to replay attacks [CVE-Replay].  If an attacker observes mode 6/7 packets that modify the configuration of the server in any way, the attacker can apply the same change at any time later simply by sending the packets to the server again.

                NTP best practices recommend configuring ntpd with the no-query parameter.  The no-query parameter blocks access to all remote control queries.  However, sometimes the hosts do not want to block all queries and want to give access for certain control queries remotely.  This could be for the purpose of remote management and configuration of the hosts in certain scenarios.  Such hosts tend to use firewalls or other middleboxes to blacklist certain queries within the network.

In Summary:

    NTP Control Message queries are an outdated function of NTP that assisted in Network Management (NM) functions before better NMs were created and utilized.  Unless your organization is still using NTP for NM functions the Network Security Best Practices are to completely disable them all together.  If you are using them, they should be an internal network only type service that is blocked by firewall or other external device.  They have even been removed from all but standard IOS and IOS-XE versions as IOS-XR and NX-OS does not support them. 

    If you choose as I do to disable this outdated feature the command is “no ntp allow mode control”.  This command will then show up in the running-config as “no ntp allow mode control 0”.  I added this command to an IOS router that was both receiving time from an external time source and providing time to my internal devices.  I also ran debug ntp all after implementation and found no loss of ntp operation or debug errors of any kind.  Finally I debugged one of my internal IOS switches that gets its time from the previously mentioned router before and after adding the command to the switch itself.  The result was no loss of ntp operation or found debug errors of any kind. 

    The site that gave me the most information on the function/packets/service was: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mode-6-cmds-06

[joel-welliver]

   This is very helpful, however my Router does not support “no ntp allow mode control”. My only option is “no ntp allow mode private". I have read that in private mode NTP packets will be blocked by default. I am not 100% clear on the difference between "control mode" and "private mode". Do these perform the same task?

[jbganaden]

Hi,

using the command "no ntp allow control", will the existing NTP synchronization will not be affected?

Thanks.

[Georg Pauwen]

Hello,

that is very useful information. So disabling these control packets does not affect NTP operation at all. Thanks for posting !