locked
TS Gateway Server Monitoring RRS feed

  • Question

  • I have setup and configured Remote Desktop and configured TS Gateway all on one Server 2008 box including the SSL Certification as described in the "Terminal Services Deployment Guide" on TechNet. Currently I can connect by RDP Client or via Browser (https).

    I have two questions:

    1. One of our customer that has a few Users login from their Network to our TS Server is claiming the initial authentication is still in clear text when using the RDP connection. Is that right? How can I verify this?

    2. Either way - RDP Client or Browser (https) - none of the connected Users show up in the TS Gateway Manager under Monitoring. But all of the connected Users show up under the Task Manager of the Terminal Server.

    Any idea what I missed?

    I appreciate all the help.

    Roman


    Wednesday, July 13, 2011 12:37 AM

Answers

  • Hi Roman,

    1. If an old RD Client version is used it will send the load-balancing cookie shown in your client's network capture, and most of the time this will contain either the last-used user name when connecting to the server (from the local account) or the local PC user name in clear text.

    This can be prevented by using a current Remote Desktop Connection Client version to connect, preferably version 6.1.7600 or higher, or at minimum version 6.0.6001.  6.0.6001 or higher is present if the client OS is Windows XP SP3, Vista SP1/SP2, or Windows 7 RTM/SP1.

    Here are some basic security recommendations: 

    • Use Security Layer: SSL (TLS 1.0)
    • Use Encryption Level: High
    • Install certificate from public trusted authority such as GeoTrust, GoDaddy, Verisign, Thawte, GlobalSign, etc.
    • Require end users to use RD Client version 6.1.7600 or higher
    • Optionally require Network Level Authentication (NLA)
    • Require complex passwords of at least 10 characters in length, set this via domain password policy
    • Configure account lockout after 5 unsuccessful logon attempts, with long reset lockout counter and lockout durations
    • Require periodic password changes (for example, every 60 days)
    • Monitor security audit logs for failed logons
    • Use TS Gateway for users connecting from the Internet

    As to the other points your client raised:

    The other issues we have using straight RDP is it large target for hackers, either through brute force attacks to the server or session hijacking:

    When properly configured, connections via RDP will use the same security as when connecting via web browser to an SSL-secured web site.  The server is authenticated using a certificate from a trusted authority, and the data transferred between the client and server is protected with strong encryption.

    Brute-force attacks would not likely be successful with long, complex passwords combined with lockout policy and regular security audit log monitoring.  Brute-force attacks do present a Denial of Service risk, so in this case if the server were accessible via the Internet (without RD/TS Gateway) I would recommend an alternate port be used combined with Network Level Authentication (NLA uses much less resources during failed logon attempts).  For access via the Internet RD/TS Gateway is recommended, that way the attack would be made against the RDG instead of the Remote Desktop Session Host/Terminal Server.

    "Session hijacking" would only be possible if the end user accepted an invalid certificate or if the user elected not to authenticate the server in the RD Client options.  This is the same situation as a SSL-secured web page.

    As far as the security bulletin is concerned it is part of a vulnerability that potentially affects a large number of programs (MS and non-MS), not just the RD Client.  In general my opinion is that this is relatively easy to mitigate and does not represent a large risk when compared to all of the other potential risks.

    2. For TS Gateway to work you must forward tcp port 443 for the public ip address of your TSG on your firewall to the private ip address of your TS Gateway server.  For TS Web Access to work you must forward tcp port 80 on your firewall to the private ip address of your TS Web Access server.  For higher security you may run TS Web Access using SSL, in this case you must forward port 443 for the public ip address of TSWA to the private ip address for your TSWA server instead of port 80.

    Tcp port 3389 should be blocked at your firewall.

    You must configure your TS Gateway settings manually in the RD Client options if the end user is connecting by using the RD Client directly or in RemoteApp Manager if the user is making the connection using TS Web Access.

    -TP

    Sunday, July 24, 2011 7:09 PM

All replies

  • Hi Roman,

    1. No, username/password is not sent in clear text.  You may verify this by capturing and examining the RDP packets using netmon, wireshark, etc.

    2. By default the RD Client will attempt to directly connect to a TS server on tcp port 3389 (or other specific port that you specify) and only if this is not possible will it use the TS Gateway for the connection.  If you are testing on the same network as the TS then most likely the RD Client is able to directly connect thus it will not use the TSG.

    If you test from outside of your network and make sure that your firewall is only allowing incoming traffic to your TSG on tcp port 443, then you will see the RD Client using TSG for the connection.  If you would like to force the RD Client to use the TSG then uncheck Bypass RD Gateway server for local addresses in the client options.

    NOTE: For best security I recommend you configure Security Layer: SSL (TLS 1.0), Encryption Level: High, and install/select an SSL certificate from a trusted authority such as GeoTrust, Verisign, GoDaddy, Thawte, etc.  This is done in Terminal Services Configuration (tsconfig.msc), Properties of RDP-Tcp, General tab.  Also please consider selecting "Allow connections only from computers running Remote Desktop with Network Level Authentication" if all of your client PCs support NLA.

    Thanks.

    -TP

    Wednesday, July 13, 2011 11:48 AM
  • Thanks so much for your input.

    Sorry it took me a little longer to get back to you but I still have two issue:

    - 1) I did some package captering on my Win7 RDP Connection and was not able to found any Username nor Password transfered in clear text as you mentioned. But on the other hand the I received the following Email from our client:

     

    The RDP session using the x.224 and TPKT protocols, these are the standard protocols used by RDP.  Also below is a copy of text from the TCP stream that shows the username in clear text.
     
    ....)......Cookie: mstshash=username             <-----  the username is clear text
    .................4....................N.....{.lEW.....\N....b........q -....].....<...<|..um.?...3....I.../.5...
    .......
    .2.8.......6..............ts.mydomain.com..........
    ..................&...Q..N....r(O".7.&5`.p)j....V..B../.I ^......q>.y..}U%+.....g.-%W...;N./..............
    P.

    The other issues we have using straight RDP is it large target for hackers, either through brute force attacks to the server or session hijacking.  Also Microsoft it's self released a Security Bulletin (MS11-017) about RDP back in March. 

     

    2. I'm trying to connect directly via TS-Gateway by closing the port 3389 on the Firewall but no I cannot connect by RDP nor browser (ts.mydomain.com/ts).

    Do I need to change the port on each RDP client to 443?

     

    Sorry but I'm a bit lost here as you can tell.

     

    Roman

     

     

    Friday, July 15, 2011 1:08 AM
  • Hi Roman,

    1. If an old RD Client version is used it will send the load-balancing cookie shown in your client's network capture, and most of the time this will contain either the last-used user name when connecting to the server (from the local account) or the local PC user name in clear text.

    This can be prevented by using a current Remote Desktop Connection Client version to connect, preferably version 6.1.7600 or higher, or at minimum version 6.0.6001.  6.0.6001 or higher is present if the client OS is Windows XP SP3, Vista SP1/SP2, or Windows 7 RTM/SP1.

    Here are some basic security recommendations: 

    • Use Security Layer: SSL (TLS 1.0)
    • Use Encryption Level: High
    • Install certificate from public trusted authority such as GeoTrust, GoDaddy, Verisign, Thawte, GlobalSign, etc.
    • Require end users to use RD Client version 6.1.7600 or higher
    • Optionally require Network Level Authentication (NLA)
    • Require complex passwords of at least 10 characters in length, set this via domain password policy
    • Configure account lockout after 5 unsuccessful logon attempts, with long reset lockout counter and lockout durations
    • Require periodic password changes (for example, every 60 days)
    • Monitor security audit logs for failed logons
    • Use TS Gateway for users connecting from the Internet

    As to the other points your client raised:

    The other issues we have using straight RDP is it large target for hackers, either through brute force attacks to the server or session hijacking:

    When properly configured, connections via RDP will use the same security as when connecting via web browser to an SSL-secured web site.  The server is authenticated using a certificate from a trusted authority, and the data transferred between the client and server is protected with strong encryption.

    Brute-force attacks would not likely be successful with long, complex passwords combined with lockout policy and regular security audit log monitoring.  Brute-force attacks do present a Denial of Service risk, so in this case if the server were accessible via the Internet (without RD/TS Gateway) I would recommend an alternate port be used combined with Network Level Authentication (NLA uses much less resources during failed logon attempts).  For access via the Internet RD/TS Gateway is recommended, that way the attack would be made against the RDG instead of the Remote Desktop Session Host/Terminal Server.

    "Session hijacking" would only be possible if the end user accepted an invalid certificate or if the user elected not to authenticate the server in the RD Client options.  This is the same situation as a SSL-secured web page.

    As far as the security bulletin is concerned it is part of a vulnerability that potentially affects a large number of programs (MS and non-MS), not just the RD Client.  In general my opinion is that this is relatively easy to mitigate and does not represent a large risk when compared to all of the other potential risks.

    2. For TS Gateway to work you must forward tcp port 443 for the public ip address of your TSG on your firewall to the private ip address of your TS Gateway server.  For TS Web Access to work you must forward tcp port 80 on your firewall to the private ip address of your TS Web Access server.  For higher security you may run TS Web Access using SSL, in this case you must forward port 443 for the public ip address of TSWA to the private ip address for your TSWA server instead of port 80.

    Tcp port 3389 should be blocked at your firewall.

    You must configure your TS Gateway settings manually in the RD Client options if the end user is connecting by using the RD Client directly or in RemoteApp Manager if the user is making the connection using TS Web Access.

    -TP

    Sunday, July 24, 2011 7:09 PM