topic Re: access-list questions inside to DMZ interfaces in Network Security

access-list questions inside to DMZ interfaces

wilson_1234_2 — Mon, 11 Mar 2019 10:16:22 GMT

I have some questions regarding an access-list applied tinbound to a DMZ interface.

1. If the firewall is stateful, and the NAT statements are set up correctly, then anyone from an inside interface should be able to access anything on the DMZ interface, with no access-applied correct?

2. the access-list that only permits certain hosts on the inside interface to access the DMZ, is put in place to prevent just anyone on the "inside" interface from accessing the DMZ correct?

3. The below access-list, if it were applied inbound to the DMZ interface goes which way?

How can you tell which direction the traffic flows by looking at the access-list?

The DMZ interface address is 192.168.100.1

Inside interface is 1

0.1.10.1

The access is :

access-list dmz permit tcp host 192.168.100.5 host 10.1.10.15 eq 2100

Re: access-list questions inside to DMZ interfaces

vitripat — Thu, 17 May 2007 22:30:25 GMT

Hi Wilson,

Here are answers to your questions-

1. Correct.

2. Correct.

3. access-list dmz permit tcp host 192.168.100.5 host 10.1.10.15 eq 2100

If this access-list is applied using following command-

access-group dmz in interface dmz

Then it would imply that host 192.168.100.5 is allowed to initiate connection to host 10.1.10.15 on port 2100. However, as 10.1.10.15 is on a higher security-level interface (inside), to permit the connection through, we would also need following static command in place-

static (inside,dmz) 10.1.10.15 10.1.10.15

Also, if the "dmz" ACL contains only one line, all the traffic except what is defined in the list will be denied due to implicit deny at the end.

Hope this helps.

Regards,

Vibhor.

Re: access-list questions inside to DMZ interfaces

wilson_1234_2 — Thu, 17 May 2007 23:53:16 GMT

Thank you for the reply,

Does this mean the the traffic is allowed both ways? In the first example:

access-list dmz permit tcp host 192.168.100.5 host 10.1.10.15 eq 2100

The traffic can flow from 192.168.100.5, any port TO 10.1.10.15 on port 2100,

and 10.1.10.15 port 2100 can send traffic TO 192.168.100.5 on any port?

Also

Say for example the traffic was in the other direction, that the host on the DMZ was sending information to the inside interface and the source was port 2100, would it look like this:

access-list dmz permit tcp host 192.168.100.5 eq 2100 host 10.1.10.15

Re: access-list questions inside to DMZ interfaces

vitripat — Fri, 18 May 2007 12:34:46 GMT

access-list dmz permit tcp host 192.168.100.5 host 10.1.10.15 eq 2100

This ACL as applied on the DMZ interface as inbound, only controls the traffic initiated from the DMZ and not the traffic initiated from the inside. Once this traffic is initiated, the return traffic from inside to DMZ will automatically flow, PIX being a stateful firewall.

To control what traffic can be initiated from inside interface to other networks, you need ACL applied on the inside interface.

Hence, this ACL-

access-list dmz permit tcp host 192.168.100.5 host 10.1.10.15 eq 2100

does not control what ports can 10.1.10.15 can initiate connection to 192.168.100.5, this can be controlled by ACL applied on inside interface of PIX.

--quoting--

Say for example the traffic was in the other direction, that the host on the DMZ was sending information to the inside interface and the source was port 2100, would it look like this:

access-list dmz permit tcp host 192.168.100.5 eq 2100 host 10.1.10.15

-----------

Absolutely correct .. 🙂

Hope this helps.

Regards,

Vibhor.

Re: access-list questions inside to DMZ interfaces

tbogie_gvds — Thu, 31 May 2007 04:48:29 GMT

Great dialogue! To fill in the gaps, is it fair to assume the following:

1. To allow the inside host to travese from inside to dmz that there was the following statement nat statement?

nat (inside) 0 10.1.10.5 255.255.255.255

2. Would there also need to be a similar statement for the dmz host like this:

nat (dmz) 0 192.168.100.5 255.255.255.255

Thanks,

Timothy Bogie