Aaron's Worthless Words

Blog

  • Resetting Sections of the Config

    I was configuring a switch the other day and realized I had configured a trunk on the wrong port. God, I hate that. Instead of dumping the configuration for the port and doing a “no” on each line, I used the default command.

    Switch(config)#default interface G0/1

    This resets the configuration on interface G0/1 to how it was when Cisco shipped it to you. Much better than killing all the lines of the configuration one-at-a-time, eh?

    Default can be used for all sorts of stuff, too. You can reset the configuration for CDP, AAA, NTP…pretty much anything. It can come in handy if you want to reset just one part of the config without touching everything else you’ve configured on the box.

  • AFOL-KE and Above.net

    It looks like there was another bad BGP announcement over the weekend.  This time, a 24-bit network belonging to the country of Kenya was being advertised by Above.net.  The heart of the problem is the same as it was with the YouTube problem a few weeks ago:  someone who wasn’t authoritative for a network began advertising routes to that network.

    While this issue didn’t have nearly the impact that the YouTube incident had, just ask the people in Kenya who were offline for several hours while things were broken.  It’s just another item to add to your list of reasons that BGP needs to be fixed.

  • NAT on a PIX/ASA

    NATting sucks and can be confusing. I’m sure everyone agrees to that, but you have to use it at some times. In a PIX/ASA, it’s easy to configure a simple setup, but can be super-complicated in larger networks. In a simple lab, we have set up an ASA with inside and outside interfaces, with the inside as your internal and outside as the Internet.

    The NAT setup here is easy.

    nat (inside) 1 0.0.0.0 0.0.0.0
    global (outside) 1 interface

    This NATs everyone on the inside (0.0.0.0 with a mask of 0.0.0.0, or 0/0) to the IP of the outside interface (overload in the IOS world). The nat command says who gets NATted; the global command says what they get NATted to. Notice the number “1” in both commands; this is the NAT group and allows you to have some flexibility in your NAT strategy. In essence, if you match a nat line with a “1” in it, you’ll be matched to a “1” on the global list.

    What if you add a DMZ interface and don’t want to NAT when your inside network talks to it? That, my friend, is a little more complicated. We’ll assume your internal network is 10.0.0.0/24 and your DMZ is 192.168.0.0/24.

    access-list NONAT permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0

    nat (inside) 0 access-list NONAT
    nat (inside) 1 0.0.0.0 0.0.0.0
    nat (dmz) 1 0.0.0.0 0.0.0.0

    global (outside) 1 interface

    That was painful, but what did it do? That’s a very good question.

    We have multiple nat lines on the inside, so the firewall starts at the top and works its way down (there are exceptions). The first nat line has a group of 0, which is very special. If you match group 0, you are not NATted at all, and your connection is passed as-is with no changes. In our second example, you match if the ACL matches, so, if you’re going from the inside network to the DMZ, you won’t be NATted. If your connection didn’t match this line (like you’re downloading porn from the Internet), the firewall goes to the next line, which says to NAT everyone to group 1 just as we did in the first example.

    Another twist here is the “nat (dmz) 1 0.0.0.0 0.0.0.0” line. This says that anything from the DMZ is NATted to group 1 just as the inside traffic is.

    So, if the inside network connects to the DMZ, it doesn’t get NATted. If the inside goes to the Internet, it gets NATted to the outside IP of the firewall. If the DMZ connects to the Internet, it gets NATted to the outside IP as well, but what if the DMZ connects to the inside? That’s another story. 🙂

  • Commenting Access-lists

    There’s a very-overlooked feature of access-lists — the remark. Yes, this is very basic, but it’s worth mentioning, as it has saved me anguish time and time again.

    I use remarks to document each line of an ACL (on IOS, PIX, FWSM, ASA, etc.) so that when I go back later, I actually know what I did. They’re simple to use, and, I promise you, you’ll thank yourself for using it when the CTO asks why access to TCP/80 is open from the Internet to the development server.

    Easy to use.

    access-list 101 remark This line allows access from the Internet to the development server. See ticket 1234
    access-list 101 permit tcp any host 1.2.3.4 eq 80

    Now, when you get asked the inevitable question, you can look at the line and know to check ticket 1234 for more information. The remark is just a string, so you can put what you want. I like to put source and destination hostnames, protocol/port, ticket number, and date/time the line was entered for reference like this.

    access-list 2001 remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***

    It works with the ip access-list command as well.

    ip access-list extended INBOUND
    remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***

    It might be a good idea to use a remark to document what the ACL itself does. For example, on a firewall with 28974 interfaces, you might want to do something like this.

    access-list DMZ1_OUT remark This ACL allows traffic out of the DMZ interface
    access-list DMZ1_OUT remark *** ….
    access-list DMZ1_OUT permit …

  • Wireless Headsets

    We all have these at our desks. Not the bluetooth guys for your [tag]phone[/tag] (we could talk about that for a while), but the 900MHz headsets that your company gave you for those long and annoying calls with the boss. These things rocks, but they are oh-so [tag]insecure[/tag].

    A coworker who fields support calls has one, and we decided to see how far we could go with these. We were shocked to discover that he could field a call 2 full stories downstairs from his desk. I was able to take mine 1 story away without even a single bit of static in it. I’m sure I could have taken it farther, but construction kept me from going any farther.

    So, what, you say? The [tag]headsets[/tag] can only talk to their own base station, right? Well, yeah, but that doesn’t really mean much. The correct question to ask is whether or not the data is encrypted, and the answer is no. Let’s do the math, then:

    No Encryption + Long Range = DANGER!

    Check out this article from Steve Stasiukonis of Secure Network Technologies, Inc. In his job as an auditor, Steve discusses how he was able to gather confidential information by listening to wireless headsets in an office and use that information to gain access to the building for three days!

    The moral of the story: Protect your data — no matter what kind of data it is.

    The second moral: Assume everything is insecure unless demonstrated to be secure.

  • Basic Logging on an IOS Device

    I’ve been looking around at some lists and forums for technical help on Cisco gear, and one thing keeps coming up — people new to [tag]Cisco[/tag] devices don’t know how to look at logs. The [tag]logs[/tag] are your friends and a great tool. You can use them to see what your router is doing, what’s going wrong, and even when something happened.

    Get on your router and do a “show logging”. You’re looking at the log buffer where the router logs [tag]events[/tag]. If you don’t have anything in there, you need to run a “logging buffered informational” and “logging on” from config mode. This will turn on some logging at a basic level, and you should see some stuff going on. Keep doing a “show logging” and you’ll see the buffer start to fill up.

    If the buffer gets too big, the router will start cycling out old logs, so, if you have a lot going on, a message may cycle out, so keep that in mind. You can always set the log buffer to be bigger; by default, it’s 4K (4096 bytes), but you can change that with the command “logging buffered <SIZE>” from config mode. The size will be in bytes, so don’t make it too big or you’ll kill your router (Google up “syslog” to get started on having your router log remotely.).

    Since logging is on now, we can take a look at a sample line to see what kind of information you get.

    %SEC-6-IPACCESSLOGDP:list 2011 denied icmp x.x.x.x -> y.y.y.y

    In this sample, we have a line telling us that ACL 2011 has denied an ICMP packet from x.x.x.x to y.y.y.y. That’s probably something we want to note, since Larry User just called and said he can’t ping his development server. Since Larry’s IP is x.x.x.x, you know that you have to change ACL 2011 if you want Larry to be able to ping his server.

    How about this one?

    %SEC-6-IPACCESSLOGP: list 183 denied tcp a.a.a.a(51325) -> b.b.b.b(22)

    Patty just called to complain she can’t reach a web server via SSH. We know that SSH runs on TCP/22, that the server has an IP of b.b.b.b, and that Patty’s workstation has an IP of a.a.a.a, so we can see that ACL 183 is blocking her from her box. Now you can tell her that she’s being blocked and that, in order to grant access, she has to go though a bunch of red tape. We don’t want anyone except the systems guys on the box anyway. 🙂

    Here’s a non-ACL example.

    %LINK-3-UPDOWN : Interface Serial0/1, changed state to down

    It looks like your serial interface went down. I bet some people can’t get to some things, and the phone is already lighting up.

    [tag]Logging[/tag] is your friend. If there’s something not quite right, do a “show logging” first. I promise it’ll help solve a mess of problems for you.

  • Pakistan and YouTube — What Happened?

    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?

    I deployed a Cisco ASA at a location and couldn’t get logged in via SSH. 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 AAA 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 PIX OS versions do that same, so keep an eye out.

  • Remembering the Little Things

    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

  • The Cisco Network Hierarchical Model

    I got my CCNP 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 Cisco Network Hierarchical Model. 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 access, distribution, and core 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.