Video Screencast Help

Monitoring HTTP GET in Vontu DLP - Web Prevent

Created: 01 May 2012 | 4 comments


Just curious if anyone has any information on monitoring HTTP GET requests using DLP Web Prevent (ICAP from Proxy).

The documentation (and configuration) has an option to enable HTTP GET scanning- but what does this mean exactly?

Does it search just "in the URI" itself ? Or does it search within other headers (eg. Cookies, XHeaders, etc)?

Further, do we know if it can handle encodings- even basic ones like Base64 in those fields?

Finally, does Vontu for GETs perform any sort of "sessionization", in other words- linking multiple GET requests together that may be part of the same session to determine leakage.

We are are currently monitoring HTTP POSTS (and evaluating HTTPS - SSL decryption on proxy), and now looking into feasibility of HTTP GETS. Just looking for some information from other users who may be heading down the same path.



Comments 4 CommentsJump to latest comment

ShawnM's picture


Great questions. While I'm not going to say I'm an expert here, I believe I do understand the nature of the questions and the appropriate answers. I'm on the 80-90% positive side about my answers for you.

HTTP GET scanning, will actually scan within all of the GET request. If extraneous information is contained within the request, it will be scanned and analyzed according to the policy. If the policy ignores headers, then no we won't view the headers.

With regard to encoded information, I don't belive this will happen. Just as we don't do any type of decryption of other information, we aren't going to break down extra encoding. We look at the raw packet data and analyze. We rely on the ICAP interface to feed us the data in your example. This allows for the HTTPS decryption to happen as the Proxy does the work in that area. Our Monitor/Prevent products are meant to do analysis on what's provided, not really to manipulate or massage the data.

On the sessionization topic, I don't think we do this no. A GET request essentially is a quick transmission and once the GET session itself has completed (aka as soon as the content has been retrieved for the user) then it is no longer the same "session" in regard to the actual packets. The only session set we keep is the current transmissions. Each new transmission after will truly be a new "session" to the Monitor/Prevent system.

Hope this helps.

Symantec Corporation | Sr Systems Engineer | CISSP, CCSK, VCP

If a post solves your problem, please flag it as solved.

If you like an item, please give it a thumbs up vote.

wgalway's picture

Thanks for the answers, Shawn.

It's good to see that scanning will (most likely) occur within the entire GET request, and not just the URI.  This would mean that cookies and xHeaders, etc would be scanned using the policies- which is a good thing.

You mentioned "scanning of headers" needing to be enabled in policy- can you tell me which setting that is? I'm not as familar with the policy side of Vontu as I am the infrastructure piece.

The sessionization thing is as I expected, with Vontu only scanning one GET at a time.

Since it seems that you've given this topic some thought..... :)..... What are your thoughts on the future of web browsing moving more towards a model where data might be, by design, chopped up and uploaded via an HTTP GET. Thinking of something like AJAX? Examples here:(

Thanks again!

ShawnM's picture

In the interface on the policy, there are checkboxes for Envelope, Subject, Body, and Attachments. Envelope equates to headers.

Unfortuantely I'm not too much of a web dev or coding genius (working on this personally this year to get more familiar), so I don't have much of a take on it all. Ask me in 2 years! wink

Symantec Corporation | Sr Systems Engineer | CISSP, CCSK, VCP

If a post solves your problem, please flag it as solved.

If you like an item, please give it a thumbs up vote.

wgalway's picture

Thanks. We'll go through the policies to make sure "envelope" is included.

Thanks for your insight on this stuff.  We'll continue digging on our side. Check out that AJAX page, which explains (and gives an example) posting data via HTTP GET.

Anyone else have any experience with this?