Archive for the ‘acl’ tag
Stubby Post – Time-based ACLs and Policy-maps
Certain divisions of the company tend to shoot themselves in the foot by kicking off large file transfers during business hours, so I had a thought that maybe we could use time-based ACLs to do some QoSing for those guys. I fired up GNS3 with a 3600 running 12.4(25b) with some virtual PCs on it’s Ethernet interfaces.
time-range BUSINESSHOURS periodic daily 8:00 to 17:00 ! ip access-list extended PINGS permit icmp any any time-range BUSINESSHOURS ! class-map match-all PINGS match access-group name PINGS ! policy-map PM-F0/0-OUT class PINGS
First, I set the router’s time to outside of the time range and sent some pings over.
R1#sh clock
00:01:13.107 UTC Wed Apr 28 2010
R1#sh access-lists
Extended IP access list PINGS
10 permit icmp any any time-range BUSINESSHOURS (inactive)
R1#sh policy-map int f0/0
FastEthernet0/0
Service-policy output: PM-F0/0-OUT
Class-map: PINGS (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group name PINGS
Class-map: class-default (match-any)
11 packets, 1140 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Alright, that’s expected. Now let’s set the clock to within the time range and repeat.
R1#sh clock
13:00:12.887 UTC Wed Apr 28 2010
R1#sh access-lists
Extended IP access list PINGS
10 permit icmp any any time-range BUSINESSHOURS (active) (10 matches)
R1#sh policy-map int f0/0
FastEthernet0/0
Service-policy output: PM-F0/0-OUT
Class-map: PINGS (match-all)
10 packets, 980 bytes
5 minute offered rate 0 bps
Match: access-group name PINGS
Class-map: class-default (match-any)
20 packets, 1970 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
How about that? Time-based ACLs seems to work with policy-maps. I didn’t know that.
A Quick Intro to Google’s Capirca
Yeled left a comment earlier this week asking if I’d seen Google’s Capirca. I’d heard of it and checked out some presentation slides on it, but I’d never actually tried it out, so, in keeping with the script, I downloaded it to see what it could do. Remember, now, that I’ve been playing with it for about 2 hours now, so I’m no expert on its use.
Capirca is a Python-based solution that Google came up with to automate ACL creation on their many thousands of routers around the world. You can’t blame them for wanting to automate it, either. How many times do you think they ran into problems with typos or keying errors from their network guys across those devices?
Capirca is configured similarly to Snort. The concept is that you define objects like hosts, networks, groups, and services, then you define policies based on those objects. You run the app against your definitions, and it pukes out ACLs for you. It can do Cisco ACLs, Juniper ACLs, or IPTables rules, so that may come in handy, but I only care about the Cisco stuff right now.
Like I said, I haven’t messed with it before, but I got it working with very little frustration. From the root of the application (~/capirca-1.0 in my case), I edited def/NETWORK.net and added some custom objects to it to mess around. I added my home networks, my public IP address at home, and some of the work networks that I would use to access home services. Here’s what I added to the sample file.
...SNIP...
GUESTS = 10.0.2.0/24
USERS = 10.84.8.0/24
HOMENETS = GUESTS
USERS
WORKNETS = 192.0.2.0/24
MYPUBLICIP = 192.0.2.1
...SNIP...
Now I can use those objects to define some rules for the ACL. The rules are defined in the policies/ directory and are a little more complicated than the objects, but it’s not that hard. There are two types of entries in the policy files – headers and terms. Headers define the beginning of a new ACL and define what the platform (Cisco, Juniper, IPTables) you’re using and the name of the list. The terms sections define the details of the ACL like source, destination, protocol, port, and action. Here’s the policy file (that I called home.pol) that I added to simulate letting my work IPs get to SSH on my public IP, everybody get to HTTP on the same, and deny everything else.
header {
comment:: "F0/0 Inbound"
target:: cisco F00IN
}
term permit-ssh-services {
destination-address:: MYPUBLICIP
protocol:: tcp
destination-port:: SSH
source-address:: WORKNETS
action:: accept
}
term permit-http-services {
destination-address:: MYPUBLICIP
protocol:: tcp
destination-port:: HTTP
action:: accept
}
term default-deny {
action:: deny
}
That creates a new Cisco ACL called F00IN (for F0/0 inbound) that allows our interesting traffic and denies everything else. Now that the policy is configured, all I had to do was run the executable and see what happens. In the root directory of the application, there’s a Python file called aclgen.py that you run. Since we put all our definitions and policies in the default location, all I had to do is run that with no arguments. The output told me to look in filters/home.acl for my new ACL. That’s where I found this.
no ip access-list extended F00IN ip access-list extended F00IN remark F0/0 Inbound remark permit-ssh-services permit 6 192.0.2.0 0.0.0.255 host 192.0.2.1 eq 22 remark permit-http-services permit 6 any host 192.0.2.1 eq 80 remark default-deny deny ip any any
Looks fine to me. I pasted this into a lab router, and it worked like a champ. I think I’ll put some more time into Capirca to see if I can find a use for it at work.
Send any misspelled Battlestar Galactica references questions my way.
Director’s Commentary: I need to get a better mic if I want to keep doing this.
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
Object Groups in the ASA/FWSM/PIX
I can’t believe I haven’t talked about object-groups yet. I had a whole other blog entry written up, and, when I went to link things over, I realized I couldn’t find an intro to it. Here it goes.
Welcome to the modern world. A world of wonder. A world of quickly-advancing technology. A world where clusters of machines sit behind load balancers for scalability and availability. A world where those clusters need access to other clusters. A world where your firewall rulebase gets so big that it’s unreadable without some help.
Enough with the drama already. I would say I hate the cheesy stuff, but I think my whole blog is nothing but cheesy stuff, right? To the point. Enterprise firewall configurations can get quite large with ACLs applied in different directions to different interfaces. Our ACL entries number in the 6000 range, but the firewall we’re running says we’re only at 5% utilization in the ACLE memory space. That means that our not-top-of-the-line firewall is designed to handle 120k lines of ACLs. That can be quite a handful to configure by hand. There may be an easier-to-maintain solution, though.
Let’s say you have a cluster of servers behind your CSM that all need to access a database. Since there’s a nice ASA, FWSM, or PIX between the servers and database (as there should be), you have to open up access for this connection. Let’s say that you have four servers with the IPs of 192.168.100.101-104 that need access to 10.10.10.1 on the mySQL port (TCP/3306).
access-list LIST1 permit tcp host 192.168.100.101 host 10.10.10.1 eq 3306 access-list LIST1 permit tcp host 192.168.100.102 host 10.10.10.1 eq 3306 access-list LIST1 permit tcp host 192.168.100.103 host 10.10.10.1 eq 3306 access-list LIST1 permit tcp host 192.168.100.104 host 10.10.10.1 eq 3306
Where are your remarks? Why don’t you document something for once in your life?
Anyway, that’s easy, right. Four configuation lines isn’t so bad, but some of the server admins come to you one day and tell you that the company actually marketed the new web app and that tey are adding 37 more servers to the cluster. Now the 37 new servers need the same rules, right? The server dudes also tell you that, since the app has grown so much, the DBAs have set up a split-read-write scenario where the current database handles the reads and a new database handles the writes. That’s 78 new rules (37 to the old and 41 for the new). That’s a lot of rules.
Object-groups to the rescue. An object-group is a logical group of objects (duh!) that you can use to create ACLEs. You can create a group of hosts, a group of network, or a group of ports. For our example, let’s create an object-group that includes all the hosts in the new huge cluster.
object-group network CLUSTER1 description The Huge Cluster (that's what she said) network-object host 192.168.100.101 network-object host 192.168.100.102 ... network-object host 192.168.100.141
What do we do with it, though? You treat it (almost) just like it was a host in an ACL. Remember we wanted to open access to the old database on TCP/3306, right?
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 eq 3306
If you do a show access-list LIST1 now, you’ll see that a new rules has been added for each object in the object-group. It should look something like this.
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 eq 3306 access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 3306 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.102 host 10.10.10.1 eq 3306 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 3306 (hitcnt=0)
Notice that the firewall created 41 rules for you out of your one configured line, but now the rules are indented. The indention means that the rules is generated automagically instead of by hand. Since you can only take out rules that you put in by hand, so you can’t take out the line allowing 192.168.100.123 access; it’s an all-or-nothing scenario. Be aware of that.
You can use object-group for ports, too. Let’s add to our example and say that the cluster will need to access the memcached instance on the database server as well. Those processes run on TCP ports 15000 – 15100.
First we build an object-group for the ports we need.
object-group service DBPORTS description mySQL and memcached ports service-object tcp eq 3306 service-object tcp range 15000 15100
Now let’s apply it to the ACL.
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 object-group DBPORT
What does the ACL look like now? Well, it’s a Duesenberg.
access-list LIST1 permit tcp object-group CLUSTER1 host 10.10.10.1 object-group DBPORTS access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 3306 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 15000 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 15099 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.101 host 10.10.10.1 eq 15100 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 3306 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 15000 (hitcnt=0) ... access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 15099 (hitcnt=0) access-list LIST extended permit tcp host 192.168.100.141 host 10.10.10.1 eq 15100 (hitcnt=0)
That’s a lot of ACL entries for one configuration line, isn’t it? Let’s see. 102 ports times 41 servers is 4182 lines in the ACL. You can see how might be to your advantage to use object-groups at times.
Send any candy corn questions my way.
NAT on a PIX/ASA
NATting sucks and can be confusing. I’m sure everyone agrees to that, but you have to use it at some times. In a PIX/ASA, it’s easy to configure a simple setup, but can be super-complicated in larger networks. In a simple lab, we have set up an ASA with inside and outside interfaces, with the inside as your internal and outside as the Internet.
The NAT setup here is easy.
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface
This NATs everyone on the inside (0.0.0.0 with a mask of 0.0.0.0, or 0/0) to the IP of the outside interface (overload in the IOS world). The nat command says who gets NATted; the global command says what they get NATted to. Notice the number “1″ in both commands; this is the NAT group and allows you to have some flexibility in your NAT strategy. In essence, if you match a nat line with a “1″ in it, you’ll be matched to a “1″ on the global list.
What if you add a DMZ interface and don’t want to NAT when your inside network talks to it? That, my friend, is a little more complicated. We’ll assume your internal network is 10.0.0.0/24 and your DMZ is 192.168.0.0/24.
access-list NONAT permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0
nat (inside) 0 access-list NONAT
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 0.0.0.0 0.0.0.0global (outside) 1 interface
That was painful, but what did it do? That’s a very good question.
We have multiple nat lines on the inside, so the firewall starts at the top and works its way down (there are exceptions). The first nat line has a group of 0, which is very special. If you match group 0, you are not NATted at all, and your connection is passed as-is with no changes. In our second example, you match if the ACL matches, so, if you’re going from the inside network to the DMZ, you won’t be NATted. If your connection didn’t match this line (like you’re downloading porn from the Internet), the firewall goes to the next line, which says to NAT everyone to group 1 just as we did in the first example.
Another twist here is the “nat (dmz) 1 0.0.0.0 0.0.0.0″ line. This says that anything from the DMZ is NATted to group 1 just as the inside traffic is.
So, if the inside network connects to the DMZ, it doesn’t get NATted. If the inside goes to the Internet, it gets NATted to the outside IP of the firewall. If the DMZ connects to the Internet, it gets NATted to the outside IP as well, but what if the DMZ connects to the inside? That’s another story. :)