Response intertwined with original message: > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Jack Beglinger > Sent: Tuesday, December 10, 2002 8:13 AM > To: [EMAIL PROTECTED] > Subject: Re: Ultra VNC born (again)? > > I hope they do not add a new back door into the unix systems > as Ultra is > adding to its windows client.
What back door? File transfer ability would be nice for windows - cut and paste is a pain to copy data where no ftp server exists. > By adding this function, you > made it so > network admins will be forced to protect their systems by not > allowing *ANY* > traffic of VNC. It is hard enough to get them to agree to > allow desktop > access but to include a new vector to attack to steal > information though... > Where do security holes come into play? On any system, the VNC user has no more access than the account they are logged in to. Sounds like your network admins are not too bright and a little education is in order! > If Ultra installed (or RealVNC) installed with a option to > load a mini-FTP > server, then issue is lowered. Because is using a known > vector - firewalling > will work. Also for windows users FTP client has been > available in the > browsers. If by mini-ftp client you mean using port 21 and the ability to connect with any standard ftp client, then you are increasing exposure. The transfer is no longer controlled by the rfb connections userid/password. How will firewalling be more effective for port 21 than port 5900? Allow any on port 21 will get the windows machine probed by bots all the time and if you allow anonymous, watch out! I run 3 Unix ftp servers for my company using a very restricted ProFTPd setup that get many more invalid requests than valid ones. Checking my Xerror logs on Unix (before going to ssh), I have never seems any attempts from an unknown IP address to gain access! FTP is a known vector alright! > Lastly, if a company is support VPN/SSH tunnels - then two > traffics travel the same pipe. > If a company supports VPN/ssh, you should hope all data travels the same pipe! After all that's what it is for. WinVNC over ssh with a file transfer built in would be infinitely more desirable that running a clear text ftp session to port 21 directly. And technically it is still the same pipe (bandwidth) anyway, just less secure. I am now forced to run VNC over ssh into my servers and desktop from the internet - OK. Our external firewall does not allow any VNC traffic. Yet the auditors and network admins have no problem with allowing telnet (port 23) with external access. When they locked down VNC, I argued that although the VNC password is sent with fairly weak encryption for challenge/response, telnet is a far more significant exposure. But like your guys, because it is a "known vector", telnet was deemed an acceptable risk! I am not really complaining about running over ssh as it really is the right thing to do. It caused me a bit of work to set up and I now have a floppy I carry with me that runs a script that puts my puTTY defaults into the registry, starts puTTY, then removes the puTTY session from the registry when I close the client if I'm on a "foreign" PC. > So why rebuild the wheel? And possible close VNC ports for an added > function that already exists? > Hopefully the wheel will remain the same -- I think they are just changing the tread pattern to get better performance! Regards, Glenn _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
