CXO

Lock IT Down: Remote Assistance has issues with security and permissions

Before your help desk embraces Windows XPs Remote Assistance, examine your current network structure, consider the time involved in administering Remote Assistance, and evaluate the security implications.


Windows XP's Remote Assistance can be a dream come true for those of you who support remote users. It allows you to share control of an end user's computer via your organization's network or the Internet. You can view the user's screen, control their keyboard and pointer, and even communicate with the user via a chat feature. Yet XP's Remote Assistance isn't all sunshine and daisies. Several security concerns might make you think twice about using this feature.

It all begins with an invitation
The remote assistance process begins when the user who’s having the problem generates a Remote Assistance invitation. The invitation is basically a code that authorizes the person holding it to remotely control the PC that issued the invitation. After the user generates the invitation, they must send it to the help desk.

The invitation can be sent via e-mail or through an instant message. Invitations can also be dumped to a file, copied to a disk, and snail mailed to the help desk, or the file can be posted to a network directory or Exchange public folder. However, e-mail and instant messages are the customary methods for delivering such an invitation.

An invitation for trouble
Although the flexibility with which a user can transmit an invitation to the help desk makes the invitation a handy tool, there are some very serious security issues that this flexibility produces. For starters, users tend to be impatient. If the help desk takes too long to respond to the user’s problem, there’s nothing stopping the user from sending the invitation to someone else. For example, most large offices have an office "guru" who thinks he or she knows everything that there is to know about computers, and who manages to convince other employees that he or she can fix the problem. A frustrated employee who hasn't gotten immediate attention from the help desk could very well turn to such a person for help.

A user could also send a remote invitation to a friend who doesn’t even work for your organization. While this friend may be a bona fide computer expert, there’s always the possibility that the invitation could be used as a chance to gather information about your organization's network configuration. (However, you can prevent Remote Assistance from connecting to anyone outside your organization by simply blocking port 3389 on your firewall.)

Any time a user issues an invitation to someone other than the help desk staff, there’s a risk of that person deleting files, spreading viruses, uploading pirated software, etc. You may now be wondering, "What exactly can someone gain access to through Remote Assistance invitations?"

Stuck with the end user's permissions
The remote user has access to the exact same resources as the local user. This can be both a benefit and a hazard. The benefit is that the remote user can see exactly what’s going on without running into permissions problems. For example, a number of times, I’ve tried to help a user, but I wasn’t initially able to re-create the problem because it was related to insufficient permissions and I had administrative rights.

Another benefit of common permissions is that if you’ve done a good job of implementing a tough group policy, it should be impossible for a remote user to do anything to damage the system, because the remote user won’t be able to do anything that the local user doesn’t have permission to do.

On the other hand, common permissions can also prevent a support tech from being able to correct the problem because the local user may not have the necessary privileges.

Other means of managing Remote Assistance
Along with controlling inbound and outbound traffic on port 3389, there are other ways the IT department can control Remote Assistance. For example, administrators can disable Remote Assistance at the individual workstation. If your organization uses an Active Directory Windows 2000 Server environment, you can use group policies to manage Remote Assistance. These policies can:
  • Permit or prohibit users from requesting help via Remote Assistance.
  • Control whether users can request assistance from friends and/or coworkers or from the help desk only.
  • Control whether users can allow a helper to remotely control their computer or if the helper can just view the user's screen.

Plan before implementing
So what's the moral of the story? In a word, plan. Before your help desk embraces Windows XP's Remote Assistance, examine your current network structure, consider the time involved in administering Remote Assistance, and evaluate the security implications. As with any IT project, you should consider alternative products, such as pcAnywhere, Virtual Network Computing, and Microsoft's own Systems Management Server (SMS) or Remote Desktop, before making a final decision.

Taking control
Does your IT organization provide support through a remote control utility? If so, which one? What do you like and dislike about it? Post a comment to this article and let us know what you think.

 

Editor's Picks

Free Newsletters, In your Inbox