23 May 2015

Restarting a complex application is a tough task, in particular when many interconnected services have to be restarted in the correct order. A restart becomes a great challenge in a mixed Linux/Windows server environment with dozens of databases, applications and web services.

Some application administrators developed a smart tool to simplify restart jobs. A graphical representation of the application system, with services represented as blocks and dependencies as connections between the blocks, allows the controlled restart of single services as well as the entire application system. Even a restart simulation is possible.

For every service a restart procedure is implemented. If the service receives a restart command, the restart procedure on the respective server is executed. Works perfect, even in a mixed Linux/Windows environment.

I first came across this smart tool during a security assessment of a complex application. On a Windows server I found an SSH service which ran in the context of a globally defined service account. This globally defined service account was member of the local administrator group. For security reasons the local login with this service account was disabled. Really clever!

Unfortunately, each globally defined service account increases the attack surface of your IT system. Once an attacker compromises such an account he gets privileged access to every system where the account is used for administrative tasks. In the worst case, without segmentation in trusted zones, an attacker could get access to all your Windows servers.

How to mitigate this vulnerability? The fast way is to ‘Deny login from the network‘ for this service account in addition to ‘deny login locally’. This will hamper an attacker from exploring your network with a compromised account. If an administrator must configure a service he must sign in with his personal administration account. To change the service he has to enter the service account’s password.

In addition I recommend to question the use of globally defined service accounts in general. As mentioned above such accounts increase the attack surface of your IT system.

With this I recommend: Before you use a globally defined service account for an administrative tasks, ask yourself the question: Can I imagine to do this with a locally defined service account?

If your answer is Yes, and the extra effort is low, you should implement the service with a local account. Make this approach mandatory for all IT staff to keep the attack surface of your IT system sustainably small.

Wishing all a Happy Memorial Day weekend!