access-list question regarding pix security levels

[triplecap]

I've been in the process of migrating from conduits to ACLs on my pix 525. Correct me if I'm wrong, but from what I've read, you can only apply 1 access list per interface. These ACLs apply to all traffic (regardless of security level) originating from the dmz,inside,outside or whatever segment, into that interface on the pix. Any traffic not defined (permitted) by the ACL will be dropped.

I have a dmz with a coulple of web and smtp servers addressed in the 192.168.x.x segment. On the inside interface I have our corporate network on the 172.16.x.x network. I have some ACLs that permit dmz boxes to authenticate to domain controllers on the inside network, which I have tied down to protocol, port & ip. However, my web servers need to go out to the net to download updates, and my smtp servers need to send email to lots of places. If I have an access list that says:

access-list dmz_out permit ip host <ipaddr of web1> any

Does that necessarily mean that web1 now has full access into my corp. network on the inside interface of the firewall?? I know I could put a deny ACL right before the above entry, that just seems kind of clunky. With conduits, security levels seemed to have more of a definitive role; now if I have ACLs on each interface it seems that the concept of different security levels is lost.

Any help or clarification would be greatly appreciated.

Thanks,

Eric

[Patrick Iseli]

Yes, you are right your access-list "access-list dmz_out permit ip host any" would give that host the right to access the inside hosts too.

But what about NAT ? If you have not configured a NONAT or a NAT statement between the inside and the DMZ network there is a problem in translation and the communication to the inside network will not occour.

As you mentioned you can add a deny to the inside network in access-list line before to remove access from the dmz to the inside.

Security Level and Access-lists:

To grant access from lower to higher level you need an access-list and a static or NONAT.

Equal to equal levels can not talk to each others.

Higher Security Level can talk to lower levels if there is no access-list on that interface and the NAT is configured correctly.

The only exception is the established traffic that may comes from the other interface access-lists to the dmz, replies etc. For example you permit port 80 from the outside to a dmz host this traffic will not be checked again by the dmz access-list.

sincerely

Patrick

[triplecap]

Thanks for the reply. It answered my question but raised another question in doing so.

My nat setup is as follows:

nat (DMZ) 1 0.0.0.0 0.0.0.0 0 0

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

where 1 is my global that all address nat out when going out to the net

Where can I find out more about how ACLs play with NAT or NONAT? I can't seem to find any decent documentation on this. The ACL is applied before the NAT takes place, correct?

Thanks again,

Eric

[aaron.g.smith]

Yes, without the deny statement your dmz server does have complete access to your inside network. I ran into the exact same situation at my last company when migrating from conduits. I solved the problem using the "clunky" method described above, but have always wondered if there was a better solution.

I agree with you that the concept of security levels seems to have diminished value when making the switch to access-lists. Perhaps somebody else knows of a better solution.

Aaron

[Patrick Iseli]

There are plenty of documents but more case to case specific.

See:

Establishing Connectivity Through Cisco PIX Firewalls

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008009402f.shtml

Using nat, global, static, conduit, and access-list Commands and Port Redirection on PIX

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml

Configuring the PIX for NAT

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v52/config/examples.htm

All Configuration documents:

http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?p=Hardware:PIX&s=Software_Configuration

Command reference:

http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_technical_documentation.html

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801727a3.html#wp1067755

For the NONAT access-list check the VPN Site 2 Site examples

http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?p=Hardware:PIX&s=Software_Configuration

sincerely

Patrick

[hoangbp]

Hi all:

I have a couple of comments regarding the above scenario:

1. Assuming you have a so-called "wide open" access-list applied to your DMZ interface (access-list DMZ_in permit ip host DMZ_www_server any),you also need to have a static statement for any inside server (let's say a DB server or a DNS server, whatever that is. i.e: static (inside, dmz) db_dmz_ip db_inside_ip netmask 255.255.255.255 # #

So in that case, you do not have a wide open access to all the inside network, only the servers that have static NAT. Agree?

And in my opinion, it is a bad security practice to apply an ACL that permits IP host Whatever to any on the DMZ interface while you only need to permit outbound traffic (from DMZ->outside) for certain protocols anyway (in your case it's HTTP or FTP or whatever),don't you think? Your ACl needs to be more granularily controlled here.

Same restricted filtering needs to be applied to traffic from DMZ to inside servers as well. What I mean is instead of allowing any any, you want to allow only the protocols that the DMZ servers need to communicate w/ the inside servers.

There are a lot more considerations that need to be taken into consideration when it comes to designing your security/trusted boundaries, and it's outside of this discussion. My comments are based on the context of ACL and how it should best be used to filter traffic from HIGH->LOW and LOW->HIGH security interfaces when applied to a single interface of a PIX.

2. For outbound traffic from DMZ-> outside, you would want to use policy NAT (NAT/GLOBAL w/ access-list), as well as ACLs applied to DMZ interface to control that type of traffic permitted or denied.

In my opinion, ACL works perfectly. There is no flaw whatsoever with ACL as compared to conduit, in fact it gives you more control on what traffic/direction you want to filter.

If anyone has different thoughts on this, I'm all ears.

Thanks,

Binh

[Patrick Iseli]

hoangbp,

You are absolutly right. There are multiple factors for really having that worst case scenario.

I agree absolutly with you that this kind of access-list is not a good security practice. But we could talk hours about that topic.

AS you mentioned and I mentioned before, there must also be a correct NAT or NONAT statement that access from DMZ to inside can happen.

sincerely

Patrick

[hoangbp]

Hi Patrick:

I'm glad that we're in sync on this issue :)

Thanks,

Binh

[aaron.g.smith]

Binh,

You make valid points. In my paritcular situation there was no NATing between the inside and dmz, so your comment regarding internal hosts being protected by the lack of static statements doesn't apply. Also I wouldn't feel comfortable relying on static statments (or lack there of) as a means of protection. Now let's get a scenario going so we're all on the same page. Let's say we have this config.

static (inside,dmz) 10.0.0.0 255.255.0.0 10.0.0.0 255.255.0.0 (I think this prevents nat between inside and dmz)

nat (inside) 1 10.0.0.0 255.255.0.0

nat (dmz) 1 192.168.100.0 255.255.255.0

global (outside) 1 x.x.x.x

With this config alone internal clients can access the dmz (without natting) and dmz servers can access the internet (assuming the security levels are set correctly). Now let's say that I decide at some later point that my web server on the dmz (192.168.100.10) needs access to a sql server on the inside (10.0.0.10) network. I create an access-list.

access-list 101 permit tcp host 192.168.100.10 host 10.0.0.10 eq 1433

access-group 101 in interface dmz

As soon as I apply this access list, my dmz servers are no longer able to access the internet. Now let's assume I just want http access to outside, so I'll add another statement.

access-list 101 permit tcp host 192.168.100.10 any eq 80

At this point my web server in the dmz should have http access to the outside world. Now let's assume that internal db server mentioned above also hosts an intranet site. Wouldn't the access-list entry I added to permit access to the outside also enable my dmz server to access any internal web servers as well?

Isn't my only solution to add a deny to inside statement above the statement/s allowing access to outside? I suppose I could only allow access to specific outside hosts, but that seems a bit excessive.

Aaron