Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Silver

How ACL's in PIX are processed (best fit?)

There seem to be a lot of misunderstanding in how the PIX firewall processes the ACL's. I always thought I did understand it, because I always been told that the PIX did process the whole ACL and selects the best fit. But, since today I do not understand. Why? Well, I have the following problem.

I have bound an inside_in access-list to the inside interface (why? because I don't follow the defaulkt policy that all outside traffic is considers save, thinking of trojans et cetera. This said here the discription to my problem.

Our customers will have only access to the web via a proxy-server, with some exeptions made for some engineers. The access-list bound to the inside interface looked like this:

access-list inside_in permit tcp host <ip-address_engineer1> any eq http

access-list inside_in permit tcp host <ip-address_engineer2> any eq http

access-list inside_in permit tcp host <ip-address_proxyserver> any eq http

access-list inside_in deny tcp any any eq http

access-list inside_in permit ip any any

This access-list worked fine, but the I tried to build it up a bit, by providing some users ftp access and denying all other traffic. So, I extended the list to the following:

access-list inside_in permit tcp host <ip-address_engineer1> any eq http

access-list inside_in permit tcp host <ip-address_engineer2> any eq http

access-list inside_in permit tcp host <ip-address_proxyserver> any eq http

access-list inside_in deny tcp any any eq http

access-list inside_in permit tcp host <ip-address_engineer1> any eq ftp

access-list inside_in permit tcp host <ip-address_engineer1> any eq ftp-data

access-list inside_in permit tcp host <ip-address_engineer2> any eq ftp

access-list inside_in permit tcp host <ip-address_engineer2> any eq ftp-data

access-list inside_in deny ip any any

I expected that this kind of ACL would give ftp and http access to the outside, and by putting in the deny ip any any it would deny all other traffic, but much to my surprise, it did not. In fact it did just deny all ip traffic, even http :-(

Now I'm wondering if there's anyone who can explain how this example list would be processed in the PIX. I think the PIX does the following while it processes the access-list:

- first look into all ip based statements

- if there is just one ip statement which defines the packet, and it is a deny, drop it

- if there is just one ip statement which defines the packet, and it is a permit, proces further on

- if there are several ip statements for the packet, select the best fit (whereby permit's are best, because it is from inside to outside and this traffic is normally implicit permitted)

- if there are no statements for this packet, permit the packet (implicit permit)

I just want to know if I'm thinkin right and if there's any good document on Cisco which describes the whole process of best fit for PIX ACL's. I haven't been able to find it in the last four weeks (and since I'm just one of those nerds who wants to know it all, I posted this thread).

Thanx in advance and best regards,

Leo Mourits

Senior network specialist, PinkRoccade (Netherlands)

15 REPLIES
Gold

Re: How ACL's in PIX are processed (best fit?)

Hi Leo,

I notice from you posted config that you have ACL inside deny ip any any on the modified ACL, also it is critical that ACL's are written/configured in the correct order (as a tutor told me once - when you write ACL's you are playing with fire), anyway if you are modifying your ACL's and accessing www via proxy then try the following :

Using ACL (Named in this case) you would do the following:

>access-list inside permit tcp host XXXX any eq www

>access-list inside deny tcp any any eq www

>access-list inside permit ip any any

..now configure the ACL to the inside interface with a access-group statement i.e.

>access-group inside in interface inside

(NOTE. ON THE FIRST ACL ABOVE XXXX IS YOUR ISA IP ADDRESS)

Also, after you have configured the ACL's make sure you do a wr m (write to memory)

Hope this helps -

New Member

Re: How ACL's in PIX are processed (best fit?)

Hi Leo

As the previous poster implies, changing access-lists on the fly can often have unpredictable results. The best way is to either

a) Completely remove your access-list (ie no access-list inside_in) and then re-enter the list with your amendments in the correct place, then reapply it to the interface, or

b) Create a new access-list, the same as your previous one, but this one has your amendments included. Apply this new access-list to your interface using the access-group command (this will overwrite the previous access-group statement pointing to your original acl). The benefit of this is if your new acl is not performing how you believe it should, you can always revert back to your old one by re-entering the access-group command that pointed to it previously (this is also a good way to handle temporary changes to access-lists). However if it all works as required, simply delete your old access list and run with the new one.

Access-lists are processed from the top down, and as soon as a match is made, the packet being inspected will be permitted or denied as required, rather than the pix comparing the packet against the whole access list and then trying to work out which action is a best fit for the packet.

Hope that helps

Kev

New Member

Re: How ACL's in PIX are processed (best fit?)

this should help out as well, but they above did a good job too.

http://www.cisco.com/cgi-bin/Support/browse/psp_view.pl?p=Internetworking:ACCESS-LIST_ARP_BOOT_DHCP

another good one...

http://www.cisco.com/warp/customer/105/acl_wp.html

hope this helps some...

Silver

Re: How ACL's in PIX are processed (best fit?)

Well, I don´t think that deleting and building up again is the access-list is really needed on the PIX , but as you say, the PIX is indeed matched every packet to the whole access-list en decides on a best fit which rule is implied.

Yes, I believe so to, but what I want to know, is which has a higher priority in best fit options? IP or TCP? UDP? permit or deny? matched against tavelling from high-level.security to low-level-security and the other way around.

Can´t find anything about this :-(

Silver

Re: How ACL's in PIX are processed (best fit?)

this would allow users to ftp directly to the Internet, or use java-apples to chat

:-\

not what I meant....

I want to control what users can do on the Internet, which protocols directly can connect, and which protocols must be proxied, not just all, nut http :-(

I haven´t figured it out yet....:-S

Re: How ACL's in PIX are processed (best fit?)

Hi Leo,

to give you a short and simple reply:

If there are no ACLs, traffic is only allowed from a higher (eg inside) to a lower (eg outside) securtiy level.

ACLs are allways processed from top to bottom (NO best fit!). If, for a certain packet, a match is found in the ACL, then the rest of the ACL is skipped.

If you create an ACL, the PIX always places an implicit deny for all traffic at the end of the ACL (this line is not vissible). So if there is no match for a packet in the applied ACL, then the packet is dropped.

Hope this helps?

Regards,

Tom

Silver

Re: How ACL's in PIX are processed (best fit?)

Hi Tom, you are incorrect on this one, this is the case for Cisco IOS based ACL´s, but not for PIX access-lists. The PIX compares the packet to all rules and makes the decision, based on best fit, which rule closest matches the packet is implied.

Best regards,

Leo

Silver

Re: How ACL's in PIX are processed (best fit?)

Hi all,

This is not what is happening or bothering me. I know that the order could be a factor in PIX access-list, but my statement about best fit is also true. Cisco states that ACL´s on PIX do not stop processing at the first matched rule, but are in fact processed all and that the best fit rule is implied to determine the action to take (I will try to find the link again on CCO and post it here in a reply).

So, although I´m sure that your replies are intended to help me out here, I´m sorry to say so they are not helping me.

What I want to do is not implicitly permit IP from inside to outside, in fact I want to deny all IP traffic, except from http and ftp for some client IP adresses.

I just saw that I made a little error in my previous posting, the ACL that I tried to use for this purpose is the following:

access-list inside_in permit tcp host any eq http

access-list inside_in permit tcp host any eq http

access-list inside_in permit tcp host any eq http

access-list inside_in permit tcp host any eq ftp

access-list inside_in permit tcp host any eq ftp-data

access-list inside_in permit tcp host any eq ftp

access-list inside_in permit tcp host any eq ftp-data

access-list inside_in deny ip any any

(in the precious post was a deny TCP any any on the 4the rule, which indeed should prevent all TCP traffic, so, also all FTP traffic)

If you all be right, then I should be able to http and ftp from this particular permitted systems (yes, I allready have the ACL deleted completely and put in in again, but it does not work), in fact: if I use this ACL, then all IP traffic is denied (including http and ftp from the specified clients and proxyserver), although there are rules which are permitting some TCP traffic from some clients.

So, what seems to happen is that every rule is processed, including the last rule, and that only the last rule is used to determine what to do with the packet, although there are rules which are permitting the traffic. I know that there is an implicit permit for traffic passing through the PIX from a high level to a low level interface, and that all rules are processed, but why just taken the deny ip any any to determine to drop the packet?

That´s what´s bothering me.......

I really hope anyone can help me out. I can almost dream the PIX, so, please, don´t provide the standard "how to build an ACL" URL´s (how well intended they might be), I know how to build an ACL, trust me, and I know how to configure a PIX (have implemented over 20 of them), but this particular config really gives me a headache.....

Silver

Re: How ACL's in PIX are processed (best fit?)

How are you testing this? - your ACLs do not permit dns traffic, so if the DNS server is on the outside, you cannot test with FQDNs Do you have logs that correlate with your behaviour?

Please post your entire config. You don't show us the access-group command.

Silver

Re: How ACL's in PIX are processed (best fit?)

please see my reply one by b-pelphrey - Apr 29, 2003, 1:07pm PST

New Member

Re: How ACL's in PIX are processed (best fit?)

what do the syslogs say? do some debugging to see what you get. otherwise, it would be much appreciated if you could post your config. there maybe something else silly that you have overlooked.....everybody does it from time to time...even those that can dream the PIX.....

Silver

Re: How ACL's in PIX are processed (best fit?)

Let me provide you all with more information on the problem, cause I really hope someone can help out:

First of all, what I want to achieve with an access-list bound to the inside interface is to prevent all users from accessing Internet directly, but to make sure they can only access Intenet via a proxy cache server (IP address 10.32.64.1 in the configs provided later on). The reason to not let users access Internet directly is obvious, in this time of trojans, messenger services, et cetera. This said I will provide you all with more detail to the different scenarios and testing I allready did.

The following adresses are important to know:

proxyserver = 10.32.64.1

dns server = 10.32.64.2 (split dns to the outside)

my station = 10.32.128.1

Let´s first consider the following part of the configuration of this PIX:

access-list inside_in permit tcp host 10.32.64.1 any eq www

access-list inside_in permit tcp host 10.32.128.1 any eq www

access-list inside_in deny tcp any any eq www

access-group inside_in in interface inside

(All other other config that is needed, like routing, nat, globals, et cetera, is off course also taken care off, but not provided here for making this threat not more complex then it is. )

I´ve tested this config and this config works as intended, all clients within the internal network can not directly browse to the Internet, but they can via the proxyserver. But because there is an implicit permit for packets traveling from inside to outside (Note that all traffic is implicit permitted by default for packets traveling from a high level security level to a low level security level interface, as in inside to outside) this ACL did not prevent users from connecting to Internet via FTP (nor any other protocol then HTTP) as I found out while testing. So, I build the following config:

access-list inside_in permit tcp host 10.32.64.1 any eq www

access-list inside_in permit tcp host 10.32.128.1 any eq www

access-list inside_in permit tcp any any eq ftp

access-list inside_in permit tcp any any eq ftp-data

access-list inside_in deny ip any any

access-group inside_in in interface inside

I was expecting this new ACL to make sure that users could still use HTTP via the proxy, could use FTP directly to Internet and nothing else. So, again tested, but something strange occured, I couldn´t use FTP to connect to the Internet . At first I thought this was a DNS resolving problem, and yep, since all IP was denied, nameresolving did not work, so, I exended the ACL to this one:

access-list inside_in permit ip host 10.32.64.2 any

access-list inside_in permit tcp host 10.32.64.1 any eq www

access-list inside_in permit tcp host 10.32.128.1 any eq www

access-list inside_in permit tcp any any eq ftp

access-list inside_in permit tcp any any eq ftp-data

access-list inside_in deny ip any any

access-group inside_in in interface inside

But still no connection with FTP to the Internet, allthough nameresolving worked fine with nslookup, strange? This really bothered me, cause it didn´t make sence, not at all in fact, cause everything was looking fine to me. Then I decided to remove the last rule, just to make sure everything was working for the next morning again. Since there is an "implicit permit all", traffic would pass again, and so I removed the deny ip any any, and I could connect via FTP to Internet. But this is not what I wanted, cause now I can use every protocol again, due to the implicit permit.

So, I thought about it a while and read a lot of the PIX documentation, and it seems to me that what happens is the following, that the deny ip any any gets priority to the permit tcp´s. Why I am thinkin this, well, nameresoling worked fine with the deny ip any any in place (yep, did clear the cache, so, it didn´t come from the cache). So, this is why I think that the PIX do not process the ACL in order of appearance, but in fact based on best fit.

I think the PIX first screens for all statements for IP in the ACL (except the implicit rule), where it finds two rules, a permit for the dnssever and a deny any any for any This would result in not taken any other actions in further processing the rest of the ACL (the TCP rules) and just permitting the packet if it comes from the dns server or dropping the packet in case of any other source. So, in fact I still do believe that the tcp rules are not processed at all. I only see the hitcounts for the ip rules are increasing in this case.

(note that IP is more easily to process then TCP or UDP because less decapsulation has to take place, so, this would make sence if you just consider performance issues to first process IP based rules and then other rules, but okay, I did not develop the PIX, so, I´m just guessing here :-)).

I will first await a reaction of anyone from inside Cisco, and if ask for by Cisco, post the complete config. But I still hope there´s someone in this forum who can really tell how the PIX processes it´s ACL, cause it is absolutely not the same as IOS ACL (you all should know) and it does not just process in order of appaereance, IMHO ;-)

The environment we are talking is a live environment, with over 1700 users, so, all the playing has to be done outside working hours, because failure is not an option. So, any suggestions on testing something are read, but I can not test everything right away. But ofcourse, any suggestions are welcome. Is there in fact anybody out there who ever tried to not iplicit permit all traffic from inside to outside?

Again, thanx in advance and best regards,

Leo

New Member

Re: How ACL's in PIX are processed (best fit?)

Hello, Leo.

This line is taken from the univercd access-list command:

3. The access-list command operates on a first match basis.

So clearly you are wrong. Unless you provide more information you can not be helpred.

Best Regards

New Member

Re: How ACL's in PIX are processed (best fit?)

Is it possible that the FTP site is the problem in this case and not the PIX? It might depend on whether or not the FTP server is configured to handle passive or active connections. Here's a summary of how a Passive FTP communication takes place:

to support passive mode FTP the following communication channels need to be opened:

1 FTP server's port 21 from anywhere (Client initiates connection)

2 FTP server's port 21 to ports > 1024 (Server responds to client's control port)

3 FTP server's ports > 1024 from anywhere (Client initiates data connection to random port specified by server)

4 FTP server's ports > 1024 to remote ports > 1024 (Server sends ACKs (and data) to client's data port)

With your current configuration step 3 would present a problem.

This is just an idea....

For more information refer to this site: http://slacksite.com/other/ftp.html

Cody Rowland

Infrastructure Engineer

dro
New Member

Re: How ACL's in PIX are processed (best fit?)

Hi Leo,

I'm not quite sure what your running into. I just setup an outbound filter for a PIX 501 running 6.2(2) in a lab environment and was able to accomplish everything your looking for (as per your posts) without any trouble.

The PIX was setup with the following access-list:

access-list inside_in permit ip host 10.0.0.2 any

access-list inside_in permit tcp host 10.0.0.3 any eq www

access-list inside_in permit tcp any any eq ftp

access-list inside_in permit tcp any any eq ftp-data

access-list inside_in deny ip any any

Everything worked exactly as expected. 10.0.0.2 could send all types of traffic. 10.0.0.3 was able to surf everywhere and use FTP. All other hosts could only surf via the proxy server (10.0.0.2) and use FTP.

I didn't setup any DNS though, I did the tests using IP Addresses only.

You didn't happen to notice any odd errors in your PIX's logging buffer that might account for the issues your seeing? What version of code are you using?

*EDIT*

I posted this before I read Cody Rowland's post..

Passive FTP definately sounds like the problem to me. Quite alot of FTP servers prefer to use a port >1024 to send FTP data, as it allows them to lower their privileges to prevent possible exploitation in the server.

If this were the case, you would be able to connect to the remote host, but any data communication (listing files, sending/receiving files) would be blocked.

Either way, the logs generated from the access-list should point you in the right direction for whats going on.

Regards,

-Joshua

245
Views
3
Helpful
15
Replies
CreatePlease to create content