Classical Cat

Off on another track on this one - found this looking for some music to listen to at work while doing a project. Classic Cat has links to tons of free classical music recordings and is well worth checking out.

My current obsession is Chopin - I re-discovered a Prelude (Op 28 - 20) that I'd stumbled across in college and always loved, but lost the recording of it and couldn't remember the name. There are several different recordings of it available and it's very interesting to hear the different interpretations.

Anyway, good stuff and worth checking out.

BGP #2

BGP main attributes - Section One

BGP, as mentioned before, was built with several primary attributes in mind. The first of which is scale. BGP is the routing protocol for the whole Internet, essentially, and so it needs to be able to scale like crazy. How much, you ask? Check this out - as of this blog entry, you're looking at around 450,000 routes. That would melt any normal IGP - but it also means that BGP has to give up some things too. Keep in mind that a lot of people will have multiple copies of the BGP table in their router at a time - one for each ISP that they connect to.

As mentioned before, one of the things that BGP has to give up is rapid convergence. In order to scale up, BGP has to place a lighter load on the routers that run it, and it does this by

1. Never sending periodic updates - you get one update when a route changes - you better write it down
• Pretty much every other protocol does a periodic refresh of routes or link state
2. Those updates, since you never get another one, are sent reliably over TCP to guarantee delivery
• Yes, TCP is "heavier" than UDP or direct IP encapsulation, but it's a set up once and forget it sort of thing with BGP - the TCP session stays up as long as BGP does, which could be literally years
3. Updates are triggered, batched, and generally rate-limited
• Since they're not periodic, updates are only sent on a "triggered" event or change
• Updates are saved up and sent in batches to peers
• Cisco defaults to 5 second batches for internal peers and 30 second batches for external peers

Put all of this together and you get a protocol that tries to place a low load on the hardware, is very stable, but gets around to convergence - or figuring out what routes are valid for a given destination - in a more pokey fashion than other protocols. It's all part of BGP's charm.

I'll get back to BGP at some point here, but I thought I would mention this interesting find. While I was skulking about looking for some good CISSP materials, I found this podcast, and found the one episode I heard very interesting as it was discussed from the point of view of experienced TAC engineers. The episode I grabbed was about GETVPN and DMVPN and was quiet good. Definitely worth checking out if you like the intersection of security and Cisco.

I've decided to try to adapt a series of presentations that I did on BGP for the blog. So here goes with the first installment.

So, let's start with the real basics. What is BGP? I'm going to skip the historical stuff, other than to say BGP-4 (or the 4th iteration of BGP) is the current Border Gateway Protocol and was designed to fill the need for a routing protocol that could communicate routes and make routing decisions based upon policy for the Internet backbone.

There's quite a bit there, so let's look at a few things a little more. Most people, if they're familiar with routing protocols at all, are familiar with what are called "IGPs" or Interior Gateway Protocols. These protocols are designed to provide the information needed inside of an organization (or Autonomous System - you'll see this term more later) in order for my computer, for instance, to talk to another computer in that same organization.

Example:
My computer, 10.1.1.1/24, wants to talk to a server on 10.3.3.3/24. We're not in the same subnet, which usually means that there are router hops between my machine and that server. How do the routers know where these subnets are? They use IGPs (usually) to share that information with each other. Router A, which knows about 10.1.1.0/24 can tell router B about it while router B, which knows about 10.3.3.0/24 can tell router A about it. At that point, packets know where to go and communication via IP can ensue. Fast recovery of routes is important here, because we don't want stretches of network down for long periods of time. Overhead be darned - we're not talking about a lot of routes here in the grand scheme of things. Detailed information about how to reach networks is also important so that optimal routing decisions are made.

BGP isn't like that. BGP is for communicating BETWEEN the various organizations, and here policy can become very important. So, BGP is, as one example, used to communicate to the greater Internet what routes are available via your organization. It's used by ISPs to tell each other what routes they have. It's also used to pick, based upon whatever policy you have, which route into or out of your organization should be used.

So, IGP - how do I get around inside of my organization/company/collective. BGP - what do I want other organizations to know about my connectivity and how do I want them to connect to me if there are several options.

Now, because BGP is responsible for communicating routes for the entire Internet (there are a lot), scale is really important. Scale, scale, scale - did I mention scale? You try to carry the Internet tables in, say, OSPF, and you'll have a lot of pools of molten metal in your data center where a router used to be. Bad idea.

Here's the thing, though. A routing protocol can be scalable, fast, reliable - pick any two. BGP picked scalable and reliable. This means that it isn't that fast. Sure, there are things you can do to speed it up, but the more of that you do, the more you subtract from its scalability. Not that big a deal  if you're using it for a private MPLS network connection and you only have, say, 20 routes. If you're carrying multiple copies of the BGP table because you have several connections to various ISPs then that's another story.

Reliability:

BGP is built on top of TCP. It uses port 179 to communicate with its peers (statically defined peers - none of that multicasting stuff that IGPs do) and this gives its updates tremendous reliability. If TCP says that an update is going to get there then it's going to get there. BGP doesn't have to worry about updates being lost, which makes it very reliable. It also allows it to be very quiet. It only talks when there's an actual change, unlike most IGPs, which periodically refresh their tables whether there's a change or not.

Scalable:

BGP does a number of things to maximize its scalability. As mentioned above, it doesn't talk much, which keeps network traffic down. It also puts in delays before it notifies a neighbor of a change. BGP batches up updates and only sends them when the time to come around for the next batch to be sent. Contrast this with OSPF, which immediately sends out updates as soon at it knows anything, which is great for speedy convergence, but bad for scale, as every update increased CPU load on the receiving router. BGP generally also has longer "hello" intervals to keep track of its neighbors than other protocols. This again lowers the amount of traffic BGP is putting on the wire, but also means that convergence (or how soon the network is completely aware of changes) takes longer.

Just a quick thought for the moment. I can't say enough nice things about Lastpass as a password management system. It's gotten to the point where having to sign up for a password to log into something doesn't bother me anymore because I just have Lastpass generate me a terribly difficult password and store it for me. It'll even auto-fill or auto-login from that point.

I feel more comfortable with this than I do with using, say, my Google or Facebook password as a way into a new site.

Anyway, check it out. I'm a premium subscriber, but you get a ton of features from the free version too.

I stumbled across this password meter tool and thought it was pretty interesting.

zxcvbn

I've always wondered what makes for a good password beyond the obvious - everyone knows that random gibberish is good (but you can't remember it) and "password", "12345" (unless you're an idiot securing his luggage), and so on are bad, but what about in between? This tool gives you a pretty good way to test some password ideas to see how they look for strength. Just reading through the tests in this tool gives you some good ideas on what to avoid. The above link is a test site for tool. I would recommend messing with it, but do not use one of your actual passwords. General paranoia should be a good guide when handing out your password - that is, don't. That said, if your password is, say, a couple of words with some numbers at the end, try a test that's similar and see what it looks like.

FYI - it looks like this, which isn't so good.

If you want to read about the mechanics of this tool and how much thought went into it, here's a good link to do so. You might even spot some areas that could be improved.

Myself, I'm a big fan of using Lastpass and using it to generate big, nasty, random passwords for me. The (super cheap) premium option of having it on your smartphone is a very nice upgrade, but the free version is great too.

I just updated the firmware on my home Cisco E3200 access point/router to address the WPS security hole that's made even WPA/WPA2 vulnerable. Being paranoid enough to care about that, I also decided to take a look at Reaver and Wash, the tools that let you try to crack WPS or see if you have a vulnerable AP, respectively. First, though, as I mentioned, I had to update to the latest firmware and disable WPS, which I show below.


Updating E3200

Firmware installed:

Go to Wireless -> Basic Wireless Settings and click on Wi-Fi Protected Setup. Click Disabled and then click on Manual again. Make sure the manual settings are all correct and then click Save Settings at the bottom. If you click back to Wi-Fi Protected Setup, it should still show Disabled.

 

On to Backtrack 5

I started out looking at running Backtrack 5 as a VM, but that honestly didn't get me very far, although I will admit that I didn't put a lot of effort into it. I downloaded the VM, ran it in Vmware Player on my Win7 laptop, and it just never saw my wlan0 interface even after I twiddled with the settings. Figuring that running directly on the hardware is a better bet anyway, I downloaded the ISO and burned a DVD.

From there, I'll say that this Lifehacker article helped quite a bit on what to run regarding reaver, but didn't mention wash, which is what I really needed, at least to start. You see, wash tests to see if your AP is actually vulnerable to this attack by seeing if WPS is enabled. After I changed my settings in my E3200 to disable WPS (which required upgrading to the new firmware), my AP didn't show up in wash's tests and didn't respond to reaver. I will say, though, that more than a dozen APs showed up in the wash report in my neighborhood. I didn't run reaver against any of them, but it's interesting to know that somebody could.