I'm happy to hear discussions regarding security of VNC. though I'm not in agreement with some of the original authors statements.
Some points to consider: - security should always be considered with use of any application, knowledge, technology, and process are important factors with respect to security - security with respect to ability to transfer files may be a concern, but thought should be given as how the application is distributed to users. If you are concerned about file transfers, consider giving users only viewer application and have them execute it only in listen mode if technical support is required. - Keep in mind that VNC like many application do not have to be used on the default ports. VNC can be moved to a different port other than 5800/5900, so blocking these ports on a firewall may not work. Security should be aware of applications used and the respective data flows. - Agreed. Active virus scanners with regular virus definition files are a good security measure. - if you are concerned about firewalls letting certain traffic through based only on state, port, direction, then possibly consider a proxy based firewall (may provide better protection). - if you are concerned about inbound file transfer, then disable SMB listening ports on systems 136-139, 445. Disable default admin shares. Install a workstation based firewall like ZoneAlarm, TinyFirewall, etc. This will at least alert the user to inbound connections. My few cents worth. Frank Pikelner Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: December 11, 2002 7:00 AM To: [EMAIL PROTECTED] Subject: VNC-List digest, Vol 1 #324 - 1 msg Send VNC-List mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://www.realvnc.com/mailman/listinfo/vnc-list or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of VNC-List digest..." Today's Topics: 1. RE: Ultra VNC born (again)? (=?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?=) --__--__-- Message: 1 From: =?iso-8859-1?Q?=22Beerse=2C_Corn=E9=22?= <[EMAIL PROTECTED]> To: "'Glenn Lovitz'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: RE: Ultra VNC born (again)? Date: Wed, 11 Dec 2002 10:43:42 +0100 > -----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 End of VNC-List Digest _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
