December 02, 2007

Don't waste your time renaming the Administrator account in Windows

There has been a LOT of recent attack attempts against Windows Server when it comes Terminal Services logins, and many communities I belong to are all in arms on how best to protect themselves against this.

First off, some people have been recommending using stronger password policies that include lockout thresholds. Great idea, but useless against the primary Administrator account; it is NOT allowed to be locked out. In other words, you can set the duration and threshold all you like in group policy... a DoS attack won't lock down the account. Nor should it. That would be an insanely easy way to make a Windows Server ineffective otherwise.

Lately I have been hearing advice by proficient security professionals that renaming the Windows Administrator account is a first step best practice, and I thought I would debunk the myth that this will solve your woes when it comes to attacks to a Windows server.

Security through obscurity isn't always a bad thing. After all, renaming the Administrator account prevents an adversary from easily guessing or brute forcing the username/password to log into the system. But security through obscurity alone is not a proper defence against this attack vector.

It is true that it makes it harder for an untrusted user to log into your server remotely. However, there are simple ways to collect the information in indirect ways. If the adversary can get a trusted user on your network to execute a single script, the game is over. You see, the domain administrator account on a Windows machine is ALWAYS in the format of S-1-5-domain-500. Through WMI or pure Windows API it is possible to first get the full domain SID for the admin account, and then use that to get the name currently associated with the SID. In other words, it can rip through your defense like a hot knife through butter (so to speak).

Of course, it is possible to create a SECONDARY admin account which does NOT fall under the "500" SID issue, and it can have full control of the domain just like the primary account. Then by disabling the primary admin account, this attack vector gets plugged up.

But does it?

When deploying a security safeguard to reduce the risk of exposure in this way, we need to weigh the benefits against the drawbacks. And we need to evaluate if the risk reduction impacts other parts of the system(s) in question that may actually cause MORE problems than it's worth. It is something I commonly refer to as "relational security". The impact of deploying a technical safeguard may adversely affect other parts of the system, which may make the safeguard an unacceptable solution.

This is such a case. In some Windows servers, such as SBS 2003, there is a reliance on the "Administrator" account for scheduled tasks, jobs and wizards. Renaming the account could actually BREAK some of the services on the system, impacting the system in a negative way. Many 3rd party applications and installers LOOK for this specific 500 account and will not install, or will install incorrectly, making this sort of "best practice" much less effective; it causes other systems to function incorrectly and possibly opens the system to more risk due to misconfiguration or poor installation. So you should be leaving the Administrator account alone.

Another recommendation I have heard was to simply change the Terminal Services RDP port from 3389 to something else. This is ludicrious. A simple nmap scan with fingerprinting will expose the alternate port in just a few minutes. Although you may be raising the bar, we are talking millimeters here; most script kiddies already blow by this sort of defense.

So what is the proper solution? How DO we prevent adversaries from attacking our Windows servers and brute force the account?

How about not letting them connect in the first place?

This is the whole point of least privilege and access control lists. You can easily apply an ACL on the firewall for the 3389 port and only allow trusted hosts to connect to it. Problem solved. Now unknown and untrusted users cannot even send an attack to the server. But what if your remote users do not have static IP addresses? Fine. Nothing prevents you from using an ISP class C block as allowed hosts, eliminating foreign hosts who are usually the ones trying to get in.

Remember, security is about risk mitigation, NOT risk avoidance. If we cannot prevent EVERYONE from connecting, we could atleast reduce it to a very small portion of the world. That would increase our security posture immensly.

But what if you need more security than that? What if you are worried about people that WILL have the opportunity to connect in? Then use identity assurance technology like strong authentication. Two-factor authentication solutions like AuthAnvil can bind the login transaction to a physical hardware authentication token, ensuring that the person logging in is indeed a trusted user allowed access. And this offers you the ability to loosen the ACL on the port and put the authentication check squarely on the incoming user.

So don't fret about renaming the Administrator account on a Windows Server. Instead prevent people from accessing it in the first place. And when that isn't available, consider using strong authentication to provide identity assurance before they can even log in.

YMMV. But I'd rather focus on more interesting pursuits than worrying about door rattling from automated script kiddies. Wouldn't you?

Posted by SilverStr at December 2, 2007 04:18 PM | TrackBack
Comments

Hello, nice site :)

Posted by: Brin at December 3, 2007 06:43 AM