CISCO
PIX: ACCESS CONTROL LISTS AND
CONTENT FILTERING CONT...
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.
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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’
Code:
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:
Code:
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)
Code:
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)
Code:
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:
Code:
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.
Code:
London(config)# filter https 0 0 0 0 allow
Or
Code:
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.
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.