Skip to main content

Inside to DMZ communication

More
17 years 6 months ago #21594 by Smurf
The bit about the Inside interface is correct, basically, if there is no access-list applied then it should allow the flow of traffic from the higher security level to a lower security level. I thought that the return traffic should be allowed back in since its stateful, is this not working ?

As for the Static, it is my understanding that the static is only required to allow incoming traffic from the DMZ to the Inside, therefore if you are not initiating the traffic from the DMZ then i am not convinced that it is required (providing the Natting is configured correctly)

Cheers

Wayne Murphy
Firewall.cx Team Member
www.firewall.cx

Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
More
17 years 6 months ago #21595 by anti-hack
Hi,

i don't mean to suggest that i am right and others are wrong, what i understand is;

From the inside, there is usally a PAT or a Pool of NATted IP addresses for the hosts to go to the internet through the configured default route.

If we don't provide a translation for the host to direct the desired traffic (RDP in this particular discussion) then all the traffic would be sent with the PAT or the Pool of NAT to the default route.

This again is my opinion and if someone has a better understanding then please update me, i would be grateful.
More
17 years 6 months ago #21599 by Smurf
I disagree, the DMZ will need to either have a NAT in place from the Inside or must have NAT0 to route traffic directly into that subnet.

The static is required to allow traffic flow from a low interface to a high interface (aswell as creating a static IP to IP translation to ensure an internal host gets the same public ip address).

Remember that the DMZ subnet is usually directly attached to the firewall interface so it will always try to send the traffic there and not to its default route.

Basically, if traffic flow between the DMZ and the Internet (outside) is required then you will require a Static command in order for the traffic to flow from outside to dmz, if you do not want any machine on the DMZ to talk to the inside network, then you do not require any static commands configuring. If you want inside machines to talk to hosts in the DMZ, then NAT needs to be configured to go to that subnet unless you just want to do normal routing then NAT0 needs to be configured.

Hope it makes sense, if not let me know and i will try and explain a little better.

Wayne Murphy
Firewall.cx Team Member
www.firewall.cx

Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
More
17 years 6 months ago #21601 by anti-hack
hi again,

i have tested the senario, the use of "static" in this particular situation was not correct (though it does work), one has to use the "NAT" command to get this done and if the NAT is done right, there would be no need to use the "static".

Thanx Smurf for the clarification,

Three Cheers,
More
17 years 6 months ago #21610 by semper

static (inside, dmz) 10.3.x.x 10.3.x.x netmask 255.255.255.255 0 0


That static rule allow one particular computer on the internal network to access any device on via any TCP/UDP port on the DMZ network.

What I usually do to when configuring a DMZ on a PIX and only want an limit the internal hosts access to the DMZ is add the static (inside,dmz) command and then add access-lists on the DMZ interface to filter source, destination addresses, and port(s).

So if I only wanted host 10.3.0.1 on the inside network to access 172.16.0.3 on the DMZ via tcp 3389 then I would d something like:

static(inside,dmz) 10.3.0.1 10.3.0.1 netmask 255.255.255.255
access-list inside-inbound permit tcp host 10.3.0.1 host 172.16.0.3 eq 3389
access-group inside-inbound in interface inside

The static command allows 10.3.0.1 to access the DMZ network and the access-list only allows 10.3.0.1 to access the Remote Desktop of 172.16.0.3.

There are many ways to skin a cat though, particularly with Cisco PIX. This is just the way that I was taught to do it by the person who mentored me in Cisco PIX's (He has a CCIE Security). Now my example assumes that you are using the PIX OS 6 series code. I haven't gotten a chance to use any of the 7 series code yet.
More
17 years 6 months ago #21611 by semper

As for the Static, it is my understanding that the static is only required to allow incoming traffic from the DMZ to the Inside, therefore if you are not initiating the traffic from the DMZ then i am not convinced that it is required (providing the Natting is configured correctly)

Cheers


By default in a PIX, the firewall treats each interfaces as if they are totally separate devices. What I mean by this is if you take a PIX and do nothing but assign addresses to the inside,outside, and dmz interface and then attach computers directly to those interfaces you will not be able to communicate from the computer in the inside to the dmz or to the outside and vise-versa with the other computers.

You specifically have to give access to each network either with the nat/global command or with the static command. They both get the job done in most cases.

The only time I use the nat/global command is if I want to use PAT instead of one to one NAT. All the static command does is provide a one to one NAT between interfaces.

Hope that helps. :)

EDIT:

It's also worth noting that I use one to one NAT when ever possible because it allows me to be more fine grained and allows for better logging because it allows the server to log individual IP's rather than PAT address. It also allows me to block individual problem children if needed rather than an entire group of people.
Time to create page: 0.137 seconds