Happy new year, all.  I’m finally over my hangover from the party and ready to blog.

Everywhere I go, I always wind up in a debate about how to alert on log messages as they come in.  I was at the grocery store yesterday, and the cashier told me that she had a list of log messages that she watched for, and, if she saw one of them, she sent an email.  I asked her what she would do if she got a log message that she had never seen before, and she said that she would have to find it first, then research the message and put in an alert for the next time it showed up.

Stretch at Packetlife has a lively little write-up on the Australian government’s attempt to implement a nation-wide web filtering service.

From Packetlife.net:

Setting aside the myriad of technical barriers to implementing such a system, the most obvious question is, “who decides what gets blocked?” When a corporation implements a web filter, it does so in accordance with corporate policy – policy that is set by the owner of the network. But the Internet doesn’t belong to any one entity, be it governmental or commercial, so such an authority simply doesn’t exist at this scale. In a very Orwellian sense, this filtering initiative appears to want to create that authority out of thin air.

I thought I’d throw an easy one out before taking off for the holiday.  Merry Christmas, Hannukah, Kwanzaa, Saturnia, etc., to all.

A few years ago, I was looking through some Cacti graphs of gigabit trunks between 6500s and noticed an abrupt change in traffic.  The graphs were nice and smooth at around 135Mpbs until, seemingly randomly, they just started going wild.  It seriously looked like a lie detector from the movies; I saw spikes up to 140Mbps in one sample and 2Mpbs the next sample for days and days.  I looked around to see if anything weird was going on somewhere on the network, but I didn’t find anything.

A few articles ago, we discussed getting logging up and running on your IOS box.  Part of the discussion was actually having the device log remotely to a box somewhere, but that’s kind of worthless without a properly (for definitions of proper) configured syslog server.  A low-end Linux box with an appropriate amount of disk space is a really good candidate to do this for you.  I’ll assume you’re running some Redhat-based distro.

I like logging on an IOS device.  I like to look at the buffer and tell you that your interface went down 30 seconds ago.  I like to look on the box and see that BGP with my Internet provider has been flapping since 02:13ET.  I like to look and see that one of the other guys has been making changes to the gear all morning.  I could go on and on.

Alright, that’s an exaggeration, but screen is pretty freaking cool.  It’s an app that’s (usually) run under Linux that lets you run commands then detach from that session and reattach later.  It doesn’t seem like much, but a few examples can show what it does for me.

I have a backup script at home that takes a target file, tars up everything listed in there, zips up the new file, and puts it on an external drive.  It’s very simple but takes about 3 hours to run.  I run it manually, so, in normal circumstances, I have to SSH in to my box and keep that window open for 3 hours while the backup runs.  With screen, I can open a new shell, run the script, and detach from it while everything gets backed up.

If you’ve never used TCPDump before, you’re missing out on one of the best parts of being a network guy – pointing fingers at everyone else.

TCPDump is an open-source app that copies packets on a machine’s NIC to screen or to file. TCPDump is typically a Linux/Unix app; in the Windows world, TCPDump is replaced by WinDump or Ethereal, now known as Wireshark. It’s a must-know for network dude(tte)s since it lets you capture the packets that a machine is generating. An app may be documented to work one way, but I’ve seen many times where the documentation is out-of-date or just wrong, and I’ve had to look at captures to see what it was actualy doing. I used it one time way back when a developer told me the switch was changing his HTTP POST to an HTTP GET; I captured the packets he was sending, pointed to the GET, and never answered a phone call from him ever again.

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].

We all have limited budgets these days. Long gone are the days of unlimited resources and uncontrollable expansion of the network, 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 monitor, trend, and alert the network. All this stuff is free and runs on Linux to save even more cash.

I assume you take every word I say to heart and that you’ve been using Dynamips/Dynagen for a few days now, right? Good. That’s a start, but let’s break down a simple lab 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. :)

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.