Mini-Lab: IOS Firewall + PAT + CBWFQ

I’m trying something new today: I’m writing a mini-lab. My idea is to take a few topics I’m not the best at or would like to review, and roll them into a lab exercise. Today’s mini-lab stems from a couple of desires. One, I need to put up an IOS firewall for my home network. I own a 2621XM expressly for the purpose, and I’ve been meaning to configure it for months. Two, I want to review Cisco’s best-practice tasks for securing an IOS device.

I don’t mean for this to be a difficult lab. If you’re seeking a major challenge, I don’t think you’ll find it here. This is mostly a “seat-of-my-pants” experiment, to gauge reader reaction. I read much of the Doc CD relating to CBAC and IOS firewall, and then came up with this task list. I didn’t invent any clever problems – mostly, these are straightforward tasks that will demonstrate that you have a handle on IOS Firewall and CBAC, or you don’t.
If you like the idea of mini-labs, perhaps I can collaborate with others to do more labs like this. Maybe a group of us can start writing “open-source” CCIE-level mini and full-scale labs. Now there’s an idea! ;-)

Mini-Lab: IOS Firewall + PAT + CBWFQ

Mini-Lab Requirements

• A single IOS router with 2 interfaces. In this lab, I’m using a 2621XM.
  • Fa0/0 is Internet-facing – the external, public, outside, or untrusted interface.
  • Fa0/1 is LAN-facing – the internal, private, inside, or trusted interface.
• IOS 12.4 Mainline, Advanced Enterprise Services – the router I’m using today happens to be running 12.4(18). You might be able to get away with a lesser version than Advanced Enterprise.
• Do not use TCP intercept or reflexive access-lists.

Task 1 – Connectivity

1. The outside interface should not use the layer 2 BIA.
2. Configure the outside interface to obtain an IP address via DHCP.
3. Create a static default-route, but allow the DHCP server to assign the next-hop.
4. Assign the inside interface 192.168.1.254/24.

Task 2 – Router Management

1. The router clock & logged events should reflect your local timezone.
2. Set the local time from a remote source of your choice. If your router is connected to the Internet, you might try 18.26.4.105.
3. Buffer 128K of router memory for logged events. Log all event classes. Logged events shall have a sequence number & timestamp.
4. When using the console port, privileged access shall be granted via a strongly-encrypted password.
5. Configure a local username and password of your choosing. The config should not store the password in plaintext.
6. Configure SSH for all virtual terminals. Require SSH V2. Authenticate using the local user database. Allow SSH access only from the Fa0/1 local subnet. SSH authentication should time out in 20 seconds, and only 2 retries allowed. Enable SSH event logging.

Task 3 – Address Management

1. PAT traffic local to your router’s private LAN interface to the router’s Internet-facing interface.
2. Relay inbound HTTP traffic on ports 80 and 888 to a web server listening at 192.168.1.80.
3. Relay inbound HTTPS traffic on port 443 to a web server listening at 192.168.1.80.
4. Relay inbound POP, SMTP, and IMAP traffic to a mail server listening at 192.168.1.25.
5. Relay inbound FTP traffic to an FTP server listening on 192.168.1.21.
6. NAT should not have to be reconfigured if a new DHCP address is assigned to the public interface.

Task 4 – Traffic Security

1. Internet hosts should not be able to query your router for NTP, CDP, finger, bootp, HTTP, HTTPS, or DHCP services. Do not filter traffic to achieve this.
2. The router should respond to TCP chargen input with a TCP reset and to UDP chargen input with an ICMP unreachable.
3. Mitigate smurf & fraggle attacks.
4. Disable source-routing and proxy arp on all appropriate interfaces.
5. The router must drop idle transit TCP sessions after 30 minutes.
6. The router will allow a maximum of 40 half-open transit TCP sessions to any one host.
7. Filter inbound traffic on the untrusted interface to only allow traffic matching the inbound NATs you created above. Log all denied traffic. Your filter should allow pings, traceroutes, and path-MTU discovery to work normally.
8. Inspect inbound traffic, using application layer inspection for traffic matching inbound NATs you created above. Use generic inspection otherwise. Log an alarm when inspection detects non-compliant HTTP traffic, HTTP traffic being used for P2P or IM, or tunneling of non-HTTP traffic, but do not drop this traffic.
9. Return traffic for sessions initiated on the trusted network should be not be dropped by the untrusted interface filter.
10. Traffic arriving on the untrusted interface with a source address from the trusted network should be dropped and logged. Do not configure filtering to achieve this.

Task 5 – QoS

1. Use the Express Forwarding and Assured Forwarding per-hop behaviors as appropriate to mark the following classes of traffic flowing from your LAN towards the Internet.
   1. 192.168.1.41 generates voice traffic.
   2. 2 non-interactive audio streams are sent to destination TCP ports 8422 and 8430.
   3. HTTP traffic flows from various LAN web servers to Internet clients.
   4. Do not mark any other traffic.
2. Apply a policy to the appropriate interface that meets the following criteria, based on the IP ToS field.
   1. Voice traffic requires 90Kbps.
   2. During congestion, audio stream traffic requires a guaranteed minimum of 160Kbps, and HTTP traffic requires a guaranteed minimum of 384Kbps. Do not reserve bandwidth exclusively for these classes.
   3. Remaining traffic should avoid TCP synchronization.
   4. Upstream from the router, your provider rate-limits the connection to 768Kbps.

Okay, there you have my first attempt at a lab exercise. I’m not 100% happy with it, but I learned a lot doing this. I really didn’t understand CBAC before this exercise, and most of the other stuff was a good review. I’ll post my solution to this mini-lab later this week and let all the readers pick it apart.