Aaron’s Worthless Words

Have I talked about the Cisco Firewall Services Module (FWSM) before? It’s a firewall on a module for the 6500 and is based on the PIX firewall. The term “based on” is important here, since it does a lot of stuff the PIX does but everything. It obviously does connection inspection and filtering, but it does not do any VPN stuff. It’s not a license thing; it just won’t do it. If you want to do VPNs on the 6500, you have to get the IPSec VPN Service Module.  The VPN thing isn’t true, actually.  I believe version 3.1 and higher has support for VPNs.

Anyway, we won’t be going over any configs this time, but we can get some in the future. I just wanted to go over some stuff that you may need to know to get an FWSM working.

The FWSM does not have any physical ports on it. It uses the backplane of the switch to get a foot in the networks that you need it to. What does that give you? Well, it’s ultrafast on the 256Gbps backplane, which is a lot better than the 1Gbps on a physical interface. It also lets you have more interfaces than you could ever have on a firewall appliance (I think you can have 128 interfaces…someone correct me). I don’t know any firewall appliance that has more than 20 or so interfaces. It also is good for your cabling guy since there are no cables. I love it since I’m the cabling guy, too.

The FWSm can be set up with several security contexts. That means that you can chop up the resources of the module into “virtual firewalls” that operate separately from each other. This is pretty cool, actually, since you can, say, make a firewall for each of your hosting customers so that configurations on one don’t affect the others. You can also set the thing up in single context mode so it acts just like a single firewall. You’ll have to do some research to figure out what you want to do, and there are a lot of possibilities.

You can also set each context up in either routed or transparent mode. Routed mode is the “traditional” way to set up a firewall, where each interface is a different IP network with packets being routed through the FWSM. Transparent mode is where the FWSM has two interfaces that bridge the same IP network. I’ve always used routed mode everywhere, but you may have some use for transparent mode.

You also have to do some stuff on the 6500 to get the FWSM working. You make a vlan-group (a list of VLANs) to present to the FWSM and then assign that to the module. If you have more than one FWSM, you can have multiple vlan-groups; different FWSMs can control access in and out of different networks. Remember the context thing? If you have an FWSM in multiple contexts, you present the module with all the VLANs on all the contexts and split them up when you get to the context config part.

No configs. This is weird, but you’ll need to get all this information straightened out before you can get an FWSM configured properly.

• Leave a comment... (0)

Let’s keep going with our example setup on the ASA 5505 and set up DHCP on this guy. You can set it up to either forward (relay) DHCP requests to a DHCP server somewhere or have it be the DHCP server. Let’s do it.

To set up DHCP forwarding, you have to configure where the DHCP server is and then enable the relaying on the proper interfaces. Let’s say we have a DHCP server on the inside interface at 192.168.14.11 and we want it to serve IPs to the guests network. Setting up the DHCP server is beyond the scope here, so you’ll have to look elsewhere on how to set that up.

dhcprelay server 192.168.14.11 inside
dhcprelay enable guests

Another piece of cake, right?

Setting up the 5505 to be the DHCP server requires a few more lines, but, again, it’s easy. In the simplest setup, you only have to define your DHCP scopes and enable it on an interface. Let’s set up a DHCP scope for the inside interface of 192.168.14.101 - 120.

dhcpd address 192.168.14.101-120 inside
dhcpd enable inside

You probably want to serve a DNS server to the DHCP clients as well. You have two options — you can provide your own DNS server or have the 5505 serve the DNS servers it got from the upstream provider (like your cable modem provider) via DHCP. To serve out your DNS server at 192.168.14.12, just do this.

dhcpd dns 192.168.14.12

Serving the same DNS servers that the firewall got from the provider via DHCP is a little weird. Who puts underscores in commands? Assuming your outside interface is toward your ISP, just do this.

dhcpd auto_config outside

There’s the basics, but you can do all sorts of stuff with it. Change the lease time. Set the default search domain. Set a WINS server. Notice one thing, though; there’s no way to configure a default gateway. The ASA 5505 (and the rest of the 5500 series) only serve their own IPs as the default gateway, so be aware.

• Leave a comment... (0)

I’ve had my ASA 5505 in place at home on my Comcast cable for a few weeks now, and, let me tell you, this thing rocks. I did, however, have a few problems finding a clear answer on how I could set up my VLANs. It turns out that the base license on the ASA 5505 comes with a few restrictions with regards to VLANning — in particular the number of VLANs and the number of trunks.

When you have the base license and the ASA is in routed mode (you have IPs on interfaces), you can have three VLANs configured. One of them, however, has to be configured to not forward to one of the other VLANs. I had to go over that a few times before I got what the doc was saying. Basically, you have two VLANs that are fully functional and one that can only initiate traffic to one of the others. At home, I consolidated my network down to three VLAN — outside (I’net), inside (Users), and a DMZ (Guests). The inside interface can initiate connections to both outside and the DMZ, but the DMZ can only talk to the outside VLAN. This is probably not a very big deal to an average user, but I’m a network guy and will add networks just to say I’ve got one more subnet than you do.

I also had some confusion over the number of trunks available on this guy. My Aironet 1231 is set up to tag multiple bridged VLANs to the Ethernet so that I could have multiple SSIDs on it with each in their own VLAN. I did this by making the switch port on the 2950 into a tagged trunk. With the base license on the 5505, you don’t get any trunks. I didn’t find any docs that said you couldn’t, but it’s pretty obvious from the “show version” info.

VLAN Trunk Ports : 0

This really puts a damper on my AP setup. I had to reconfigure it to just use a single, untagged bridged interface with a single SSID. If I wanted to implement the Aironet 1231 the way I had it beforehand, I would have to upgrade my license on the 5505. I’m not paying any more money for this thing, so I’ll have to get one of my lab APs in place for guests. Thank God for eBay.

So, how do you configure this thing? First, let decide on our VLANs — say VLANs 11, 12, and 13. The configuration is just like any PIX 7.X

interface Vlan11
description OUTSIDE
nameif outside
security-level 0
ip address dhcp setroute
!
interface Vlan12
description GUESTS
no forward interface Vlan13
nameif guests
security-level 10
ip address 192.168.13.1 255.255.255.0
!
interface Vlan13
description USER
nameif inside
security-level 100
ip address 192.168.14.1 255.255.255.0

The interface VLANs are what handles the IP addresses. We’ll put specific ports in the VLANs in a minute, so hold tight. The configuration is pretty self-explanatory with VLAN11 being the outside (I’net), VLAN 12 being the DMZ (guests), and VLAN13 being the inside (users).  There is, however, the one line that reads no forward interface Vlan13. This is the line  that makes dictates which VLAN is a DMZ with respect to the base license and that this VLAN (VLAN12) can’t initiate connections to VLAN13. You also might have noticed the line ip address dhcp setroute. You can read one of the earlier articles on that guy.

The last thing you do is to put ports in VLANs. The ports on the 5505 are labeled Ethernet0/0 - 7, and you treat them just like an IOS switch with the switchport access vlan X command. At home, you would plug your cable modem (or whatever) into one of the interfaces (say, Ethernet0/0) and put that port into VLAN11.

interface Ethernet0/0
switchport access vlan 11

Plug all your stuff in, put the ports in the right VLAN, and enjoy.

• Leave a comment... (1)

GRE tunnels rock.  They are interfaces on a router that are used to “connect” to another router somewhere on your LAN, your WAN, the Internet, wherever.  The most popular use for them is for router-to-router VPNs.

I’ll let my friend Josh from blindhog.net show you how to do it.  He’s got a video on how to configure the tunnels, and another on how to set it up for VPN.

• Leave a comment... (0)

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 [tag]remark[/tag]s to document each line of an [tag]ACL[/tag] (on [tag]IOS[/tag], [tag]PIX[/tag], [tag]FWSM[/tag], [tag]ASA[/tag], 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 …

• Leave a comment... (0)

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.

• Leave a comment... (0)

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.

• Leave a comment... (0)

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

• Leave a comment... (0)

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

Nipper was the dog in the RCA logo, but that has nothing to do with this. What I´m talking about is the Network Infrastructure Parser. It´s a very nice tool for parsing the configs of your [tag]IOS[/tag] [tag]routers[/tag], IOS [tag]switch[/tag]es, CatOS switches, PIXes, ASAs, FWSM, and a whole mess of other gear. It´s ultra-fast and spits out a great report in HTML by default.

It’s very easy to use, so I won’t get into that, but check it out. It’s worth running your config through this guy every once in a while to make sure you didn’t miss something stupid. Check it out!

—

Note: You shouldn’t just trust one app to do all your auditing. There’s no way that just a single app can cover everything, so download a bunch of them and run them all when you do your audit.

• (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)