Remote Desktop Connection - Safe behind an up to date router for LAN access?

[Orange Battery]

Hi

 

If I enable RDC on an up to date Win 7 PC behind a modern Netgear router that has up to date firmware, do I need to worry about anyone trying to access the PC?

 

I'm a home user, no special important data or anything like that, just don't want to enable something that causes more problems than it solves when dealing with family computers on the same home network that I am.  I used to use Teamviewer but as I now have the option for RDC I thought I should look at it.

 

My PC - Win 8.1 Pro

PC to access - Win 7

 

Router - Netgear  wnr2200

 

Thanks

[sc302 Veteran]

nm

[+Warwagon MVC]

Why would he have to worry? Unless the RDP port is forwarded on the router he should be fine.

 

By LAN access do you mean you are just accessing one PC to another over the same LAN?

[sc302 Veteran]

I thought he was trying to access remotely.  Perfectly fine on the same network.

[+Warwagon MVC]

I thought he was trying to access remotely.  Perfectly fine on the same network.

 

Ya, I dunno, he said Lan access not WAN access.

[+BudMan MVC]

Unless you have put one of these boxes in the "DMZ" of your router, or have forwarded the remote desktop port to their private IPs.  Then no body from the internet can hit your machines to even attempt a remote desktop session.

 

The router allows you to use 1 public IP (internet) with multiple private IPs (local, rfc1918 addresses, 10.x.x.x, 192.168.x.x, 17.16-31.x.x), while at the same time this NAT prevents anyone on the internet from starting a conversation with your machines. 

[Aergan]

RDP wont allow you to share a screen but that's one of the reasons that it's more secure than accessing your local network computers via TeamViewer.

 

If you're on stock Netgear firmware, enabling RDP on your local devices isn't going to make matters any worse for you.

[sc302 Veteran]

how does that make it more secure?

 

btw

 

mstsc /shadow:sessionid will allow  you to share the screen.

 

/control takes over the session

[Aergan]

how does that make it more secure?

 

btw

 

mstsc /shadow:sessionid will allow  you to share the screen...generally the default session is 1.

 

/control takes over the session

 

(To a client OS) With TeamViewer, you're sharing the default console session and with RDP you're establishing your own separate session.

 

I wasn't aware mstsc supported shadowing natively these days.

[sc302 Veteran]

by simply running no, you have to enable it with a switch. You also have to allow remote support connections. 

 

You can lock the keyboard and mouse as well as blank the screen when going in with teamviewer.  It has been a remote control function since pcanywhere days, prior to any current remote utilities.  You remotting in kicks locks the local user anyway.  Might as well blank the screen out and disable inputs.

 

http://choorucode.com/2012/02/16/how-to-show-black-screen-on-remote-computer-using-teamviewer/

[Aergan]

by simply running no, you have to enable it with a switch. You also have to allow remote support connections. 

 

You can lock the keyboard and mouse as well as blank the screen when going in with teamviewer.  It has been a remote control function since pcanywhere days, prior to any current remote utilities.  You remotting in kicks locks the local user anyway.  Might as well blank the screen out and disable inputs.

 

http://choorucode.com/2012/02/16/how-to-show-black-screen-on-remote-computer-using-teamviewer/

 

TeamViewer is still running in the console shell and the solution isn't guaranteed across all devices and platforms (similar to other non-native remoting products). I've quite often seen the screen blanking fail but it does do a good job of locking user input (so long as your end user doesn't start removing and adding input devices in rapid succession). As local input is still attached to the local console (but ignored in most cases via a software application) I could not say it was as secure as RDP.

[sc302 Veteran]

I don't see how it is any more or any less secure personally.  Dealing with multiple users daily, needing to interact with their sessions constantly, being able to see their console and interacting is a must.  Remotting into a session to do something private, well then you really should have a headless machine or a machine that has a vm within it so that you can do what you want without notice and without obstruction to the user interface of a system in a public area.  rdp obstructs the current user session in the fashion you are using it, also there are ways to find out what you are doing even in a rdp session if you think it is so secure....I have had to put in monitoring tools on a rdp server to monitor users, screen grabs, keystrokes, messages could be all captured even in a vm session...while not native, if you are suspect of doing something suspicious it could happen.

[Aergan]

I don't see how it is any more or any less secure personally.  Dealing with multiple users daily, needing to interact with their sessions constantly, being able to see their console and interacting is a must.  Remotting into a session to do something private, well then you really should have a headless machine or a machine that has a vm within it so that you can do what you want without notice and without obstruction to the user interface of a system in a public area.

 

Depends, my employer has machines in the public domain that members of the public use on a daily basis. If you need to do administrative work on the machine to resolve an issue, RDP is an extremely valuable tool.

[Orange Battery]

Thanks for the responses, much appreciated. This will be on the same local network. Its basically me being able to access another computer in another room without having to go back and forth. All behind my netgear router.

[sc302 Veteran]

Depends, my employer has machines in the public domain that members of the public use on a daily basis. If you need to do administrative work on the machine to resolve an issue, RDP is an extremely valuable tool.

What kind of administrative work are you doing on a users machine?  There should be none that if a user sees would have access, and even if it were you shouldn't be doing domain level administration on that computer, it should all be done on your computer, not theirs.  Even if you were to push a script down, the script should be encoded and ran with the user not seeing anything.  Simply put, you don't do any sort of high level administrative work on a users pc.   Local registry, installations, and uninstalls can be done with the user watching (many times it is done).   They shouldn't be able to do it being logged in as a standard user (they should not have admin access over their machine), as far as elevated credentials they can count the *'s as much as they want, you shouldn't have anything less than a 8 char password anyway.  Who cares if they see what you do otherwise to their machine, which you should be pushing settings from the server anyway.

 

Installing a network printer is usually a task handled at the user level, which can be pushed out by a group policy.  Network shares, handled at the user level.  Installs, can be done at the user level as they don't have the rights anyway (would require you to put in your admin creds, and again who cares if they see the ******).  Fixing something that is borked, if it can't be done in 15-30 minutes you schedule a time to take their computer and troubleshoot further or reimage.  I wouldn't do anything that is so private on a users pc, they don't need to see the aduc, exchange console, spam filter interface, switch interfaces, or any other backbone networking equipment. 

[Aergan]

What kind of administrative work are you doing on a users machine?  There should be none that if a user sees would have access, and even if it were you shouldn't be doing domain level administration on that computer, it should all be done on your computer, not theirs.  Even if you were to push a script down, the script should be encoded and ran with the user not seeing anything.  Simply put, you don't do any sort of high level administrative work on a users pc.   Local registry, installations, and uninstalls can be done with the user watching (many times it is done).   They shouldn't be able to do it being logged in as a standard user (they should not have admin access over their machine), as far as elevated credentials they can count the *'s as much as they want, you shouldn't have anything less than a 8 char password anyway.  Who cares if they see what you do otherwise to their machine, which you should be pushing settings from the server anyway.

 

Installing a network printer is usually a task handled at the user level, which can be pushed out by a group policy.  Network shares, handled at the user level.  Installs, can be done at the user level as they don't have the rights anyway (would require you to put in your admin creds, and again who cares if they see the ******).  Fixing something that is borked, if it can't be done in 15-30 minutes you schedule a time to take their computer and troubleshoot further or reimage.  I wouldn't do anything that is so private on a users pc, they don't need to see the aduc, exchange console, spam filter interface, switch interfaces, or any other backbone networking equipment. 

 

....Tangent much? You've never had to support kiosk machines, Windows Embedded/WIS or machines with write filters (Read-Only / RAM Disk) I take it. No one said anything past local device administration.

[sc302 Veteran]

Yes, however the kiosk machines did absolutely nothing other than bring up a terminal service client, citrix client, or a preloaded app that gave them access to nothing other than the app or client (even the client was fool proof in that it was configured to access a specific program or server desktop).  Completely locked down from any user interaction.  Have you ever had to completely lock down a system to where they can't do anything other than one specific app, to where the system restarts the application when closed or rebooted?  There is nothing on that kiosk that would require any sort of administration on, other than initial setup, it really is a dumb terminal designed to do one specific task.  If it breaks, it would get swapped out.

 

Any true kiosk only does one task, which is open a specific application....kind of hard to break that if properly locked down.  ATMs and your self checkout at grocery stores are kiosks,...they usually pull their ui from a central location, many times a image is pushed at boot to override the pre existing image if there is a image on the local device...nothing that I have ever been involved with needed configuration or modification after the initial installation that couldn't be done at the server or at boot reimage.  I remember in the late 90s at the bank, even the csrs had a very specific image that gave them the ability to access their programs to open accounts, lookup accounts, print documents and shutdown the computer.  There were no other ui objects that they had access to and was reimaged at reboot, we basically made those windows 98 machines kiosks.

 

I go on tangents when I see something that doesn't make sense and want clarification.  In this case, your example of security doesn't make sense to me.