2

If I set up a Domain Controller server to be accessible from the internet via Remote Desktop Connection (through port forwarding in the router), how much of a threat would that be?

  • and if I have a strong administrator password?

  • and if there are users with weak passwords?

Which mitigation steps could be taken?

EDIT: I perfectly agree with the idea "use the Domain Controller ONLY as a Domain Controller" expressed in the comments.

But there are cases of small companies (15-30 users) that do not want to purchase more than one server, nor buy a new hypervisor to host multiple servers on it. In those cases the only server ends up doing everything...

  • 2
    As an admin I would just want to ask this: What the F--K are normal users with weak passwords doing on a domain controller? Get a separate server for that (or actually more than one). They do not have to be fast, but the only thing you want to run on that hardware is windows with the DC role. Fix that before you start worrying about trivial alternative risks. – Hennes Aug 29 '13 at 16:12
  • 2
    First mitigation step should be to remove any type of remote desktop access to the DC. – bdjb Aug 29 '13 at 16:32
  • I'm with Hennes on this one, why are non-administrators allowed to log into the DC anyway? ...especially, why would they be allowed to log in remotely? I cannot think of a case where this is needed. – Rod MacPherson Aug 29 '13 at 18:00
  • Why is your DC running anything but Server Core?! – Michael Hampton Aug 30 '13 at 02:17
  • see my EDIT on the original post... –  Aug 30 '13 at 16:07
  • windows is generally much less secure than other POSIX systems. it's also harder to develop on. – noɥʇʎԀʎzɐɹƆ Jul 18 '16 at 15:38

1 Answers1

2

You would have two types of risks:

  1. There could be a flaw in the server code. This is a generic situation for every server, but a Remote Desktop server is known to be relatively complex, and thus probably has more exploitable bugs than, say, a SSH server. Microsoft themselves offers an additional product called Remote Desktop Gateway (previously known as Terminal Services Gateway) which acts as an intermediate step. The gateway runs a "normal" SSL server, on port 443, and can perform a user authentication, but it is much simpler (and therefore assumed to be stronger) than a full-blown Remote Desktop server, since it does not actually handle the Remote Desktop protocol -- it just forwards it to the actual Remote Desktop server.

    Note that among possible "flaws" in Remote Desktop is configuration, in particular with regards to certificates. A basic Remote Desktop server can use various encryption layers, some custom, some encapsulating SSL. A critical point is that, depending on the configuration and on how the user handles it, the client might fail to properly validate the server's certificate (in particular when the server's certificate has been automatically generated and is self-signed). In that case, the client is open to a Man-in-the-Middle attack. There again, the Gateway makes things sturdier, in that it enforces a very Web-like SSL server model which is harder to configure wrong.

  2. If a user is allowed to open a session on the server, on virtue of presenting a matching password, and that password is weak, then an attacker could run a dictionary attack, which means trying possible passwords until the right one is found. This would be an online dictionary attack, and you might be able to automatically notice such an ongoing attack by the huge amount of "failed login" events. However, if the attacker succeeds, then he gets to run arbitrary code on the machine. Privilege escalation on a local machine tends to work (locally exploitable flaws are much more common than remote flaws) so you basically have lost.

    The only good defence against weak passwords is to educate users into choosing stronger passwords. As a mitigation measure, you can also restrict Remote Desktop access to some specific users; by default, only members of the local Remote Desktop Users group will be allowed to open a session. Your first step should be to actually decide who is allowed to do that on the machine (As @Hennes suggests, given that the machine is a Domain Controller, the list of people who are allowed to open a session on it should be limited to just the administrator; or you are doing it wrong).

Remote Desktop Gateway is not free and tends to require an extra machine. A cheaper alternative is to deploy a VPN solution like OpenVPN (the core software is GPL, no license needed). This is functionally equivalent. It won't do anything against weak passwords, though.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475