[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 16143
  • Last Modified:

RDP security question

We are setting up remote desktop web connection. My question is how secure is remote dsktop? Is the data that passes between the client and the server encrypted in any way? Can it be? I am fowarding port 3389 through my corp fire wall to my ts server and it makes me a little leary to do so. Is there any thing aside from not doing that to make it a more secure connection? is there a 3rd party app that will sit between the firewalla nnd the server that will provide another level of security. Thanks.
0
uyht
Asked:
uyht
  • 2
  • 2
  • 2
  • +3
2 Solutions
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Yes, it is encrypted.  It's not the best encryption, but it is encrypted.  The safest thing to do is setup a VPN, connect to the VPN, then connect to the system you want to connect to.  No poking holes in firewalls.
0
 
rdivilbissCommented:
If you are press for money you can use Putty (SSH) to handle the VPN.  Not the most user friendly product but good security.

0
 
uyhtAuthor Commented:
we have a vpn, but i do not want home PC's cnnecting to our network. My laptop users use the VPN but we also use a firewall and av on those indivdual machines when outside the network. This provides my end users wih the ability to just go to a web browser and work remotley with no hassels and it doesn't pen my network up to what ever crap thier machines might have on it.
0
Independent Software Vendors: 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!

 
fixnixCommented:
I like the SSH tunnel solution for added measure when a VPN is not desired for everyone needing RDP access.

At one of my clients with no Server OS, I set them up with TightVNC through an SSH tunnel, same could easily be done for RDP.  The employees that connect from home aren't very computer-literate, so when I set it up for them I placed Putty on the desktop and called it "Step One" then put the vnc client (in your case it'd be the mstsc executable shortcut) renamed to "Step Two".  Only problem I had a few months later was that one employee's spouse has deleted them from the desktop...easily fixed by emailing them replacement files already renamed for them.

If you need advice on setting up OpenSSH on the server or how to configure the putty and terminal service clients to tunnel, just ask.  Not sure if this has been changed, but as of XP-SP1, the mstsc executable wouldn't allow connects to 127.0.0.1....resolvable by using the win2k mstsc or possibly using 127.0.0.2 (I carry the 2k mstc executable on a thumbdrive...never used 127.0.0.2 myself but heard it works).

FWIW, I've had my home play/expendable network segment configured with 3389 open to the world for about a year and haven't had any problems...but I hardly ever RDP into it (prolly once in the last 6 months just to jump on IRC to see if a bud was around to ask a question when I was at a client).  Not sure how difficult it would be to crack with a live session to sniff tho, so for "real" use I'd feel more comfy tunneling it through SSH.
0
 
Rick111Commented:
Programs | Administrative Tools, select Terminal Services Configuration and perform these steps:

   1. In the left console pane, select Connections.
   2. In the right details pane, right click RDP-TCP and select Properties.
   3. Click the General tab.
   4. Under Encryption level, select the desired level in the drop down box and click OK.  // Group Policy Object Editor (gpedit.msc), double click Administrative Templates > Windows Components > Terminal Services and then choose Encryption and Security.

From here you can set the encryption level for the TS session.
0
 
Rich RumbleSecurity SamuraiCommented:
I've commented on RD/TS sessions a few times before, here is a quick run down
1) The only unencrypted information you can obtain from the rd/ts session is a Username, and that's only at the begining of the session.
2) the encryption is very good by default, as well as compressed, and the encryption can be turned up to make brute-forcing near impossible- the encryption level is determined by the server, not the client. Encryption can be disabled btw.
3) I've never found a program to attack an RD/TS session that may have been captured, I look quite often actually.
4) To further secure the connection, you should do a few things, change the listening port, and change the local administrator account's name to something else. The local admin account is the main weakness of RD/TS, since this account cannot be locked out, your free to try to guess the local admin password. A program like TSGrinder will help to automate this task, since you will be disconnected after a few failed attempts. And actually with XP-sp2 and 2003-sp1 the local admin account can be locked out from TS/RD access, but local access(terminal) is still allowed. The lockout last's 90 minutes, and I think the lockout threshold is 6 failed attempts.
5) Even with the listening port changed, it's easy to spot an RemoteDesktop/TerminalService port if you look at the returned headers from the scan packets. So a VPN solution is probably the best idea overall to secure RD/TS or any remote control software such as vnc or timbuktu.
-rich
0
 
rdivilbissCommented:
>but as of XP-SP1, the mstsc executable wouldn't allow connects to 127.0.0.1

Copy mstsc.exe and its dll to a separate folder.
Make a shortcut to mstsc.
Set compatability mode to W2K.
Problem solved....
0
 
Rich RumbleSecurity SamuraiCommented:
Rdp just got less secure...
Cain & Abel v2.7.3 released
New features:
- RDPv4 session sniffer for APR
Cain can now perform man-in-the-middle attacks against the heavy encrypted Remote Desktop Protocol (RDP), the one used to connect to the Terminal Server service of a remote Windows computer. The entire session from/to the client/server is decrypted and saved to a text file. Client-side key strokes are also decoded to provide some kind of password interception. The attack can be completely invisible because of the use of APR (Arp Poison Routing) and other protocol weakness.
-rich
0

Featured Post

Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

  • 2
  • 2
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now