Cisco 2960XR connecting to NTP server (ntp restriction)

[SJ K]

Hi all,

I have the following requirements ->

1) I need to connect my switch to an NTP server 192.168.4.5

2) My switch will only synchronize itself with 192.168.4.5

3) My switch will not respond or peer or handle any time query, control query with any other server.

In my switch, I configured the following

ntp server 192.168.4.5

ntp access-group peer 10

access-list 10 permit 192.168.4.5

q1) Can what I have configure fulfilled my above requests ? I do not want my switch to handle any other ntp queries at all with any other devices in the network.  Do I have to add anything else ?

q2) If I have created and ntp access-group but does not have the corresponding access list, does it means I will allow my device to peer with every other devices ?

WEB1#show ntp status
Clock is synchronized, stratum 3, reference is 192.168.1.6

ntp server 192.168.1.6 
ntp access-group peer 10  -- but I do not have any access list 10 defined.  why is my switch still synchronized ?!

Regards,

Noob

[Mark Malone]

Hi

q1) Can what I have configure fulfilled my above requests ? I do not want my switch to handle any other ntp queries at all with any other devices in the network.  Do I have to add anything else ?

Yes it will work with what you want  but I would always use v4 where possible as its more secure use keys and authentication but its optional

..............

From the doc below if you want to prevent other devices getting NTP then you need to lock it down

You can control access to NTP services by using access groups. Specifically, you can specify the types of requests that the device allows and the servers from which it accepts responses.

If you do not configure any access groups, NTP access is granted to all devices. If you configure any access groups, NTP access is granted only to the remote device whose source IP address passes the access list criteria.

ntp access-group peer 10  -- but I do not have any access list 10 defined.  why is my switch still synchronized ?! 

Then the access-group is not in use its open like having no acl so it can sync with everything

[SJ K]

Hi Mark,

Thanks for your reply.

From the doc below if you want to prevent other devices getting NTP then you need to lock it down.
If you do not configure any access groups, NTP access is granted to all devices. If you configure any access groups, NTP access is granted only to the remote device whose source IP address passes the access list criteria.

If I have configured the following

ntp server 192.168.4.5

ntp access-group peer 10

access-list 10 permit 192.168.4.5

With the access group and access list defined -> Does it means that I have locked down the switch and prevent other devices from doing NTP requests on the switch ?

Regards,
Noob

[Mark Malone]

Hi

what you have in place is fine its locked down you could go trust keys for extra security but may be overkill , the issue will occur though when you do go to peer and an access-group is still in place on the master ntp device , even if you peer by allowing another ip in the acl you must allow the internal ip address that ntp uses in the access-list 127.127.7.1, this is what the local routers would sync to internally if that's not in place any router that connects to your master will stay out of sync until the acl is corrected , just something to remember when using ntp access-group

[SJ K]

Hi Mark,

Thanks for your reply.

Just 1 question, can i configure a switch/router to be both a NTP server and client at the same time.

It seems like if if i create the switch/router to become an NTP master, it start to sync itself with its internal clock.

What should I do if I wanted the router to sync to an external source, and yet is also the source providing to all the internal devices.

=======

Can a router serves time requests without becoming an NTP master ?

Regards,
Noob

[Mark Malone]

Hi

It seems like if if i create the switch/router to become an NTP master, it start to sync itself with its internal clock.

Yes that's correct ......

When the router is using its own clock as a master clock (using the ntp master command), the output from show ntp associations looks like the following:

address            ref clock     st    when   poll   reach   delay    offset    disp 
*~127.127.7.1      127.127.7.1   6     20     64     377     0.0      0.00     0.0 
* master (synced), # master (unsynced), + selected, - candidate, ~ configured

The interesting value here is in the stratum field, which is one less than the configured value, ntp master 7 in this case. The router polls its own internal clock, but the clock is never unreachable, and the router never increases the poll interval to more than every 64 seconds.

What should I do if I wanted the router to sync to an external source, and yet is also the source providing to all the internal devices.

NTP server x.x.x.x prefer  will do it on the main router pointing to an external clock (set multiple clocks and chose the best stratum), you can have multiple servers and then also set it as a master to server time and then set the other switches to use the the master for its time

Can a router serves time requests without becoming an NTP master ? hmm doubt it , needs the master to serve clock times from what I remember

[SJ K]

Hi Mark,

Thanks for your reply.

NTP server x.x.x.x prefer  will do it on the main router pointing to an external clock (set multiple clocks and chose the best stratum), you can have multiple servers and then also set it as a master to server time and then set the other switches to use the the master for its time

But when you set a switch with the "ntp master" command, it no longer peers with an external clock source already right ?

Looking at the ntp association, its only peer it is own clock - isn't it ?

I need the switch/router to be sync to an external ntp server on the internet and that switch/router will also be the ntp source for rest of the internal devices (that are not able to reach the internet)  --> if I set the switch/router to become NTP master, can it still sync to external source ?

Regards,
Noob

[Mark Malone]

Actually if the switch is set with ntp server and the ntp access group is not in place your other devices will be able to peer with it by pointing to that switch with the external ntp server , theres no requirement for the master syntax

[SJ K]

Hi Mark,

Thanks for your reply.

Since a router/switch that is internet facing can still sync with an external source and yet still provide / be the ntp source for the internal devices being the NTP master,  then what is the point of having the "ntp master" command  ?

Regards,
Noob

[Mark Malone]

Some companies due to security will not allow any internet facing ntp servers , ntp is not that secure , there are a lot of vulnerabilities so you have master as well you an set the clock locally and source of that if required and take the clock locally only and then peer tat to other switches , by the way the algorithms in a cisco ios are not as good as and external clock service so eventually the time always shifts off very little bit by bit that's why some will still use public servers but try mitigate the vulnerabilities as much as possible to prevent issues

Like this we were flagged this only last week by our internal security teams , we were effected by it in the S3 version in IOS-XE and had to put in preventative measures

Cisco Security Advisory

Cisco IOS and IOS XE Software Crafted Network Time Protocol Packets Denial of Service Vulnerability

High

Advisory ID:

cisco-sa-20160804-wedge

First Published:

2016 August 4 16:00  GMT

Last Updated: 

2016 August 9 12:39  GMT

Version 1.1:

Final

Workarounds:

No workarounds available

Cisco Bug IDs:

CSCva35619

CVE-2016-1478

CVSS Score:

Base 7.8, Temporal 6.4Click Icon to Copy Verbose Score
AV:N/AC:L/Au:N/C:N/I:N/A:C/E:F/RL:OF/RC:C

CVE-2016-1478

Download CVRF

Download PDF

Email

Summary

• A vulnerability in the processing of Network Time Protocol (NTP) packets by Cisco IOS and Cisco IOS XE could allow an unauthenticated, remote attacker to cause an interface wedge and an eventual denial of service (DoS) condition on the affected device.
  
  The vulnerability is due to insufficient checks on clearing the invalid NTP packets from the interface queue. An attacker could exploit this vulnerability by sending a number of crafted NTP packets to be processed by an affected device. An exploit could allow the attacker to cause an interface wedge and an eventual denial of service (DoS) condition on the affected device.
  
  Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability; however, there is a mitigation for this vulnerability.
  
  This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160804-wedge

Affected Products

• Vulnerable Products

  The following releases of Cisco IOS Software and the corresponding releases of IOS XE Software are affected by this vulnerability:
  

  • 15.5(3)S3 - 3.16.3S
  • 15.6(1)S2 - 3.17.2S
  • 15.6(2)S1 - 3.18.1S
  • 15.6(2)T1

  Cisco devices running an affected version of IOS or IOS XE Software are vulnerable if they are configured for NTP operations. NTP is not enabled in Cisco IOS or IOS XE Software by default.
  
  To see if a device is configured with NTP, log in to the device and issue the command-line interface (CLI) command show running-config | include ntp. If the output returns any of the following commands, the device is vulnerable:
  

  ntp master <any following commands>
  ntp peer <any following commands>
  ntp server <any following commands>
  ntp broadcast client
  ntp multicast client
  

  The following example identifies a Cisco device that is configured with NTP:
  

  router#show running-config | include ntp
  ntp peer 192.168.0.12 

  The following example identifies a Cisco device that is not configured with NTP:
  

  router#show running-config | include ntp
  router# 

  This vulnerability can be exploited using both IPv4 and IPv6 packets. The vulnerability can be triggered by crafted NTP packets destined to UDP listening port 123 and using an IPv4 or IPv6 unicast address of any interface configured on a device or a network address. 
  
  This vulnerability can be triggered only by traffic destined to an affected device and cannot be exploited with traffic transiting an affected device.
  
  Determining the Cisco IOS or IOS XE Software Release
  

  To determine which Cisco IOS Software release is running on a device, administrators can log in to the device, use the show version command in the command-line interface (CLI), and then refer to the system banner that appears. If the device is running Cisco IOS Software, the system banner displays text similar to Cisco Internetwork Operating System Software or Cisco IOS Software. The banner also displays the installed image name in parentheses, followed by the Cisco IOS Software release number and release name. Some Cisco devices do not support the show version command or may provide different output.

  The following example identifies a Cisco product that is running Cisco IOS Software Release 15.5(2)T1 with an installed image name of C2951-UNIVERSALK9-M:

  Router> show version 
  Cisco IOS Software, C2951 Software (C2951-UNIVERSALK9-M), Version 15.5(2)T1, RELEASE SOFTWARE (fc1)
  Technical Support: http://www.cisco.com/techsupport
  Copyright (c) 1986-2015 by Cisco Systems, Inc.
  Compiled Mon 22-Jun-15 09:32 by prod_rel_team
  .
  .
  .

  For information about the naming and numbering conventions for Cisco IOS Software releases, see White Paper: Cisco IOS and NX-OS Software Reference Guide.

  Products Confirmed Not Vulnerable

  No other Cisco products are currently known to be affected by this vulnerability.

Indicators of Compromise

• On devices where this vulnerability is exploited, crafted NTP packets will get stuck in the ingress input queue of the receiving interface and eventually wedge the queue. Once this interface is wedged, it will stop receiving traffic until the router is reloaded.

Workarounds

• There are no workarounds that address this vulnerability; however, there is a mitigation for this vulnerability.
  
  As a mitigation measure, customers can use an interface access list (ACL), limiting NTP traffic to that coming from known NTP peers. Detailed knowledge and careful configuration is required by the network administrators in order to avoid dropping valid NTP traffic by implementing such mitigation measures. Because the NTP protocol in this vulnerability uses UDP as a transport, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses.

Fixed Software

• Cisco has released free software updates that address the vulnerability described in this advisory. Customers may only install and expect support for software versions and feature sets for which they have purchased a license. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license
  
  Additionally, customers may only download software for which they have a valid license, procured from Cisco directly, or through a Cisco authorized reseller or partner. In most cases this will be a maintenance upgrade to software that was previously purchased. Free security software updates do not entitle customers to a new software license, additional software feature sets, or major revision upgrades.
  
  When considering software upgrades, customers are advised to consult the Cisco Security Advisories and Responses archive at http://www.cisco.com/go/psirt and review subsequent advisories to determine exposure and a complete upgrade solution. 
  
  In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers.
  
  Customers Without Service Contracts
  Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC):
  
  Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.
  

  
  Fixed Releases

  
  This vulnerability has been corrected in the following releases of Cisco IOS Software and the corresponding releases of Cisco IOS XE Software:
  

  • 15.6(3)M
  • 15.6(2)SP - 3.18.0SP

  Cisco will release fixed software for remaining affected releases as soon as it is available.

Exploitation and Public Announcements

• The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.

Source

• This vulnerability was found during the resolution of a support case.

Cisco Security Vulnerability Policy

• To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.

Subscribe to Cisco Security Notifications

• Subscribe

Action Links for This Advisory

• Cisco IOS NTP Denial of Service

URL

• http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160804-wedge

Revision History

• Version	Description	Section	Status	Date
  1.1	Specified corresponding affected IOS XE Software releases	Vulnerable Products	Final	2016-August-09
  1.0	Initial public release	—	Final	2016-August-04

[SJ K]

Hi Mark,

Thanks for the information.

So in my situation, whereby I have a switch/router that is facing the internet and is able to sync to an external source, I do not need to use "ntp master" on the switch/router itself to allow/enable my internal devices to use it as a time source right ?

Regards,
Noob

[Mark Malone · Accepted solution]

Hi yes you should be able to once you set the ntp server x.x.x.x. for the internet ntp ,once that is synced , then on your other devices you can set them to have ntp server as well but you point it to the router itself internal ip address and it should sync off that then