Alternative to IE for RDP access.

[Mick]

We look after a few SBS 2008 installations and some users make use of Internet Explorer for remote log-ins (as in 'remote desktop'). As most will know, other browsers - even Edge - do not render the code which makes the log-in link accessible. However, IE is long in the tooth and a big target for the bad people. I can see it will not be long before MS decides to 'EOL' it and I'd quite like users not to have to invoke it. So, I'm looking for an alternative means of accessing workstations remotely for users. It needs to be a simple 'one-click' operation - or as near to that as we can get - but I haven't found anything yet. Any suggestions appreciated.

 

[YeOldeStonecat]

Configure and deploy RDP files for them. Basically a remote desktop connection profile configured to go right to their workstation. SBS08 and 11 and Essentials use TSGateway under the skin, for the Remote portal. It just launches an RDP connection and TSGateways it to the desktop. So...skip that step, configure the RDC file and distribute it. Bypassing using a browser!

 

[Blues]

You can create and save RDP sessions and create shortcuts for them so unless thats what your talking about which to my knowledge it has no link to IE I need some more information of specifically what you are trying to do.

 

[YeOldeStonecat]

Start...Run...MSTSC
Expand "show options"

Computer:name of clients workstation
Username: domain\username

..click on Advanced tab
..click on settings button

radio button choice for Use these RD Gateway server settings:
Server name: (external public FQDN of clients WAN, like remote.clientdomain.com)
Logon method: Ask for password (NTLM)
Check in the box for Bypass RD Gateway server for local

Logon settings:check in the box for Use my RD Gateway credentails for the remote computer

Click OK
Click back to General Tab
Click "Save As"..give it a name, and MSTSC by default saves profile files to the My Documents folder.

If this is on the clients computer...right click and send a shortcut to the desktop.

Or..we build them here at our office, from our computers...and just e-mail the file to the client.

 

[Sky-Knight]

Or deploy a VPN, and give them RDP icons that point directly at the desktop's DNS name.

I will not support RDP in any form without a VPN online, or a two factor authentication system (Duo). Every single crypto that's hit me, has gotten in via TCP 3389. Running the HTTPs proxy is sadly no help.

Get RDP off the web, or suffer the consequences.

 

[Blues]

Or deploy a VPN, and give them RDP icons that point directly at the desktop's DNS name.

I will not support RDP in any form without a VPN online, or a two factor authentication system (Duo). Every single crypto that's hit me, has gotten in via TCP 3389. Running the HTTPs proxy is sadly no help.

Get RDP off the web, or suffer the consequences.

Yes RDP should only be done via secure VPN connection but creating a click-able RDP icon for the users should never involve IE and RDP itself has a way to create such which @YeOldeStonecat has given detailed instruction set for.

 

[YeOldeStonecat]

I will not support RDP in any form without a VPN online, or a two factor authentication system (Duo). Every single crypto that's hit me, has gotten in via TCP 3389. Running the HTTPs proxy is sadly no help.

I haven't seen or heard of a single instance of the TSGateway being busted into.....with TSGateway to proxy RDP you only need port 443, secure certificate and NTLM, I never have port 3389 open/forwarded. User accounts set to lock after X failed login attempts, complex passwords, old leftover accounts and legacy account from old SBS history removed.

Not saying it won't be possible for some crypto variant to bust through TSGateway...but as of yet...not heard of it.

 

[Mick]

Thanks all. TBH, when I read @YeOldeStonecat 's first reply, I could have kicked myself - why the hell didn't that occur to me??! It's because of I.E.'s increasingly buggy behaviour and insecurities that I want to wean these folks off using it. I don't use port 3389, but I must say, the (three) instances of crypto that I've dealt with on server installations have all been through dodgy email attachments, not coming in via the gateway.

 

[YeOldeStonecat]

I don't use port 3389, but I must say, the (three) instances of crypto that I've dealt with on server installations have all been through dodgy email attachments, not coming in via the gateway.

I agree most crypto's now are coming in via PDFs...e-mail. But when the first cryptoware came out...they did exploit port 3389. Outdated OS's...with port 3389 exposed to the internet. I never found a direct answer as to how/what it exploited....how it punched into the OS. It was patched...but since then, I suspected a cat 'n mouse game would happen, so we don't like exposed 3389 anymore, shut the door on our managed clients for that, and have 'em all do TSGateway instead...which does not expose 3389 on the wild side.

 

[Sky-Knight]

I lost two VPSs this year to RDP breaches. The admin account on the platform that was placed there by the host didn't have its password properly rotated. Account lockouts were in place, heck I even had RDPGuard installed. Didn't matter, 3 years of working at it, they broke the password that was supposed to be unique per VPS that obviously wasn't, and the entire cluster was smashed. Again, it's a VPS you cannot close RDP because that's your only way in. Fix, apply DUO.

There are also ways to use RDP that don't require authentication to breach systems, such mechanisms are well documented in the wannacry tech briefs.

Moving TCP 3389 to another port on your router does nothing, it takes less than a second to scan for and identify RDP on an entire IP block, much less a singular address.

Seriously, expose RDP to the world at your own peril.

Also, Stonecat, Jim actually lost a customer that was using TSGateway Q1 this year as well. That client is now using DUO, no more problems. Same scanner that was looking for 3389 started poking at TCP 443. The bad guys know where that gateway is and how to break it. This wasn't SBS, it was Standard 2012 R2 deployed with TSGateway with continuum based patch management and AV.

Seriously, use two factor or a VPN. You can choose to ignore this if you wish, but please at least make sure your backups are good.

 

[YeOldeStonecat]

Yeah I know alternate RDP ports do nothing...the scanners scan up 'n down and will find the RDP fingerprint on another port and start grinding it.

Busting through passwords...that's a whole 'nutter matter.

But I was (and still sorta am) quite sure the RDP exploits had to actually touch the RDP listen service to rape it (via direct port 3389 or alternate port hanging out the firewall)...and the TSGateway cloaked that because it authenticates first, and then once approved....begins proxying the RDP. Thus no direct RDP listen service hanging its exposed butt out on the internet. Would like to find info on if TSGateway is now exploitable by those same RDP busting tools.