Archive for the ‘firewall’ tag
I’ll start off with a warning. I’ve been running 8.3.1 on my home 5505 for a few hours now. Not only is this not really enough time for a thorough review, it’s also not the environment to test enterprise-level configurations. There are also a lot of details missing that I just don’t know about yet, so please do some research on your own to figure out what’s going to break if you upgrade your ASA.
If you haven’t heard, Cisco has released version 8.3.1 of their ASA operating system. I’m excited about this for only one reason – Smart Tunnels with tunnel policies.
If you’ve never heard of Smart Tunnels, you’re probably not alone. I don’t know why they’re not more popular than they are, but I dig them. A user connects to a URL, logs in, and a little applet loads on the machine that is used to proxy traffic through the ASA. It doesn’t proxy all your traffic, though; only traffic from applications that you define are sent through the tunnel. There is a huge problem that I can’t stand, though. What if you need to SSH through the firewall and to your local LAN at the same time? The smart tunnel applet doesn’t care or even know what you want to do; it tunnels all the traffic from the application. Not good, eh?
The big change to this in 8.3.1 is the addition of tunnel policies to the smart tunnels. According to the release notes, you can now dictate which connections do and don’t go through the smart tunnel. Now, I can configure the tunnel so that some traffic goes through the ASA to get to the production gear, but other traffic pukes out the NIC normally. I know a lot of users who are going to like not having to log in and out all day.
Note: I may do an article on smart tunnels once everything slows down a bit. It’s a solid way to implement a clientless VPN that doesn’t require administrative access on the machine to run.
The big feature that everyone is talking about, though, is the change to the way NAT is done. Back in the day (that means earlier this morning), if I wanted to configure a static NAT, I’d do something like this to create a static and a service NAT to two different boxes.
firewall(config)#static (inside,outside) 192.0.2.1 192.168.1.100 firewall(config)#static (inside,outside) tcp interface ssh 192.168.1.101 ssh
Now, you create an object and give that object all the attributes. I think Cisco calls this auto-NAT. I have no idea what the auto part means. In our example, we would do something like this.
firewall(config)#object network TESTHOST1 firewall(config-network-object)#host 192.168.1.100 firewall(config-network-object)#nat (inside,outside) static 192.0.2.1 firewall(config)#object network TEST2 firewall(config-network-object)#host 192.168.1.101 firewall(config-network-object)#nat (inside,outside) static interface service tcp ssh ssh
I would say that the configuration is easier to parse with your eyes if the ASA didn’t break up the configuration into two parts. If you were to do a show run and look for our configuration, you would have to look in two places. The first part declares the object name and the host/subnet/IP range for which it’s associated. The next part, which comes after the ACLs, declares the NAT stuff.
object network TESTHOST1 host 192.168.1.100 object network TESTHOST2 host 192.168.1.101 [SNIP a billion lines of ACL] pager lines 24 logging enable logging timestamp logging buffer-size 8192 logging buffered informational logging asdm informational logging host inside x.x.x.x flow-export destination inside x.x.x.x 12345 mtu outside 1500 mtu guests 1500 mtu inside 1500 icmp unreachable rate-limit 1 burst-size 1 icmp permit x.x.x.0 255.255.255.0 inside asdm image disk0:/asdm-631.bin asdm history enable arp timeout 14400 object network TESTHOST1 nat (inside,outside) static 192.0.2.1 object network TESTHOST2 nat (inside,outside) static interface service tcp ssh ssh
It may be simpler to configure, but it’s not simpler to figure out later. I’d rather have single lines of static statements; at least I can use regex on those efficiently.
There is a bright side to the new NAT thing, though. Because the NAT statements are configured in the object, you can now reference the real IP of the host in ACLs instead of the NATted IP. This will help those of us who use firewalls with 488249284 interfaces and that many NATs for each host. If we wanted to allow access to the SSH host in the example, we would write an ACL that allows access to 192.168.1.101 instead of finding the NATted address on that interface and building the rules to that address.
Speaking of ACLs, you can actually create a global access-group. Instead of creating an ACL with rules and an access-group to bind to an interface, you can build one single ACL and configure an access-group with the global directive to basically apply that ACL to all interfaces. A few quick tests show that you can have both interface and global access-group configured simultaneously and that interface ACLs will be executed first. I need to do some more testing to figure out exactly how these work together.
Everyone should upgrade, right? Nope. I don’t ever upgrade to something cool just because it’s cool. I also don’t like to have to buy more hardware to go up a minor revision. Take a look at the the memory requirements for 8.3.1; every model up to the 5510 requires more than the base amount to upgrade. I got lucky since my 5505 has 512MB in it already, but I would hate to have to justify quadrupling (!) the RAM in a 5540 just for some cool features.
Send any rotten tomatoes questions to me.
Here’s a simple one since I haven’t updated in a while. I have my ASA 5505 at home and want to forward TCP/80 traffic to my public IP to my webserver at 10.10.10.10. There are two steps here — forward the port and open the ACL.
To forward the port, I would use the static directive, but there are two ways to do that. I can either set up a one-to-one NAT or a port redirection. In the one-to-one NAT, you have a outside address that’s mapped directly to an inside address, and any traffic to that IP is passed to the inside host (if it passes ACLS, of course). One of the limitation, though, of using this setup is that you can’t use that IP as your PAT address, and, since I only have one IP, no other inside hosts would have a outside address to which to be NATted. The other method — port redirection — is a much better solution. In this setup, I actually forward a protocol/port on a outside address to a protocol/port on an inside address. Since there are other ports available on that outside address, the address is still available for other hosts to use as a NAT address.
In an enterprise, I would probably use an address out of my pool for the port forwarding, but, since I only have one address at home, I’ve got another decision to make. I can configure the static statement with an IP address or I can use the reserved word interface to indicate the IP that is on an interface. This is a great feature, actually, since my outside IP could potentially change without notice. I’m going to use that feature, too.
static (inside,outside) tcp interface 80 10.10.10.10 80
This is pretty simple, but I’ll explain. The ASA will take any request that comes in on TCP/80 (HTTP) on its outside interface’s IP and forward it to TCP/80 of 10.10.10.10. If my webserver ran on TCP/81 on my box, I could just change the last 80 to 81 to make it work.
The port is redirecting, but I still need to open the ACL. When that’s done, everything should work as expected.
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 very fast with a 5Gbps uplink to the backplane, which is potentially 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.
I use Google Analytics to track the 2 or 3 hits I get a day, and sometimes I see some interesting search terms. Yesterday, some googled up the term “does the ASA 5505 run HSRP”; I think that deserves a short article.
The ASA and PIX firewalls don’t actually run any of the usual HA solutions you use on routers. They don’t do HSPR, VRRP, or GLBP at all. Since firewalls have all sorts of state tables, connection tables, translation tables, blah, blah, blah, they need to share more information than just if they’re alive or not, so they use different methods to provide HA.
Cisco uses two different methods to handle this issue – a failover cable or a failover interface. On a PIX (above the 501s and 506s), you’ll see a DB-15 interface labelled…wait for it…”failover”. When a very expensive Cisco cable is placed between the failover ports of two PIXes, the boxes do some election stuff over it and decide on an active and a standby state for each (it does all sorts of stuff, but I won’t go into it). The other method is basically the same, but, instead of an expensive, proprietary Cisco cable, it uses one of the interfaces to connect the two. You basically connect a crossover cable between two of them, do some configuration, and we’re good. The ASA doesn’t come with a failover cable so it uses the interface method, but you need a license for that (imagine that).
Just for the record, if an ASA or PIX becomes the active member of the cluster, it takes over both the IP and MAC address of the primary. There’s no election and configuration of a standby address. The use of the real addresses, along with the constant sync of the state data, means a very fast and seamless failover. I actually SSHed through an FWSM (think of it as a PIX on a blade) and pulled the power plugs from it; I actually only lost one packet.
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.
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
ip address dhcp setroute
no forward interface Vlan13
ip address 192.168.13.1 255.255.255.0
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.
switchport access vlan 11
Plug all your stuff in, put the ports in the right VLAN, and enjoy.
I finally got my ASA 5505 up and running at the house, but I ran into a little problem — the box wouldn’t add the DHCP-provided default route into its routing table. That one threw me for a loop since the box is made for SOHOs, but it makes sense in some corporate, lazy way.
I got an IP from the DHCPD on the 5505, but I couldn’t get to the Internet. I checked the console, and it had an IP from the provider, so I checked ACLs; those were fine. I looked at the log and found this.
%ASA-6-110002: Failed to locate egress interface for UDP from inside:x.x.x.x/1028 to y.y.y.y/53
I had no clue what this really meant until I checked the routing table; there was no default route at all. For some reason, the ASA 5505 was ignoring the default route from the DHCP server upstream. The fix? Assuming your outside interface is VLAN 1, just do this.
ip address dhcp setroute
The box will go out and get the DHCP default route by itself, so no need to shut/no shut.
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. :)
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 126.96.36.199 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 …
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.