I disagree slightly with what you say. Squid can do the
following security oriented things:

0 sanitizes http commands going through it (dos, espec
unintentional doses by corrupt clients or bad networks)
0 can limit sizes to limit buffer overflows
0 can anonymize or even edit headers to limit access to
user-agent, link, www-authenticate, referer, from, server,
accept-charset, etc.
0 filter out known signatures for malware such as pop-ups,
hijack scripts, cross-site scripting, etc.

That's just what I can think of off the top of my head.... You
can use Squid as an outgoing proxy for your users, or an incoming
cache for your servers, and both ways would provide different
security possibilities.

I am NOT saying Squid is the end-all be-all, not even advocating
its use at all. I was merely using it as an example of an
application proxy. SOCKS might make more sense than Squid,
from a purely security perspective....


Marcin Antkiewicz
> I am well aware that Squid does not do all of the previous--
> it is an application proxy. Application level proxies, or
> the equivalent, are the best form of deep packet inspectors.
> The rest of the Stateful with deep packet inspection would be
> what is more traditionally thought of as a firewall. They
> would not substitute for one another, but instead complement
> each other.

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. Squid and most popular
http proxies are http caches/load balancers but not security devices.
firewall-wizards mailing list