[Webinar] Streamline your web hosting managementRegister Today

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1045
  • Last Modified:

VNC inside my LAN for W2K Pro Remote Access?

Hello all.  I am evaluating remote access options for Windows 2000 Professional clients inside my LAN.  

I was wondering from a security standpoint if it would be safe to install WinVNC Server as a service on these PCs and then just simply disable the service from starting up when the PC boots.  Then, when I need to access the PC, I can just login via a remote command prompt (psservice) and start the VNC service.  I'll do my work on the remote system from the VNC client on my WinXP laptop, log out, and then stop the service.

Does working through VNC this way still pose security risks?  I would imagine that leaving the service running at all times on a client PC is much more dangerous.  Can anyone outline the security risks of running it this way?  This is a basic Windows Server LAN with a perimeter firewall and NAT'd router.

Thanks in advance everyone!

  • 3
  • 2
1 Solution
CHANGE ALL YOUR PASSWORDS FREQUENTLY!  This is especially true of the vncserver password since they are traveling the net in pure text ( nonencrypted) form.
Change the password often or routinely shut down the vncserver at the end of the session.
If installing vnc on multiple desktops use different passwords for each one. That way it should be slightly harder for somebody to break in. And no, using the machine name isn’t usually a good idea

Making VNC more secure using SSH ( http://www.uk.research.att.com/archive/vnc/sshvnc.html )
We therefore recommend that if security is important to you, you 'tunnel' the VNC protocol through some more secure channel such as SSH.
Tunneling Windows NT VNC traffic with SSH2

You might wish to try UltraVNC which has MS Logon/NT security support. You can manage server access using MS Users,
Domains and Groups. It also includes a logging feature where all actions are written to a log file.

good luck

heatfan07Author Commented:
Thanks nedvis!  I also want to clarify from my original post that this topic is only related to VNC from one PC inside a LAN to another PC inside a LAN.  I am not planning on accessing these client PC via VNC from outside my LAN.

Questions are:

1) Does working through VNC this way (PC to PC inside LAN) still pose security risks?

2) Can anyone outline the security risks of running it this way? (PC to PC inside LAN)

Thanks again!
Rich RumbleSecurity SamuraiCommented:
These are the "insecurities" of vnc in it's native/default state, I am going by the old vnc from At&t, the new vnc's from RealVNC and TightVNC
WinVNC, TIghtVNC and RealVNC are all free, rather offer free server/client programs

VNC transmissions are plain-text. With the newer clients they may be compressed, but still not encrypted. TightVNC can automatically use SSH as an encrypted tunnel when used with unix/linux machines. But on windows, tightvnc simply uses compression when it can, but with some other tools any vnc client/server can use ssh as a tunnel.
RealVNC is the offical maintainer of the "old" At&t lab's VNC (aka winvnc) RealVNC offers a security enhanced version with a small cost for licenses, 50$ for a single license, and 390$ for 10 lic... etc
RealVNC still has the free version, and all of these, WinVnc,RealVnc,TightVnc all seem to play nice together, the server client's and the viewer clients are interoptable and work equally well on a Lan, but again, the free versions are not encrypted in anyway, so usernames and password typed into logon screens are sniffable to a certain degree.

The remote registry service is actually a security flaw that pertains to all VNC itterations, as to keep interoptability working, they all store 8 char maximum lenght passwords. These password values are encoded with 128-bit Triple-Des encryption, however, the flaw is that the same key is used each time a password is encrypted, and reversing the password by obtaining the "hash" from the registry is very easy and some tools such as Cain&Abel automate finding the regisry key, but it's always in the same place anyway and has a sniffer looking specifically for the VNC password exchange. If you have linux you can still find VNCDEC.C to decode vnc password using gcc, just get the hash from the registry and edit vncdec.c in the proper spot. Looks like people are automating it also for win32 now using vncdec.c
gcc vncdec.c

VNC can also be done using internet explorer, open IE, type in the pc name or ip followed by colon 5800 and now your using java to view the desktop. Note, on IE, you have to include http:// along with the ip or host name when specifing a port other than 80
http://some_pc:5800    or

Those are the risks of vnc in a nutshell. The password is simple to reverse, and even simpler to obtain, even a null session can allow you access to another registry if the remote registry service is turned on. And the info is Plain-Text, but might be compressed to obusifcate the data somewhat, but it's not keystrokes that are compressed typically, so you see those no problem.

Again the transmissions are PT when using the browser, and they certainly don't benefit from any compression as far as I can tell.
I think nedvis outlined how to secure the traffic pretty well, if you tunnel over ssh, you should be all set, but still disable remote registry service, or set the proper permissions on the ORL registry entry so that unauthorized users can't view anything beyond that key (HKLM\software\orl\vnc... i think it is)
I'll have a look at ulta-vnc, and report a flaw or two if I find them.
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!


I think the answer ( at least partial) can be found here:
"You should firewall VNC off at the desktop and router/gateway level. If anybody from outside your business can connect, then it’s only a matter of time before somebody will brute-force their way in"

So you can probably block all inbound traffic and requests sent to (VNC) port  5800 on your router/internet gateway.
Other thing you could do is to configure VNC servers to listen to incoming requests on nonstandard ports ( for instance 4560 or any other port)
Plus, you should bind the VNC service only to your intranet network class IP adresses  ( e.g. ) .
Besides that you can configure personal firewalls on each workstation to accept only  VNC viewer requests from a range of IP addresses  e.g. IP addresses range from  to All other IP addresses from the same Class C as well as VNC viewer requests from other ( Class A and Class B) networks should be rejected by firewalls.
I dont think running VNC services inside LAN will pose hight risk to your PC.
good luck
heatfan07Author Commented:
Thanks for these ideas nedvis.
Thank you!
BTW, I'm running UltraVNC on my daughters Windows2000 24/7 since we used to share dial-up connection through Proxy+ server services installed on all my home computers ( 3 desktops + laptop). They all know how to connect to remote systems ( in other room) VNC servers and connect gateway pc to internet and then reset their browser proxy settings. And so far none of my Win2k machine was rooted!
I used to connect from my home to the workstation at work ( they have cable modem) each time I have to download big Linux iso files ( I'm Linux fan too) again thanks to UltraVNC. How long that game's gonna last , I don't know but chances are : hackers have to assume there is VNC server running on attacked/monitored/targeted machine, they have to know what port I'm using as well as display number and password.
Not very easy to crack!
Also I have Sygate 5 personal firewall as well as PrevX Home intrusion detection installed on all my computers.


Featured Post

Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now