Aaron’s Worthless Words

Let’s talk [tag]audit[/tag]ing for a bit. It’s important to have an outside person look over your [tag]configuration[/tag]s every so often to be sure you didn’t do something stupid, so, every quarter or so (mostly so), I bring in someone to…wait a minute. It would cost about $3000 for someone to do that, and the company surely isn’t going to pay for that. The wonderful people from “The Internet” know this, though, and have released a whole bunch of tools to audit gear like that. One of those is called [tag]Nipper[/tag].

Nipper was the dog in the RCA logo, but that has nothing to do with this. What I´m talking about is the Network Infrastructure Parser. It´s a very nice tool for parsing the configs of your [tag]IOS[/tag] [tag]routers[/tag], IOS [tag]switch[/tag]es, CatOS switches, PIXes, ASAs, FWSM, and a whole mess of other gear. It´s ultra-fast and spits out a great report in HTML by default.

It’s very easy to use, so I won’t get into that, but check it out. It’s worth running your config through this guy every once in a while to make sure you didn’t miss something stupid. Check it out!

—

Note: You shouldn’t just trust one app to do all your auditing. There’s no way that just a single app can cover everything, so download a bunch of them and run them all when you do your audit.

• (0)

We all have limited budgets these days. Long gone are the days of unlimited resources and uncontrollable expansion of the [tag]network[/tag], so it’s important that any network dude or dudette pay attention to the open-source world. Below is a list of stuff I use at the office and at home to [tag]monitor[/tag], [tag]trend[/tag], and [tag]alert[/tag] the network. All this stuff is free and runs on Linux to save even more cash.

• [tag]Cacti[/tag] – This is a system for trending pretty much anything. If it has an [tag]SNMP[/tag] value, Cacti can trend it. It’s also really flexible, allowing multiple displays of data and even a mechanism to get values from scripts you write. At the office, we use it to monitor utilization of the circuit and Ethernet ports, CPU and memory of the gear, and the number of connections on the load-balancer. At home, I use it to watch utilization and track the number of connections to the wireless networks.
• [tag]Nagios[/tag] – This is a monitoring and alerting system for all sorts of stuff. It watches hosts and applications for availability and response time, then alerts based on threshold. This is one of the most complicated apps to configure, but, once it’s up, it rocks. I use it at home to monitor all the network gear and systems for response times. I also use it to monitor the web servers and restart them if they’re down.
• [tag]Apache[/tag] – You know what Apache is. You use it already. About 71% of webservers on the Internet are Apache.
• [tag]Squid[/tag] – A caching [tag]proxy[/tag] server by the same guys who do Apache. It can be configured for both inbound and outbound application acceleration. It’s great to put in front of a CMS like Drupal or Joomla. It has a mess of built-in functions that can look for bad requests, do redirects, or completely rewrite requests. At work, it fronts our application and CMS servers so users don’t have access directly to them. At home, it runs on the firewall to serve pages to the Internet. The real webserver actually sits on a box behind the firewall for security.
• [tag]Subversion[/tag] – This is a version control system. Subverions lets you create repositories, check out the contents, edit them, and check them back in. This is good for keeping track of configuration files or scripts you write. We use it at work to track configuration files for Apache, NTP, yum, etc. At home, I use it to keep track of my scripts and Perl module.
• [tag]Rancid[/tag] – This is configuration management for Cisco (and other network) devices. It gets configs from devices and checks them for changes. It’s got built-in alerting and is easy to set up. I use it at home to keep track of the configs on the switches and access points.
• [tag]nfsen[/tag]/[tag]nfdump[/tag] – These are [tag]netflow[/tag] tools. Nfdump is a suite for collecting the data, while nfsen is for displaying the information. Check out netflow if you’ve never worked with it…it’s pretty cool.
• [tag]Dyanmips[/tag]/[tag]dynagen[/tag] – These apps let you run virtual Cisco routers on a machine. You can set up full network deployments for testing and configuration experimentation. It takes a good bit of resources, but it’s well worth it for the functionality. I use it all the time at work to test or tweak configs. I also use it to simulate certification labs.

• (0)

I assume you take every word I say to heart and that you’ve been using [tag]Dynamips[/tag]/[tag]Dynagen[/tag] for a few days now, right? Good. That’s a start, but let’s break down a simple [tag]lab[/tag] to make sure everyone’s on the same page. I run my labs on Linux most of the time, so you’ll see my commands for that platform. You’re a smart one, so you can figure out what to do on Windows.

First of all, everyone download the lab file. This is a very simple lab that I created to do some experimentation with [tag]BGP[/tag]. I modified it a bit to save resources for the general public, though; it’s a lot easier to run 2 2651XMs than 2 7206s, right? Let’s go through the lines.

autostart = False
[localhost]

Yes, that means don’t start up the routers when you fire up dynagen. The second line is the dynamips server you want to use. This will always be localhost unless you’re leveraging another box to use as the emulator. That’s an advanced topic that I’m not going to cover right now, though.

[[2651XM]]
image = /home/jac/labs/images/c2600-adventerprisek9-mz.124-17.img
ram = 96

These lines define the parameters for any 2651Xm that we’ll be using. The image file is the actual IOS image to use. I can’t provide an IOS file for you, so you’ll have to download one yourself and change this line to where you put the file. Guess what the “ram” line is. Wow…you’re a genius if you said it was the amount of RAM to give each 2651XM.

[[ROUTER R1]]
s0/0 = R2 s0/0
f0/0 = LAN 1
model = 2651XM

[[ROUTER R2]]
f0/0 = LAN 2
model = 2651XM

Here’s the meat of the lab. We’re creating 2 2651XMs, called R1 and R2, that each have s0/0 and f0/0 interfaces.

The 2651XM has 2 FastEthernets, so, when you fire up the lab, the routers will have those interfaces, but we don’t care about f0/1 in the scope of this lab. We’ll just ignore it for now. The “LAN” keyword in the f0/0 lines tell how you want the FastEthernets cabled up. We’re trying to do BGP here, so the FastEthernet interfaces are connected to different network (R1 to LAN 1 and R2 to LAN 2).

Notice that, in the R1 configuration, we say that R1’s s0/0 is connected to R2’s s0/0. This lets the routers talk across the serial interfaces in the virtual world. In our lab, this is the link that we’re going to run BGP over to share the paths to the f0/0 interfaces. Very simple setup.

So, let’s fire this guy up. First, make sure you’ve started your dynamips server. I run mine in a screen session to get it out of the way, but it’s your choice. Run “dynamips -H 7200″ to get going and listening on port 7200. When that’s up and running, you simply run dynagen against your lab file with a “dynagen bgp.net”.

If everything is right, you’ll be see the “=>” prompt. Remember that we set autostart to false, so we have to start up our routers. You can type “start R1″ and “start R2″ to get them going, but it can be easier to do a “start /all”. You may run into problems with CPU or memory if you do that, though, so be careful.

If you do a “list” at the dynagen prompt, you should see both of the routers in a “running” state. That’s good, but now what? Time to get on the console. If you’re running your lab on your workstation (the box that’s attached to the keyboard you’re typing on), you can do a “console /all” to bring up all the consoles at once. If you’re doing the lab remotely, you’ll have to telnet to the right port to get a console. That info’s in the last column of the “list” command.

Now comes the configuration, so get to it. Configure these guys to share their routes on the f0/0 interface via BGP. Experiment a little. Experiment a lot. You’re not going to break anything, but remember to save the configuration when you’re done. You can reuse the lab later.

—–

If you’re lazy, you can use the configs that I used for this lab. They’re very, very simple, but they work.

• R1
• R2

• Read comments... (1)

I had an article a few weeks ago about the [tag]Cisco[/tag] [tag]CSM[/tag], which is a load-balancer module for the 6500 series switches. This thing is a pretty good device, but monitoring the connections to each VIP and RIP is not very straightforward. If you have an [tag]SNMP[/tag] monitoring system like Cacti or MRTG, you need to know the [tag]OID[/tag] to [tag]monitor[/tag], but it doesn’t work like anything else in the world.

Let’s start with the OID for the vserver. First, there’s the base OIDs that you can look up on CCO. This is just standard SNMP stuff that Cisco defined long ago. The slot number that the CSM is in is added to that base OID. You then have to add the length of the vserver name — don’t ask me…I don’t know. Next comes the really stupid part — you have to take the names of the vserver and get the ASCII values of every character in the name and add each to the end to get the full OID. Yes, it’s that stupid.

<BASE VSERVER CONN OID>.<SLOT>.<LENGTH>.<VSERVER NAME>

The serverfarm OID is pretty close — the base OID and slot. You then add the length of the serverfarm name along with the ASCII values of the serverfarm name (quite like we did for the vserver). Finally, the only part that might make sense, you take the IP of the real server and add it to the end with the instance of “0″. Again, I have no clue why it’s like this or what Cisco was trying to do. It’s terrible.

<BASE SF CONN OID>.<SLOT>.<LENGTH>.<SF NAME>.<REAL IP>.0

How about an example. Let’s say you have a vserver called VSERVER1 that you want to monitor. This vserver is configured to use the serverfarm FARM1, which has two reals of 192.168.1.101 and 192.168.1.102 that you also want to monitor. You also know that the CSM is in slot 3. The base OID for vserver connections is .1.3.6.1.4.1.9.9.161.1.4.1.1.17; the base OID for serverfarm connections is .1.3.6.1.4.1.9.9.161.1.3.1.1.5. This all gives you this:

VSERVER: .1.3.6.1.4.1.9.9.161.1.4.1.1.17.3.8.86.83.69.82.86.69.82.49
RIP1: .1.3.6.1.4.1.9.9.161.1.3.1.1.5.3.5.70.65.82.77.49.192.168.1.101.0
RIP2: .1.3.6.1.4.1.9.9.161.1.3.1.1.5.3.5.70.65.82.77.49.192.168.1.102.0

Did I mention it’s overly-complicated and terrible? It’s actually so bad that I just wrote a Perl script to do it for me because, for God’s sake, I’m not doing that by hand. Let me know if you need any help with it.

• (0)

I finally got around to looking into [tag]SNMP[/tag] v3 and was shocked at how easy it actually is. When I first looked up info on it so many moons ago, I saw table after tables of views and privilege levels and thought I would have to put in a billion hours getting it customized. I settled down and went through some Google results and found a blog post by Richard Bejtlich that shows the simplest of configurations. Works like a champ!

SNMP v3 gives you a few things that you’ll like. First of all, the transactions can be encrypted, so you don’t have to worry about people sniffing your traffic on the evil Internet. You also get username and password combos for authentication. Older versions use the community, which serves as a password. My buddy has a story about using the default communities on his cable modem to find upstream hosts, the using the same on his ISP’s network gear. That’s pretty lackluster security that could be hardened with v3.

This version of SNMP is very complicated, and the key to starting off is to forget about the views. Views make SNMP v3 ultra-powerful, but you don’t need them in a simple setup. Obviously, we all evolve, and you’ll probably use it later, but there’s no need to worry yourself to start.

Let’s do this, then. First, you need to define a v3 group and user/pass. Just something simple will do. Let’s choose a group name of “snmp-group” and a user of “snmp-user” with the password “user-pass”. Now all we have to do is configure the thing. I’m assuming you’re setting it up on a Cisco IOS device of some kind, but SNMP v3 has been available for quite a while on a lot of platforms and OSes.

snmp-server group snmp-group v3 auth
snmp-server user snmp-user snmp-group v3 auth md5 user-pass priv des56 encryption-key

Note that we’re using an MD5 hash for the password right now. If you have the right code, you can do DES56 encryption, but every version of [tag]IOS[/tag] that supports SNMP v3 also supports MD5.

That’s it, actually. By default, you have read-only access to the whole MIB tree. If you want to set up more granular access, you can look at views, but that’s beyond the scope here. I’m sure I’ll have an article about that later.

Let’s test our new setup with an snmpwalk. There’s some new flags you need to pass to use v3, but it’s pretty straightforward. “a” is for encyrption; “u” is for user; “A” is for password; “l” is for the authorization level (another advanced SNMP v3 topic).

snmpwalk -v 3 -a MD5 -u snmp-user -A user-pass -X encryption-key -l authPriv hostname .1

You should see a whole list of stuff scrolling by. If you don’t, check the username and password and try again. Let me know if you need any help getting it running.

—-

Here’s my usual note. If you still have your “snmp-server community” line configured, then v1 or v2c is still available. If you’re converting completely to v3, then just remove the community line. This will disable the old school versions and let you enjoy your encrypted goodness.

Also note that I’m not sure if Cacti or Nagios actually supports SNMP v3 encryption.  You’re on your own with that one.  If you decide to not use encryption, you can just take out the “priv” section of the user configuration to go with authentication only.

• Leave a comment... (0)

A few months ago, a friend of mine told me about the concept of port knocking, where you send packets to a server on certain ports to authenticate access to the box. A daemon running on your server detects the sequence of packets that you send and runs a script (usually IPtables commands), waits a certain amount of time, then runs another script (usually to take the IPtables commands out). This seems like a good way to get access to your home firewall from anywhere without having to open up access to the whole Internet.

To set it up, you have to install knock, which is the daemon that listens to the port knocking. Just use yum or apt-get to install it and you’ll wind up with the configuration file in /etc/knockd.conf. This is where you set up one or more knock sequences to do what you want. I won’t go into the internals of how it works or how you should set it up but I will go into a few examples.

I use port knocking on my home network to protect administrative access to everything on the network. I wrote a custom IPtables script that, when activated, open access from my IP on the wireless network to SSH (TCP/22) on my firewall, file server, access point, and switch. After 30 seconds, another script runs, and those rules are removed. Here’s an example of a config file that opens up SSH when you hit ports 1234, 5678, 9876, and 5432. After 30 seconds, it kills the rule.

[options]
logfile = /var/log/knockd.log

[openssh]
sequence = 1234, 5678, 9876, 5432
seq_timeout = 5
tcpflags = syn
start_command = -A INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT
cmd_timeout = 30
stop_command = -D INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT

So, how do you generate these packets? On my CentOS boxes, you get the knock command which is the port knocking client. On Windows, I use KnockKnock. I have no clue about Macs, but there are lots and lots of clients out there, so just look around and I’m sure you’ll find one.

• Leave a comment... (0)