Re: [fw-wiz] firewall-wizards Digest, Vol 20, Issue 13

Hello,

May I ask why you are going to the inside for the internet access for your dmz? Do you have a proxy server or something that the dmz needs on the inside to get to the internet? If not, you will need a nat policy for the dmz because it will have to nat outbound to traverse the internet. By the standard configuration your security level for the dmz is higher than the outside interface. If it is not then just raise the security level above the outside interface (default 0), but below the inside (default 100), say 90 maybe. There is an implicit deny from the outside, but due to the nat you have access to all lower security levels. As mentioned before you should not want complete access outbound on all ports, but I am just creating a mental picture for your traffic to simplify this.

Hang tight, because the above configuration becomes more complicated if you want access to the inside from the dmz.

You do not need any ACL's on the inside interface to reach the dmz because the security level is higher on the inside than on the dmz.

Remember ACL's applied to interfaces are for initiated traffic from IP's behind the interface it has been applied to. You only need an ACL on an interface if the traffic is originating with a SYN packet from an IP behind that interface. The state of a packet is maintained in the state table for all initiated traffic, and all acknowledgements are completed. If you need hosts on the dmz to initiate connectivity to the inside, then be stingy with what gets access and lock it down to hosts and specific services. Once you have determined that you need an ACL that has gone beyond the security level requirements, then you now need ACL's for all traffic regardless of security levels. If you determine that you need RDP port 3389 from the dmz to the inside, then once you apply an ACL for it then you will need an ACL to all other interfaces due to the implicit deny now on the interface for explicit traffic. Remember you don't have to give access in the static statements for whole subnets. You can lock them down to hosts, but deny statements will work with the interface ACL's, although unnecessary if you have good security planning.

example: nat (inside) 0 access-list nonat
access-list nonat permit tcp host 192.168.2.1 192.168.1.1 eq 3389

nat (dmz) 1 192.168.2.0 255.255.255.0 0 0 (this causes a global many to one and nat as the outside address of the firewall)
access-list dmz permit tcp host 192.168.2.1 192.168.1.1 eq 3389
access-list dmz permit tcp 192.168.2.0 255.255.255.0 any eq 80

static (inside,dmz) 192.168.1.1 192.168.1.1 255.255.255.0 0 0 ( you are only announcing the host for rdp to the dmz)







On Dec 27, 2007, at 11:39 AM, Boni Bruno wrote:

The 3rd line in your dmz access-list will not deny traffic from the
inside when communication is initiated from the inside.

By default, a higher security zone can access a lower security zone and
the state information maintained by the Pix firewall will allow for the
return traffic to go back to the inside network.

That being said, many companies deny traffic out from the inside network
as a best practice. If you are denying traffic from the inside out
(which you should be doing), then you need to make sure you permit the
traffic you need from the inside to the dmz before any of your deny
statements in your acl.

-boni bruno

.
.
.
Ok, I think I understand this a little better now. Say my private
network is 192.168.1.0/24 and my dmz is 192.168.2.0/24. I already have
the static (inside,dmz) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
which is required in 6.3(3). So, in order to make this work i.e the
inside network has access to everything on the dmz network and the dmz
network can access the internet and I only allow specific communication
from the dmz to the inside I need to do the following:

access-list dmz permit udp host 192.168.2.2 host 192.168.1.202 eq domain
access-list dmz permit tcp host 192.168.2.2 host 192.168.1.203 eq smtp
access-list dmz deny ip 192.168.2.0 255.255.255.0 192.168.1.0
255.255.255.0 access-list dmz permit ip 192.168.2.0 255.255.255.0 any

I will also need to add the nonat statements as was suggested by
Brandon:

access-list nonat permit ip 192.168.1.0 255.255.255.0 192.168.2.0
255.255.255.0 access-list nonat permit ip 192.168.2.0 255.255.255.0
192.168.1.0 255.255.255.0 nat 0 (inside) access-list nonat nat 0 (dmz)
access-list nonat

My only concern here is the 3rd line in the dmz access-list and whether
it will deny communication from the inside network to the dmz (except
dns and smtp), but I will test that when I get home tonight.

Thank you for everyone's help.

Brian


-----Original Message-----
From: firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxxxx
[mailto:firewall-wizards-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of
firewall-wizards-request@xxxxxxxxxxxxxxxxxxxxxxx
Sent: Thursday, December 27, 2007 9:00 AM
To: firewall-wizards@xxxxxxxxxxxxxxxxxxxxxxx
Subject: firewall-wizards Digest, Vol 20, Issue 13

Send firewall-wizards mailing list submissions to
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@xxxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
firewall-wizards-owner@xxxxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific than
"Re: Contents of firewall-wizards digest..."


Today's Topics:

1. Re: PIX access-list help (Brian Blater)
2. Re: Anyone have any informed opinions on the Watchguard
product line? (Jim Seymour)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Dec 2007 13:07:37 -0500
From: "Brian Blater" <brb.lists@xxxxxxxxx>
Subject: Re: [fw-wiz] PIX access-list help
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@xxxxxxxxxxxxxxxxxxxxx>
Message-ID:
<7743536a0712261007ic01f92fm562685817ecd9e0a@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On Dec 25, 2007 12:25 AM, Paul Melson <pmelson@xxxxxxxxx> wrote:
On Dec 21, 2007 11:02 AM, Brian Blater <brb.lists@xxxxxxxxx> wrote:
So, my main question, is there an access list command I can have
that basically says "allow all communication from the dmz to the
internet"
and one that says "allow communication from the inside to the dmz"?
I know I can add "access-list dmz permit ip host 192.168.1.1 any"
and that solves the problem of getting to the internet, but then it
opens all communication to the inside from this host and I don't
want to do that. Since this is version 6.3(3) I can't use an out
access-list which I think might solve the problem. I have enough
memory to run version 7.x on this PIX, but I'm trying to tackle one
problem at a time and I'm a little hesitant about doing the 7.x
upgrade just yet.

The short answer to your question is that PIX access-lists are read,
per-interface, top-to-bottom:

access-list dmz_in deny ip 192.168.1.0 255.255.255.0 10.0.0.0
255.0.0.0 access-list dmz_in permit ip 192.168.1.0 255.255.255.0 any
access-group dmz_in in interface dmz

If your internal network is 10.0.0.0/8 and your DMZ is 192.168.1.0/24,

this will prevent traffic from the DMZ to the inside, but allow
everything else.

PaulM

Ok, I think I understand this a little better now. Say my private
network is 192.168.1.0/24 and my dmz is 192.168.2.0/24. I already have
the static (inside,dmz) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
which is required in 6.3(3). So, in order to make this work i.e the
inside network has access to everything on the dmz network and the dmz
network can access the internet and I only allow specific communication
from the dmz to the inside I need to do the following:

access-list dmz permit udp host 192.168.2.2 host 192.168.1.202 eq domain
access-list dmz permit tcp host 192.168.2.2 host 192.168.1.203 eq smtp
access-list dmz deny ip 192.168.2.0 255.255.255.0 192.168.1.0
255.255.255.0 access-list dmz permit ip 192.168.2.0 255.255.255.0 any

I will also need to add the nonat statements as was suggested by
Brandon:

access-list nonat permit ip 192.168.1.0 255.255.255.0 192.168.2.0
255.255.255.0 access-list nonat permit ip 192.168.2.0 255.255.255.0
192.168.1.0 255.255.255.0 nat 0 (inside) access-list nonat nat 0 (dmz)
access-list nonat

My only concern here is the 3rd line in the dmz access-list and whether
it will deny communication from the inside network to the dmz (except
dns and smtp), but I will test that when I get home tonight.

Thank you for everyone's help.

Brian


------------------------------

Message: 2
Date: Wed, 26 Dec 2007 11:23:14 -0500 (EST)
From: jseymour@xxxxxxxxxxx (Jim Seymour)
Subject: Re: [fw-wiz] Anyone have any informed opinions on the
Watchguard product line?
To: firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <20071226162314.E4BC9E158@xxxxxxxxxxxxxxxxxx>


"Richard Golodner" <rgolodner@xxxxxxxxxxxxxxxx> wrote:

[snip]
There was also a nice GUI interface ...
[snip]

Is that still limited to running on a Windows PC?

I believe their management GUI once ran on both Windows and Linux.
Then, later, on Windows only, I was told. I tend to shun network
infrastructure products that require Windows to configure and administer
them.

Jim
--
Note: My mail server employs *very* aggressive anti-spam filtering. If
you reply to this email and your email is rejected, please accept my
apologies and let me know via my web form at
<http://jimsun.linxnet.com/contact/scform.php>.


------------------------------

_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards


End of firewall-wizards Digest, Vol 20, Issue 13
************************************************
_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

Relevant Pages

  • Host placement and DMZ internal/external questions.
    ... I have a few questions I have about dmz internal and external networks ... internal network does that sit on your DMZ? ... modify firewall rules so that the host has the access they need to ...
    (Security-Basics)
  • RE: Re: Re: VM Host with guests on the Internal and DMZ networks
    ... So are you saying that you should put your HOST in the DMZ. ... NIC and then add and IP Address that would work on the inside network while ... I would question the sysadmins level of competency. ...
    (Security-Basics)
  • Re: DMZ Arguments....
    ... A DMZ is used with a firewall, ... link to the rest of the network. ... A common approach for an attacker is to break into a host that's vulnerable ... the case of a web server, unauthenticated and untrusted users might be ...
    (Security-Basics)
  • Re: Host placement and DMZ internal/external questions.
    ... > internal network does that sit on your DMZ? ... 25/tcp requests outbound, ... > modify firewall rules so that the host has the access they need to ...
    (Security-Basics)
  • [NEWS] SMC Barricades Dodgy "DMZ" Feature
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... hosts in a DMZ should not be ... able to initiate connections to internal LAN hosts. ... DMZ host be compromised (from having its connected-to-from-the-internet ...
    (Securiteam)