access-list problem

[rchavesm]

Hello , I have a problem with PIX Firewall Version 6.0(1), the problem is:

I have a pix with 3 interface inside,outside and dmz,

ip address outside x.x.x.2 255.255.255.248

ip address inside 200.115.10.10 255.255.255.0

ip address dmz 192.168.6.28 255.255.255.0

I need to make an acl where only 3 PC's in the inside access the server installed in the dmz,with an ip public, but the acl doesn't work.

Following is the acl, but I have change the IP addresses.

access-list 108 permit ip 200.115.10.0 255.255.255.0 172.16.1.0 255.255.255.0

access-list 108 permit ip 200.115.10.0 255.255.255.0 200.105.10.0 255.255.255.0

access-list 108 permit ip 200.115.10.0 255.255.255.0 200.105.20.0 255.255.255.0

access-list 108 permit ip 200.115.10.0 255.255.255.0 200.105.30.0 255.255.255.0

access-list 88 permit ip 200.115.10.0 255.255.255.0 200.105.10.0 255.255.255.0

access-list 88 permit ip 200.115.10.0 255.255.255.0 200.105.20.0 255.255.255.0

access-list 88 permit ip 200.115.10.0 255.255.255.0 200.105.30.0 255.255.255.0

pager lines 24

logging on

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

mtu outside 1500

mtu inside 1500

mtu dmz 1500

ip address outside x.x.x.2 255.255.255.248

ip address inside 200.115.10.10 255.255.255.0

ip address dmz 192.168.6.28 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

ip local pool test 172.16.1.1-172.16.1.254

no failover

failover timeout 0:00:00

failover poll 15

failover ip address outside 0.0.0.0

failover ip address inside 0.0.0.0

failover ip address dmz 0.0.0.0

pdm history enable

arp timeout 14400

global (outside) 1 interface

global (dmz) 1 192.168.6.10

nat (inside) 0 access-list 108

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

nat (dmz) 1 0.0.0.0 0.0.0.0 0 0

alias (inside) x.x.x.5 192.168.6.30 255.255.255.255

static (inside,outside) x.x.x.6 10.10.70.1 netmask 255.255.255.255 0 0

static (inside,outside) x.x.x.4 200.115.10.16 netmask 255.255.255.255 0 0

static (dmz,outside) x.x.x.5 192.168.6.30 netmask 255.255.255.255 0 0

conduit permit tcp host x.x.x.6 eq lotusnotes any

conduit permit tcp host 2x.x.x.4 eq www any

conduit permit tcp host x.x.x.4 eq lotusnotes any

conduit permit tcp host x.x.x.5 eq www any

conduit permit tcp host x.x.x.5 eq domain any

conduit permit icmp any any

conduit permit tcp host x.x.x.5 eq https any

conduit permit tcp host 2x.x.x.5 eq 21010 any

the public IP that I need to access from the inside is x.x.x.5

[l.mourits]

Hi,

First thing I noticed in your config is that you are using conduits and ACL's at the same time. This is not recommended! So, thirst thing I would do is get rid of the conduits and convert this to an ACL.

Second thing is that I see that you're having two ACL's (108 and 88) and they are not bound to an interface (with the access-group command), so, if this is your whole config then the ACL's are never used.

Question: What is the use of ACL 88 (sounds to me like a anti-spoofing ACL, but there are easier ways to prevent IP-spoofing on the PIX with using IP verify reverse path)

Remember, Cisco recommends to use only ACL's (or conduits only, but conduits are not the recommended way anymore).

Then you have to remember that you when you build an ACL, the PIX does only support inbound ACL's, and the ACL is bound to an interface using the command access-group.

(example: access-group 108 in interface dmz)

You do not have to concern about return traffic, cause the ASA algorithm within the PIX will take care of this (that is, if all the right translations are in place).

Finally, do not test with ICMP (ping), because ICMP is not handled by the ASA, so the returning echo replies does not pass the PIX (unless you create a rule in your ACL which does permit ICMP echo replies)

Better to use TCP/UDP for testing, cause these are statefully inspected and are handled by the ASA.

Hope this helps.

Kind Regards,

Leo

[rchavesm]

Thanks you, for your answer

I'm goint to take the conduit off and I will use the following ACL, do you think this will work or I have to make some changes.

Can you help me?.

access-list 110 permit tcp host 200.115.10.40 host x.x.x.5 eq www

access-list 110 permit tcp host 200.115.10.41 host x.x.x.5 eq www

access-list 110 permit tcp host 200.115.10.42 host x.x.x.5 eq www

access-list 110 deny tcp host 200.115.10.0 host x.x.x.5

access-list 110 permit ip any any

access-group 110 in interface inside

[l.mourits · Accepted solution]

Hi,

The ACL you're providing will still do the same thing when you shorten it to this:

access-list 110 deny tcp host 200.115.10.0 host x.x.x.5

access-group 110 in interface inside

(this one would not work though, because host 200.115.10.0 *watch the zero* probably does not exist)

Assuming that your dmz has a lower securitylevel then your inside interface, you have to remember that if packets are travelling from higher to lower level security the PIX does the following:

1) if it is an existing flow, let the packet through

2) if it is not an existing flow, check ACL

3) if ACL denies, then drop the packet, if ACL permits, let packet through

4) if ACL does not match at all, let the packet through (since it is from high to low level security)

But I'll guess this is not what you want to achieve.

I think you need something like this:

access-list 110 permit tcp host 200.115.10.40 host x.x.x.5 eq www

access-list 110 permit tcp host 200.115.10.41 host x.x.x.5 eq www

access-list 110 permit tcp host 200.115.10.42 host x.x.x.5 eq www

access-list 110 deny ip 200.115.10.0 255.255.255.0 x.x.x.0 255.255.255.0

(assuming you have a 24-bit subnet on your dmz)

access-list 110 permit ip any any

access-group 110 in interface inside

This will let the three inside hosts access the server x.x.x.5 on you dmz with HTTP, let no one else from the subnet 200.115.10.0/24 to the dmz, and permit all other outside traffic.

Hope this helps.

Kind Regards,

Leo

[rchavesm]

thanks all