Thursday, December 17, 2009

iACLs; A Service Providers Best Practice on your LAN

When I first started working on Cisco gear back in the early 18th century, ACLs were one the the biggest deployment problems I ran into on a day to day basis. On my first day of being introduced to ACL's was also my first day of introducing our user base to self inflicted Goober Admin Denial of Service attacks (GADOS).... Oh sure they made sense on the various certification exams and talking about them with other geeks over a Bawls Cola at Star Trek conventions. Hey it's just basic boolean logic right? If this variable AND that condition AND this direction MATCH=1 please proceed with instruction, if not drop into the bit bucket. And no I never fell for the old noob; "Time to empty the bit bucket" trick...more then once. But something happened between paper and practice that made me loathe ACL's more then a middle seat and vegetarian airline meal. Is it just me or do vegetarians have the worst farts ever?

anyway...

Any field engineer worth their salt knows that you have to know ACLs like you know where all the speed traps are on your way to work. It is true that you will certainly use them often but ACL theory enables a lot of other features like Flexible Packet Matching, QoS, MCQ, etc... As Yoda would say, Know them you must yes...hmmmm" I really learned ACL practical implementation by fire as a consultant for a major ISP. We used ACL's to the most minute level. As the security threats changed, large hard to follow ACL's had to change. They were eating up too much router resources, folks were afraid to edit them due to a possible outage and staff turnover not only meant the loss of a team member but a loss of the verbal history to understand why many configs were done they way they were.

The iACL came out of that casting forge. ACLs as a feature will not change because of their boolean logic they will only keep expanding to include more AND conditions and some OR conditions. And lets face it, the security threat is not going to get easier only more detailed. A new way of using ACLs was needed at the ISP level. iACLs are not a new feature or a product from Apple they are a new method to use ACL's at your Internet Edge. The "i" in iACL stands for Infrastructure. These entries are very detailed and very powerful. I was going to put in some pointless quote about power and the darkside of the Force but I have already quoted Star Wars once in this blog and that is the legal limit. So let's build out an iACL for my network here in the CodeCave(tm). My network internal address in 172.16.1.0 which is the same I am using on the Internet which is of course illegal which means I am of course lying for simplicity sakes!

Step 00x01: iACLs are as personal to your network as your own underwear is to you. With that is mind, most of us have a good idea what traffic is on the network and if not if you have a feature like NBAR and/or NetFlow this will help shape your initial ACL. To get started, lets build out a Discovery ACL to see what traffic we actually have. I would start out with this one:

access-list 222 permit tcp any any eq 22 log
access-list 222 permit udp any any eq syslog log
access-list 222 permit udp any any eq ntp log
access-list 222 permit ospf any any log
access-list 222 permit icmp any any log
access-list 222 permit tcp any any eq tacacs log
access-list 222 permit ip any any log

Place this ACL on the inbound interface. Remember this eats up router resources so leave this on only as long as you need it to get a good picture of your network. I normally do 3-5 days, however, your mileage may vary! Many things depend on this, number of connections, router size, etc.

Step 00x02:Now I monitor my logs to see what is hitting where. I can do this with the command:

TechWiseTVRTR#sh access-list 222

10 permit tcp any any log (55 matches)
20 permit udp any any eq syslog log (8 matches
..... you get the idea here.....but one more just for fun
70 permit ip any any log (73 matches)

What I am looking for is a small number of hits on my IP ANY ANY statement. A large number means I have stuff not being classified and I need to redefine my Discovery ACL just a bit or dig back into NBAR/NetFlow to see what is flowing thru this network and try again. Remove the Discovery ACL when I am finished.

Step 00x03:Test time! Time for the rubber to hit the road! This is the final step before we create the iACL. I will create a phone call ACL that is very specific. I know this ACL works if the phone in the support center does not ring...

access-list 222 permit ospf host 172.16.1.1 host 224.0.0.5
access-list 222 permit ospf host 172.16.1.1 host 224.0.0.6
access-list 222 permit icmp host 172.16.1.1 192.168.0.0 0.0.255.255
access-list 222 permit tcp host 172.16.1.1 eq 22 192.168.0.0 0.0.255.255
..... You get the idea...OK one more, but this is the last time
access-list 222 permit ip any any log

I put the IP ANY ANY at the end with a log statement to still monitor hits. Run this for a week or so then remove it and proceed to the iACL!!!

Step 00x04: This is it. All the training in a Russian barn in Winter, running up the snow covered hill...Oh sorry, I really need to turn the TV off. Built out the iACL. An iACL has four modules that make it up:

- Deny Special Use and Fragments
- Explicit Permit
- Explicit Deny to Protect the Infrastructure
- Expect Permit for Transit Traffic

Before we get started building out our iACL remember the two most coveted rules in network engineering:

- Never have a end user troubleshoot a network
- Always build out your networks for the next person that follows you.

PLEASE remember to comment out your ACL's, so your history does not leave when you do.

Module 01: Deny Special Use. This module of my iACL looks like this with dated comments:

!---- Module 1 iACL Dec09 Deny Special Use RFC 3330

access-list 222 deny ip host 0.0.0.0 any
access-list 222 deny ip host 127.0.0.0 0.255.255.255 any
access-list 222 deny ip host 192.0.2.0 0.0.0.255 any
access-list 222 deny ip host 224.0.0.0 31.255.255.255 any

***shortened for blog. Check out the table in RFC 3330 for more address***

!--- Module 1 Dec09 Deny RFC 1918 IP space

access-list 222 deny ip 10.0.0.0 0.255.255.255 any
access-list 222 deny ip 172.16.0.0 0.15.255.255 any
access-list 222 deny ip 192.168.0.0 0.0.255.255 any

Module Two:Explicit Permit This is where I allow only authorized external traffic to access internal devices. In this example I will allow routing protocols and SSH only. Basically, it is my control and management traffic.

!---- Module 2 iACL Dec09 Explict Permit

access-list 222 permit ospf host 172.16.1.1 host 172.16.1.2 eq ospf
access-list 222 permit ospf host 172.16.1.1 eq ospf host 172.16.1.2
access-list 222 permit ospf host ospf_neighbor host 224.0.0.5
access-list 222 permit ospf host ospf_neighbor host 224.0.0.6
access-list 222 permit tcp host 172.16.1.4 host 172.16.1.8 eq 22

Module Three: Explicit Deny to Protect the Infrastructure from external sources

!--- Module 3 iACL Dec09 Explicit Deny to Protect Infra
access-list 222 deny ip any 172.16.1.0 0.0.0.255

Module Four: Explicit Permit. This is my transit statement to let internal traffic move about.

!--- Module 4 iACL Dec09 Explict Permit for LAN traffic

access-list 222 permit ip any any

Now you may have noticed that I do not have the source address in many iACL entries. This is becuse I have IP Source Guard enabled at the edge ports and I am enforcing this validation there. This keeps my iACLs smaller and router processing more streamlined. More info in iACL can be found at http://www.cisco.com/go/safe This iACL example is for an Internet Edge router. You can also have a smaller iACL for the LAN as well. Give iACLs a try in your shake and bake lab. They may look a little tough, but it's kinda like eating crap food, breaking it down to smaller parts makes it much easier and that's the idea of modules!

Jimmy Ray Purser

Trivia File Transfer Protocol
Astronomers have long used the Light Year as a standard of measurement. Not to be left out Nuclear Physicists need a measurement standard as well but for much smaller distances. They use the beard second. Which is basically how fast an average (define that I dare you) Nuclear Physicists beard grows in one second, around 5 nanometers. Type in beard-second in Google to see it covert an inch into a beard second to see how small of a measure this really is.

Disclaimer: The article is originally written By JimmyRay, www.networkworld.com

No comments: