cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

6936
Views
0
Helpful
2
Replies

ASA ACL best practices

Hi Guys

Silly question, I have an ASA that has a very large number of access-rules. I have been tasked with performing a clean up of the rule base to remove any un needed entries.

A large number of rules consist of the same source and destination addresses and a single service entry i.e.

Interface= Outside

Source = any

Dest = ExchangeNAT (public IP)

Service = 25 (SMTP)

Then another

Source = any

Dest = ExchangeNAT (public IP)

Service = 443(HTTPS)

And another

Source = any

Dest = ExchangeNAT (public IP)

Service = 80 (HTTP)

Now what I was considering was grouping together the different services with ACE entries so it looks like this -

Source = any

Dest = ExchangeNAT (public IP)

Service = 25(SMTP),443(HTTPS),80(HTTP)

My reasons for doing is to condense the rulebase down so the others that need to access are not so imitidated by the large number of rules, can someone tell me if there would be a reason/benefit to keep it as it is or make the changes as I see fit?

Sorry if this sounds like a dumb question

Many thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Jouni Forss
Mentor

Hi,

Not a dumb question at all.

I think every or atleast most firewall enviroments runs into this at some point. This is because after possibly years of adding rules to the firewall there are probably alot of rules that could later be made more compact by creating "object-group" for both services and source/destination IP addresses.

Are you going to do this work through the ASDM or the CLI?

I personally only use the CLI to work with the NAT and ACL and therefore my view and approach to building rules are a bit different than you (IF you use ASDM)

Some small thing I personally tend to do while  rewriting ACL/NAT rules

  • Only use object-groups when you have several TCP/UDP ports or source/destination addresses that need to be grouped. Always using object-groups even for rules that have low amount of services or network defined might eventually make the configuration harder to read
  • Avoid using created object/object-group in many places so that later minor changes to the said object/object-groups dont cause unwanted changes in the configurations.
    • In some cases this might be beneficial. For example when defining object-group for source networks you might use the same object-group in some Policy NAT type configuration and therefore new network additions to both ACL and NAT rules could be done by adding network under the "object-group"
  • Configure the ACL and object/object-group NAMES in CAPS
    • Purpose is to easily differentiate them in CLI format configuration as all keywords and other configuration lines on the CLI are in small letters
  • Keep ACL and object/object-group names as short as possible to avoid long configuration lines
  • Try to plan a naming policy that follows certain logic. This will eventually make the configuration A LOT easier to read and might make troubleshooting faster.

Those are just some things that came to my mind. I will add if something else comes to mind and naturally if you have something on your mind do ask more.

I would see it as a benefit to go through and possinly partly rewrite the ACL and object/object-group configurations as it makes the administrative work easier. I guess there might be some performance related improvements but that depends on how much memory your firewall model has and how big the rules actually are.

On the Cisco router I am under the imperssion that writing big specific ACLs might cause problems or slow down the operations, though I have never run into a situation where an ACL has caused problems with its size on either IOS or ASA/PIX OS side.

- Jouni

View solution in original post

2 REPLIES 2
Jouni Forss
Mentor

Hi,

Not a dumb question at all.

I think every or atleast most firewall enviroments runs into this at some point. This is because after possibly years of adding rules to the firewall there are probably alot of rules that could later be made more compact by creating "object-group" for both services and source/destination IP addresses.

Are you going to do this work through the ASDM or the CLI?

I personally only use the CLI to work with the NAT and ACL and therefore my view and approach to building rules are a bit different than you (IF you use ASDM)

Some small thing I personally tend to do while  rewriting ACL/NAT rules

  • Only use object-groups when you have several TCP/UDP ports or source/destination addresses that need to be grouped. Always using object-groups even for rules that have low amount of services or network defined might eventually make the configuration harder to read
  • Avoid using created object/object-group in many places so that later minor changes to the said object/object-groups dont cause unwanted changes in the configurations.
    • In some cases this might be beneficial. For example when defining object-group for source networks you might use the same object-group in some Policy NAT type configuration and therefore new network additions to both ACL and NAT rules could be done by adding network under the "object-group"
  • Configure the ACL and object/object-group NAMES in CAPS
    • Purpose is to easily differentiate them in CLI format configuration as all keywords and other configuration lines on the CLI are in small letters
  • Keep ACL and object/object-group names as short as possible to avoid long configuration lines
  • Try to plan a naming policy that follows certain logic. This will eventually make the configuration A LOT easier to read and might make troubleshooting faster.

Those are just some things that came to my mind. I will add if something else comes to mind and naturally if you have something on your mind do ask more.

I would see it as a benefit to go through and possinly partly rewrite the ACL and object/object-group configurations as it makes the administrative work easier. I guess there might be some performance related improvements but that depends on how much memory your firewall model has and how big the rules actually are.

On the Cisco router I am under the imperssion that writing big specific ACLs might cause problems or slow down the operations, though I have never run into a situation where an ACL has caused problems with its size on either IOS or ASA/PIX OS side.

- Jouni

View solution in original post

Hi Jouni

Thanks for your response, I will be reconfiguring the ASA using the ASDM (Easier and quicker for me)

I totally get where you are coming from, I want to make it as simple and easy to understand as possible, saves people having to call me all the time!

cheers,

Matt