Access list question

Unanswered Question
Dec 29th, 2003
User Badges:

Is it necessary to create access lists to "allow" hosts on the inside interface to browse the web? Or is the rule that communications initiated from the inside to the outside will cause the required ports to open?


In other words, for a typical PIX firewall, would the following lines be necessary to allow user to browse the web, FTP to sites on the Internet et.:


access-list inside_access_in permit tcp any eq www any

access-list inside_access_in permit tcp any eq https any

access-list inside_access_in permit udp any eq domain any

access-list inside_access_in permit tcp any eq domain any

access-list inside_access_in permit tcp any eq ftp any

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


Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
l.mourits Mon, 12/29/2003 - 04:53
User Badges:
  • Silver, 250 points or more

Hi,


It is not necessary to put an access-list on the inside for clients to browse the Internet. Putting a nat and global statement for the needed translation (or nat 0 in case you do not want translations) will be enough for users to be able to browse the Internet.


Statefull inspection will handle the response traffic, so, you do not have to worry about the response traffic also.


However, I would advice to use an access-lists on the inside interface. Just to be able to reduce not neaded traffic which worms and virusses oftenly use. So, an access-lists saying what is permitted would be the best way to configure. I think most engineers on this forum will agree on that.


Kind regards,

Leo


jmx2020 Mon, 12/29/2003 - 07:11
User Badges:

Thanks for your reply! Another person replied as well with similar news but I'm not sure I understand completely....so I can either leave off these access lists completely, or add them exactly as stated which will have the effect of limiting inside users from access just those ports/protocols (due to implicit deny)?


Thanks again!!

No, by default any machine on the inside interface can make all connections to the outside. The minute you add an ACL to the inside interface, this is no longer true (because of the implict "default deny" statement at the end of every ACL). So, if you do decide to add an ACL to the inside int, those 6 lines you cited would be a good addition to allow clients to use http/https, dns and ftp

jmx2020 Mon, 12/29/2003 - 07:03
User Badges:

Thanks for the reply! I *almost* understand...are you saying that I don't have to include the access lists in my post, but I could include them and therefore only these specific ports/protocols would be allowed (since there is an implicit deny at the end of the list)?


I do have some "access-list outside-access-in" permit statments to allow certain outside host to access some statically mapped inside host for PCanywhere. Is it accurate that the presence of some outside-access-in lists would not have the impact of creating an implicit deny for inside-access-in lists?


Thanks again for your help!

Yup, if you did put in that ACL and bind it to the inside int via an "access-group..." command, you would be only allowing clients to use those protocols - they could not make a smtp connection outbound, etc.


PIX access lists are stateful. SO whatever you allow in via an ACL on the outside interface (pc anywhere), the pix will allow the returning outbound traffic, regardless of what your inside ACL is.


Lets assume that the pcanywhere port is tcp 12345. You have an ACL that permits from any to tcp 12345 for that host, which resides on your inside interface. You have an ACL on the inside int just like the one you wrote, that only permits http, https, dns and ftp.


If I, out on the internet, send a pcanywhere connection attempt to that host, it will be groked by the outside ACL, and allowed in. The reply traffic to my request, with source port tcp 12345, and destination to me, will be passed through any acl on the inside interface as it is part of a stateful request. If the pcanywhere machine, of its own choosing, initiated an outbound communication from port 12345 to me (i.e, a packet that would have the same source and destination port and ip addresses as pcanywhere return traffic, but does *not* have the ACK flag on as it is not part of an existing connection), that would be blocked as it did not meet any of the 6 permit rules in your inside acl, and would be blocked by the implicit deny all at the end




jmx2020 Mon, 12/29/2003 - 09:14
User Badges:

Thanks for the clarification and the detialed explanation. I do have access-groups set for the inside and outside lists. And, I do want to limit outbound traffic to just these ports. I also am happy with the way my PCanywhere setup works...the PC's inside don't initiate any outbound sessions...they initiatiate from the Internet back to the host inside. And everything is working fine...just wanted to make sure these inside lists had a purpose!


Thanks again!

Actions

This Discussion