cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1124
Views
0
Helpful
5
Replies

ACLs - managing traffic between low and high security zones ?

oragain01
Level 1
Level 1

Hi,

I have two network with admin systems. The first one contains all the admin servers, DC, DNS, DHCP, WSUS,... for LAN servers. The second one contains an RODC, DNS, DHCP for DMZ servers.

I then have 20 DMZ networks. From: http://www.cisco.com/web/about/security/intelligence/firewall-best-practices.html#_Toc332806000 :

  • By default, all inbound traffic from lower-security-level interfaces to higher-security-level interfaces is denied; to pass, this traffic needs to be allowed in an ACL applied inbound on the lower-security-level interface.

I gather that to be able to allow traffic between the 20 DMZ networks and the RODC or the WSUS server, I actually have to add the rules to each interface. Which means not only do I have to add ACLs every time I create new networks (and remember to do it too), it is also a lot of ACLs to manage as these rules are not the only ones.

Without changing the security level of the networks. Isn't their a simple way to have only one ACL on the high security level interface for outbound traffic ? 

Because at this point, it be pretty much simpler to drop the level of the shared admin/dmz zones lower than the other DMZ and do an outbound ACL. But that would be weird.

Regards,

5 Replies 5

Philip D'Ath
VIP Alumni
VIP Alumni

Yes you can just create one ACL on a high security interface for outbound traffic.  Return traffic is automatically allowed.

But you really should have an ACL on every DMZ interface, or I don't see the point of having the DMZ if there are no access restrictions.

For instance, my DNSs are in the higher security zone. I want to open port 53 to everybody so they can actually talk to the DNS. Why would I need to add the DNS ACL rules 20 times ?

Same thing for all the domain chatter between servers and windows DC.

At the moment because Cisco by default denies traffic from lower security interface to high security interface, to allow traffic to pass it is required to add the ACL to each DMZ interface as inbound ACL.

So, sure, you have a gain in hardware resource consumption, but you get huge expense in setup, maintenance and ease of read forcing that kind of behavior.

Or if you prefer, is there a way to make a rule that applies to all (or a group) of interfaces. For instance, I would group the 20 DMZ interfaces into a group GrpA and apply an ACL to GrpA.

Or even better, all the networks that need access to the DNS and DC are Class C in the 10.1 Class B range. I could setup an ACL with the source being 10.1.0.0/16 that allows the DNS / DC traffic to the high security zone. And done. No need to apply to specific interfaces and every time I add a new DMZ I know for a fact the rule will apply as long as it is in the correct addressing scheme. After all, ain't an IP plan the point of reducing the management pain of ACL and routes ?

I don't think you understand the purpose of a firewall (to restrict and control access).  I think you might be better off with a layer 3 switch or a router.

Other options

  • Make all your zones the same security level, and add the "same-security-traffic permit inter-interface" command to allow interfaces of the same security level to talk to each other.
  • I have never used this myself, but you could try creating a global access-list.  Something like:

access-list global-in extended permit udp any object <ad controller> eq domain
...
access-group global-in global

Although I am no expert by far, a router with ACLs would be able to handle part of the job in the same way that a firewall is able to handle parts of what a router can do. But as much as I might not understand the purpose of a firewall. Granted, i ain't a firewall expert. I do believe that you do not understand my question either.

Coming back to ACLs, in this scenario, each network has its own VLAN and its one virtual interface (or whatever Cisco calls them) for each DMZ network.

Now how is the following rule:

* allow from 10.1.0.0/16 to 192.168.0.10 on tcp 53 and upd 53

applied to internal interfaces globally and used on every interface for incoming traffic any worse than having to do the same rule on a per interface basis where I would have to, considering Cisco's best practices, reduce the scope of the class B network to the specifc traffic coming in that interface ?

I would end up with

IFACE 1: allow from 10.1.1.0/24 to 192.168.0.10 on tcp 53 and upd 53

IFACE 2: allow from 10.1.2.0/24 to 192.168.0.10 on tcp 53 and upd 53

IFACE 3: allow from 10.1.3.0/24 to 192.168.0.10 on tcp 53 and upd 53

IFACE 4: allow from 10.1.4.0/24 to 192.168.0.10 on tcp 53 and upd 53

And so on....

Let me think for just a second there.... case 1, one ACL that can be applied uniformly to all the necessary internal interfaces automatically or one by one (a pain):

* easy to maintain, easy to implement, easy to setup. If you need to modify it, modify it once and it applies to every interface. You only set tcp 53 and forgot udp 53, only one change, not 20.

* Cost as much as a more scoped down ACL

* A server in the zone gets hacked, the guy changes the IP, what the hell do I care ? (Again in this specific scenario) Whatever IP he uses or tries to send traffic, he is still limited to the 10.1.0.0/16 scope as a source IP and only for tcp53/udp53 traffic ... and even then I don't really see the problem.

Case 2... As many ACLs to maintain as there are interfaces.

* pain in the ass to maintain and setup

* Cost as much as the more generic ACL, maybe even a little more in terms of hardware resources consumption as more bits are compared to validate a rule. I aint a HW expert either.

And I don't want each DMZ to be able to talk to each other, so i ll pass on that option :)

I do manage firewalls from other manufacturers, and you actually have the choice as to what level you apply a rule (the network level or network group level). Thus you can group all the required networks and apply the ACL to the network group. And because they are grouped, it does not automatically mean they can talk to each other.

Now if you tell me Case 1 is entirely doable and has no security impact other than not respecting Cisco's best practices. Then I call bull on my third party that has been billing me way too many hours!

I haven't used the global ACL rule.  I prefer to have per-interface rules myself.

My understanding is the per-interface rule is processed first (if one exists) and then the global rules.

So give the global one a try.  Perhaps it is a good fit for your needs.

Review Cisco Networking for a $25 gift card