Even though you used a template to configure your network devices from the beginning, and you have policy in place which says that all your devices should be configured in the same way, you might have a vague sense that some of your routers aren’t configured according to the standard you’ve setup. In my experience if you have that vague sense, that’s enough to say that you have devices which aren’t configured as you would want them to be. There are a lot of great tools which can compare two files and show you where they differ. However if you have hundreds of routers and switches it’s just not that fun anymore. Also you might not want to compare the entire configuration files to each other as no files will be identical since they will have different hostnames, ip addresses and other local settings. nk-compare-configs.sh is a free tool which can help you identify which of your devices are deviating from your templates.
It’s always bad when a service fails. It’s worse when the failure could have been easily avoided. When you’re asked if it would have been possible to prevent the disruption you don’t want to answer; “Yes, but it would have taken ten minutes of my time.” Service failure due to certificate expiration is an example of a scenario which never needs to happen. Check Windows Certificate Expiration is a Nagios Plugin which warns you before a service fails. The plugin is part of Networklore Monitoring pack for Nagios. It is written in Powershell and queries a servers LocalMachine personal certificate store. Some type of certificates you can monitor using other plugins, such as check_http which can monitor certificates on ssl sites. This plugin is intended for other services where you don’t want to open up additional ports, or if you can’t access the certificate directly from your Nagios server. Once you have setup NSClient++ this plugin should take less than ten minutes so install.
Using templates to configure your network devices have several benefits. This post describe how you can use Numbers for Mac to create a dynamic template you can use to create new configuration files. If your network consists of several routers you generally want them to share as much configuration as possible with each other. Say you have several branch offices which all has a local router which connects to the data center. Chances are that those branch office routers will be configured in the same way. The difference in configuration will mainly be hostnames, ip addresses and perhaps access-lists. When it’s time to connect a new branch office you can cut and paste parts of the config from another router or you can use a template. In the network-device-template.numbers released in Nelkit, I’ve used a simple configuration for a Cisco 880 router. However the example can be used for any type of device which uses a text based config.
“No problems I said, I’ll just use SNMP to collect that.” Or so I thought. There are so many different MIBs so at times I just want to believe I can collect everything from SNMP. However once you have a specific need the information just isn’t there. It started with a simple question. Is there a better way to collect interface information? My client had been using Rancid to collect the output from “show interface”. This worked quite well until some hardware and software upgrades changed the output causing the parser scripts they were using to stop working. So I wrote a small script which collected the ifTable from IF-MIB and created a csv file. That was easy enough. But since this was so easy there were a few more things my client needed. They wanted to know which mac-domains used which port-channels on their Cisco uBR10012 routers. In this scenario a mac-domain is tied to a bundle interface and policy based routing was used to decide where the traffic from each bundle interface was sent.
I never thought much about wireless bridges. At least until that day when not having one almost ruined my family evening. What a wireless bridge does is to connect an isolated part of your network to the rest of your infrastructure. Typically the need for a wireless bridge arise when, you a) have equipment which doesn’t have any wireless capabilities, and b) you don’t have any cables in place to connect that equipment to a switch. The need might arise when installing new cables is too expensive or you’re for some reason prohibited to do so.
I often think of Zone Based Policy Firewall or ZBF is Cisco’s new firewall engine for IOS routers. However it came as a new feature in IOS 12.4(6)T, which was released in 2006. So new is a bit of a stretch. The new is probably more related to the fact that I haven’t used it much. As I’m planning on taking CCIE Security Zone Based Firewall is something I have to learn more about. Up until now I’ve used the good old trusted CBAC to while using a router as a firewall, and I’ve a feeling a lot of people still use the legacy CBAC out of old habit. After doing a review of the setup, my impressions are that the configuration of a zone based firewall seems more complex and can be depending on what your access-lists looked like with the CBAC engine. If you have fine grained access-lists it can take some time to convert the rules to ZBF. However it also feels flexible and overall it’s growing on me. Starting from scratch I started with a clean config in terms firewall settings. In this post I’m just going to setup a basic config for zone based firewall and I’ll keep more advanced topics for other articles.
Of late I’ve started to use Nagios more and more. Looking at the various plugins available I came across some plugins which were supposed to check after missing Windows Updates. I found most of them to be quite blunt with the exception of the setup over at Frank4dd. However I just wanted a plugin to monitor a single server and Franks setup was a bit to big for my needs. I was also interested in writing plugins for Nagios mostly to see what is needed to make it work. I ended up writing a script which runs locally on a Windows machine. In my setup I’ve installed NSClient++ on the Windows machine. Nagios calls the NRPE part of NSClient++ which in turn runs the VBScript I wrote.
The PKI server which ships with Windows, Active Directory Certificate Services lets you install it in four different modes. Before you install your CA servers you will want to know how these different types differ from each other so you can plan your setup to suite your needs. Stand Alone Root CA You would use the stand alone Root CA in the scenario where you want to use an offline Root CA. Stand Alone in the context of the CA server means that is it not integrated with Active Directory. However information from the CA, such as CDP and AIA, could still be published to Active Directory. Typically the Stand Alone CA is a member of its own workgroup as opposed to being a member of a domain. It is disconnected from the network only accessible to the operators of the CA server. The only time anyone needs to interact with the server is when it is to sign subordinate CA certificates or when it publishes a new CRL. This can be done by transferring files on a USB stick.
A PKI hierarchy can have one or more tiers. In a single tier PKI environment your only CA server will be the Root CA. If you have more tiers your Root CA will issue subordinate CA certificates CA servers below the root. If you have a two tier PKI setup you don’t need to have access to your Root CA server on a day to day basis. Since your users can request certificates from the subordinate CA the Root CA can be offline. Obviously having your Root CA offline increases the security of your PKI environment since no one has network access to the server. How many tiers your setup will use depends of what you want to do with the PKI environment, your security requirements and the trust you put into the environment.
At its core PKI is all about certificates, how they are created, what information they contain, how they are used, the level of trust you put into them, what happens when they are lost and the simplicity of using them.