Some of us would really like to know what the risks are with Netmeeting. We
get requests for it frequently - through the firewall, and would like a
configuration that would allow that, but haven't found a secure way to do it
yet...
-----Original Message-----
From: Chris Malott [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 10, 2001 5:39 PM
To: Michael T. Babcock; Paul D. Robertson
Cc: Firewalls (E-mail)
Subject: Re: Microsoft Netmeeting
This crap is freakin pathetic. Can we please get to the subject? If an
individual wants to be stupid and argue without basis, or with, don't let it
get to you. That person will find out in there own right how #*$#n stupid
they are.
Enough Said,
Chris Malott
Chameleon Communications
GeEK
----- Original Message -----
From: "Michael T. Babcock" <[EMAIL PROTECTED]>
To: "Paul D. Robertson" <[EMAIL PROTECTED]>
Cc: "Scott Overfield" <[EMAIL PROTECTED]>; "Firewalls (E-mail)"
<[EMAIL PROTECTED]>
Sent: Thursday, May 10, 2001 12:37 PM
Subject: Re: Microsoft Netmeeting
> 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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
