21 Mar 2008

On Securing RDP

Author: q | Filed under: Coolness, Security, Tools

Last December, I worked out an arrangement to better protect our clients for whom we provide primary support. This involved finding ways to tighten access their severs via RDP (the infamous port 3389). There are a lot of different takes on controlling access to port 3389 out there, from simply not allowing it at all through the firewall (which works for SBS boxes running Remote Web Workplace, provided there”s not a problem with IIS on the box at the time you want to access it) to configuring the firewal to allow inbound port 3389 connections only from specific IP addresses. For our purposes, neither of these options, nor the other similar variations, really worked for the way we conduct our business.


Enter Dana Epp and Scorption Software. Dana is a Security MVP from Vancouver whose software development company has been developing security products designed fo the SMB market for a couple of years. 


After working with two of his tools, AuthAnvil and RWW Guard, we finally developed an approach that mitigates the risks of opening port 3389 to the internet, yet still allowing our opration a reasonable level of access for support and maintenance. Here”s the approach we”re taking.


  1. Create a secondary administrative account with the same name across all of our supported servers.
  2. Change the password on the Administrator account to be a really, really secure password.
  3. Modify the local security policy to deny the Administrator account the ability to log in via terminal services, effectively limiting the Administrator account to a local console login only (which also does not affect any services running with that account).
  4. Install the WinLogon Agent component of AuthAnvil on each client system and point it back to the AuthAnvil system running on our servers.
  5. Configure AuthAnvil on our servers to have a grouped account,whose name matches the secondary administrative account we created on our supported servers,and add local users to that grouped account who are allowed to log in to the remote server.
  6. Add the Administrator account to the AuthAnvil Override security group on the local server so that the Administrator account does not require a token to log in to the server.

We have started rolling out this configuration this month, and so far it is working according to plan. The benefits of this arrangement include:


  • Local access to the sever is still possible with the Administrator account and no security token.
  • Remote access to the server is limited to the secondary administrative account, which also requires the use of a security token to successfully log in.
  • The access logging in AuthAnvil gives me an accurate accounting of hich of my staff accessed one of our support servers and when.
  • When staff turnover occurs, access to remote systems is denied in a single step by disabling the employees token in the main AuthAnvil system.

So for the cost of equipping my staff with the security tokens, we are able to increase the security of our supported systems with two-factor authentication, while blocking remote access to the Administrator account at the same time.


None of this would have been possible without Dana”s efforts to bring quality security products to the SMB space at an affordable price. It”s a very small price to pay for the enhanced security benefits our client base is receiving. 


 

2 Responses to “On Securing RDP”

  1. Ryan O''Dwyer Says:

    What would happen if the internet at your office was down? How do you access the remote servers?

  2. eriq Says:

    The WinLogon agent has an optional “override” passphrase that is configured for exactly this reason. Either the network could be down at the site that”s hosting the AuthAnvil system, or at the site where the WinLogon agent is deployed.

Leave a Reply

*