Blog Home | INE Home | Members | Contact Us | Subscribe Free Resources View Archives All Access Pass 28 NTP Access Control Posted by Petr Lapukhov, 4xCCIE/CCDE in CCIE R&S,System Management CCIE Bloggers Search Jul 7 Comments Search Submit 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: Categories 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 Select Category Let’s see how access control works. It is convenient to classify NTP messages in two types: Current Poll 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: The best enhancement to CUCM v8.x is Intercompany Media Engine (IME) SAF Call Control Discovery Extension Mobility Cross Cluster (EMCC) Cross-Cluster RSVP SIP Preconditions UCS / VMWare Support Vote View Results Polls Archive CCIE Bloggers Brian Dennis CCIE #2210 Routing & Sw itching ISP Dial Security Service Provider Voice Brian McGahan CCIE #8593 Routing & Sw itching Security Service Provider Petr Lapukhov CCIE #16379 Routing & Sw itching Security Service Provider Voice Mark Snow CCIE #14073 Voice Security Bootcamps March 21 - April 1 2011 12-Day Bootcamp R1: Seattle, WA access-list permit 127.127.7.1 Enroll Now access-list permit 150.1.2.2 April 25 - May 6 2011 ntp master 12-Day Bootcamp ntp access-group peer Tampa, FL ntp access-group serve-only Enroll Now R2: access-list permit 150.1.1.1 Popular Posts ntp source Loopback0 ntp access-group peer Submit Your Topic Requests for ntp server 150.1.1.1 the New CCIE R&S Advanced 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 Technologies Class other. Correspondingly, R2 should only accept NTP updates from R1 or R3 Technologies Class New CCIE R&S Advanced INE's CCDE Bootcamp Demo OSPF and MTU Mismatch R1: access-list permit 150.1.2.2 Understanding OSPF External access-list permit 150.1.3.3 Route Path Selection access-list permit 127.127.7.1 ntp master ntp access-group serve-only ntp access-group peer ! ! 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 permit 150.1.2.2 access-list permit 150.1.1.1 access-list permit 127.127.7.1 ntp master ntp access-group serve-only ntp access-group peer 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 ref ID 127.127.7.1, time D2AA2222.362546B9 (00:06:58.211 UTC Sun Jan 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 org time D2AA2222.363128BC (00:06:58.211 UTC Sun Jan 2012) rcv time D2AA2222.395A8A9D (00:06:58.224 UTC Sun Jan 2012) xmt time D2AA221C.BA22B989 (00:06:52.727 UTC Sun Jan 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 ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 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 org time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 2012) rcv time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 2012) xmt time D2AA224F.BA09890A (00:07:43.726 UTC Sun Jan 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 ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 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 org time D2AA2252.BA44EC9D (00:07:46.727 UTC Sun Jan 2012) rcv time D2AA2252.BD81F301 (00:07:46.740 UTC Sun Jan 2012) xmt time D2AA2262.362614E6 (00:08:02.211 UTC Sun Jan 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 ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 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 org time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 2012) rcv time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 2012) xmt time D2AA2263.36244305 (00:08:03.211 UTC Sun Jan 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 ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 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 org time D2AA225B.921F769B (00:07:55.570 UTC Sun Jan 2012) rcv time D2AA258A.85F5230D (00:21:30.523 UTC Sun Jan 2012) xmt time D2AA258A.6E599935 (00:21:30.431 UTC Sun Jan 2012) filtdelay = 92.15 136.81 0.00 0.00 0.00 91.34 filtoffset = -814906 -814908 -814909 -814886 0.00 0.00 0.00 2.22 2.94 16000.0 16000.0 16000.0 7.83 filterror = 90.97 0.02 0.99 90.84 1.97 150.1.3.3 configured, selected, sane, valid, stratum ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 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 org time D2AA2273.89780E2F (00:08:19.536 UTC Sun Jan 2012) rcv time D2AA25A2.747F40E8 (00:21:54.455 UTC Sun Jan 2012) xmt time D2AA25A2.6E3030A3 (00:21:54.430 UTC Sun Jan 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 Tags: access-control, ntp Download this page as a PDF About Petr Lapukhov, 4xCCIE/CCDE: Petr Lapukhov's career in IT begain in 1988 w ith a focus on computer programming, and progressed into netw orking w ith his first exposure to Novell NetWare in 1991. Initially involved w ith Kazan State University's campus netw ork support and UNIX system administration, he w ent through the path of becoming a netw orking consultant, taking part in many netw ork deployment projects. Petr currently has over 12 years of experience w orking in the Cisco netw orking field, and is the only person in the w orld to have obtained four CCIEs in under tw o years, passing each on his first attempt. Petr is an exceptional case in that he has been w orking w ith 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 7 Responses to “NTP Access Control” July 29, 2008 at 1:59 pm Thiago 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 Reply July 31, 2008 at 1:52 am Vijay Tyagi 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 Reply August 5, 2008 at 11:32 pm Mohammed Ather Khan 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 Reply October 17, 2008 at 5:54 am Mike 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? Reply May 30, 2010 at 3:34 pm ntp accessgroup So Do You Want to be a CCIE? 2bccie.com [ ] http://blog.ine.com/2008/07/28/ntp-access-control/ [ ] Reply August 4, 2010 at 10:09 pm NTP confirmation … petr So Do You Want to be a CCIE? 2bccie.com [ ] http://blog.ine.com/2008/07/28/ntp-access-control/ [ ] Reply November 15, 2010 at 2:41 pm Tom Kacprzynski 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 Reply Leave a Reply Name (required) Mail (will not be published) (required) Website Submit Comment Cius tablet set for release through partners http://dlvr.it/MvkNp Many CCIE Voice Product Updates http://bit.ly/hWbrl9 Cisco announces enhanced security solutions http://dlvr.it/MnSpD twitter.com/inetraining © 2010 Internetwork Expert, Inc., All Rights Reserved pdfcrowd.com