My observations on virus vulnerability if RDP drive redirection is enabled is
this:
First, RDP runs on encyrption, much like HTTPS. It is the network
administrator of the domain who configures just what encyrption level will be
for each and every class of RDP clients [class meaning a novel client versus
a windows TCP client, for example.] So the encryption for RDP 5.0 and
higher, such as released with Windows XP, can be set as high as 128-bit and
no virus can traverse such a connection.
The risk of infection is simply in file transfer ability on open shares. In
the case of RDP, it is the VPN connection where there is a potential risk.
The largest concern is a worm that can replicate over open shares on a
network and / or take advantage of a security vulnerability. For a domain
network, the risk is greater for a worm as long as the worm is able to get
inside the domain first. Any remote computer accessing a network that is not
on the domain will not authenticate to any resource automatically. A remote
user must manually authenticate for each and ever server or machine being
accessed remotely unless a utlity is used to automatically authenticate such
as setting up a remote computer as a trusted resource to the domain. So the
risk for a remote computer to infect a domain is either: a domain user moves
an infected file onto the domain, or a domain user authenticates to a
resource that a worm then can access to. Generally speaking, a worm on a
domain can spread "unattended" but for a worm to spread from a remote
computer onto a domain has to be attended by the domain user to log on except
if that remote computer is "trusted" to that domain.
Since most corporate Anti-Virus packages load defense watch and real time
scanning as a Windows service, no one even has to be logged on for the
sniffing to be done. This then would add another line of defense behind
authenticating to a resource. If it is unknown whether or not your
anti-virus software runs truly as a Windows service, there are usually
several options you can try to test with. 1) If there is a scheduled scan
that occurs at a certain time, and that time passes when no one is logged on,
but the scan runs anyway, then the scheduled scan is running as a service,
and the real time scan likely runs along with. 2) Have the network admin
monitor the real time scan log on the anti-virus console software while some
one does a test logon via VPN unto a server resource. If the real time scan
log starts logging the files the VPN user is accessing, then the real time
scan is effectively defending against spreading a virus.
The risk of virus infection is somewhat more risky for the remote computer
that may not have its own firewall and has an open share. Generally remote
computers are not on their own "domain" and so may not have the
authentication requirement for anyone on the domain network to access your
open share on your remote computer (if they new how.) It is at that time
that an infected domain actually might be able to infect you.
If the remote computer is on a domain anyway; such as a laptop from work
that hot seats on the domain via a docking station., the risk is almost equal
as if phsically on the domain. When this happens, the vulnerability of the
laptop is just about on par as the vulnerability of the domain because the
domain probably manages the anti-virus / intrusion detection of that remote
laptop. The only increase of vulnerability of such a remote laptop is if,
while local on the domain is behind a firewall , or router, and the standard
ethernet connection is not firewalled for internal connectivety purposes. It
is prudent to then have your VPN connection with firewall turned on; but your
ethernet with firewall turned off. If the firewall is not turned on for VPN
then there is a risk for intrusion while at home; and if circustances are
correct, spread to the domain because the remote computer is viewed by the
domain as being either trusted to the domain, or simply as a domain computer
as if at work.
