Aaron’s Worthless Words

Let’s set up a scenario. You have a single [tag]router[/tag] that terminates your T1 to the Internet for your company. You serve your own website and email, but you’d like to be as secure as possible and use ACLs on the router to lock stuff down. Your router has two interfaces — S0/0 for the T1 and F0/0 for the LAN connectivity. Here’s a simple configuration showing the interfaces and an ACL to let you host your stuff.

access-list 101 remark *** Allow everyone to the website ***
access-list 101 permit tcp any host 192.168.1.11 eq 80
access-list 101 remark *** Allow everyone to the mail server ***
access-list 101 permit tcp any host 192.168.1.12 eq 25
!
interface Serial0/0
  ip address 1.1.1.2 255.255.255.252
  ip access-group 101 in
!
interface FastEthernet0/0
  ip address 192.168.1.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 1.1.1.1

So, that’s all, right? Yeah, not really. Remember that router ACLs are based on packets, not connections, so every packet is compared to the [tag]ACL[/tag]. Let’s say your workstation is at 192.168.1.201, and you try to go to aconaway.com to get some more great information (heh). What’s going to happen?

First, your packet will hit F0/0 on the router, and, since there’s no inbound ACL, the packet passes. The routing table send it across S0/0, which has no outbound ACL, so the packet keeps going and eventually lands on the web server. The return packet is generated and lands on S0/0 of the router. The router checks the ACL since we have one configured to look at packets inbound, but it doesn’t match. The only thing that’s allowed in is HTTP and SMTP to the appropriate hosts, so…*plunk*…right in the bit bucket.

The very-old-school way would be to allow all tcp established in (permit tcp any any established), but that’s pretty much worthless on today’s wonderfully-safe Internet. A better way would be to use [tag]CBAC[/tag] to dynamically allow access back in for your outbound connection.

The first thing you do is configure the inspect statements to create an inspection object that can be applied to interfaces just like an ACL. There are about a dozen things to inspect, but let’s keep it simple and only inspect TCP and UDP connections.

ip inspect name INSPECT-OUTBOUND tcp
ip inspect name INSPECT-OUTBOUND udp

In our simple case, we want to watch any traffic coming into F0/0 since this is the “trusted” interface, so we’ll apply the [tag]inspect[/tag]ion object inbound on F0/0. If you have a bunch of interfaces, you may have several inspection objects and have to apply each to the outbound direction of specific interfaces, but we’re just starting out, so here’s what’ we’ll do in our setup.

interface FastEthernet0/0
  ip inspect INSPECT-OUTBOUND in

That’s it! From now on, when you send TCP or UDP packets from your workstation to the Internet, the router will dynamically add entries in ACL 101 to allow the return traffic back in.

Running CBAC requires the firewall feature set of [tag]Cisco[/tag] [tag]IOS[/tag], so keep that in mind. Here’s Cisco’s typical technical page on CBACs. Depending on your IOS version, you should be able to do a “show access-list 101″ and see the dynamic rules. You can also do a “show inspect ?” to see a bunch of inspection stuff. Just check out the Cisco page for what to do.

—

NOTE: CBAC is very CPU and memory intensive. Depending on your traffic load, you may have to upgrade your router to get it working without taking the router down.

NOTE: Using CBACs is safer to use than the very-old-school way I mentioned, but it is not a replacement for a firewall even if you’re running the firewall feature set. The real security solution is to implement a firewall to filter traffic like this.

• (0)

Have you even looked at the first few lines of your [tag]Cisco[/tag] [tag]switch[/tag] or [tag]router[/tag] [tag]config[/tag] and wondered what those “service” lines were? Yeah, me, too, so I did a little research through the web and through some audit tools to figure a few out. Here’s some to pay attention to the next time you’re configuring that guy. As always, ? is your friend.

• service timestamps [ [tag]debug[/tag] | [tag]log[/tag] ]. This line deals with timestamps. Wow…what an eye-opener. You use this service to put timestamps in the debug or logging output instead of the standard uptime. You’ve seen it, haven’t you? The log says “5w8d: A HACKER GOT IN”, but there’s no way to know exactly when that really happened, eh? I actually set itmy gear up to record all the way down to the millisecond level.
• service [tag]password[/tag]-encryption. This guy encrypts your system passwords when your list the config. This is default nowadays (I think), but make sure it’s there so you won’t accidentally send someone your single enable password that you use as your user and enable mode passwords on all your devices. This isn’t a good encryption cypher at all, though, so don’t rely on it for password security.
• service [tag]compress[/tag]-config. If you have a huge config, you may run out of room in [tag]NVRAM[/tag] for the config. It’s not a good thing to see that your config buffer is full, and the config can’t be saved. Enable this guy to compress the config down so it can fit.
• service [ [tag]tcp-small-service[/tag] | [tag]udp-small-services[/tag] ]. Auditors love it when you have a “no” in front of these. This turns off the antiquated services like chargen, finger, and echo. Luckily, the default is to turn these off, but always make sure the intern didn’t enable them.
• service [tag]prompt[/tag] config. This is a good one to play tricks on your buddies. Doing a “no service prompt config” actually turns off the prompt on the box. You don’t see anything, but the box still takes commands. Funny when it’s not done to you.
• service [tag]dhcp[/tag]. Pretty easy — it turns on the DHCP server on the device. Of course you’ll have to configure the details, but it might be convenient.

That’s all.  Carry on.

• (0)