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.....