none
server 2012 needs a setting to disconnect RDP after x invalid login attempts

    Question

  • Brute force robots are a constant problem for windows servers.  It's easy to throttle the connections at the gateway (for those who can not block RDP).  However, windows server has historically allowed each connection to try many login attempts in a single RDP connection before being disconnected. 

    Microsoft has got to make a new GP setting to disconnect a RDP client after x invalid login attempts.  I'm not talking about lock the user out.  I'm talking about kicking off the RDP client/killing the socket and forcing them to reconnect.   This will stop the brute force RDP attackers in their tracks.


    BarrySDCA

    Sunday, June 10, 2012 11:25 PM

All replies

  • has there been any consideration to this by MS?  It really is very important if you are serious about protecting MS OS users.

    BarrySDCA

    Wednesday, June 20, 2012 4:51 PM
  • Following up internally about this. I agree that this is an important feature to have both in Windows and SQL Server where I have personally seen logs grow in GB with login failure messages. Thanks!
    Wednesday, June 20, 2012 5:33 PM
  • thanks

    not just logs.  the windows OS must spend resources to deny each and every login request.  it can bring a VPS to a screeching halt easily.

    we can't filter these at the gateway because RDP is encrypted.  so we have a filter setup, 3 TCP connections to 3389 from the same remote IP in a 60 second window and we block all new tcp3389 traffic from the remote IP until no more traffic is received for 60 seconds.  that works well except each connection they can try a gazillion login attempts in just a few seconds and down go the resources, and along with it the windows OS.

    really such a simple tweak could stop most of it.  seems silly not to.

    thanks


    BarrySDCA

    Wednesday, June 20, 2012 5:37 PM
  • Note that PowerShell web access has a one second logon delay to mitigate against brute force attempts. Would a similar delay in RDP be acceptable/desirable?

    Wednesday, June 20, 2012 5:37 PM
  • probably not desirable as it will interfear with authorized users. 

    just kill the socket after x invalid login attempts.  that's all you need to do.   leave the rest to the firewalls in front of the box.

    DO NOT lock out the user account.

    thanks


    BarrySDCA

    Wednesday, June 20, 2012 5:40 PM
  • I have filed a security impact bug against RDP. I can't guarantee that this will make WS2012 but it will definitely be seriously considered.

    Thanks for your feedback!

    Wednesday, June 20, 2012 6:03 PM
  • thanks.  I have been asking for it since OS 2003.  glad someone finally gets it.  

    Ideally you should put it in 2003 and 2008 by way of windows update too.  It could stop many RDP hacks in their tracks.  I estimate 80%+ of them.

    we ended up changing the RDP port random for different subscribers.  but the GP option would be MUCH better.

    much appreciated - thank you


    BarrySDCA

    Wednesday, June 20, 2012 6:08 PM
  • I think a hard-coded limit of, say, 10 bad attempts would probably be fine. The simpler we can keep this the more likely it will make it. As soon as you start talking about new GPs and settings we have to bring in localization people and more testing etc. and that makes it way more expensive for us to implement and likely to be cut -- especially this late in the game.
    Wednesday, June 20, 2012 6:23 PM
  • 10 is fine.  I was just thinking GP because (I thought) it would be easiest.  however it can be done is great.

    thank you


    BarrySDCA

    Wednesday, June 20, 2012 7:31 PM
  • We're investigating how to best address this issue given our resources right now.

    As a workaround for now, you can try turning off NLA. That will force all logon attempts through winlogon which I believe does have a built-in brute force protection system.

    Thursday, June 21, 2012 5:45 AM
  • interesting NLA is/has been off already and not having that effect

    the built in brute-force protection system (I think) locks the user account out.  as I said earlier, this is not good.   it locks out legit users and does not do anything to address the real problem - draining of resources from hundreds of login attempts in just a few seconds.


    BarrySDCA



    • Edited by BarrySDCA Thursday, June 21, 2012 1:09 PM
    Thursday, June 21, 2012 1:08 PM
  • > interesting NLA is/has been off already and not having that effect

    We're now looking into this too. Thanks!

    Thursday, June 21, 2012 3:28 PM
  • +1 from me too. The RDP attacks to 3389 are really stepping up. When there's an active attack, this drains CPU cycles and upstream bandwidth, as well as generating huge log files.

    I would like to use RD gateway to filter the attacks (and also provide connectivity from locations where 3389 is blocked outbound). But this only seems to be available after you install the RDS role. The problem is with that is that it requires RD licensing to be set up for all RD connections. It would be good to be able to use RD gateway for remote administration without requiring RD licensing.

    Is there any way an RD host or RD licensing server could give 1-2 free RD licenses for remote administration purposes, so we could use the full RD functionality for remote administration?


    Wednesday, June 27, 2012 1:18 AM
  • interesting NLA is/has been off already and not having that effect

    the built in brute-force protection system (I think) locks the user account out.  as I said earlier, this is not good.   it locks out legit users and does not do anything to address the real problem - draining of resources from hundreds of login attempts in just a few seconds.


    BarrySDCA



    It shouldn't lock the user account out, but the server should stop listening on port 3389 for a time. 


    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Wednesday, June 27, 2012 12:25 PM
  • stop listening to port 3389 is just as bad as locking them out.

    It should DISCONNECT the TCP socket.  that's it!  just drop the connection.

    then we can use our hardware firewall to block repeat connections from the same IP in a short window.  right now we are blocking more than 3 RDP connections from the same remote IP in a 60 second window. 

    this way legit subscribers are not impacted.  which is after all the #1 goal.


    BarrySDCA

    Wednesday, June 27, 2012 2:10 PM
  • I just wanted to make sure it was understood that we don't do anything to the user's account in AD.

    Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging

    Wednesday, June 27, 2012 2:28 PM
  • Yes, this is understood.
    Wednesday, June 27, 2012 2:38 PM
  • I'm happy to announce that we were able to add a delay to bad logon attempts which should effectively stop the brute force/CPU overload/bandwidth usage issues you have been experiencing. The feature is present in Server 2012 RTM :-)

    Thanks for the feedback!

    Best,
    Ben

    Thursday, August 16, 2012 7:15 AM
  • This is great news. Thank you Ben.
    Thursday, August 16, 2012 5:40 PM
  • Hi Ben,

    Can you explain where this feature is? Does it need any configuration?

    Monday, December 24, 2012 1:08 AM
  • There is no configuration option, it is on by default and cannot be disabled. We just added a small (several millisecond) delay to the login that is not noticeable in normal use, but significantly reduces the potential for brute force attack success. It also blocks that connection during the delay period meaning that CPU cycles are available for other processes to use. This should significantly reduce CPU load during a brute-force attack. We have tested it and it does indeed make a significant difference.  This new feature is available as of Windows Server 2012 RTM.

    Thanks for the feedback!

    Saturday, January 05, 2013 6:31 AM
  • Hi

    Just found a really efficient tool to overcome brute force attacks eg. for RDP.
    Check out: http://cyberarms.net/

    - configure soft lockouts, lock duration, ...
    - and they give a free version with full functionality (but lock limits on daily basis)

    Martin

    Monday, October 21, 2013 10:10 AM