Re: VNC Security

[Alexandre Zglav <azglav () heritage ch>]

Hi all,

Aside from SSH tunneling, do you think that there would be a way to use
regular SSL to encrypt the vnc stream between two computers ? Or maybe
something more complicated such as RSA and securid autentication ? I
thinking of this in the purpose of offering remote assistance services for
a wide set of users. Such a practice would require me to sufficiently
secure the stream between my help desk center and my users whilst I cannot
afford to spend too much time explaining port forwarding and SSH etc ...

Thanks


________________________________________________

IT Projects
Alexandre Zglav
Heritage Bank & Trust
12 cours des bastions
P.O. Box 3341
1211 Geneva
Switzerland
Phone :  ++ 41 22 817 31 11
Direct Line : ++41 22 817 32 21
azglav () heritage ch
www.heritage.ch
________________________________________________




                                                                                                                        
           
                      Bart Crijns                                                                                       
           
                      <gorby () skynet be>        To:       Andy Bruce - softwareAB <andy () softwareab net>            
                 
                                               cc:       Steve Bostedor <Steveb () tshore com>, security-basics () 
securityfocus com,    
                      19.04.05 23:15            vnc-list () realvnc com                                                 
              
                                               Subject:  Re: VNC Security                                               
           
                                                                                                                        
           




Andy Bruce - softwareAB wrote:

> 5. Tell them to turn off port forwarding from the router (if they
> could grok it), or just have them connect their PC back to the router
> and their router back to the cable/dsl modem. In either case, 5900
> isn't available to the outside world so there's no risk even if they
> were running VNC in service-mode.

Another (very easy) way to make these connections more secure with those
users is the following:
I'm using UltraVNC, so I'm not certain that everything is possible in
other VNC variants.
- set a very long and very difficult password for the server (it will
never be used anyway in this approach)
- disable the 'accept socket connections' checkbox in the server
properties (may be UltraVNC only)
- when the users need assistance let them start the server, and instead
of connecting to their PC, you start the viewer in listen mode
- tell them your IP, and have them add a client throug the system tray
icon's menu, and have them enter your IP when requested.
You'll need to have your router setup for port forwarding to the ports
for the listening viewer...

That way noone needs to know their password, and with UltraVNC the
server isn't even accepting connections in the unlikely event that the
password is known by someone. No password is transmitted, and the only
thing that could be captured is the data sent during the VNC session,
which isn't too much of a problem in most cases when helping someone out.
Furthermore, no incoming ports need to be opened on their router,
because most users aren't really capable of changing that themselves.

Of course, when connecting to my own PC via VNC, I use a SSH tunnel.


> Am I missing something here?

Other than the fact that in the unlikely event of someone malignant
actually taking over their PC, you'll be the one who's blamed... no :-)
I think the method I described is a bit safer, and also very easy to
explain to the person at the other end of the line. If I may have missed
something in my plan, please correct me.


Kind Regards,
    Bart Crijns






E-mail contains confidential information or information belonging to Heritage Bank & Trust (hereafter "HBT") and is 
intended solely for the addressees. Any views or opinions contained in this message are solely those of the author, and 
do not necessarily represent those of HBT, unless otherwise specifically stated and subject to the sender being 
authorised to express such view or opinion.The unauthorised disclosure, use, dissemination or copying of this e-mail, 
or anyinformation it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be 
guaranteed. Internet communications are not secured, therefore HBT shall not be liable for this e-mail if modified or 
falsified. If you are not the intended recipient of this e-mail, please delete it immediately and notify the sender of 
the wrong delivery. This message is for informational purposes and should not be construed as a solicitation or offer 
to buy or sell any securities, investments or related f
 inancial instruments.