Hello Paul,
Thank you for your complete answer.
> > For the FW part, this doesn't seem to difficult : they should know which
>
> You mean 'packet filter' part, proxies are firewalls too.
Yes you are right. I lose my latin which so many confusing technics ;)
...
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.
I very well understand your point. But what if you wanted to developp a new
product which needed C/S communication over the Internet? What would be the
less "damageable" choices?
I understand it is not so much a protocol problem as an application problem
: can you trust an application which may receive informations (i.e. commands
maybe) from outside the innocent protected world?
> How much security does the protocol have? How much security does
> the client
...
> trying to tunnel over HTTP.
...
> > 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!
Ok, ok, ... not as a canonical case maybe... ;)
> 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.
but if our application only open a TCP port on a distant server, do we still
need a specific proxy? (OK, a proxy is still needed if we want to be able to
control the contents of the flow)
> > - 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.
OK for the client side but I meant a framework (an interface, dll, libs,
...) in which we could develop our specific proxy so that it can be plugged
in different FW solutions.
...
> 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.
sorry for my ignorance but what is a "WKS"
> That's a lesson that's been learned the hard way with RealAudio and lots
> of other protocols.
Could you tell me a bit more about the "RealAudio lesson" learnt the hard
way? Thank you.
...
> > 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.
yes but it involves having the client software available for every specific
platform.
Still a basic question for you : does client socks libraries directly relate
to the use of proxies or not?
Thank you for your help. Cheers,
Sacha
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
