03-05-2012 12:24 PM - edited 03-11-2019 03:38 PM
Hello,
One question I have seen asked repeatedly is "How can I add an ACL to allow *some* traffic from one security interface to a higher one, while still allowing (the implicit rule for) all traffic to lower ones?" The answer is always that you can't, and that explicit permit statements need to be added.
The question I have is, how can ACLs be kept neat and manageable with such a limitation?
I'd like to illustrate my problem by example. If I have:
outside, security level 0
dmz, security level 50, subnet 192.168.101.0/24
inside, security level 100 subnet 192.168.201.0/24
By default inside can access everything, dmz can access outside only, and outside nothing. If I decide to allow traffic for DNS, say, from dmz to inside, I create an inbound ACL on dmz:
access-list dmz-in extended permit tcp any host 192.168.201.50 eq domain
How can I nicely allow all traffic to outside on the ACL? I could add a deny to inside, and then permit all...
access-list dmz-in extended permit tcp any host 192.168.201.50 eq domain
access-list dmz-in extended deny ip any 192.168.201.0 255.255.255.0
access-list dmz-in extended permit ip any any
That works; but then if I add more interfaces later (e.g. database with security level 75) then I've got to add similar exceptions. (And since I will probably need to allow access to the DNS server from database also, the problem is compunded, and multiplied each time I add a new interface. We're creating a VLAN for each customer and most will be routable without NAT.)
I would love it if there was a way to say "permit from dmz to outbound". Am I missing something, or a way of implementing that will be much neater? Or can anyone provide an example that shows better configuration?
Thanks,
Bob McChesney
Solved! Go to Solution.
03-05-2012 05:13 PM
Hello Bob,
With ASA's that is the way you got to configure them. my recomendation would be to create an object-group for the subnets or networks that the DMZ should be blocked and finally do a permit ip any any.
In the future if you add any new interface that the DMZ should not access, all you need to do would be to add that subnet into the previously configured object group.
For me that would be the best way to do it, and this will maintain a clean and neat ACL database in your ASA.
Regards,
Do rate all the helpful posts!!!
Julio
Security Engineer
03-05-2012 05:13 PM
Hello Bob,
With ASA's that is the way you got to configure them. my recomendation would be to create an object-group for the subnets or networks that the DMZ should be blocked and finally do a permit ip any any.
In the future if you add any new interface that the DMZ should not access, all you need to do would be to add that subnet into the previously configured object group.
For me that would be the best way to do it, and this will maintain a clean and neat ACL database in your ASA.
Regards,
Do rate all the helpful posts!!!
Julio
Security Engineer
03-06-2012 01:46 AM
Hi Julio,
That is quite a clean solution, thanks. I've created an object-group called 'local-networks' and I've put all subnets in it. Now if I overrule the implicit access-list, I just need to deny 'local-networks' then allow 'any any' for the Internet.
The only thing I don't like about that is that everyone must remember to add new subnets to the local-networks when they are created.
It would be nice (in my opinion) if it was more like IOS zone-based firewall, where rules are defined between two interfaces (not just on a single interface with IP addresses to defined blocks of addresses). I guess that's just not how ASAs (currently) work, and I'm sure there are people who disagree.
Thanks again,
Bob
03-06-2012 12:11 PM
Hello Bob,
That is correct! Glad I could help.
Please mark the question as answered so future users can learn from this topic.
Regards
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide