On Thu, 23 Sep 1999, Sacha Labourey wrote:
> For the FW part, this doesn't seem to difficult : they should know which
You mean 'packet filter' part, proxies are firewalls too.
> ports they use, when, ... They can tell their users how to deal with this
> new protocol relatively easily.
That doesn't mean it's a good idea though. Product developers are
constantly expecting firewall admins to pass new protocols without any
good reason. Per-application protocols are *not* generally a good idea
for firewalls to pass, as it's very difficult to add additional
protection if each application uses a different protocol. IMO there
should be an especially compelling _security reason_ for a new protocol
to go through a firewall. In other words, it should be compelling
because of a security enhancement, not because of an application unless
it's an application that will bring so much value to my business that I'm
compelled to re-architect my security model to support it.
How much security does the protocol have? How much security does the client
application have? Is it well-written to be secure without buffer
overflows, dynamic system calls, etc.? What about the server code and
configuration? Is passing this new protocol going to open up more risk
to a tunnel attack, and if so why should I pass it? HTTP is bad enough
(FTP is about the only protocol that sucks more- and it's debatable), why
should I open yet another attack vector into my network? Without a compelling
reason, you're better off doing like everyone else who's hit that wall and
trying to tunnel over HTTP.
Note that "security" for the protocol *does NOT mean* 'pass an encrytped
tunnel from the client to the external server so there is no possibility of
trending, analysis or intrusion detection (HTTPS is the suckiest varient
of HTTP).
Protocol flexibility and the ability to secure a protocol are at odds.
> Concerning the proxy, I think we have two cases :
> 1) Hybrids FW-Proxy products (like MS Proxy) : same case as above
This depends on the local security policy, though I'd hardly raise MS
Proxy as a canonical case of a hybrid firewall! Hybrids exist because
some sites still want to have conservative security stances that ensure
they've got some measure of application-layer protection for their
networks while being able to make local per-application exceptions to
that model.
> My questions are for this second point :
> - do you know such pure proxy to test against?
Proxies must be written to handle the application protocol. A new
protocol won't go through a proxy solution without having an application
proxy written specifically for it. In firewalling terms, that's a major
advantage, as it keeps traffic between the somewhat-protected network and
the Internet restricted to a small subset of possible traffic. That
makes it easier to do things like trending and analysis on the traffic.
> - do you have some advice on how to develop a protocol easy to "proxy"?
You have to make a secure, well-written reference proxy available that will
compile on multiple operating systems.
> - does it exist a standard framework to develop a proxy service for a
> protocol which could then be used in more than one proxy product?
Nope, proxies by definition are supposed to be application-protocol
aware, they should combine both the client and server edge code of the
application with some data-checking enforcement.
> - do you have special advice concerning this kind of problem (new protocol
> and proxies)?
Steer clear of new protocols if you want widespread acceptance. If it's
compelling enough an application, stick to TCP to a single WKS port on
the server so it can be tunneled through something like plug-gw.
That's a lesson that's been learned the hard way with RealAudio and lots
of other protocols.
If you're going to tunnel it and you want to get on the good side of
firewall administrators, make it easy to identify in the tunnel. We'll
probably want to be able to block it no matter what.
For me to pass a new protocol through my firewall, it'd take-
(1) An in-depth analysis of the protocol, client and server interaction to
assess the risk of attacks I'd be taking.
(2) A high level of assurance that the client and server code had been
through a well-done security audit *and* the fact that the code hadn't
been written using a lot of toolkits, 4GLs, or common object libs.
(3) A reference implementation of a proxy that did more than check for
the existance of a string in the data stream and also provided some
measure of application, client, and user-level configuration and
protection.
(4) A very compelling business need that couldn't be met in an already
approved way, or a better way all-together.
So far, there has yet to be a vendor who's met my tests and provided enough
assurance to get me to modify my firewall for a single application over a
new protocol. In fact, there aren't many who've gotten me to do it for
an existing protocol and a new client. The closest was a compelling
business argument for ReadAudio a few years ago, but the protocol sucked
too much and I didn't feel that the reference proxy did enough to ensure
it was actually a valid datastream. We didn't even get to the client
questions stage.
> P.S. : do you know some good working true transparent proxies?
Most commercial firewalls that offer proxy protection have transparency
available. Not everyone will use it though - transparancy just means the
firewall intercepts the traffic and directs it to the proxy instead of
the client having to know about the proxy's address. It's a much better
idea to leave the option in the client, since that covers all cases.
Also, there used to exist some patches for the FWTK under Linux to do
transparancy - no idea if they'll work with a recent kernel though. Most
transparent HTTP solutions make it rather trivial to hijack the
datastream by adding a malicious proxy setting to the client.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
