Aaron’s Worthless Words

Most firewalls should block [tag]ICMP[/tag] requests to them, so how do you know that your router or server has layer-2 connectivity to one? It’s pretty elementary, actually, but I’ve found that not a lot of people know this trick. If you ping the firewall, it will receive the ICMP packet and drop it per the rulebase. In this process, though, the firewall has to answer [tag]ARP[/tag] requests, which will be stored in the router or server’s ARP table. If you see it in there, you have connectivity.

On [tag]IOS[/tag]:

show arp

On [tag]Linux[/tag]:

/sbin/arp -an

This won’t help you if you’re not on the same network as the firewall, but it’s very helpful — especially if the firewall group is separate from the group you’re in. These commands have saved me a lot of time by not having to get a bunch of people on the phone to sniff packets as I generate them only to find that the firewall isn’t talking to my router.

• Leave a comment... (0)

I’ve seen a thousand [tag]firewalls[/tag] in my time, and nearly all of them are poorly configured. The biggest culprit? No [tag]outbound[/tag] [tag]filtering[/tag]. I guess a lot of people think that firewalls are there to protect the network from the Internet, but that’s only part of it. The firewall is to protect every segment from every other segment — all segments both inbound and outbound.

I guess that way back in the day that was true. You had your well-behaved network behind a firewall, and the only threat was from the evil hackers of the Internet. That’s not true any more, though. What about viruses? Or spyware? You don’t want those things spreading out from your network, do you? Think about liability, too. If you run a corporate network and an employee starts illegally downloading stuff from Kazaa, the company is liable for that, and the first step is to block any unneeded traffic from getting out.

Forget that your workstation sits on the inside of the firewall and remember that the intern down in development has a machine there. You know — the guy who “learned all about computers” in school. Use your firewall to protect the Internet from him!

—-

The note: Outbound filtering doesn’t keep the badies out completely. One of the first rules on your list will be to allow all users to TCP/80 on any host so everyone can surf. Any worm worth its salt these days will use TCP/80 for all its communications to take advantage of that hole, so you need to keep your antivirus and antispyware software updated to protect yourself and everyone else.

• Leave a comment... (0)

Remember the article on router-on-a-stick? And the one on HSRP? Let’s add to that example network, shall we? Let’s make those routers into edge routers so they connect your internal network to the Internet with some size circuit. Let’s just say they each terminate DS3s to different providers.

Here’s our network now (I’m experimenting with Visio alternatives, so excuse the diagram footer there). Let’s assume that we have [tag]HSRP[/tag] set up like the HSRP article and that we have many sub-interfaces on the Ethernet side of the routers like the ROAS article. Also, Router1 is the HSRP active peer and each router has a default route pointing to the upstream ISP through interface Serial 0/0.

This looks pretty good, but what happens if the DS3 on Router1 goes down? We won’t be able to pass traffic to the Internet at all since all the hosts are using the HSRP IP as their gateways. Oh, God…that sucks. What can we do? HSRP has a tracking feature, and we can use it to monitor the DS3 and decrement [tag]priority[/tag] if something happens to it.

Like everything in the network world, this is a piece of cake. All we have to do is one single line to each of our HSPR standby groups to set this all up. Remember to do each standby group on both routers.

standby 1 track Serial 0/0 decrement 55

Now, when the [tag]interface[/tag] goes down, the HSRP priority will be decremented by 55. If Router1 gets decremented by 55, Router2 will be the active peer since Router1’s new priority will be 45. If Router2 loses the interface and gets decremented by 55, nothing will really happen since Router2 is already the standby peer.

—-

The note: An interface has to be down for this to take place. If you lose line protocol but the interface stays up (the interface is up/down), HSRP won’t decrement the priority. Look out for an article on object tracking later to fix this problem.

• Leave a comment... (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)

When I started in IT, I tried to get my gear as standardized as possible to impress everyone. I worked at it and worked at it until I realized that there were a handful of things that sound good but just won’t work. If you’re just getting started in the field, you may not agree, but come back in 5 years and see how right I am. Heh.

• Assigning switchports to VLANs in chunks just doesn’t work. This seems like a great idea. You can put client A on port 1 through 12 and client B on ports 13 through 24. Then client A winds up with 13 servers, and B only has 3, so your whole scheme is in pieces on the floor. It’s just easier to plug servers into the next available port and forget physically organizing the ports. The switches don’t care if the ports are in order by VLAN. Just keep it simple.
• Color-coding cables only works for a while. Let’s cable web servers with green cables and application boxes with blue cables and the database servers with pink and the mail servers with aubergine. I promise you, though, that you will run out of cables of one color or another and wind up having a database server in green. Then you’ll have something else wrong. It won’t be long before the color standard only applies on paper.
• Labeling switchports by name only works if you buy servers all the time. If you’re in an environment where servers change roles and names, I guarantee you that your ports are mislabeled. The only time that labeling really works is if you’re lucky enough to work for a company with enough money to buy new stuff for every project. I’ve actually resorted to labeling ports with serial numbers instead of names since those won’t change.
• Complicated naming schemes don’t work. They may sound cool, but simpler names are almost always better. Name your router “r1″ or something.  Don’t try “rtr001prod1″ or something as ludicrous. I once made up this awesome naming scheme, and it worked until the business took on other projects that didn’t fall into the standard, so I was screwed. Save yourself some problems and keep it simple.

• Leave a comment... (0)

By default, most Cisco [tag]IOS[/tag] devices come configured to be accessed via telnet. This is probably fine for your house, but I really cringe when I run across corporate networks that use [tag]telnet[/tag] to access the devices. Telnet is old and out-dated and can be very dangerous. It’s in plain-text, which means that anyone who sees the packets can get your username and password. It also has no remote identification mechanism, so you can’t guarantee you’re talking to the device you think you are; you could be telnetting to a rogue device on your network without knowing it. [tag]SSH[/tag] gives you both things and more.

On IOS devices, SSH is encrypted based on host [tag]keys[/tag]. This means your stream cannot be read by anyone but you and the box. Since the [tag]encryption[/tag] is based on host keys, it guarantees that you are talking to the router or whatever you meant to. If you wind up on a rogue box or something, your SSH client tells you that the key the host provided isn’t the same as the one that was used the last time you SSHed over. Possibly the most important thing to know about SSH is that it is required for PCI or SarBox compliance where telnet is a no-no. Yes, I hate compliance, too, but what’s an admin gonna do?

So, how do we do this? Let’s work on the prerequisites first.

First of all, you have to be sure your IOS version actually supports it. Since there are two IOS naming standards, there’s not a magic number or letter to look for to know if yours is supported. I suspect that the letters “k9″ will guarantee that SSH is supported, but, if in doubt, the easiest thing to do is to look at the Cisco Software Advisor and look for a version that support “Secure Shell SSH Version 2″ (SSH version 1 is a terrible [tag]implementation[/tag] and should be avoided). Upgrade your box if needed.

The next prerequisite is pretty elementary: you simply have to add a domain name. You may have this configured already, but you need it to generate a host key. Here’s how.

ip domain-name your.domain.name

There’s another thing that is not really a prerequisite, but, in my mind, it is a wonderful thing to do. You should have a way to authenticate users instead of the telnet password/enable password thing. I mean where you put in a username and password and authenticate against some source somewhere. I recommend TACACS+ since it loves Cisco devices, but Radius or even local [tag]authentication[/tag] are fine. I’ll show you how to set up local authentication here since it’s the easiest thing to do here.

aaa new-model
username myuser password mypass
username myuser privilege 15

This is very simple, and I would never run it like this, but here’s what it means. The “aaa new-model” says to use the advanced authentication model to authenticate users. The default is to use local authentication, but it is fully customizable (this sounds like another article for later). The “username myuser password mypass” sets the password, duh! The last line sets your privilege level to 15, which is the same as getting into enabled mode. I suggest you set your users to other privilege levels and have everyone enables; it’s the same as logging into a Linux box and doing a sudo. NOTE: Try to log into the box from another window before you log off to make sure AAA is working. You may get locked out if you log out before testing!

Alright, now for the SSH part. First we need to generate a key.

cryto key generate rsa

It’ll ask you for the length. The standard is 2048, so just type that in for now. You can always re-generate your keys later. That’s actually all you need to configure to enable SSH. Yes, I realize 95% of the configure time is prerequisites. It’s comical, really.

After you get the key generated, open another window and try to SSH to it from your local SSH client or Linux box. It should ask if you want to add the key to the key ring or known_hosts file. Just say yes so you can track the keys in the future (remember the remote identification thing?). If it works, you’re golden. If not, check your firewall or AAA for problems.

Done, right? Wrong. Try to telnet over to your box — it’s still available. We should turn off everything but SSH. It’s not hard. The lines here will turn off all access to the CLI on the box except for SSH.

line vty 0 15
transport input ssh

One more thing and we’re done. You should set your SSH version to 2 instead of the default negotiate. This will make sure you’re not running the vulnerable and exploitable SSH version 1.

ip ssh version 2

The configuration is done, and we all still have all our toes, but what would a Cisco article be without a show commands. Here’s how to list all the settings for SSH on your box.

show ip ssh

Don’t you dare complain that this was hard because it wasn’t. Leave a comment or drop me an email if you have any questions or problems. I’ll be glad to help.

• Leave a comment... (0)