On Sun, 28 Mar 1999, Frank Knobbe wrote:
> 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'.
No, I deny the protocol from my internal network. It seems that you wish
to do the same. I'd allow it on a client out on an external network, but
my users wouldn't want to get off their butt to use it.
>
> 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.)
We'd probably end up in a better state as an industry if we did because
protocol designers would then be forced to consider the risks their
protocol brings to the table.
> 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
It's been my observation that without a thorough discussion of the negative
aspects of protocols many administrators make choices they wouldn't otherwise
make. That makes it a related issue and therefore in-charter. When you sign
up for a list, you end up with the opinions of people on the list. Procmail
is usually a good solution if you'd rather close your mind to the negative
aspects of what you're doing.
> 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,
I've done a cursorary analysis of the binary and it's behaviour, but didn't
go so far as to run it through any type of disassembly or call analysis.
The protocol just wasn't there and it succumbed to crude DoS attacks, add
in the remote execution risk and it wasn't worth persuing a full client
analysis.
> 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.
This was indeed one of the bigger issues in our thinking followed by some
local bandwidth issues on the target networks that wouldn't support the
client function amongst the necessary number of participants.
>
> 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 |
> +--------+
Depending on your firewall, you may wish to add another filtering layer 3
device between the firewall and the Citrix server. Having a layer 2 device on
the same network as a firewall interface can expose you to risks such as
packet leaking (significant especially for Solaris), attacks against
switching protocols (spanning tree and its cousins), and if "Firewall" ==
Firewall-1 potentially some protocol leakage into the internal network for a
subset of protocols that you'd rather not have attacking your internal
network. Any low-cost router with basic screening rules can protect from
this eventuality.
> 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
I've not analyzed the Citrix protocol to date, so you'll be left with
your own assessment of its weaknesses unless anyone else has anything to
share.
Also, our experiences with Citrix on the internal network hasn't been the
best testament to stability. If your test users can run for two days
without a reboot you're doing much better than ours are on certified
hardware (the current average is three boots a day.)
> 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
s/is/may be/
> 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.
You may want to test response. Even internally we weren't thrilled with
the traffic levels generated by the early releases. It may help to dual-home
both the Citrix server and the firewall to have exclusive in and outbound
interfaces (assuming Ethernet or FastEthernet not FDDI or Token-Ring) to take
away the collision domain on an interface if you get excessive collisons (it's
cheap for about a 40% bandwidth increase)
>
> 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.
Therefore it's not possible to secure the protocol. Remote display can
work, but it's prohibitively expensive to smaller shops, and can be an
administrative nightmare if the original machine configuration isn't very
exacting. I'm not in the habit of fielding compromisable machines even
on a service network. YPMV. You're also moving the trust issue to
another protocol which may, or may not be worthy of that trust, so it's
still not a definite win.
> 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...
Remote display has been beaten to near-death several times here as an
alternative. It sometimes presents a viable alternative (Bennett's
comments on the subject in conjunction with SSL spring to mind), but
sometimes just moves the problems over a protocol. It also does nothing to
address poor protocol design. While you might be more interested in winning
battles, I'd much rather win the war.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
