RE: [fw-wiz] Proxy - content filter related
From: Bruce Smith (bruces_at_southerngold.co.za)
To: <email@example.com>, <firstname.lastname@example.org> Date: Sun, 3 Jul 2005 22:08:16 +0200
This isn't a direct answer to your question, but here's my 2000 lira.
Simplest way to do this is to get some sort of firewall, *BSD, *Linux or
even a Linksys class box, in place and to block outgoing traffic except for
the proxy server. Force the little ones through the proxy by making it the
only route to the Internet. If they can get a direct route, NATed or
unNATed, to the Internet, then there's a big problem if the idea is to
control what they have access to. Then the proxy can do the work it's
supposed to be doing.
If the kids are using tunneling software that goes via legitimate channels,
then you're s****ed. They're already several steps ahead of you and you're
never going to catch up. We run in a billing situation and try to control
access to media files to conserve bandwidth. When the users began tunneling,
we investigated ideas on how to block them and found that since we were
getting the money for the tunneled traffic anyway (goes through the billing
proxy), it wasn't worth our while.
As for sniffing flowing traffic, you would have to stick a *BSD or *Linux
router in the path, hook a sniffer like Ethereal to it and hunt through what
is probably large volumes of traffic. With the capture filters that Ethereal
can use, you could try and catch the first packets in a conversation only.
That would lessen the volume. Another option is to use Snort in a
listen-only configuration, although this may require a switch capable of
spanning ports, and write custom rules to look for HTTP traffic, unless they
Hope this has helped a bit.
[mailto:email@example.com] On Behalf Of noc ops
Sent: Thursday, June 30, 2005 7:21 PM
Subject: [fw-wiz] Proxy - content filter related
I'm not sure if my previous e-mail made it the list as I didn't see it.
Anyway, here it is again and my apologies for any duplication.
Is it possible to look at the *outgoing* client-proxy request headers
(w/o going through a local proxy server) in order to identify/block
proxy related traffic?
a. users (user-agent) to non-SSL HTTP proxies
b. users (user-agent) to SLL HTTP proxy (encrypted)
Since the traffic is being redirected (transparently) via school's
content filter appliance (open-source product), does it make sense to
enable proxy so that the appliance provides SSL & non-SSL tunneling
CONNECT extension method, so that we can identify (via CONNECT) and
filter traffic (via keyword). Is it a worthwhile effort?
I can't see any other way to address proxy related traffic (google web
accelerator as an example) which is currently bypasses our content
filter based on egress traffic. Unless I perform deep packet inspection,
look for incoming response, which might slow things down since filtering
is being done in the software.
I'm not sure what I can get out of SSL proxy packets since it creates
a secure connection (encrypted session) between client and server but
any thoughts will be greatly appreciated.
The purpose of this is to inspect/block naughty sites which students
access using third party proxies to bypass school's content filter(s).
I'm trying to help a public school with this issue and any help will be
Any pointers to any in-depth papers or books which talks about proxies
in depth will be excellent.
Appreciate your time/help.
firewall-wizards mailing list
firewall-wizards mailing list