-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: Paul D. Robertson [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, March 28, 1999 9:29 AM
> To: Frank Knobbe
> Cc: '[EMAIL PROTECTED]'; Firewall List
> Subject: RE: Netmeeting
Paul,
you seem to read too much between the lines. I never said I want to
leave the risk at the end user, I never said that I defend NetMeeting.
Let me try to explain one last time:
Our discussions and judgements should not just focus on the protocols
but review the implementation of the discussed
requirement/application.
According to your reasoning, you see the security risks with
NetMeeting in the protocols its using. For that reason, you deny
NetMeeting any chance of discussion. You come down to 'Protocol
flawed, Application out of question. Period'.
This is exactly that kind of reasoning that got me to started on this
thread. In my opinion, its a very arrogant attitude. If every list
members would behave like this, then we would have the 'Firewalls
Discussion List' successfully converted into a voting ballot for
protocols. (User1: What about NetMeeting? User2: Don't use it, to
unsecure. User3: Yeah, protocol sucks. Etc.)
This list charter reads: The Firewalls mailing list is for discussions
of Internet firewall security systems and related issues. Relevant
topics include the design, construction, operation, maintenance, and
philosophy of Internet firewall security systems.
In other words we can discuss the design and philosophy of a
NetMeeting implementation. I don't want to hear 'No, don't use it. I
don't use it either.' If you don't have a suggestion on how to
securely implement NetMeeting, then don't post. Again, I'm not trying
to defend NetMeeting, I'm trying to defend the approach.
Following brought you back on track in your reply.
> [...]
> Tunneling application data streams places the security burden on the
> applicaiton. How much analysis of NetMeeting's application
> code have you
> done?
None. How much have you or anyone else out there done? In my opinion,
NetMeetings main risk is remote application sharing. Even if the code
turns out ok, without any bugs and back doors, there is still the risk
of users executing uploaded code. This can happen very quickly. A
macro virus or even an executable, that the attacker carries in his
clip board, can quickly be pasted and executed on the users end.
Depending on deception techniques even without the users knowledge.
The second risk that comes with NetMeeting is the requirements of
opening port on the firewall.
Now, can NetMeeting still be implemented securely without the user
having to move to a different workstation? Yes, I think so. Here is my
proposal:
+----------+
| Internet |
+----------+
|
Router
| +--DMZ Server, i.e. Mail
Firewall---|
| +--NetMeeting Server
+--------+
|Internal|
|Network |
+--------+
NetMeeting Server: Windows NT Terminal Server, Citrix MetaFrame
Add-On, NetMeeting. Local User accounts different from internal
accounts.
Firewall rules (S/D/Serv/Cond)
Internet / NetMeeting Server / 1494 TCP / Deny
Internet / NetMeeting Server / 1024 - 65535 TCP / Allow
Internet / NetMeeting Server / 1024 - 65535 UDP / Allow
Internet / NetMeeting Server / 389 TCP / Allow
Internet / NetMeeting Server / 522 TCP / Allow
Internal Net / NetMeeting Server / 1494 TCP / Allow
Imagine return paths enabled. (i.e. NM servers 1494 back into Internal
Net)
The idea is that any user of the internal network can execute the
NetMeeting application residing on the TS in the DMZ. The only
protocol that has to be allowed through the firewall is Citrix ICA
protocol (1494 TCP). TS is configured not to map to client drives and
printers, so there is no network connectivity between the NM server
and the internal network. The only thing that gets transmitted is
video/mouse/keyboard/audio via the ICA protocol. Should the NetMeeting
Server be compromised by an unknown vulnerability in the T.120
protocol or (more likely) malicious code executed (i.e. netcat
listening on 6000), the internal network is still protected since no
other route back into network exist. Above configuration lets you log
IP addresses for intrusion response purposes, but not session content.
However, once the server is compromised, it may be quarantined and
examined. This server may even replace your existing honey pot.
Disadvantages are: Shared applications need to reside on TS. Should
not be an issue with general purpose apps. However, maintenance of
these apps may be cumbersome. Also, documents to be shared need to be
uploaded separately (i.e. FTP). Audio should work with latest ICA
client, but video may not be available. However, for whiteboarding and
application sharing, this should suffice.
As you can see it is possible to securely implement NetMeeting, even
though the protocols used by it are not fit for transport back into
the corporate network.
If folks would just discuss alternatives instead of disregarding a
discussion based on their opinion of the protocol used, then this list
may see a higher volume once again (It's been relatively quite
lately). This would also give the list a higher value, because folks
can train creativity and approach methods. As of now, the list
transfers existing information (about protocols or firewall setups).
It would be nice if it would also give the member the opportunity to
collectively create new information such as design and implementation
strategies...
Final Regards,
Frank
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2
Comment: PGP encrypted email preferred
iQA/AwUBNv8CHilma9DCzQQeEQLTSQCfdb74bA23BR2IHWzE3rC2UdiREuwAniZf
sOZqWQa5i2evuVHva5c6YzSN
=3n3g
-----END PGP SIGNATURE-----
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
