David Ramsden – Network engineer, general geek, petrol + drum and bass head
13Oct/14

Cisco Crypto ACLs – Do they really need to match?

When starting out with IPsec tunnels it seems to be a common misconception that the crypto ACL, sometimes referred to as the encryption domain or the interesting traffic, must match 100% or be mirrored at both peers or the tunnel won't come up. This isn't strictly true. Whilst the ISAKMP phase 1 and IPsec phase 2 proposals must match, the crypto ACL can be different.

Assume that at the local peer traffic to be encrypted originates from 10.0.0.0/24 and is destined for 192.168.0.0/24. The crypto ACL would be:

But what about the following?

IPsec phase 2 can still be established even though the crypto ACL isn't mirrored at the local and remove peer. The local peer specifies 10.0.0.0/24 but the remote peer specifies 10.0.0.0/8. In this scenario IPsec phase 2 can only be initiated from the peer that has the larger subnet. This is true for both Cisco ASA and IOS.

And in the example above, in the local peer's ACL there's a deny ACE but none on the remote peer's ACL. In this scenario any traffic originating on the local peer from 10.0.0.0/24 destined to 192.168.0.200/32 won't traverse the tunnel. The device (ASA or IOS router) will look at the next crypto map in the sequence and try to match traffic there. If no crypto maps are found it'll flow unencrypted out of the egress interface.

Obviously be careful with mismatching subnets and using deny ACEs in the crypto ACL because you may end up with traffic trying to enter the wrong tunnel and other strange things happening.

 

Tagged as: , , , , , , No Comments
9Sep/14

Reviewing Cisco ASA firewall rules

Today I was reviewing a firewall rule set on a Cisco ASA firewall. The firewall has around 399 ACLs (Access Control Lists) comprising of 7272 ACEs (Access Control Entries). Quite a task! Unfortunately I didn't have any tools to hand such as Cisco Security Manager or something like FirePac to audit the rules and give me some suggestions.

Stage 1 was to visually look at the ACLs and spot the obvious mistakes and remove them. Stage 2 was to then remove any unused names, objects and object-groups. I hacked up a Perl script to do this. The script reads the complete ASA config, gets all the names, objects and object-groups then works out which ones aren't referenced anywhere else:

Stage 3 was to work out which ACLs could be completely removed and which ACLs should be reviewed in more detail. If an ACL with or without ACEs, has a total of 0 hits it can (probably) be removed. If an ACL with ACEs has less than or equal to 100 hits it should be reviewed in more detail because the chances are some of the ACEs associated with it can be removed. A quick and dirty Perl script did the trick:

I found 181 ACLs that can be immediately removed and a further 16 to be reviewed. With an average of 18 ACEs per ACL, that equates to 3258 ACEs that can removed and 288 that may be able to be removed after a review.

By the end of this journey I should have reduce the rule set by at least 44.80%. After that the rule set just needs re-ordering to optimise the processing.

Tagged as: , , , , , 5 Comments
10Jun/12

Editing Cisco IOS ACLs

If you've administered Cisco PIX or ASA security appliances, you'll know how easy editing ACLs is. If you want to insert a new rule in to an existing ACL you can easily insert it where you want. For example:

 

This will insert the rule at position 12 of the outside_access_in ACL, pushing the existing rule at position 12 down to position 13 and re-ordering everything.

In Cisco IOS there's no obvious way to do this when working with ACLs. A lot of the time people will copy the ACL out, edit it in a text editor, "no access-list" the ACL and then paste in the modified ACL. Which does work but can be risky when working remotely as it's easy to lock yourself out of the IOS device. This can happen if you don't remove the ACL from interfaces before deleting the ACL.

But you can edit ACLs on the IOS device itself when using an extended ACL. Lets create an ACL:

 

If you view this ACL you'll notice line numbers:

 

Lets say you need to add another rule before the deny (sequence number 20). Enter the extended ACL:

 

Now you can insert a new rule by specifying a sequence number less than the deny rule (which is sequence 20):

 

If you view the ACL you'll see the new rule:

 

What you can now do is resequence the ACL so that all the sequence numbers are sequential. For example if you wanted the sequence numbers to start at 10 and go up in increments of 10:

 

If you want to delete a specific rule:

 

Tagged as: , No Comments