Archive for July 2012
My CCIE reading list!
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:
- Routing TCP/IP Volume I 2nd Edition
- Routing TCP/IP Volume II
- Cisco LAN Switching
- CCIE: Routing & Switching Certification Guide
- Troubleshooting IP Routing Protocols
- QoS Certification Guide
- BGP Design & Implementation
- Developing IP Multicast Network
- MPLS Fundamentals
- Deploying IPv6 Networks
- IPv6 for the Enterprise
- Optimal Routing Design
- Cisco Firewalls
- 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.
Securing NTP
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 172.31.1.1 (our NTP master) with authentication key 1, however the packet we received from 172.31.1.1 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 127.127.1.1 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 127.127.1.1
Configure your router to watch for login attacks.
Even though we can configure SSH for secure management, this still does not stop a random person from connecting to your device in an attempt to guess the password. In some cases this could be a bored user who is just curious or in worst cases it could be a malicious user trying to perform a dictionary attack on your password. Something we can do is to configure our router to start blocking login request after so many failed attempts occur within a specific time frame. Now this isn’t going to secure your router indefinitely but it is a simple preventative measure they will slow down any real dictionary attacks and will most likely discourage any bored employees in hopes that they lose interest or remember they have other work to do.
So now let’s say we have an existing router with SSH enabled and we want to configure this login block feature, well let’s enter the following command:
Yep one command. This will block all logins for 120 seconds when 5 failed attempts occur within 60 seconds of each other. Below is a breakdown of the block-for command, and notice all the timers are in seconds.
Now when the router notices these failed attempts it enters a “quiet mode”. This quiet mode is what tells the router to block all further login attempts until the timer expires.
So now I hit my router with a bunch of invalid attempts and noticed the following error get logged:
This message states quiet mode is now on and also notice it actually logs the username I attempted to log in as (ss in this case), the source of the login attempt (192.168.1.109), the port I connected on (22 default for SSH), and the reason (failed login authentication)
From this point I cannot even connect to the router over port 22, putty flat out tells me the connection is refused:
The following error message will also get logged when I attempt to login to a router that is currently in quiet mode:
Stating our login attempt has been blocked by an ACL, but wait we didn’t configure an ACL on this router. Let’s check the VTY lines:
We didn’t configure this ACL but the login block feature did. The cool thing about this is when “quiet mode” is turned off the ACL dissappears:
Pretty cool right? We have now taught the router to protect itself.
While this is a nice feature to have configured the last thing you want is to find yourself locked out of your own equipment. So what we can do is configure the router to accept login attempts even when quiet mode is enabled, while that might sound counter-productive to this whole feature it will be something you definitely want to do.
And we do it this way:
The first thing I did was create an ACL (SSH_MGMT) that permits my management workstation (or management subnets) and then I issue login quiet-mode access-class command and reference the ACL I created. This tells the router to accept login requests from the hosts allowed within the quiet-mode ACL when quiet mode is on and the router is blocking login attempts from everyone else.
So now when quiet mode is initiated this custom ACL is applied to the line VTY lines:
You can verify your configuration with the show login command, this provides you a nice summary of what has been configured as well as the current state of the router:
A few things to keep in mind:
- While the quiet mode ACL will allow login attempts from hosts matched in the ACL, those very same hosts can trigger the router to enter quiet mode.
- If you already have an access-class assigned to the VTY lines and quiet mode kicks in, the quiet mode ACL will be applied during the block-for time. However when the timer expires the quiet mode ACL is removed and the original ACL back in place.
CCIE or Null! 