This is getting stupid. You're ignoring the points I'm making entirely
and trying to state things that are either baseless assumptions on your
part or you've discovered through some process you haven't mentioned.
When you make points like you have in this thread, you must either back
them up or just not make them. Stating that H323 is a chest wound was
such a point. You have given no evidence, anecdotal or even conceptual,
that it is the smallest security risk.
On 10 May 2001 15:00:32 -0400, Paul D. Robertson wrote:
> > And what evidence do you have that any streaming protocol is a security
> > risk, since you harp on them?
>
> The same evidence that makes HTTP a security risk with tunneling- lack of
> ability to control what gets passed and detect and stop things which abuse
> the channel. Added to the fact that the protocols are based on
> throughput, and therefore designed to be passed quickly, not inspected.
You're mistaken. A) I do full inspection of _all_ streams coming into
my network. This is almost always possible. Video teleconferencing
doesn't use anywhere near the bandwidth that conxion.com does for FTP
traffic, and FTP has known security problems in some circumstances.
The ability of a protocol to kill your network is based on several
factors. Being a high-bandwidth application is almost never included
(unless you can't afford, or just aren't willing to put high-speed NIDS
on your firewall(s) and/or routers).
The only problem you've given in H323 is the possibility that a given
application that supports H232 might have a bug in it that would allow
an outside attacker into your network. This is a problem with the
software, and a reason to install security measures on workstations and
LANs such as outgoing connection filtering, monitoring of open ports on
workstations, etc. Users running ICQ with the built-in web server
scares me a lot more than picking a random streaming protocol and
letting it jump through my firewall, especially when its stateful (on
TCP) and allows me to monitor every connection.
> > Oh? Would you mind reading up on how H323 gatewaying works and come
> > back later?
You ignored this point.
> Oh, would you mind contacting a dozen firewall vendors and finding out how
> much inspection of the content goes on?
That would be an issue for the design and selection of your firewall.
If your firewall doesn't meet your needs, that's a firewall issue. It
may mean that you decide to not deploy video teleconferencing within
your enterprise. However, that does not make video teleconferencing a
'chest wound', it makes your firewall's ability to do inspection poor.
> > And how do you propose that anything be proxied over H323?
>
> The same way it's done via HTTP or DNS, but with the larger ammount of
> data required by streaming media, detection will be more difficult than it
> is with DNS and potentially HTTP.
So, you don't understand the question.
> I look at more than one implementation when measuring interoperability,
> and I've specificly given the timeframe that I was looking in detail at
> the protocol and product.
You also specifically stated your areas of ignorance w.r.t. the product
and the protocol. I addressed those.
> Most people don't even *know* that they need ancillary encryption because
> the marketing collarteral doesn't contain exceptions.
Why does that make H323 a 'chest wound'? It means your network admins
are perhaps lunk-heads (not too much offense intended). I use PGP for
all my private E-mail communications and VPNs between my home computer
and contract locations as well as VPNs between customers' facilities. I
have them redirect all inter-department traffic that would go over the
Internet (like E-mail) go through their VPN connections instead. These
are security decisions that require that one take into account what type
of traffic is going over a protocol (like E-mail or video or audio), but
they do not make those protocols good or bad. If you want a _bad_
protocol for security, take a look at DNS AXFRs ... and they're done all
the time by companies who should know better.
> Because the range of ports is obviously not covered by the "standard
> H.323 application." So much for the standards argument.
Obviously? Where'd you see that? That's a nice piece of assuming on
your part. You still didn't refer to the documentation I mentioned did
you? With H323, you can set up a gateway in your DMZ that accepts all
incoming traffic for your clients. Microsoft may not have such a
product and therefore doesn't talk about it, but they'll admit it exists
as soon as MS Proxy Server supports it. NT can't masquerade ICMP for a
private network ... that doesn't mean that you _can't_ ping from inside
a private network to the Internet. It just means you chose the wrong
tool.
> Just because you don't agree with the perspective doesn't mean I haven't
> evaluated the application. Your idea of risk management is obviously
> significantly different than mine. I've never been a fan of "open wide
> and swallow."
My idea of risk management is to understand what the protocols do, and
what the potential implications are. I then must take into account the
necessity or desirability of the functionality that the protocol
provides. Hacks and work-arounds are acceptable (like masquerading or
'invisible' firewalling bridges with a real-time NIDS on them) if they
allow me to provide a client with the functionality they need within the
security parameters they have.
If you want perfect levels of security, don't use the Internet.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
