CISCO
PIX: ACCESS CONTROL LISTS AND CONTENT FILTERING
Cisco PIX 5: Access Control Lists and
Content Filtering
Hopefully after reading this you will understand the basic and advanced
features of ACL’s, how to block ActiveX and Java applets and how to
configure URL filtering on a security appliance.
Just to recap, by default every PIX has an INSIDE interface with a
security level of 100 and an OUTSIDE interface with a security level of
0. There is nothing more secure than the INSIDE interface and likewise
there is nothing less secure than the OUTSIDE interface.
By default a more secure interface can send traffic to a less secure
interface with a minimum of ACL’s configured but if we want to allow
traffic from a less secure interface to pass to a more secure one we
need to have a static translation and an ACL permitting that type of
traffic.
An ACL can be configured on any interface to filter both inbound and/or
outbound traffic but they are ‘evaluated’ only once per connection.
If there is no ACL applied to an interface then the above mentioned
default rule set is followed – allowed outbound by default but denied
inbound.
The guidelines for applying ACL’s are fairly simple.
From a higher to lower security level (Inside to Outside) an ACL is
used to restrict outbound traffic, so for example it would be applied
to the first interface traffic would encounter, in this case the INSIDE
interface. The source IP address in the ACL is the real address of the
host and/or network not the translated external address.
For lower to higher security level traffic the ACL is used to enable
traffic from a less secure network to traverse he PIX so it is applied
to the less secure interface, e.g. OUTSIDE interface, an ACL on the
OUTSIDE interface can also be used to restrict protocols. The
destination IP address in the ACL will be the external translated
address.
The following diagram will explain it a bit better:
Code:
London(config)# static (dmz, outside) 80.80.80.80 10.10.10.20 netmask
255.255.255.255
Translated IP
80.80.80.80
--DMZ--
10.10.10.20
|Internet|--->--->--->--->--->--->--->| PIX |
--->--->--->--->--->--->| Web Server |
So we have a web server in a DMZ with a real IP of 10.10.10.20. This is
translated to 80.80.80.80 on the outside interface of the PIX, in other
words an internet user puts 80.80.80.80 into his web browser which then
arrives at the PIX interface, the PIX knows that anything coming to
80.80.80.80 needs to go to 10.10.10.20. But what if FTP, Telnet, SMTP
etc traffic arrives? We have not told it what traffic is allowed on
what port and from what host(s). Remember a static translation needs
two things, a Address translation and an Access List that is applied to
the correct interface.
To reiterate what I said before about applying the correct ACL to the
correct interface; if the ACL saying that only HTTP traffic was allowed
to go the web server was applied to the DMZ interface, the PIX would
have dropped the traffic before it ever gets a chance to reach the
DMZ….why? If you remember back to the last paper about the process the
PIX goes through when traffic comes in:-
Quote:
1) Packet arrives at the PIX
2) The PIX first consults the Access Rules of the interface the packet
arrives on.
3) The PIX makes a routing decision to determine which interface to
send the packet out of
4) The source address of the packet is checked against LOCAL ADDRESSES
in the translation table
5) If an entry is found in the translation table, it is translated as
per the configuration
6) If an entry is not found the PIX will look for a translation match
in the following order:
1) nat0 access-list (NAT Exemption) to see if the host is exempt
translation or not
2) Static (Static NAT) will look through the static NAT table starting
at the top until it finds a match
3) Static TCP / UDP (PAT) – will examine the static PAT table starting
at the top until it finds a match
4) nat (NAT-ID access-list) this is policy NAT which will be covered
later
5) nat – regular NAT, best match
6) If no match is found at all then the packet is dropped
In step one the PIX checks the Access Rules of the interface the packet
is received on…..if we applied the ACL for the web server on the DMZ
interface the PIX will never look there for it, so will presume there
is none…..even though there is a translation for it, there is no rule
telling the PIX it is allowed to send it, so ultimately the packet will
be dropped.
If we apply it on the OUTSIDE interface, and thus the first interface
the traffic encounters on its way to the web server, when the PIX looks
for an access rule, the ACL is there and the PIX will act accordingly
If you want to restrict traffic leaving your network, put your ACL on
the inside interface, if you want to restrict it coming in put it on
the outside interface.
So what access rule do we apply?
Code:
London(config)# access-list ACLOUT permit tcp any host 80.80.80.80 eq
www
Here is the break down:
access-list – tells the PIX we are configuring a ACL
ACLOUT – The name of the access list, this can be anything you want, I
have called it ACLOUT to let me know it is the ACL I have applied to
the OUTSIDE interface.
permit permit the following traffic
TCP – TCP traffic
[/b]any[/b] – that comes from any host on the OUTSIDE interface
host 80.80.80.80 – destined for the host with the IP address of
80.80.80.80.
eq – equal to [the type of traffic being permitted]
www – the type of traffic allowed, in this case HTTP, we can use [port]
80 instead if we want.
So in a nutshell, any TCP traffic coming from any host that is destined
for 80.80.80.80 and is HTTP traffic will be allowed to pass through as
per the translation rule we have set up. If UDP traffic, or say FTP
traffic came in it would be dropped.
When configuring an ACL by default you deny everything else. So after
entering the above ACL, we will have denied EVERYTHING that does not
meet the criteria laid down in that ACL.
Once we have compiled the ACL we still need to apply it to the correct
interface using the rules I mentioned above. The following command is
used for this:
Code:
London(config)# access-group ACLOUT in interface outside
The breakdown of the command is:
access-group- – tells the PIX we want to bind an access list to an
interface
ACLOUT – the name of the ACL we want to bind to the interface. We can
only apply one ACL to an interface using the access-group command
in – The direction of traffic that will be affected by this ACL, in
this case inbound traffic.
interface outside – this speaks for itself, we have applied the ACL to
the OUTSIDE interface.
So we have now told the PIX that any HTTP traffic incoming to the
OUTSIDE interface, from ANY IP address destined for 80.80.80.80 on port
80 is allowed to pass through as per the translation rule. The PIX will
now look at the translation table, see the 80.80.80.80 is translated to
10.10.10.20 and allow the HTTP traffic to pass through.
*It is a good habit to name the ACL’s using capital letters, such as
ACLOUT, to make it more obvious when viewing the configuration
afterwards.*
We can use the following commands to view our access lists/groups:
sh access-list
sh run access-group
With version 7 of the PIX operating system we have the ability to use
time based ACL’s, so for example we could permit traffic to a web
server from the hours of 09:00 – 13:00 only. Or if a temporary worker
was hired for a month and needed access to something you could set an
ACL to allow him access to the server between certain hours for a one
month period.
Timed ACL’s (tACL) depend on the system clock, so ensure the clock and
date are correct, it is best to configure the PIX to use NP times from
an NTP server (explained in an earlier paper).
Like most of the PIX commands, the command relates to what we are doing:
Code:
London(config)# time-range WEB-SERVER
London(config-time-range)#
Obviously the command we use to tell the PIX we are configuring a tACL
is time-range the WEB-SERVER is the name of the tACL, and again it is a
good practise to use capital letters for brevity reasons when viewing
configurations.
Code:
London(config)# time-range WEB-SERVER
London(config-time-range)# absolute start 00:00 1 october 2006 end
00:00 20 october 2006
London(config-time-range)# periodic weekdays 8:00 to 17:00
Now we have two different commands, the absolute command defines the
absolute start and finish time of the tACL’s validity, this can be as
long or as short as is needed. The Periodic command sets the recurring
weekly time for the tACL.
So our tACL called WEB-SERVER would apply from 08:00 to 17:00 on every
weekday between midnight on the 1st October to midnight on the 20th
October.
Now we have defined when the tACL is valid to and from, we need to
define what the actual tACL actually allows:
Code:
London(config)# static (dmz,outside) 80.80.80.81 10.10.10.21
London(config)# access-list ACLOUT permit tcp host 123.123.123.123 host
80.80.80.81 eq www time-range TEMP-WORKER
So we have statically translated a web server to an external IP in the
normal way, then created the necessary ACL permitting tcp traffic from
host 123.123.123.123 going to host 80.80.80.81 with traffic that equals
www, then we told the PIX to apply a time range to it and the time
range that it needs to apply is what we specified in the TEMP-WORKER
tACL.
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on October 6th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.