I would like to apologize to Chris Shenton and the rest of the readers of
this list for a previous post. My sarcasm had obviously gone too far. My
only excuse is that I feel very passionate about data conferencing and that
I hate to see it (or it's risks) misrepresented. So, again, I apologize.
Now, back to the issues Chris raised in regards to my post. I don't want to
quote them entirely so I'll summarize what I _think_ are his points and
address them individually (Chris, please correct me if I misinterpreted
these).
1. NetMeeting application collaboration is dangerous
2. There is no way to authenticate other participants in a NetMeeting
conference
3. An application proxy is the only way to protect a NetMeeting user
4. T.120 uses multiple ports
But first I want to address the notion that underlies Chris's assertions
about NetMeeting, particularly application collaboration. He seems to
suggest that because there are potential risks with application
collaboration you should not use it (or allow it to be used).
Granted, the things you could do with remote application control are pretty
nasty, Chris points them out quite well. However, if you read the article I
pointed you to in an earlier post (ok, another plug, it's at
http://www.cannell.org/larry/opinions/conferencing) you would have seen a
section where I talk about determining the value of a product. Everyone on
this list who read this should have immediately thought to themselves that
something was missing out of the value equation (which, in short, is Value =
Function/Cost).
What was missing was Risk. How does it fit? The best answer I can give is
that you must first quantify the value, then assess it against the risk.
Obviously, something which is low-risk/high-value is a no-brainer, do it. On
the other hand, anything high-risk/low-value is probably not a good idea.
Risk has to be assessed along with value and not simply viewed by itself.
There is much more to dealing with risk (such as determining proper
controls, etc.) but this is getting a little too far from the subject at
hand. Needless to say, my opinion is that NetMeeting poses very low risk and
provides enormous value.
1. NetMeeting application collaboration is dangerous
First, you must realize that NetMeeting supports interactive conferencing.
That means there are live people at each end of the line. A user has to take
two very distinct steps (in _every_ conference) to enable remote control of
an application. They first must share the app, then collaborate. This allows
others in the conference to take control of the window by double-clicking.
The owner of the window revoke control by hitting escape.
This is far from the risk associated with, say ActiveX, where an
unsuspecting victim might have turned controls off and suddenly has a rogue
program running on their computer. A NetMeeting user has to go out of their
way in _every conference_ to allow this risk to occur.
2. There is no way to authenticate other participants in a NetMeeting
conference.
True, the programs involved do not authenticate themselves. One exception is
a conference server. Participants must know the conference password to
enter. This is established by the conference organizer and distributed prior
to the meeting.
Also, in a business environment a telephone call is involved in the
conference (I suppose NetMeeting audio could be used, but we don't). How do
you authenticate your telephone conference calls? If you were really worried
that someone else had joined your conference couldn't you look at the
NetMeeting call roster? You could also ask the other party to type a word in
the chat window just to verify that the person you are talking with is
indeed the same person in your NetMeeting.
NetMeetings involving audio are inherently self-authenticating. It's just
not done programmatically.
3. An application proxy is the only way to protect a NetMeeting user.
Well, unfortunately, no T.120 proxies exist on the market today. Actually,
months ago, I saw references about PictureTel and DataBeam developing T.120
proxies but have yet to see a product on the market. Checkout this old
article in PC Week: http://www.zdnet.com/pcweek/reviews/0630/30collab.html.
It talks about a T.120 proxy disabling certain features in a conference
(such as application collaboration).
Lotus (which bought DataBeam) appears to refer to a proxy on their web page
at: http://www.lotus.com/home.nsf/tabs/sametime (take a look at the product
overview, it references a "unique proxy.")
However, there are also others ways to protect a NetMeeting user. Firewalls
and transparent proxy servers (ie. SOCKS or MS-Proxy) can restrict where
NetMeeting calls can be placed. User training and sensitivity to the type of
information they are sharing is also important.
4. T.120 uses multiple ports.
No, it doesn't. Microsoft's resource kit itself says T.120 only needs port
1503. This is the only port we allow through our firewall for calls to a
conference server. NetMeeting will also try to use H.323 setup on port 1720
to negotiate audio and video capabilities, but this is optional.
I have tested NetMeeting with an AutoSOCKS-ified winsock through a SOCKS
proxy server and watched it attempt to open a path on port 1720 (this was a
great exercise to learn how NetMeeting initiates calls). Since I didn't
allow this through the proxy server, it failed the socket connection and
reported back to the caller that "the person you are calling cannot support
audio and video (or something like that)". But the T.120 connection stayed
up and worked fine. These were calls initiated by double-clicking an ILS
user entry. NetMeeting probably assumes these to be direct calls to another
NetMeeting client and, hence, try to establish an H.323 session. Manual
calls to a conference server don't provoke this error message.
So how are we controlling our risk when using NetMeeting through firewalls
(I think Doris asked this question)?
- All external T.120 conferences require a conference server, no
point-to-point connections allowed. This gives us a single, manageable point
of contact for the conference.
- Only a limited number of conference servers are allowed connections
(someone has to approve the connection)
- Any conferences involving confidential data (current product plans, for
example) must be hosted on a "secured" server. We will configure our
firewalls to only allow connections to these from private network paths
(ANX, private point-to-point lines, etc.) but no secured conferences are
allowed over the Internet.
- We are not allowing connections to any external ILS servers.
I hope this helps explain my position regarding NetMeeting, firewalls, and
the risks involved with remote application control. I sincerely believe that
data conferencing is an incredibly powerful tool. It works with existing
equipment and runs on existing networks. Enabling this to work between a
manufacturer and supplier offers enormous cost saving opportunities.
NetMeeting has been very popular where I work and I suspect you firewall
admins will be asked to accommodate these conferences soon (if you haven�t
already).
--
Larry Cannell
[EMAIL PROTECTED]
--
Larry Cannell
http://www.cannell.org/larry
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
