Best way of restricting web access?

[Ante]

Hi there,

Have a "interesting" problem.

Scope

* Clients are not to be allowed access to the internet. Restrict and control with firewall.

Scope creep

*Clients need access to Google to do a search, click on any links in that search. They will search for people/location

How can I best isolate and protect these clients web access? I've been trying to figure out what would be the best possible way to allow them a Google search access and 'click' access to the search that comes up.

Any input would be greatly appreciated and anything goes to try and mitigate the scope creep to try and be somewhat 'in line' with scope!

Cheers

A.

[mikand]

Filtering on dstip just wont work because Google uses shitloads of ip addresses.

Setup a custom url category which contains (for example) www.google.com (you might need to add a few other domains/subdomains/urls aswell) and enable ssl termination (so you can inspect encrypted https flows).

1) Then as first rule you deny stuff from Google which you dont wish to allow, such as Google Translate etc which can be used as proxy.

2) Then as second rule you allow by use the above custom url category along with appid for google search (if such exists).

You could also create a custom appid for this. Dont forget to set service to application-default (or manually to TCP80, TCP443).

[Ante]

Mmm how do I deal with that the user has to click on the actual search links that comes up? That means internet, I'm wondering if I could allow the actual search itself and then allow the "click" to any of the links, they'll have some 'google' link in them when clicked at first. (creating a new APP ID) then have an ultra restricitive web-browsing and not allow any files up or down. Has anyone tried to design something like this in the past?

[mikand]

Could using google webcache be sufficient for the users?

Because if you want them to be able to traverse to the searchresult then you must enable surfing.

You could perhaps setup a custom appid that will trigger on http-method: GET, HEAD, POST along with http-referer: ^http://www.google.com/ (or whatever domain google uses in your case). This appid could of course be easily bypassed by the client by sending a custom referer to fool the filter but still...

[Ante]

Will look into how to best use the appid, they'll click pre defined links so could use some filtering on that, they're happy to use cached web after their google search which means they can still 'surf' the internet but it'll be pretty cumbersome to do for them and it'll more then likely result in them not doing it on these machines. I'll update this thread with the final result.

Cheers and thanks

A