Pakistan and YouTube — What Happened?

Posted on February 25th, 2008 in BGP, InterNetworking by Aaron Conaway

BGP has issues; the main one being transitive [tag]trust[/tag]. [tag]BGP[/tag] works by having networks (companies, providers, etc.) advertise [tag]routes[/tag] that it owns to its peers. These peers pass those routes on to their peers, ad nauseum, until everyone knows what networks everyone has. The big assumption here is that you are advertising only networks for which you are responsible. The word “assumption” should be emphasized.

The Pakistani government decided that a video on [tag]YouTube[/tag] was bashing Islam, so they ordered the Pakistani Internet services to block it. Instead of filtering from their network out, they decided to advertise via BGP that they were YouTube. To make things worse, they used a more-specific, 24-bit route; since YouTube advertises a 22-bit route, the new Pakistani route is preferred since its more specific. The transitive trust of the BGP cloud allowed them to tell the world that YouTube was on their network, effectively taking YouTube completely off the Internet for few hours. YouTube finally changed their advertising to a bunch of 25-bit networks, which restored connectivity, and, eventually, the Pakistani ASN withdrew the route. Here’s a timetable from Martin Brown of [tag]Renesys[/tag].

Obviously something needs to be done about this. This is not the first time time that someone has (un)intentionally advertised someone else’s routes and took stuff down (The Yahoo! outage from July 2007 comes to mind). I have no solution, but TPTB might want to prioritize finding a more-secure method for controlling an IP space advertisements. Certificate-based peering? More filtering on the transit networks? There’s no good solution, really.

Can’t Login to Your ASA via SSH or Telnet?

Posted on February 18th, 2008 in ASA, PIX, Firewall, Cisco, Security, InterNetworking by Aaron Conaway

I deployed a [tag]Cisco[/tag] [tag]ASA[/tag] at a location and couldn’t get logged in via [tag]SSH[/tag]. I would get prompted, but, no matter what username/password I put in, it would just reject me. After some digging, it turns out that I forgot this command.

aaa authentication ssh console LOCAL

When I put this in, it let me right in as expected. I have no clue what the deal was. I guess I assumed that the ASA would use the local userbase if a [tag]AAA[/tag] service wasn’t configured. I guessed wrong.

I’m sure this will apply to telnet sessions as well. I’d also bet money that equivalent [tag]PIX[/tag] OS versions do that same, so keep an eye out.

Remembering the Little Things

Posted on February 7th, 2008 in Cisco, Security, InterNetworking by Aaron Conaway

Back in the day, when I used to put a new piece of IOS-based gear on the network, I would have to go through the gear already in production to remember what all those “little configurations” were that kept the devices running. Guess how many times I remembered to set the NTP server or turn off the HTTP server? Never.

To fix that problem, I started to keep a list of IOS commands that every IOS device on the network was configured with. That way, if I had another device to configure and deploy, I could just paste the list in and then do the IP and hostname stuff. It makes me feel a little more confident that the gear I deploy is more standardized and maybe even a little more secure.

Here’s a sample for you that I just made up off the top of my head. Obviously you need to change some stuff for your purposes, but you get the idea. Use the sample to generate your own list and save yourself from the embarrassment of having your box run SSH v1.

service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption

no logging console
logging buffered informational
logging 192.168.0.1
logging 172.16.0.1

no cdp run

ip domain-name mydomain.com
ip ssh version 2

no ip http server

access-list 1 remark *** SNMP access ***
access-list 1 permit 192.168.1.4
access-list 1 permit 10.1.0.1
access-list 1 permit 172.31.0.1
access-list 2 remark *** Remote access ***
access-list 2 permit 192.168.1.5
access-list 2 permit 10.1.0.2

snmp-server community mysecurecomm ro 1

line con 0
transport output none
logging synchronous

line vty 0 15
access-class 51 in
transport output none
transport input ssh
logging synchronous

ntp server x.x.x.x

What?

Posted on February 6th, 2008 in InterNetworking by flickr


What?

Originally uploaded by aconaway1

A few years back, my buddy Stephen was out doing a network installation for his company. He got everything working except for two workstations which had link lights, but simply would not send or receive any network traffic.

He checked the switch and didn’t see anything. He checked the jack, and everything seemed great. I’m guessing something caught his eye, because he pulled the jacks out of the wall and pulled out a cluster of cables you see here. The cabling contractor (a high-voltage guy who didn’t know what he was doing) actually painstakingly split the pins of the Cat5 cable from the switch to two jacks in the wall.

You’re right. It doesn’t work that way. He had the guy come out and fix it, and both workstations were fine.

The Cisco Network Hierarchical Model

Posted on February 6th, 2008 in Cisco, InterNetworking by Aaron Conaway

I got my [tag]CCNP[/tag] certification library the other day to finally get myself another cert, so I’ve been doing some reading of late. The thing I hate about certs is that, even if you have all the experience in the world, there’s always a whole mess of academic stuff that no one really knows or cares about. One of those things is the [tag]Cisco Network Hierarchical Model[/tag]. This model is purely academic and comes with the caveat that you may or may not want to need to use this model in your situation. In other words, here’s what we recommend, but do what you want to make your network run properly.

This model tells us to configure our network in three layers — the [tag]access[/tag], [tag]distribution[/tag], and [tag]core [/tag]layers.

  • The access layer is where hosts are connected to the network. This includes your closet switches for your users and any other switches where your servers connect up. This layer is OSI layer-2 only and includes physical segments and VLANs. When I think of this layer, I immediately think of a Catalyst 2950 or 3550.
  • The distribution layer aggregates the access layers into a central layer-3 device (a router or L3 switch) for distribution between access devices or up to the core. This is where you lock down access with ACLs. When I think of the distribution layer, I think of a 3750 or 4500.
  • The core layer combines your distribution layers at layers 3 and 4 and simply ships data from distribution layer to distribution layer. There’s no access control so that everything is as speedy as possibly. I think of 6500s or 7600 at this layer.

Did you notice that this seems to be LAN-based? You’re not imagining things. This model is for deploying a campus network where every host is in the same building or very close, so Ethernet dominates connectivity. You could apply other technologies, such as OC3s or DS0s on the core, I imagine, but there’s no mention of WANs at all in the model description.

Speaking of WANs, where’s my Internet access? Where’s my HTTP server farm? Where’s my firewall? Where’s my management system? Those questions are left answered in this model. This is where the caveat comes into play. You have to be able to place those devices in the network in the most efficient and effective place. Your Internet access will probably be in the core. The server farms, by definition, are just hosts, so you would create another access layer for those. Since you need to firewall those servers off, you’ll put their access layer under their own distribution layer with the firewall at the top for access control. Management is just another access layer, but the distribution layer where that lives isn’t quite as clear.

Like I said, it’s an academic model, so there’s no definitive answers for anything, but it has a lot of information in there that you may or may not have considered.

afs