Best Practices for ASA DMZ configuration

[schinatti]

Hi,

I'm configuring a new ASA box and am looking for some suggestions as to the best approach to configure and control my DMZ. Let's assume I have 3 interfaces:

- outside (security level 0)

- dmz (security level 50)

- inside (security level 100)

Both "dmz" and "inside" are RFC1918 private networks.

In general, I want to allow:

1) unrestricted access from "inside" to "outside" (via NAT global)

2) unrestricted access from "inside" to "dmz"

3) unrestricted access from "dmz" to "outside" (via NAT global)

4) Specific "dmz" hosts are exposed to "outside" (i.e. web, mail servers, etc.)

5) Some specific "dmz" hosts are allowed to connect to specific "inside" hosts on specific ports (like relaying mail internally)

Seems to me like a pretty basic setup, no rocket science here. I have this basically configured, but I'm not sure the best way to control "dmz" host access. The default "security level" based access rules seem to do the trick, except that when I add in the rules to allow the "dmz" hosts to allow access to specific inside hosts (#5), by assigning an ACL to the inbound interface of "dmz", then the DMZ hosts can now no longer access "outside" hosts. I can fix that by adding "allow any any" statements to the DMZ-IN ACL, but then those hosts can access "inside" hosts as well.

I can see a few approaches:

A) Add explicit "deny" rules to the DMZ-IN ACL to prevent the "dmz" hosts from accessing specific internal hosts/networks before the "allow any any" that gives them outside access.

B) Add an ACL on the outbound direction of the "inside" interface to explicitly deny all DMZ traffic except the traffic that I want to allow from the "dmz"

C) Maybe do something with NAT between "inside" and "dmz" ... although I'm not sure that truly prevents access, but rather masks the "inside" hosts addresses from the "dmz" hosts - specifically if an attacker compromised a "dmz" host and knew an internal host's address, they could still connect.

"A" seems like a decent solution (block it at the source), but I'm not thrilled with having to remember to add explicit deny rules if I add new networks, etc. It would be nice if I could have a rule that would "deny" traffic destined for an interface (as opposed to traffic destined to a host/netmask).

"B" seems like it might be slightly better since I don't have to remember to update the ACL if I add new internal networks.

For all the experts out there, what are your thoughts on what the best way to approach this is? Maybe an alternative approach that I'm not seeing?

Thanks in advance.....

[Jon Marshall]

Steve

"Maybe an alternative approach that I'm not seeing?"

No you have pretty much covered it i'm afraid. Bear in mind that to go from a lower to higher security interface you need static NAT (unless you have disabled nat altogether) but you shouldn't really rely on NAT for security.

Solution B will work but bear in mind it could intercept some none stateful traffic that is not coming from the DMZ ie. consider GRE as an example.

Solution A only affects DMZ traffic and so although you have to remember to add subnets, but your'e summarizing internally right :-), it will be easier to troubleshoot. Also the additional benefit is it doesn't have to pass through the firewall before it is dropped.

To be honest it isn't really going to make a huge difference other than what i have mentioned above. I tend to use inbound acl's but that is probably because i have been using pix firewalls for a while ie. pre 7.x code, and you only had inbound acls then.

Jon