Solved

PIX and Websense URL filtering issue

Posted on 2006-11-22
16
1,753 Views
Last Modified: 2013-11-16
First the network overview...
                           ____________
[Site A 2800]-----(                      )
                         (                      )-----[2800 Outside]--------+
[Site B 2800]-----(                      )                                      |
                         (       ISP          )---[3800 WAN]----[PIX-525v7.0]-----[Inside]
[Site C 2800]-----(      CLOUD      )                                      |
                         (                      )                                   [DMZ]---------[ISA2004]
[DialUpUsers]----(_____________)                                                |-----[Websense]
                                                                                                  |-----[CiscoACS]

We have 3 remote sites and a number for dial in users. Each remote site is equipped with a 2800 series Cisco router, which is connected to our ISPs frame-relay cloud. As for the dial in users, they have been given a universal access number to dial which connects them to our ISP. We, at the Head Office, are also hooked up to the ISPs frame-relay cloud using a 3800 series Cisco router. There are total of 4 point-to-point links, linking to the remote sites and for the dial in users to come in. The remote sites communicate with the HO router via an IPSec tunnel that terminates on the 3800’s outside interface. The dial in users use the Cisco VPN client and establish a VPN that terminates on the PIX’s WAN interface.

We employ Websense to filter all HTTP traffic on our network. The PIX intercepts HTTP traffic originating from the INSIDE to the DMZ and DMZ to OUTSIDE. However the PIX does not intercept HTTP traffic originating from the remote sites or the dial in users coming in from the WAN interface.

All nodes are configured to use the ISA server located in the DMZ as a HTTP proxy on port 8080. Nodes in the DMZ and INSIDE are subjected to the URL filtering and are properly forwarded to the ISA server which then forwards HTTP requests outside. Nodes behind the WAN interface appear to be skipping the HTTP inspection and effectively bypassing the Websense URL filtering. Their requests are forwarded to the ISA server and onwards to outside.

Our experiments have shown that HTTP request that originate from a high security level interface destined for a lower security level will trigger the URL filtering. But a HTTP request that originates on a lower security level interface destined for a higher security level interface will skip the URL filtering. If we configure the nodes at the remote sites to use an external proxy server, such as the one provided by our ISP, and configure the PIX to NAT the internal IPs to public ones, the URL filtering kicks in.

We suspect that the issue lies somewhere with interface security levels and URL filtering. Security levels of the PIX’s interface are as follows:

Inside 100
DMZ 90
WAN 50
Outside 0

So before I go messing with security levels, I wanted to get a 2nd opinion on this issue… so fire away!
0
Comment
Question by:bugsaif
  • 6
  • 6
  • 4
16 Comments
 
LVL 11

Expert Comment

by:prueconsulting
Comment Utility
I would suspect its related to the traffic flow vs security levels.

Traffic flowing outbound ( ie High to Low ) trips the filters  while inbound (Low to High ) as you said does not.

Also since the packets are hitting the WAN interface as VPN packets they are being decapsulated and bypassing all traffic filters since they are IPSec Packets so this makes sense they are making it to the ISA server.

How have you implemented Websense  ( On the PIX or on ISA ) .

I would put it in place on both
in the pix configuration as url-server (dmz) host ip
and also in teh ISA server as a plug in filter

0
 
LVL 3

Author Comment

by:bugsaif
Comment Utility
I am in touch with Cisco TAC... they just denied the possibility of a security level issue...

    "In relation to your quire, I have to tell you that the situation of traffic coming
     from a low security level to a high security level should not skip the URL filtering
     as the commands configure for this task should be inspecting the traffic even
     if this come from a lower security network."

The traffic from the remote sites do not hit the PIX as VPN packets, the tunnels terminate at the WAN router and from there on are unencrypted. The dial in users however are terminating at the PIX but we have tried with and without VPN and its the same issue... anything coming in from the WAN interface will skip URL filtering...

Websense is configured on the PIX.

     url-server (DMZ) vendor websense host Websense timeout 30 protocol TCP version 4 connections 5
     filter url except ISA2004 255.255.255.255 0.0.0.0 0.0.0.0
     filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

All nodes are configured to use the ISA as their proxy on port 8080. And only ISA is allowed to go outside.

At the moment I'm not looking for a solution to the URL filtering, rather I am more interested in figuring out why the PIX won't enforce URL filtering on traffic coming in on the WAN interface.
0
 
LVL 11

Expert Comment

by:prueconsulting
Comment Utility
The thing here that seems especially odd is according to the PIX the traffic will be sourced from the ISA in every case since its acting as the proxy. So it will all be travelling high to low.

0
 
LVL 32

Assisted Solution

by:rsivanandan
rsivanandan earned 250 total points
Comment Utility
>>"In relation to your quire, I have to tell you that the situation of traffic coming
     from a low security level to a high security level should not skip the URL filtering
     as the commands configure for this task should be inspecting the traffic even
     if this come from a lower security network."

This doesn't seem to be correct. Till date I have seen the URL filtering working only from high security to low.

Did you ask this question to the tac guy ?

Say if you had hosted a webserver inside your network and if every user around the world accesses it, will that also be filtered, well, that is what the above explanation says!

Strongly suggest him to get this from any of the online documents, one of the good things about Cisco is that they do test it out when a scenario example is posted onto the site.

Cheers,
Rajesh
0
 
LVL 3

Author Comment

by:bugsaif
Comment Utility
To: prueconsulting
We had to configure the ISA2004 as an exception to the filter rule because if we didn't than every HTTP request was being reported twice in the Websense reporter. Once for the user and the same from ISA when it goes out to get the page. If we take out this exception, the PIX will intercept the HTTP request from the WAN interface but NOT when its going to ISA... but when ISA is goes out to get the requested page... and then it is incorrectly reported in the reporter as ISA going to that URL not that perticular user plus all the other requests that ISA is proxying.

To: rsivanandan
That was a direct quote from the TAC guy... for the moment he is having me capture traffic on the PIX from one of the remote sites coming through the WAN interface to ISA. I'll put your question to him with the captured data...
0
 
LVL 11

Expert Comment

by:prueconsulting
Comment Utility
Why not simply configure websense on the ISA server itself to do the filtering and don't worry about the PIX .And as rsivandandan said i too have only ever seen url filtering working in an outbound fashion , never inbound. But with the exception in place i can understand why its not working from the ISA

But here is the idea.

If you want reporting and your environment is as you said http only allowed out from the ISA just use the Dll plugin module to load websense into ISA , turn it off in the pix and then you will have accurate reporting and all filtering will function.

I do not believe that filtering will ever work correctly inbound.
0
 
LVL 3

Author Comment

by:bugsaif
Comment Utility
Well I sent the packet capture to TAC along with rsivanandan's question... and prueconsulting, I do admit to the logic of URL filtering working from a higher security level interface to a lower one as we suspected from the beginning. I'm also aware of the Wensense and ISA integration method, but as I mentioned earlier, I'm not looking for a solution to the URL filtering, rather a confirmed explanation as to why the PIX is acting the way it is... I'm going to wait and see what the TAC guy has to say since he claims the security level to be a non-issue... in the mean time... I have a partial syslog for a remote node and inside node accessing google. There are obvious differences but nothing that would make sense to me... maybe you guys can make something of it...

Remote Node:
6|Nov 23 2006 18:15:44|302014: Teardown TCP connection 8253963 for wan:192.1.4.9/24861 to DMZ:ISA2004/8080 duration 0:01:07 bytes 9276 TCP Reset-O
6|Nov 23 2006 18:15:39|302014: Teardown TCP connection 8253971 for wan:192.1.4.9/24862 to DMZ:ISA2004/8080 duration 0:01:02 bytes 785 TCP Reset-O
6|Nov 23 2006 18:14:37|302013: Built inbound TCP connection 8253971 for wan:192.1.4.9/24862 (192.1.4.9/24862) to DMZ:ISA2004/8080 (ISA2004/8080)
6|Nov 23 2006 18:14:37|302014: Teardown TCP connection 8253951 for wan:192.1.4.9/24860 to DMZ:ISA2004/8080 duration 0:00:02 bytes 5572 TCP FINs
6|Nov 23 2006 18:14:36|302013: Built inbound TCP connection 8253963 for wan:192.1.4.9/24861 (192.1.4.9/24861) to DMZ:ISA2004/8080 (ISA2004/8080)
6|Nov 23 2006 18:14:35|302013: Built inbound TCP connection 8253951 for wan:192.1.4.9/24860 (192.1.4.9/24860) to DMZ:ISA2004/8080 (ISA2004/8080)

Inside Node:
5|Nov 23 2006 18:01:42|304001: 10.1.3.24 Accessed URL ISA2004:http://www.google.com/images/x2.gif
5|Nov 23 2006 18:01:42|304001: 10.1.3.24 Accessed URL ISA2004:http://www.google.com/intl/en_ALL/images/logo.gif
6|Nov 23 2006 18:01:42|302013: Built outbound TCP connection 8250375 for DMZ:ISA2004/8080 (ISA2004/8080) to inside:10.1.3.24/1764 (10.2.1.202/1764)
6|Nov 23 2006 18:01:42|302014: Teardown TCP connection 8250367 for DMZ:ISA2004/8080 to inside:10.1.3.24/1762 duration 0:00:01 bytes 5492 TCP FINs
6|Nov 23 2006 18:01:42|302013: Built outbound TCP connection 8250372 for DMZ:ISA2004/8080 (ISA2004/8080) to inside:10.1.3.24/1763 (10.2.1.202/1763)
5|Nov 23 2006 18:01:42|304001: 10.1.3.24 Accessed URL ISA2004:http://www.google.com/
6|Nov 23 2006 18:01:41|302013: Built outbound TCP connection 8250367 for DMZ:ISA2004/8080 (ISA2004/8080) to inside:10.1.3.24/1762 (10.2.1.202/1762)
0
 
LVL 32

Expert Comment

by:rsivanandan
Comment Utility
nothing unusual!

Cheers,
Rajesh
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 11

Expert Comment

by:prueconsulting
Comment Utility
But if you look at the logs even there is shows .. Inbound only as a connection.. Outbound as accessing a URL.


Ohh just had another thought as well ..
Do you have your filter command in the pix like this

filter 8080 0.0.0.0 0.0.0.0 as well ?
0
 
LVL 3

Author Comment

by:bugsaif
Comment Utility
You did mean: filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 right?
this is what I've got in the PIX apart from a couple of ther host exempted and java and activex filters in place...

     url-server (DMZ) vendor websense host Websense timeout 30 protocol TCP version 4 connections 5
     filter url except ISA2004 255.255.255.255 0.0.0.0 0.0.0.0
     filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

0
 
LVL 11

Accepted Solution

by:
prueconsulting earned 250 total points
Comment Utility
Yes this is what i meant so that it did take 8080 traffic as a url request.

I did some testing with both an ASA  and a PIX running 6.3(5) and could not make the url filtering function on any inbound traffic requests.

We have a WAN site that is behind a PIX and they connect through us to access the internet out another pair of pixs so i turned the url filtering on on thier inbound path and it just sets them up as connections not as url requests.

So i think the behaviour you are seeing is by design of the ASA security model (high to low)

0
 
LVL 3

Author Comment

by:bugsaif
Comment Utility
Aright, I haven't heard back from the TAC guy... I'm going to send him a wassup in a bit... just a little update... two things really...
1- I did manage to get the PIX to show in syslog for inbound as 'Accessed URL' by putting an inspection rule on the wan interface...
2- Using the ASDM, under Configurations > Features > Security Policy > Filter Rules
it'll list all the filtering rules in place... there's a little radio selector at the bottom 'Show Summary' and 'Show Detail'. Highlighting the url filter rule and clicking on 'Show Detail' it listed all the source and destination subnets the rule applies to... only high to low were listed. So I tried adding a specific rule that would filter WAN traffic to the DMZ... this I have done before using the CLI and without change in behaviour. The ASDM however gave me an error box with the following:

---------------------------------[Error Box Text]---------------------------------
Filter rules can only be applied to outbound connections.

An outbound connection is a connection from a higher security interface
to a lower security interface or, if the same security level communication
is enabled, between two interfaces with the same security levels.

To enable the same security level communication, check the
corresponding checkbox at the bottom of Configuration > Features >
Interface
---------------------------------[Error Box Text]---------------------------------

So I guess that pretty much says it... I guess Cisco TAC ain't what it used to be... thanks guys for all your help and testing... I'll split the points between the two of you in a couple of days... I wanna see what the TAC guy comes up with...
0
 
LVL 32

Expert Comment

by:rsivanandan
Comment Utility
:-) Exactly... no explanations needed now.

Cheers,
Rajesh
0
 
LVL 11

Expert Comment

by:prueconsulting
Comment Utility
No problem..
0
 
LVL 3

Author Comment

by:bugsaif
Comment Utility
Here's the final Cisco TAC comment...

"I really apologize for the confusion I formed on you in relation to this
particular issue. You are perfectly right in state that “outbound
connections” are connections established from a higher security interface to
a lower security interface, and because of this URL filtering from a lower
security level to a higher security level interface will be not possible.

As a workaround you can configure The only solution I see in your case would
be to change the Security levels for the interfaces involved in order to
make the WAN interface higher that the DMZ in which the ISA2004 relies."

Thanks again...
0
 
LVL 32

Expert Comment

by:rsivanandan
Comment Utility
:-) Funny..... I won't ask the name..

Cheers,
Rajesh
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

Suggested Solutions

There are many useful and sometimes not well documented or forgotten IOS or ASA/PIX commands. See IPE article here , there was also one on PacketU and on Cisco Tips & Tricks. Below are my favorites. I give also a few most often used for Cisco IPS an…
To setup a SonicWALL for policy based routing to be used with the Websense Content Gateway there are several steps that need to be completed. Below is a rough guide for accomplishing this. One thing of note is this guide is intended to assist in the…
Illustrator's Shape Builder tool will let you combine shapes visually and interactively. This video shows the Mac version, but the tool works the same way in Windows. To follow along with this video, you can draw your own shapes or download the file…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now