I'm a bit confused on this one. How is this related to SIEM (this is the community you posted to)? Also, how does this relate to MWG (you used it in the title).
As far as this "websense udp protocol" are you talking about IFP (internet filtering protocol)?
I'm just confused about what you're asking from the Community.
Yes to connect to MWG but my firewall does not offer that option and just websense so i need to write a program to recived udp requests from the firewall and then the program will call MWG to filter the Url's
with the reply being sent back to my little program and then back to the firewall.
it's just a relay conversion program i am writing and this is why i need details on the packets sent from the firewall
I think you are going about this the wrong way.
If this is a Cisco firewall it likley supports the IFP protocol. The IFP protocol supports two vendors (smartfilter aka n2h2, and websense).
MWG supports IFP when you configure the Cisco device to use MWG as the IFP server.
PIX/ASA commands to enable IFP:
1. Define the IFP Server using the command:
-url-server vendor [n2h2 | smartfilter] (if_name) host local_ip [timeout seconds] [protocol TCP | UDP version [1|4] [connections num_conns] ]
-example: url-server vendor smartfilter host 10.0.0.1 timeout 10
For vendor us the key below, the version is the version of the PIX/ASA:
With versions 6.3 through 7.1, type n2h2.
With version 7.2 or newer, type smartfilter.
If you are using Webwasher, either will apply so type n2h2/smartfilter depending on your version.
2. Apply the filtering to the traffic using the command:
-filter url [http | port[-port]] source_ip source_mask dest_ip dest_mask [allow] [proxy-block] [longurl-truncate | longurl-deny] [cgi-truncate]
-example: filter url http 0 0 0 0 allow longurl-truncate
3. To apply filtering to HTTPS traffic* use the following command:
-filter https source_ip source_mask dest_ip dest_mask [allow]
-example: filter https 443 0 0 0 0 allow
*This "https" command will only work on versions 7.2 or newer, older versions will not support filtering of https traffic.
4. (Optional) To exempt traffic from filtering, use the following command:
-filter (https|url) except source_ip source_mask dest_ip dest_mask
-example: filter url except 10.10.0.0 255.255.0.0 0 0
5. (Optional) To enable buffering of HTTP replies for URLs that are pending a response from the IFP filter server, type the following command:
-url-block block [block_buffer_limit]
For block_buffer_limit, type the maximum number of blocks (1 to 128) for the URL buffer.
-example: url-block block 128
6. (Informational) To remove any of the commands from the device just copy the exact command and place a 'no' in front of it.
-example: no filter https 443 10.10.0.0 255.255.0.0 0 0 allow
Is there a reason you posted this is the SIEM community and not the McAfee Web Gateway community (MWG).
Hi Jon and thanks for your reply
We have a Sonic TZ firewall without a licence but very little works on the route without one and Dell seems to want us to pay just so we can see whats been blocked by the firewall
in the in-built log viewer even when it shows everything else from NAT mapping to firewall rule changes and it seems to me that they are trying to force people to upgrade
to a licence so that blocked packets can be viewed in a report thats costs user money in licence fees.
So anyway i tweaked a bit of code so we could see what was going on from our Syslogs server on port 514 when packets were blocked by the firewall and it looked
like data was still being sent out even when it was blocked by content filtering but i thought no one could be that stupid and did a bit of reading after i read your reply
to see if i could hook this Sonicwall up to MWG like you said instead of paying "Web-Sense" $100 a year per user just for traffic filtering and came across this article.
- The user sends the request, and the router examines it.
- The router forwards the request to the external server.
- The router also forwards the request to the content-filtering server to determine whether the access is allowed. Basically, Steps 2 and 3 are occurring almost simultaneously.
- When the content-filtering server receives the lookup request, it examines its internal database policies to determine the action that the router should take. It then sends the policy action to the router.
- The response from the content-filtering server typically arrives before the external web server has a chance to return the content that the user was asking for. However, if the external data is returned before the router receives the policy action in Step 4, the router can buffer the returning external web data.
- The router implements the policy action from the content server: permit or deny the URL data. If the action is to deny the user access, the content-filtering server actually passes back a redirection URL to the user that directs the user to a URL location on the content-filtering server. The URL contains a message about inappropriate use of the type of content the user was trying to download.
See http://etutorials.org/Networking/Router%2Bfirewall%2Bsecurity/Part%2BIV%2BStatef ul%2Band%2BAdvanced%2BFiltering%2BTechnologies/Chapter%2B10.%2BFiltering%2BWeb%2 Band%2BApplication%2BTraffic/URL%2BFiltering/
Thats not how a firewall should work and anything could be pushed out to the internet in the requests by members of staff and this does nothing to stop tracking/spyware and makes me wonder
why no one else has pointed out the obvious security flaws with this approach so i won't be connecting our firewall to MWG using this methord and other sys-admins should in
my view take note of my comments.
We have our own proxy server and internal DNS server on the LAN and can forward 80/443 requests from the router on to the proxy server to block/allow so think that
will be the way to go so i hope MWG has API stub program that will llink up with .Net 4 code in windows so i can connect to McAfee from the proxy server.
Sorry to rant on but i do feel a bit let down by this Sonicwall with little to nothing working without a licence and leaking data out to the WAN and the only saving grace is that it allows
outbound NAT unlike our old trusted firewall router that was much easyer to use.