Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Remote Security
Since the ability to take over someone’s computer and run it remotely is the Holy Grail of computer criminals, vandals, and other assorted cyber-lowlifes, remote control software needs excellent security.
VNC is a particular security concern. The original versions of VNC weren’t secure at all, and some of the products based on VNC are still very insecure. The big concern with VNC is hijacking. In theory, a host with VNC software installed can be connected to any VNC guest. To prevent this nightmare, VNC should be protected by a password-and-authentication scheme.
VNC-based remote control products differ widely in how thoroughly they’re protected. For example, RealVNC, from the people who originally wrote VNC, comes in several versions. The commercial versions come with strong password and authentication features; but the free version, VNC Free Edition, uses only a simple eight-letter password. RealVNC advises that VNC Free is only suitable for use over local networks or secure VPNs.
One useful—but hardly sufficient!—security method is positive permission. Someone sitting at the computer has to specifically authorize its remote use. Microsoft calls this feature Remote Assistance Permission Required, and it cannot be disabled on Microsoft products.
Data also needs to be protected in transit between the computers, especially over the Internet. Many products, such as UltraVNC, can encrypt the link between the computers.
When setting up remote control software, less is definitely more—security, that is. You want the remote system to have the minimum access necessary to do the job. This is especially true of access to other resources on the network or over the Internet. The permissions granted the remote control software should be set accordingly. For example, unless you absolutely need the host system to run unattended, you should insist on user permission from the host system for every session, using a feature like Windows’ Remote Assistance Permission Required. Needless to say, most Help Desk applications shouldn’t need unattended operation.
Likewise, unless you need it, you should block remote control access to your host systems over the Internet. If you’re not careful, giving remote control software Internet access can open security holes in your firewall that can be used to do all kinds of bad things without ever touching the host.
If possible, the host shouldn’t accept connections from just any guest. Some vendors embed customer-specific keys in their products so that guest-host interaction can be restricted to those with specific keys. CrossTec’s NetOp Remote Control lets administrators register both guests and hosts in its security server and assign specific privileges to each.
You should log your sessions. If your remote control product has a logging feature, make sure that it’s enabled. Ideally, both host and guest should maintain separate logs of remote control sessions. This won’t prevent the bad guy from getting the horse, but it will tell you when the barn door is open.
Likewise, your remote control software should have authentication features so that both parties can be sure who they’re dealing with. One simple additional authentication method is to require that all Help Desk interactions start with a phone call from the user to the Help Desk, even if the Help Desk and user will communicate by chat while the session is in progress.