PIX: Access Control Lists and Content Filtering

[Nokia]

PIX 5: Access Control Lists and Content Filtering

Originally posted HERE

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 the PIX 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 may explain it a bit better:

London(config)# static (inside, 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:-

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?

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
any – 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:

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:

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.

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:

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 WEB-SERVER

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 WEB-SERVER tACL.


Modifying ACL’s

Obviously we are not going to get the ACL’s correct first time and they are not going to remain unchanged for the lifetime of the firewall. ACL’s on the PIX or given consecutive line numbers, to allow us to change, add or remove Access Control Entries (ACE) without having to change the entire ACL.

An ACL is made up of one or more ACE’s.

If we issue the ‘sh access-list’ command the output will be along the lines of:

London(config)# sh access-list
access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0)
access-list ACLOUT line 3 permit udp any any (hitcnt=0)
access-list ACLOUT line 4 permit tcp any any eq ftp (hitcnt=0)
access-list ACLOUT line 5 permit tcp any any eq https (hitcnt=0)

**The hitcnt (hit count) shows us how many times that specific ACE has been used by the PIX which gives us the best indication of if they are being used or not.**

The PIX automatically adds the line numbers for the ACE’s and requires no configuration from the administrator.

**The line numbers are only displayed when you issue the sh access-list command and will not appear when you view the running or startup configuration**

So say we add a new web server with the IP of 80.80.80.81, we need to be able to add the ACE without taking down the whole ACL.

Here is what we do:

London(config)# access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www

This would add the ACE to the ACL at line 3 and push the other ACE’s down one (unlike a router where this command would overwrite the existing ACE)

London(config)# sh access-list
access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0)
access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www (hitcnt=0)
access-list ACLOUT line 4 permit udp any any (hitcnt=0)
access-list ACLOUT line 5 permit tcp any any eq ftp (hitcnt=0)
access-list ACLOUT line 6 permit tcp any any eq https (hitcnt=0)

Or if we decide we don’t need a particular ACE anymore we use the ‘no’ command to remove it from the ACL.

London(config)# no access-list ACLOUT line 3 permit tcp any host 80.80.80.81 eq www

Remarks
When a lot of ACE’s are configured in an ACL viewing and administering them can become very hard indeed, especially when you are looking for a certain ACE to alter. For this reason Cisco have given us the option to add a remark to an ACE to better explain to us or subsequent administrators what the ACE is for.

London(config)# access-list ACLOUT line 1 remark BILLING WEB SERVER ACE
London(config)# access-list ACLOUT line 3 remark ORDERING WEB SERVER ACE

London(config)# sh access-list
Access-list ACLOUT line 1 remark BILLING WEB SERVER ACE
access-list ACLOUT line 2 permit tcp any host 80.80.80.80 eq www (hitcnt=0)
access-list ACLOUT line 3 remark ORDERING WEB SERVER ACE
access-list ACLOUT line 4 permit tcp any host 80.80.80.81 eq www (hitcnt=0)
access-list ACLOUT line 5 permit udp any any (hitcnt=0)
access-list ACLOUT line 6 permit tcp any any eq ftp (hitcnt=0)
access-list ACLOUT line 7 permit tcp any any eq https (hitcnt=0)

As you can see in the above output the remark is inserted above the ACE it is remarking about and all the subsequent line numbers are incremented by one. This is a good example as to why anything like this should be wrote in capitals, as it stands out straight away for us.

A remark can be up to 100 characters long.

ICMP

ICMP can be configured in pretty much everyway imaginable on the PIX.

By default pinging through the PIX to a PIX interface is not allowed but pinging an interface from a host attached to that interface is permitted. So for example a host on the internal network can ping the INSIDE interface but not the OUTSIDE interface.

It is recommended to permit ICMP type 3 messages (destination unreachable) as denying this type 3 ICMP disables the ICMP MTU discovery which can cause IPSec and PPTP traffic to fail.

To allow ICMP we use the following command:

London(config)# icmp permit any echo-reply outside
London(config)# icmp permit any unreachable outside

The syntax for the ICMP commands is:

icmp {permit | deny} Source Address Source mask {icmp type} {interface name}

So

icmp permit 80.80.80.81 255.255.255.255 echo outside
icmp deny any redirect outside

And so on.

You can find a list of all the different ICMP types here:
http://www.iana.org/assignments/icmp-parameters

To remove all ICMP configurations use the ‘clear icmp’ command:

London(config)# clear icmp

Alternative methods for using an ACL

NAT exemption
Up until now we have only used ACL’s to permit or deny traffic. ACL’s can be used in conjunction with other commands to alter the normal flow of traffic.

Take a site to site VPN for example, even though we may have told the PIX that everything leaving the OUTSIDE interface needs to be NAT’d, we would not want our VPN traffic to be NAT’d but rather tunnelled. Hence we need to tell the PIX to exempt the VPN traffic from NAT.

As mentioned earlier we do this with the NAT 0 command – but we can take this one step further with a NAT 0 access-list command.

London(config)# access-list VPN_NAT permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0
London(config)# nat (inside) 0 access-list VPN_NAT
London(config)# nat (inside) 1

You should by now be familiar with the layout of ACL’s, so I will only briefly explain the above.

We have created an ACL called VPN_NAT, which permits IP traffic from 10.10.10.0/24 going to 10.10.20.0/24.
Then we told the PIX not to NAT traffic on the INSIDE interface if it meets the settings laid out in the VPN_NAT ACL.


Policy NAT
Policy NAT is very commonly confused with NAT Exemption as explained above.

Policy NAT allows us to identify traffic that will be translated when it meets a certain criteria that we configure such as destination port and source port.

So if we want to NAT a host when it is sending HTTP traffic to Company A (90.90.90.90) to an external IP address but when it sends HTTP traffic to Company Z (100.100.100.100) we want it to use a different external IP address, then we can use policy NAT.

The following configuration should make it more apparent:

London(config)# access-list COMPANY_A permit tcp 10.10.10.0 255.255.255.0 host 90.90.90.90 eq www
London(config)# nat (inside) 5 access-list COMPANY_A
London(config)# global (outside) 5 80.80.80.81 netmask 255.255.255.255
London(config)# access-list COMPANY_Z permit tcp 10.10.10.0 255.255.255.0 host 100.100.100.100 eq www
London(config)# nat (inside) 6 access-list COMPANY_Z
London(config)# global (outside) 6 80.80.80.82 netmask 255.255.255.255

Here is what we just configured:

We defined an access-list and called it COMPANY_A which permits tcp traffic from 10.10.10.0 255.255.255.0 going to 90.90.90.90 that is equal to www (HTTP).

Then we told the PIX that any traffic that matches the criteria defined in access-list COMPANY_A should be NAT’d to the IP address defined in the global pool with the ID of 5

We then defined the global pool by giving it an ID of 5 and the IP address of 80.80.80.81 255.255.255.255

So when a host on the 10.10.10.0 network sends HTTP traffic to 90.90.90.90 the PIX will NAT it to an external IP of 80.80.80.81

We then configured traffic destined for COMPANY Z in the exact same way, just with the relevant IP addresses.
When the PIX sees HTTP traffic destined for 100.100.100.100 it will NAT it to an external IP of 80.80.80.82

The ACL defines the type of traffic to be NAT’d – and the NAT command defines what the translation will be.

So we have an ACL in conjunction with a NAT command.


Filtering Malicious Code

We can also configure the PIX to filter unwanted code such as ActiveX and Java. Although you may thing this will be a very complex thing to configure, it is in fact extremely easy.

Java
As we all know Java programs can provide an ideal ‘carrier’ through security systems to invade an inside host as they are executable programs that arrive on port 80 – which is nearly always open in most firewalls. Java can contain hidden code that could potentially destroy data on an internal network.

Most decent security policies prevent Java Applets from being downloaded/displayed.

The Applet filter on the PIX looks out for the ’café babe' string and if found it will drop the packet(s).

**Read THIS if you are unsure what café babe refers to. Basically it is the unique ‘Magic Number’ that identifies the type of program **

A sample Java class snippet would be:

0000000: café babe 002 004a 0023 6243 8252

The café babe identifies it as a Java program, which obviously the PIX will see and block the packet.

**MAC OS X also used the café babe magic number, so you may want to test the configuration before hand if you have OS X hosts on your network**

To configure Java filtering we use the following commands:

London(config)# filter java 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

The above command simily filters java on port 80 to any local IP address ( 0.0.0.0 0.0.0.0) going to any remote IP address (0.0.0.0 0.0.0.0)

Or we could have:

London(config)# filter java 80 10.10.10.10 255.255.255.255 0.0.0.0 0.0.0.0

Which would stop the host with the IP address of 10.10.10.10 from downloading a Java Applet from any IP address.

We can configure it for individual hosts, subnets or entire networks in this way.

ActiveX
ActiveX controls or Object Linking and Embedding (OLE) as it's known by some are applets that can be inserted in to web pages or other applications and provide a method of entry on to a network through a firewall as just like java they arrive on port 80 and can be embedded in a web page without the users knowledge and can bring a server to its knees fairly quickly.

It is blocked in exactly the same way as Java, we just replace the ‘java’ keyword with ‘activex’

London(config)# filter activex 80 10.10.10.10 255.255.255.255 0.0.0.0 0.0.0.0

Again, it can be configured for certain hosts, subnets or the entire network.


URL Filtering

The PIX itself can not filter URL’s but instead it can forward requests to a web filter server such as Websense and N2H2

When the PIX receives a request from a user requesting access to a URL the PIX wil querery the URL filter server to enquire if it should block or return the requested web page. Web filter servers can be configured to display a blocking message or to send the users to a particular web site.

For large networks multiple web filter servers can be configured, up to a maximum of 16. But you may only use one application at a time, either Websense or N2H2.

To configure the PIX to use a Websense server the following command is used:

London(config)# url-server (inside) vendor websense host 10.10.10.50 protocol tcp

The syntax for a Websense server is as follows: (anything in the [] will be specific to your setup and requirements, anything without the [] should be entered as shown)

url-server [interface name] vendor websence host [ip address of server] [timeout in seconds] protocol [tcp | udp | version]

And for N2H2 the syntax is: (anything in the [] will be specific to your setup and requirements, anything without the [] should be entered as shown)

url-server [interface name] vendor n2h2 host [ip address of server] [port number to talk to n2h2 server, default is 4005] [timeout in seconds] protocol [tcp | udp ]

So now we have told the PIX where the web filter server is and what make it is, we need to turn URL filtering on:

London(config)# filter url http 0 0 0 0 allow

We have told the PIX to filter url’s from data crossing the PIX that or on port 80( http) from any local IP address 0 0 destined for any IP address 0 0. If for any reason the URL filter server was to go offline then the PIX will allow the traffic through.

Without the ‘allow’ command at the end the PIX would block all traffic on port 80 until the web filter server came on line again.

We can add a few more key words to the end of the command should we so wish:

proxy-block – Prevents users from connecting to a HTTP Proxy server
longurl-truncate – Enables outbound URL traffic regardless of if the URL buffer is available or not
longurl-deny – Denies the URL request if the URL is over the maximum size or the URL buffer is unavailable.
cgi-truncate – Sends a CGI script as a URL

And finally, with version 6.3 and later of the PIX operating system we can also filter HTTPS and FTP traffic.

The syntax is the same as the HTTP command; we just remove the URL keyword and replace HTTP with HTTPS or FTP.

London(config)# filter https 0 0 0 0 allow

Or

London(config)# filter ftp 0 0 0 0 allow

If we wanted to could use 443 instead of the HTTPS keyword and 21 instead of the FTP keyword.

The only difference is we have one more keyword we can use with FTP filtering and that is interact-block, which would stop a user connecting to an FTP server through an interactive FTP application.


Next Chapter will be Object Grouping.

Find more PIX Tutorials HERE