Re: Query: Why bother with an application proxy over stateful packet filtering?

["K K" <kkadow () gmail com>]

On 8/27/07, william fitzgerald <wfitzgerald () tssg org> wrote:
> Also, are web proxy's used in conjunction with firewalls
> or in place of a firewall.

Depends on the site.  There are many "firewalls" which include web
proxy functionality, and many commercial web proxy products market
themselves as being a replacement for a traditional "firewall".

In big business I often see an ingress+egress packet filter (a "filter
router") on the outermost edge, with proxy firewalls just inside the
filter, and then the soft and juicy center just "inside" the proxy
firewall layer.


> While agree with you view of controlling telnet or in appropriate
> protocols across a firewall as compared with using a more fine grained
> web proxy, i can still by pass the proxy via "httptunnel" for example.
>
> So both proxy and firewall can be equally subverted internally via out
> bound traffic to a rogue service listening on a http port.

Any good administrator and/or log analysis tool can detect basic
tunnel tools such as "httptunnel".

While it's still possible to bypass the proxy, it's no longer nearly
as trivial as it once was.  Newer application proxies are doing true
Man In the Middle (MITM) against encrypted protocols such as SSL and
SSH, so even wrapping your protocol in TLS is no longer sufficient.

Squid doesn't have these particular features, yet.


> Second Point:
> also iptables could use its "string matching" to filter in appropriate
> sites that match content keywords or even based on a black-hole list.

While the difference between an "application proxy" and a "protocol
aware stateful inspection packet filter" is shrinking, there is still
a gap between the two types of products, generally the difference is
how much actual protocol awareness and state is in the security
gateway, and how high in the OSI stack the gateway can do rewriting
and remediation.

Also, I prefer a policy of "that which is not explicitly permitted is
denied by default, and repeated attempts to evade policy have swift
and non-trivial consequences."


> I guess I am still struggling to see any real benefits as of right now
> apart from the obvious web caching abilities but thats not what this
> discussion is about.

There are some specific benefits to using a non-transparent HTTP proxy
to funnel all HTTP protocol requests through a single specific port,
so applications which expect a browser to be able to establish a HTTP
session using non-standard TCP ports work without having to write a
custom filter rule for each, or just permit all possible outbound
ports.

For an extreme example of the benefits of application proxy over a
"smart" packet filter, take a look at the BalaBit Shell Control Box
(SCB), which intercepts and inspects SSH sessions, auditing behavior
and selectively enforcing policy, without the network administrator
needing to have any visibility into or control over the local policy
on the endpoint machines (the only other way I know of to have that
level of granularity and control over an encrypted tunnel).

Kevin

(P.S. Has anybody here actually deployed SCB?)
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards