ASA 5510 DMZ config

[jsdurstjsdurst]

Hi!  I've configured a DMZ on my ASA 5510 using ASDM 6.4.

The DMZ has a security level of 25.  I added an ACL to allow the servers in the DMZ to communicate to a couple of our backend databases on our internal network over SQL ports.

My problem is that once I configured the ACL, the whole security level concept seems to have gone out the window.  In order to allow the DMZ servers to freely initiate communication to the outside world, I had to add a deny entry to prevent further access to my internal networks, then right below I had to allow IP any any.  This gives the same effect I guess, but its kinda tedious.  Is there a way to get the Implicit rule back that stated a destination "Any less secure networks"?  It disappeared once I configured the rule.

Thanks for any assistance.

Jeremy

[varrao]

Jeremy,

Two things here, first for going from high security to low security interface, you don't need an ACL to permit the traffic, it is implicitly allowed. But if you are going from low security to high security, you would need an ACL to allow the traffic, so for going from DMZ to internal network I would suggest you to keep only those hosts which are allowed to access servers, rest should be dropped. Maybe I am not in sync with you, so I would request you to please provide a running config from the firewall, so that I can have a look at it, the main things that i am looking out for is the NAT configuration, ACl and Access-group config. If it is not apt for you then you can remove the real ip's and replace them with dummy ip's.

Thanks,

Varun

[jsdurstjsdurst]

We are not utilizing NAT.

Without an ACL applied to the DMZ interface, the DMZ hosts could communicate with any networks with a lower security level.  Once I added a single entry to permit traffic from a DMZ host to a specific host on a more secure interface, then all other traffic was being dropped by the implicit deny any.  Hosts on the DMZ could no longer freely communicate with hosts residing on an interface with a lower security level to include the outside interface.

Our config is fairly lengthy, and it includes my current ACL that I had to implement as a workaround to this problem.  The pertinent information is below.  Without those last two lines of the access list, the hosts on the DMZ could not reach the internet via the outside interface and the hit counter was incrementing on the implicit deny all listed in ASDM.

interface Ethernet0/0
speed 100
duplex full
nameif outside
security-level 0
ip address x.x.x.x.
ipv6 address x.x.x.x
ipv6 enable
!
interface Ethernet0/1
no nameif
no security-level
no ip address
!
interface Ethernet0/1.100
vlan 100
nameif sdn
security-level 50
ip address x.x.x.x
ipv6 address x.x.x.x
!
interface Ethernet0/1.200
vlan 200
nameif DMZ
security-level 25
ip address x.x.x.x
ipv6 address x.x.x.x.x
!
interface Ethernet0/1.401
vlan 401
nameif MGMT
security-level 90
ip address x.x.x.x.
ipv6 address x.x.x.x
!

access-list DMZ_access_in extended permit object-group TCPUDP host SVRLIN-MI-RSEWS object-group ADservers object-group ad-3
access-list DMZ_access_in extended permit udp host SVRLIN-MI-RSEWS object-group ADservers eq ntp
access-list DMZ_access_in extended permit tcp host SVRLIN-MI-RSEWS object-group ADservers object-group DM_INLINE_TCP_1 inactive
access-list DMZ_access_in extended permit tcp host SVRLIN-MI-RSEWS host SVRLIN-MI-RSEDB eq 3306
access-list DMZ_access_in extended permit ip host SVRLIN-MI-RSEWS host x.x.x.x
access-list DMZ_access_in remark To allow Website to monitor backhaul devices.
access-list DMZ_access_in extended permit icmp host SVRLIN-MI-RSEWS object-group DM_INLINE_NETWORK_3
access-list DMZ_access_in extended deny ip any object-group DM_INLINE_NETWORK_1 log
access-list DMZ_access_in extended permit ip host SVRLIN-MI-RSEWS any log

[brquinn · Accepted solution]

Jeremy,

This is expected behavior. Once you add the ACL all traffic hits the implicit deny any rule regardless of the security level of the destination. The security levels at that point really only matter for your nat configuration.

I hope this helps.

Thanks,

Brendan

[varrao]

Hi,

Sorry for the late reply, had a busy day today. Yes, Brendan is correct, once you add an ACL on an interafce, it would implicitly add a deny ACL at the end, so you would need to specify the traffic that needs to be permitted otherwise it would be dropped. Moreover just to verify this, in the ASDM if you remove all he ACL from an interface, you would see the implicit deny also removed, but the moment you add an ACL, the deny ACL would be added as well.

Thanks,

Varun

[jsdurstjsdurst]

Thanks for the clarification.  It seems to me anyway that it would be beneficial to allow the security levels to remain in effect with the ablity to create exceptions.  Sure, it can be worked around, but it would be a nice feature especially when you have several networks located in higher security levels that are not easily summarized.

Thanks again!

Jeremy

[Mark Mattix]

I am in the same situation as Jeremy. I've added an ACl rule to my DMZ but the allow DMZ to less secure networks is gone. So if I read people's respnses correctly once I add any rule all traffic owuld be blocked if I now don't create a rule allowing the DMZ back out to the internet? What would that ACE look like, this?

access-list dmz permit dmz outside

I just need help in insuring the DMZ access to the internet continues to function as it currently is. Thanks for any help!

[jsdurstjsdurst]

Mark,

My workaround has been to first put in Deny statements for each network in security level above the DMZ.  Then add a Permit IP any any below those .  This will have the same effect, and you can punch holes by adding your specific Permit statements to the top. 

Keep in mind that when you add another network with a higher security level, you will have to add the appropriate Deny statement to the DMZ interface.

Hope that helps.

[Mark Mattix]

Thanks for your reply Jeremy. So you're saying you added deny statement for your DMZ going to the Inside or any more secure network than after those denies you added the permit ip any any? I'm not totally sure about that.

[Jouni Forss]

Hi,

You can easily create an ACL for the interface that blocks traffic to higher "security-level" interfaces/networks

You can group all the networks in question under an "object-group" and use that in the ACL rule

Lets say we had the following networks

• DMZ 192.168.10.0/24
• LAN networks 
  • 10.10.10.0/24
  • 10.10.20.0/24
  • 10.10.30.0/24

Lets also say that we wanted to block traffic from DMZ to any of the LAN networks but allow traffic to the external networks (Internet)

We could do

object-group network DMZ-BLOCKED-NETWORKS

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

network-object 10.10.30.0 255.255.255.0

access-list DMZ-IN remark Block Traffic to Internal networks

access-list DMZ-IN deny ip any object-group DMZ-BLOCKED-NETWORKS

access-list DMZ-IN remark Allow other outbound traffic

access-list DMZ-IN permit ip 192.168.10.0 255.255.255.0 any

access-group DMZ-IN in interface dmz

Now lets say you have some internal DNS servers like 10.10.10.10 and 10.10.10.20 to which your DMZ server must reach then you would add the following things to the above ACL

object-group network INTERNAL-DNS

network-object host 10.10.10.10

network-object host 10.10.10.20

access-list DMZ-IN line 1 remark Allow DMZ DNS queries to Internal servers

access-list DMZ-IN line 2 permit udp 192.168.10.0 255.255.255.0 object-group INTERNAL-DNS eq 53

access-list DMZ-IN line 3 permit tcp 192.168.10.0 255.255.255.0 object-group INTERNAL-DNS eq 53

After this the ACL would look like this

access-list DMZ-IN remark Allow DMZ DNS queries to Internal servers

access-list DMZ-IN permit udp 192.168.10.0 255.255.255.0 object-group INTERNAL-DNS eq 53

access-list DMZ-IN permit tcp 192.168.10.0 255.255.255.0 object-group INTERNAL-DNS eq 53

access-list DMZ-IN remark Block Traffic to Internal networks

access-list DMZ-IN deny ip any object-group DMZ-BLOCKED-NETWORKS

access-list DMZ-IN remark Allow other outbound traffic

access-list DMZ-IN permit ip 192.168.10.0 255.255.255.0 any

Any other future additions to allow traffic to the Internal networks would be added just like the DNS rules

Hope this helps

Please do remember to rate helpfull answers

EDIT: Naturally if you are implementing an ACL to an interface which has had none it would be good practice to determine all the internal resources these servers require before attaching the ACL to the interface.

- Jouni

[jsdurstjsdurst]

As Jouni also demonstrated, the Permit IP any any (Jouni was specific to the interface address range) allows the traffic out to the internet.  This rule is at the end, and processed last, so if the traffic was destined to one of your internal addresses, it would have been blocked by the Deny statements above it.

Good Luck!

[Mark Mattix]

What Jouni and Jeremy said makes sense to me. I called TAC just to make sure and he mentioned that a NAT would have to be setup to allow the DMZ into the Inside. I have ASA 8.2 is this why I have to NAT? The TAC is going to call me back soon so I can discuss this with him but NATing to the inside from my DMZ doesn't make sense to me, why is that also something I have to do? I thought if something from the DMZ is destined to my allowed inside host that the ASA would know how to get there, where does NAT come in to play?

Thanks for the help!

[Jouni Forss]

Hi,

The reason probably is that if you only had Dynamic PAT configured for local interfaces and nothing for the traffic between the local interfaces then the traffic from DMZ would match the Dynamic PAT rule but would have no PAT address configured for the INSIDE interface.

For example

global (outside) 1 interface

nat (inside) 1 x.x.x.x y.y.y.y

nat (dmz) 1 x.x.x.x y.y.y.y

Traffic going from DMZ to INSIDE would probably match the "nat" statement and since there is no "global" command for "inside" the traffic wouldnt be permitted.

I usually go around this by configuring Identity NAT.

static (inside,dmz) netmask

I guess NAT0 would also be an option.

In the newer softwares you wont run into this problem between your local interfaces

- Jouni

[Mark Mattix]

In my config there is no nat (dmz) 1 x.x.x.x y.y.y.y. We use static translations to the specific external IP. The other 2 statements you mentioned are correct.

With the command, "nat (dmz) 0 access-list acl_name" Does this mean, anything matching in the ACL, "acl_name" would get no address translation? Does 0 after the nat statement always mean there will not be a translation?

I also have "global (dmz) 1 interface" configured. Does this mean anything on my internal network going to my DMZ is being NATted with the DMZ's interface IP?

With the new info I provided do you still think hosts from the DMZ are matching a NAt statement somewhere? I'm still not 100% clear on why NAT has to be setup. Is it becuase anything going out the inside interface is already setup for NAT to my global interface?

[Jouni Forss]

Hi,

The following configuration line

nat () 0 access-list

Refers to a NAT0 configuration. You can have one of these per interface. All the NAT0 rules for networks behind those interface should be configured in the ACL used.

To me the command

global (dmz) 1 interface

says that you possibly have a Dynamic PAT configuration that might translate traffic arriving from behind other interfaces which have a "nat" command of corresponding ID 1 to the IP address of the "dmz" interface when they are connecting to some host behind the "dmz" interface.

That single command doesnt really tell me if its applied in your situation since I dont know the rest of the configurations. But it might hint to a situation where you would run into problems with traffic initiated from "dmz" to "inside" since in that direction the packet wouldnt match any translation but on the reverse check it would match the Dynamic PAT configuration mentioned and be dropped.

The easiest way for you to test what would happen and happens to your traffic is to simulate those packets with the "packet-tracer" command

For example for traffic coming from "inside" to "dmz" could be simulated with

packet-tracer input inside tcp

This would tell if the traffic would be allow by the ACLs, if there would be a NAT configuration for the destination IP address, if there would be a NAT configurations for the source address, among other things.

- Jouni