Re: firewall-wizards Digest, Vol 20, Issue 13

[Chris Myers <clmmacunix () charter net>]

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 () listserv cybertrust com
> [mailto:firewall-wizards-bounces () listserv cybertrust com] On Behalf Of
> firewall-wizards-request () listserv cybertrust com
> Sent: Thursday, December 27, 2007 9:00 AM
> To: firewall-wizards () listserv cybertrust com
> Subject: firewall-wizards Digest, Vol 20, Issue 13
>
> Send firewall-wizards mailing list submissions to
>         firewall-wizards () listserv icsalabs com
>
> 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 () listserv icsalabs com
>
> You can reach the person managing the list at
>         firewall-wizards-owner () listserv icsalabs com
>
> 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 () gmail com>
> Subject: Re: [fw-wiz] PIX access-list help
> To: "Firewall Wizards Security Mailing List"
>         <firewall-wizards () listserv icsalabs com>
> Message-ID:
>         <7743536a0712261007ic01f92fm562685817ecd9e0a () mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Dec 25, 2007 12:25 AM, Paul Melson <pmelson () gmail com> wrote:
> > On Dec 21, 2007 11:02 AM, Brian Blater <brb.lists () gmail com> 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 () linxnet com (Jim Seymour)
> Subject: Re: [fw-wiz] Anyone have any informed opinions on the
>         Watchguard      product line?
> To: firewall-wizards () listserv icsalabs com
> Message-ID: <20071226162314.E4BC9E158 () jimsun linxnet com>
>
>
> "Richard Golodner" <rgolodner () infratection com> 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 () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
>
> End of firewall-wizards Digest, Vol 20, Issue 13
> ************************************************
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards