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
- The outside interface should not use the layer 2 BIA.
- Configure the outside interface to obtain an IP address via DHCP.
- Create a static default-route, but allow the DHCP server to assign the next-hop.
- Assign the inside interface 192.168.1.254/24.
Task 2 – Router Management
- The router clock & logged events should reflect your local timezone.
- 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.
- Buffer 128K of router memory for logged events. Log all event classes. Logged events shall have a sequence number & timestamp.
- When using the console port, privileged access shall be granted via a strongly-encrypted password.
- Configure a local username and password of your choosing. The config should not store the password in plaintext.
- 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
- PAT traffic local to your router’s private LAN interface to the router’s Internet-facing interface.
- Relay inbound HTTP traffic on ports 80 and 888 to a web server listening at 192.168.1.80.
- Relay inbound HTTPS traffic on port 443 to a web server listening at 192.168.1.80.
- Relay inbound POP, SMTP, and IMAP traffic to a mail server listening at 192.168.1.25.
- Relay inbound FTP traffic to an FTP server listening on 192.168.1.21.
- NAT should not have to be reconfigured if a new DHCP address is assigned to the public interface.
Task 4 – Traffic Security
- 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.
- The router should respond to TCP chargen input with a TCP reset and to UDP chargen input with an ICMP unreachable.
- Mitigate smurf & fraggle attacks.
- Disable source-routing and proxy arp on all appropriate interfaces.
- The router must drop idle transit TCP sessions after 30 minutes.
- The router will allow a maximum of 40 half-open transit TCP sessions to any one host.
- 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.
- 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.
- Return traffic for sessions initiated on the trusted network should be not be dropped by the untrusted interface filter.
- 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
- 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.
- 192.168.1.41 generates voice traffic.
- 2 non-interactive audio streams are sent to destination TCP ports 8422 and 8430.
- HTTP traffic flows from various LAN web servers to Internet clients.
- Do not mark any other traffic.
- Apply a policy to the appropriate interface that meets the following criteria, based on the IP ToS field.
- Voice traffic requires 90Kbps.
- 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.
- Remaining traffic should avoid TCP synchronization.
- 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.