On Tue, 16 Mar 1999 19:27:39 -0500, "Larry Cannell" <[EMAIL PROTECTED]> said:
Larry> Basically I think Mr. Shenton is a little too paranoid. Life is
Larry> full of risks and NetMeeting application collaboration is just
Larry> one more in a big long line of them. 'nuff said.
Well, when I wrote the paper at NASA we were really paranoid about
people finding out where the space aliens were kept so we couldn't
risk it. :-) I admit that H.323 and T.120 tools are useful, but
question how the proto is implemented. In the paper, in fact, I said
the H.323 audio/video presented no significant risk. It is the remote
control of people's desktops that poses the threat to the enterprise.
Ford might be a little concerned, for example, that their competitors
can exploit T.120 to get access to corporate LAN data through a
compromised NetMeeting desktop...
Larry> Mr. Shenton also basis his premises regarding H.323 and
Larry> firewalls on two usenet posts made by someone in Raptor.
Uh, there was a little more research than that -- including
discussions with MicroSoft NetMeeting product managers, MS's own docs
about how to configure your firewall ("open all ports above 1024, both
UDP and TCP"), reviews of anything I could find about those wonderful
OSI protocols (docs were not available on line from them).
I also tried a couple of gateway products and watched how they behaved
on the net. Unfortunately, they pretty much plumbed the traffic --
hostile or friendly -- right through into the corporate LAN. Not much
help there I'm afraid.
Larry> I don't recall all of the specifics now (and I will not read the
Larry> article again)
Oh, my...
Larry> If he had bothered to do his own research he would have found
Larry> that H.323 best traverses a firewall via an H.323 proxy.
Well, duh. It's just that implementing one was *extremely* difficult
due to the complexity of the protocol itself.
Sounds like you're letting your _a priori_ decision to use the product
prevent you from doing your own research -- more than just
reading the hype but finding out how it really behaves on your net
and what threat it might pose. You gotta understand the threat before
you can decide whether to accept the risk, whether the benefit is
worth it.
Larry> At the time I first read this article I couldn't find
Larry> any commercially available H.323 proxies but Intel did have
Larry> some nice articles on their website regaring the subject
Larry> (including a description of an H.323 proxy it had running in
Larry> their labs). Since then, however, H.323 proxies have showed up
Larry> on the market.
Yes, a few are *now* available. Had they been available when I wrote
the paper, I might have been able to evaluate how they mitigated the
security risk. But they weren't so I couldn't.
Larry> One notable product is PhonePatch available at
Larry> http://www.equival.com/ (best part, its cheap and runs under
Larry> Win95/98/NT, Linux, and Solaris). It's not strictly a h.323
Larry> proxy but it is still pretty cool!
Beware of proxies, filters, and such that essentially pass through
stuff unchecked. If the thing simply follows the port negotiation and
lets the traffic through without checking what's in it, then you're
still vulnerable to attacks based on the application. That's why I
like application layer firewalls with which you can can control
content: you could chose, for example, to allow H.323 but disallow
T.120, or better, allow read-only sharing an app but not world-writing
to the shared app. If you can't do this with your proxy, filter, or
whatever, then it's not helping you protect yourself.
Try the little exercise I mentioned in the paper. Share a Word doc to
someone outside your firewall, proxy, filter, or whatnot, and -- if
you'd use it this way -- let them write to your doc. Have them insert
an object, select a command.com/command.exe into the doc. Now they can
click on it and get a shell; have them delete a few dozen files from
your hard drive or LAN server. If they can do this, they can put a
sniffer on your LAN or do anything else you have rights to do. It only
takes a few seconds for the remote user to do this.
If you can block this hostile behavior with fine-grained controls on a
proxy then excellent -- good product. If you can't, then what good is
it? How is it protecting you?
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
