CCIE or Null!

My journey to CCIE!

Archive for July 2012

My CCIE reading list!

with 4 comments

A few of the CCIE books I have next to my bed!

Well, I’m still working towards my CCIE: Route/Switch, I figured I’d post an update about it, and why not focus on the books I’m using to prep for the CCIE: R/S Written exam:

  1. Routing TCP/IP Volume I 2nd Edition
  2. Routing TCP/IP Volume II
  3. Cisco LAN Switching
  4. CCIE: Routing & Switching Certification Guide
  5. Troubleshooting IP Routing Protocols
  6. QoS Certification Guide
  7. BGP Design & Implementation
  8. Developing IP Multicast Network
  9. MPLS Fundamentals
  10. Deploying IPv6 Networks
  11. IPv6 for the Enterprise
  12. Optimal Routing Design
  13. Cisco Firewalls
  14. CCNP: Security SECURE

I’m sure that will be enough to cover the objectives of the CCIE:R/S Written. I’ve actually already read through a good portion of the books mentioned, hopefully in the next month or two I will be ready to tackle the written exam!

Anyway back to reading and labbing, I’m working my way through the Multicast objectives, then I’m going to tackle IPv6, and review VRF/MP-BGP and then I’ll be ready to take on the exam!

I guess it’s time I should update my library page.

Written by Stephen J. Occhiogrosso

July 30, 2012 at 9:15 AM

Securing NTP

leave a comment »

Like all technologies in a network there are ways to secure it from being used maliciously, and NTP is no acception. We actually have a few different ways to secure the communication between our NTP peers and servers.

  • Authentication

Yep, we can configure our NTP clients to authenticate to our NTP server/master and make sure we only accept the time from NTP servers that we have control over. This ensures our routers will not get the time from any unauthorized sources and prevents a malicious user from spoofing their own NTP server and changing the time on the network. Do keep in mind NTP authentication only supports a PSK type authentication method and will use an MD5 hash so were not doing anything over the top here. Configuration below:

NTP authentication on the NTP master.

NTP authentication on the client

Do keep in mind, I’ve built this configuration off my previous NTP lab post so not every NTP command is shown above.

Now, when I configured this I forgot the command ntp trusted-key 1 on the NTP server, but I did specify the key for the ntp server on the NTP client, so obviously my configuration did not work right off the bat. I ended up debugging NTP to troubleshoot, so I issued the debug ntp packet and debug ntp auth, which provided me the following:

NTP debug with wrong key on the master.

From there you can see we transmitted a packet to (our NTP master) with authentication key 1, however the packet we received from had an authentication key 0 (No authentication). So once I saw that I quickly realized where my problem was. I went back to the NTP master and issued the command ntp trusted-key 1 and then went back to client check the ntp status.

After reviewing the debug output again, both packets are using an NTP authentication key. Keep in mind the NTP key # does not have to match but the MD5 password within the keys has to match.

  • Access Control Lists

Good old ACLs what can’t they do for us? Well NTP can be configured with an ntp access-group command, this command will limit the number NTP peers we perform transactions with, which can be useful and if you consider the IP Scheme during your design this won’t be hard to implement (Especially if you source NTP packets from loopback address). Here is my configuration:

NTP access group on the NTP Master

NTP access group on the NTP client

I’m a big fan of using named ACLs whenever possible, it just makes it easier to manage in my opinion. My NTP client is a Cisco Catalyst 2960 and NTP on this device only supports numbered ACLs, which is why I had to use a normal numbered ACL there and not a named ACL. The only slightly complex portion of  NTP access-groups is the fact we can have different types of access-groups:

  • Peer: Peer access-groups allow both request and control queries to be processed meaning the router will be allowed to update its time from the allowed peers.
  • Query-only: This only allows control queries to be accepted, control queries don’t actually the effect the date/time so I’m going to skip this one. See RFC 1305 for addition information about this.
  • Serve: Allows the router to reply to request as well as control queries.
  • Serve-only: Does not allow control queries and only replies to NTP requests.

So from our example our NTP master is setup to serve-only our NTP clients, and our NTP master has full access to our NTP clients.

One last thing I want to touch on concerning NTP access-groups is the fact if your setup an ACL between 2 NTP servers, you must remember to allow the local NTP server address, in this case it is this address might different depending on the router model and IOS version so it’s always a good idea to check it out.

The NTP Master Internal IP

Written by Stephen J. Occhiogrosso

July 24, 2012 at 9:30 AM

%d bloggers like this: