Jul
28

NTP security goal is to prevent unauthorized time sources to affect time synchronization within a set of network devices. Cisco IOS offers two methods of securing NTP infrastructure:

1) NTP Access Control. Limit types of NTP access and NTP sources associating with out router.
2) NTP Authentication. Validate the identity of NTP sources.

Let’s see how access control works. It is convenient to classify NTP messages in two types:

1) Control messages. Documented in RFC 1305 Appendix B, serve the purpose, usually fulfilled by SNMP. Without digging into any details, let’s just say the control messages are for reading and writing internal NTP variables and obtaining NTP status information. Not to deal with time synchronization itself.
2) NTP request/update messages. Those are used for actual time synchronization. Request packet obviouly asks for synchronization information, and update packet contains synchronization information, and may change local clock.

IOS router defines the following four types of access for NTP:

1) Peer – permits router to respond to NTP requests and accept NTP updates. NTP control queries are also accepted. This is the only class which allows a router to be synchronized by other devices.
2) Serve – permits router to reply to NTP requests, but rejects NTP updates (e.g. replies from a server or update packets from a peer). Control queries are also permitted.
3) Serve-only – permits router to respond to NTP requests only. Rejects attempt to synchronize local system time, and does not access control queries.
4) Query-only – only accepts NTP control queries. No response to NTP requests are sent, and no local system time synchronization with remote system is permitted.

IOS router may associate an access-list with any of the above access-types, classifying NTP message sources by their types. Two rules are observed by IOS when an incoming NTP packet is matched against configured types of access:

1) All access-groups associated with access types are scanned in the ordrer presented above (from 1 to 4) – that is, following from most permissive to most restrictive. The first match is used to determine the message source access type.
2) If any of the access types has been defined with an ACL, all other access types are implicitly denied. Just by restricting some sources, you may effectively block all others as well

Now here is a catch. If your router is configured as NTP master, and you set up any access-control group, you must allow “peer” access type to a source with IP address “127.127.7.1”. This is because “127.127.7.1” is the internal server created by ntp master command, which the local router synchronizes to. If you forget to enable it peer access, your server will always be out of sync. Here are some examples. First one: configure R1 as NTP master and allow the server to be polled for NTP updates just by one client. Client should receive updates just from one source:

R1:
access-list 1 permit 127.127.7.1
access-list 2 permit 150.1.2.2
ntp master
ntp access-group peer 1
ntp access-group serve-only 2

R2:
access-list 1 permit 150.1.1.1
ntp source Loopback0
ntp access-group peer 1
ntp server 150.1.1.1

A more complicated example. R1 and R3 are both NTP masters, peering via NTP. R2 is a client to both of them. Configure so that R1 and R3 only allow R2 to poll themselves for time updates, and allow synchronizing each other. Correspondingly, R2 should only accept NTP updates from R1 or R3.

R1:
access-list 2 permit 150.1.2.2
access-list 3 permit 150.1.3.3
access-list 3 permit 127.127.7.1
ntp master
ntp access-group serve-only 2
ntp access-group peer 3
!
! The following is needed to poll our peer from
! a consistent source IP address
!
ntp source Loopback0
ntp peer 150.1.3.3

R3:
access-list 2 permit 150.1.2.2
access-list 1 permit 150.1.1.1
access-list 1 permit 127.127.7.1
ntp master
ntp access-group serve-only 2
ntp access-group peer 1
ntp source Loopback0
ntp peer 150.1.1.1

R2:
access-list 13 permit 150.1.1.1
access-list 13 permit 150.1.3.3
ntp source Loopback0
ntp access-group peer 13
ntp server 150.1.1.1
ntp server 150.1.3.3

Some show commands output for the last example:

Rack1R1#show ntp associations detail
150.1.3.3 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA2222.362546B9 (00:06:58.211 UTC Sun Jan 1 2012)
our mode active, peer mode active, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.05, reach 377, sync dist 12.466
delay 24.70 msec, offset 0.0294 msec, dispersion 0.05
precision 2**18, version 3
org time D2AA2222.363128BC (00:06:58.211 UTC Sun Jan 1 2012)
rcv time D2AA2222.395A8A9D (00:06:58.224 UTC Sun Jan 1 2012)
xmt time D2AA221C.BA22B989 (00:06:52.727 UTC Sun Jan 1 2012)
filtdelay =    24.77   24.70   24.69   24.69   24.81   24.78   25.16   24.60
filtoffset =    0.01    0.03    0.01    0.01    0.07    0.02    0.30    0.04
filterror =     0.02    0.03    0.05    0.06    0.08    0.09    0.11    0.12

127.127.7.1 configured, our_master, sane, valid, stratum 7
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 17, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
rcv time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
xmt time D2AA224F.BA09890A (00:07:43.726 UTC Sun Jan 1 2012)
filtdelay =     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =     0.02    0.99    1.97    2.94 15995.3 15995.3 15995.3 15995.3
Reference clock status:  Running normally
Timecode:

Rack1R3#show ntp associations detail
150.1.1.1 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode active, peer mode active, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 376, sync dist 13.474
delay 24.70 msec, offset 0.0428 msec, dispersion 0.84
precision 2**16, version 3
org time D2AA2252.BA44EC9D (00:07:46.727 UTC Sun Jan 1 2012)
rcv time D2AA2252.BD81F301 (00:07:46.740 UTC Sun Jan 1 2012)
xmt time D2AA2262.362614E6 (00:08:02.211 UTC Sun Jan 1 2012)
filtdelay =    24.99   24.70   24.69   25.02   24.70   24.67   24.67   24.66
filtoffset =   -0.15    0.04   -0.06    0.16   -0.04   -0.04    0.03   -0.02
filterror =     0.75    0.76    0.78    0.79    0.81    0.82    0.84    0.85

127.127.7.1 configured, our_master, sane, valid, stratum 7
ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 377, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
rcv time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
xmt time D2AA2263.36244305 (00:08:03.211 UTC Sun Jan 1 2012)
filtdelay =     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =     0.02    0.99    1.01    1.02    1.04    1.05    1.07    1.08
Reference clock status:  Running normally
Timecode: 

Rack1R2#show ntp associations detail
150.1.1.1 configured, our_master, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 17, sync dist 2924.316
delay 92.15 msec, offset -814906.4035 msec, dispersion 2877.85
precision 2**16, version 3
org time D2AA225B.921F769B (00:07:55.570 UTC Sun Jan 1 2012)
rcv time D2AA258A.85F5230D (00:21:30.523 UTC Sun Jan 1 2012)
xmt time D2AA258A.6E599935 (00:21:30.431 UTC Sun Jan 1 2012)
filtdelay =    92.15   90.97   90.84  136.81    0.00    0.00    0.00   91.34
filtoffset = -814906 -814908 -814909 -814886    0.00    0.00    0.00    2.22
filterror =     0.02    0.99    1.97    2.94 16000.0 16000.0 16000.0    7.83

150.1.3.3 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.05, reach 377, sync dist 13.916
delay 24.57 msec, offset -814905.7885 msec, dispersion 1.59
precision 2**18, version 3
org time D2AA2273.89780E2F (00:08:19.536 UTC Sun Jan 1 2012)
rcv time D2AA25A2.747F40E8 (00:21:54.455 UTC Sun Jan 1 2012)
xmt time D2AA25A2.6E3030A3 (00:21:54.430 UTC Sun Jan 1 2012)
filtdelay =    24.57   24.73   24.70   24.84   24.64   24.75   24.55   24.67
filtoffset = -814905 -814907 -814907 -814907 -814907 -814907 -814907 -814907
filterror =     0.02    0.99    1.01    1.02    1.04    1.05    1.07    1.08
About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

9 Responses to “NTP Access Control”

 
  1. Thiago says:

    Absolutely brilliant this post!!!

    The catch about “127.127.7.1” is not something usually documented and even on IE’s SP workbook this is not documented and the solution of a task that involves this is not complete as it’s missing this catch.

    Another great post !!!

    Thanks.

  2. Vijay Tyagi says:

    Hi Petr,

    First of all thanks a lot for putting such a great efforts, all this is really helpful to all of us.

    One thing we all wants to request to you that for Security candidate DMVPN is still a mystery, so if you can explain about DMVPN that will be really helpful to all the security candidates.

    Regards
    Vijay Tyagi

  3. Mohammed Ather Khan says:

    Excellent Post Petr,

    Clear lot of my doubts, thanks a lot dear. If possible can you please post on port-security, protected ports, dot1x and aaa. Im little bit confused on this topics. your input will be highly appreciated.

    Regards,
    Khan

  4. Mike says:

    Petr, I found this explanation to be very insiteful to my newly found understanding of NTP.

    Can you explain how using stratum levels internaly works with synchronizing with NTP peers?

    We are currently using a heirarchy of internal stratums in our organization that spans from the branch routers across the wan, through the core, out to our internet edge routes, then finally to internet time servers. Each router hop, we assign the router as a master but with a stratum level.

    I’m a bit confused about how synching is supposed to work since the ntp server command states that it replies to requests but rejects NTP updates itself.

    this doesn’t explain the ntp master command

    Does ntp masters stay in synch with each other using stratum numbers?

  5. It appears that Cisco changes their IOS in later version to use the loopback address of 127.127.1.1 instead of 127.127.7.1 and with that address you don’t need to add that loopback to the ACL when using access-groups in NTP.

    For for info please check out my more detailed post on http://ieoc.com/forums/t/13823.aspx

    Hope that helps.

  6. Svetlana Klašnić says:

    Great!!! Petr and others, thank you very much for your help!

  7. Fulvio Allegretti says:

    Not sure Tom’s comment is correct, I have replied to his post.

    http://ieoc.com/forums/t/13823.aspx

 

Leave a Reply

Categories

CCIE Bloggers