Well, i can. Fix HTML to be valid XHTML which is basically valid XML
as well. Apply XML-based filtering policy then (you need pretty complicated
one that probably goes beyond the abilities of current XML proxies, as
things like ajax and javascript in general need special handling, but
we already do have some of those in current http firewalls) and you
get it. At least it is the way we are going to do if somebody will
sponsor it as it is a bit too big for a free time hobbyst project :-)

For your "war story", i guess IDS/IPS relied on signature analysis
and no one looked if there are suscpicious persistent https tunnels
or unusual dns traffic? Well, some bad guys may live without that
but they are really really rarely *that* smart ;-)

On Tue, Nov 27, 2007 at 09:19:10PM -0600, Marcin Antkiewicz wrote:
> I would not look at Squid as a security device - I cannot imagine a
> security proxy written for HTTP as it stands today. In order to have
> any install base, HTTP proxy can, at most, implement ACLs/user auth with
> content filtering and some spam, maybe some cookie encription/info leakage
> prevention, but cannot really limit the protocol.
> And now, we slap a NATing router with some ACLs, AV, caching proxy,
> sieve-like egress filtering and call it a firewall.
> Everyoen loves war stories: I do consulting sometimes, and last time it
> was for a place with IDS, IPS, 3 AV subscriptions, HTTP proxy, split
> horizon DNS, 2 (!) layers of firewalls (statefull), encrypted and
> unencrypted wireless, NAC and traffic shaper. The bad guys still got in!
> How you ask? Easy: via HTTP/s, dns, smtp (traffic on all the protocols
> was proxied, in and out).

firewall-wizards mailing list