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

Remote desktop open to Internet. Is it a big risk

Can anyone give me some concrete evidence regarding how vulnerable it is to open up remote desktop to the Internet.

My customer is basically saying what the risk if there is a difficult username and password.

And although I know systems can be hacked, even the most skilled user cannot crack a difficult username and password. I would presume there is a minisquel risk?

I'm interested to know other peoples point of view?
3 Solutions
Let me start off by saying that enabling any remote access will never be "secure". To be secure is to be without risk from attack, and that's just not going to happen.

As far as RDP is concerned, RDP traffic is encrypted. RDP uses RSA's RC4 cipher. The encryption strength that is used is determined by the server (your client's machine in this case), and can be up to 128-bits.
There have only been a few vulnerabilities found in thr RDP protocol so far, and they've all been fixed before it caused any problem. (http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2830240,00.html) Of course, you always run a risk that there may be a future exploit that isn't patched so quickly.
Of course, the other risk is the password complexity. This plays an important role in securing the authentication to the host. The longer and more complex the password, the better you can stop a brute force attack.

While there are safer (and by safer, I only mean more secure) ways of establishing a remote connection (think VPN with certificate-based encryption), for basic or home user remote access, I personally feel RDP poses a minimal risk given some basic guidelines.

Sid_FAuthor Commented:
Ok, Basically on a customer site they have there SBS server open for RDP access to allow a remote worker connect in and run a network application.  Is this considered safe?

I feel this might be an extra load on the server but I'm not sure what type of load a remote user creates? on a machine

Do I have an argument or should I let things continue this way?
My philosophy is not to have any 'management or admisitrative' protocols open to the internet, instead join the local network via vpn and then use the RDP. There are are quite a few automated hacking tools for remote desktop, but they are slow and rely on brute force, that being said how many users ever check there access logs??

Hope that helps
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Rich RumbleSecurity SamuraiCommented:
The main risk is as indicated above, brute-forcing an account and getting access. By default the local administrator (not domain admin account) cannot be locked out, so your free to try the admin username and try to guess the password as much as you want, and never get locked out. Renaming the administroator account is one of the better ways of thwarting this attack. If the local admin name is guessed, eventually the password can be also. In XP and 2003 RDP will make it appear as the admin account is locked out after 9 failed logins, however in 1 hour your free to try again, unless you switch the computer name your trying to BF from, then your able to try 9 more times. TSGrinder automates this process, and in my opinion, a weak password will be guessed in a few hours using it.

VPN is probably the best solution, but you can mitigate the risks by changing the default listening port as well as and especially renaming the admin account. If ports 135-139, and 445 are closed on that server then it's not currently possible to use a null session to enumerate the accounts on the server, and obtain the admin SID using a tool like User2SID or SID2user, which will quickly show you which account (renamed or otherwise) has SID=500, the admin SID.

The load on the server is mostly dictated by what they are doing on it. All process run on the server, it's like your sitting in front of it an using it at a desk, so if they use an app that eats mem/proc then the server will have less resources available. The sessions themselves, on modern hardware, use little resources.

If you want to get ultra-paranoid you can preform a man-in-the-middle attack on RDP sessions, however this is difficult on the public internet:
Here are some good examples of how to protect yourself!
1. DVation191 is correct.  Packets that are transmitted are basically safe due the extremely high levels of encryption.
2. Richrumble is correct.  You must set standards within your organization to be safe using good business standards.  
3. Create a group policy allowing on selected users to have access to the remoted login function.  Create business rules for passwords to have 8 characters with a least one number and one letter. Rename administrator account to some arbitrary name and create admin without privs to view brute force methods
4. RDP is located on port 3389. Download this file to look at port activity and auditing. http://www.microsoft.com/downloads/details.aspx?FamilyID=69ba779b-bae9-4243-b9d6-63e62b4bcd2e&DisplayLang=en
5. Train users about what hackers need.  Most hacks are done through person hacking, a user gives out credentials via phone to the hacker rather than hacker tools breaking into a system.
No one can crack complex user name and password but...
everyone will know that your computer is there!!!
they can scan all your port !
they also know about some security risk that window have and try to harm your computer !
if you want to leave the remote desktop connection open make sure that all the ports AR close  and you run a good fire wall

Featured Post

2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

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