> -----Original Message----- > From: Glenn Lovitz [mailto:[EMAIL PROTECTED]] > 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
The back door of jet an other way to transfer files (read programs, bugs, features, trojans, scripts, viri etc) Hence, jet an other path to check by virus scanners. > windows - cut and > paste is a pain to copy data where no ftp server exists. There is more file transfer than ftp: The smb protocol (aka: samba on unix, file sharing on M$Windows). Mail the files from the remote to the local account. If your server is on unix and the webserver is on, put your file in the .../vnc/classes/. directory (no subdirectory) and download it with your browser (http://vncserver:58##/filespec, exchange ## with your display number). Be warned, don't use .vnc estentions here, the will get mangled by the vnc-web-server. If no filetransfer is available between the machines, there is most likely a reason. > > > 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! You are right. The vnc user has no more access than the account they are logged into. BUT the vncserver does ont always run with the rights of the user. Specially if it runs as a service (M$Windows) or from inetd (unix) the vncserver has other (read: more) rights than the user. Then, if the network admins are not too bright, education is in order, specially for the users, they must know the risks as they are not properly protected. > > > 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. No, not increasing exposure, just using the available routes with the available protection. This includes a properly monitored port 21 and even a closed port 21. > The transfer is > no longer controlled by the rfb connections userid/password. How will > firewalling be more effective for port 21 than port 5900? I don't know firewalls that don't do port 21 with the ftp protocol. I don't know firewalls that do know ports 5900 - 59xx for the rfb protocol. Then, don't rely on the rfb userid/password (is there a userid??) > 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! So you say you already have proper tools to see and fight the atacs. At the moment you allow file transfer with jet an other protocol (read: vnc/rfb here) then you have to find, install and use similar tools for that other protocol too. Do you see your extra (doubled!) work here? > > 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. If you use vpn/ssh, both the vnc and the ftp sessions go trough that pipe. Properly configured vpn/ssh equipped access points don't allow other acces. > > 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! THe acceptance is in the restrictions of a telnet session: Only terminal access: text terminal and keyboard. Currently, I'd accept vnc on the same level since it does similar stuff and not more for a graphical console. > > 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! That's an other issue. What performance do you need? CBee _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
