> -----Original Message-----
> From: David Lang [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 11 May 2001 07:19
> To: Michael "T." Babcock
> Cc: Paul "D." Robertson; Scott Overfield; Firewalls "(E-mail)
> Subject: Re: Microsoft Netmeeting
<snip>
>
> the point that was being made was that no firewall did very
> much checking
> of this protocol.
>
> if you have one that does more extensive checking, let us know.
Maybe Paul should start off by stating the ones that he knows do very little
checking, and qualify it with a date at which he knew that info to be
correct....
Cheers,
Alex Hague
>
> David Lang
>
> On 10 May 2001, Michael "T." Babcock wrote:
>
> > Date: 10 May 2001 15:37:55 -0400
> > From: Michael "T." Babcock <[EMAIL PROTECTED]>
> > To: Paul "D." Robertson <[EMAIL PROTECTED]>
> > Cc: Scott Overfield <[EMAIL PROTECTED]>,
> > "Firewalls \"(E-mail)" <[EMAIL PROTECTED]>
> > 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.]
