Security During Remote Debugging
There are two ways to increase security during remote debugging: by restricting who can connect to your session and by restricting the powers of someone who does connect.
If you are using the TCP, 1394, COM, or named pipe protocols, you can require the Debugging Client to supply a password. However, this password is not encrypted during transmission, and therefore these protocols are not secure.
If you want your Debugging Server to be secure, you must use secure sockets layer (SSL) or secure pipe (SPIPE) protocol.
If you are performing remote debugging through remote.exe, you can use the /u parameter to prohibit connections from unauthorized users.
If you are setting up a kernel-mode debugging session, you can restrict the debugger's ability to interfere with the host machine by using Secure Mode.
In user mode, Secure Mode is not available. You can stop an intrusive client from issuing Microsoft MS-DOS commands and running external programs by issuing the .noshell (Prohibit Shell Commands) command. However, there are many other ways for a client to interfere with your computer.
Note that both Secure Mode and .noshell will prevent both the Debugging Client and the Debugging Server from taking certain actions. There is no way to place a restriction on the client but not on the server.
When you start a process server on a remote machine, the process server runs silently.
If you perform remote debugging through this process server and then end the session, the process server continues to run.
A forgotten process server is a potential target for an attack. You should always shut down an unneeded process server. Use the Kill.exe utility or Task Manager to terminate the process server.