Discussion on:

Get secure with Cisco extended IP access control lists

Man, I hate to admit it, but I was running a deny by exception setup (for simplicity sake), but that is changing immediately! Yes I have a firewall to permit by rule (I love my pix), but a border router is intended to be the first layer of defense, and set as it is, it isn't much of a defense at all. This article really helped show me that I was behind the curve. Now... can I get the next installment early???

Great Article!

Skkz

As a rookie to ACLs,(and maybe speaking for other newcomers to the Cisco ranks) I'd love to see an article going into more detail on the wildcard masks (I believe you called them network masks) The writing of the ACL statement includes the wildcard mask, and this is where I always seem to falter. I've found it a bit easier to break the mask down to binary, (00000000.00000000.00000000.00000000) This seems to come in handy when writing a mask that is not all ones or all zeros. Where I run into trouble is when I have to include or exclude certain subnets where I don't want all of the subnets covered ( such as a wildcard mask of 0.0.15.255) I find that I'm a bit shaky in writing masks of this sort. Any suggestions for a rule of thumb for writing these? Is breaking the address into binary the best way?

in newer versions of IOS, you can type the subnet mask in ext. ACLs instead of the wildcard mask, Router will calculate it for you if the IOS is older, you can find a wildcard mask checker at http://www.boson.com/promo/utilities/wildcard/wildcard.htm

another thing is: try NOT to delete an access-list entry by typing "no ip access-list 100 host a.b.c.d host e.f.g.h", it will delete your complete access-list nnn; instead, copy and paste the complete ACL to a text editor, alter (or delete)the entries you want, insert a first line "no ip access-list nnn", then copy and paste the whole thing to the Cisco's command line

or use an ACL-Editor (www.chesapeakenetsolutions.com will help)

do not forget the rule "first match", all ACLs are handled top-down, exiting if a packet matches an entry (sound simple, but is often forgotten - believe me, you will spend ages for troubleshooting). The last entry is always an explicit deny any any, you do not have to enter it.

Last, ACLs are NOT working on Ciscos OC-48 and OC-192 Interfaces.

If you can do standard subnet mask notation, you can do access list wildcard masks. Access list wildcard masks are the binary NOT of standard subnet masks. For example, the standard address/subnet mask for the private class B address space is 172.16.0.0 255.240.0.0 (172.16.0.0 - 172.31.255.255). Expanded to binary, the subnet mask is:

11111111 11110000 00000000 00000000

Just change all 1s to 0s and vice versa to get the wildcard mask:

00000000 00001111 11111111 11111111

which equals 0.15.255.255, thus the wildcard mask on the second line of the sample access list.

This is a great article! I want to add some things to remember about access lists:

Access lists eat up CPU time on the router. Thus, try to be efficient (i.e. the fewest number of lines doing the most good). For example, I put the security (anti-spoofing, anti-PING, anti-known-attack), anti-known-troublemakers, etc.) list on the inbound port of my WAN link, where it can protect the entire network.

The other thing to remember is that while allowing by exception is the most efficient, itrequires you to decide what is allowed. That means layer 9 of the OSI model (Politics), with complaints from customers who want to do (fill in the blank) via the Internet while they're supposed to be working. Also, I had a customer once who had noclue that his homemade application was using port numbers above 1024, and wondered why he couldn't communicate with a distant location when he was able to PING it. Adding the port to the "allowed" list fixed his problem, once I found the ports he was using.

Good fortune,
Don

a couple things I have to correct from this article:

1. "access-list 100 permit ip any [your network IP address] [your network mask] est" does not work - it has to be TCP established, not IP.

2. I would recommend you go a bit more in depth so that people understand that with all extended access lists, there is an implicit deny at the end, even if it is not stated.

3. Do you have any plans on discussing CBAC/ip inspect rulesets? From my experience, thats the recommended way to go, instead of "tcp established" rules.

4. you mention 127.0.0.1 as the hardware loopback address of the ethernet interface - 127.0.0.1/8 is actually used as a software loopback interface on a system itself, not on the interface. i.e. you can have a loopback interface without even having a network adapter in a system. And, Cisco routers do not have a loopback address - and when they do, its very seldom a 127.x IP address.

5. A couple other recommendation I would add would be to permit udp/53 so clients can get DNS resolution, as well as ICMP echo-reply, time-exceeded, and unreachables so that clients can do traceroutes and pings out.

Just my $.02.

Unfortunately, once again there is a typo in your ACL. It needs to be "permit tcp any established" not "permit ip established" since TCP is the only protocol IOS will accept an established option for.

There's applications that do Service Port Hopping (jumping from port to port). Do you have any advise on approach in dealing with this? I've been told that Port Hopping is a result of bad application coding or implementation and that it needs to be fixed on the applications end.

Has anyone experience an application that only does port hopping and can not be port dedicated?