AppLocker Locking Down Servers is a Good Start

Overview

 

Much has been said and written about AppLocker since its introduction in Windows 7. Microsoft primarily positions the tool as a way to lock down the applications that run on desktop computers, and while the tool has its fans for that use, it also has its detractors. Maintaining an organization-wide inventory of all the desktop software you use is difficult, and AppLocker’s relatively primitive tools don’t make it an easy task.

 

That said, clients aren’t the only computers on our networks, and the exact conditions that make AppLocker more complicated to use with clients can make it a real winner on servers. With clients, AppLocker becomes complex because we have so many applications, users are always after a one-off or temporary exception, and no matter how homogeneous we try to make our clients, little unique differences always crop up over time. Servers, on the other hand, are almost exactly the opposite: We know exactly what’s running on them, that list of software rarely changes, and when it does change it tends to do so as part of a controlled change process. So AppLocker might be perfect for helping to control change on our servers, as well as prevent malware.

 

 

What’s the Goal for AppLocker on a Server?

 

So what, exactly, do we want to achieve?

 

First of all, we want to apply an additional layer of defense to our servers to help prevent malware. Yes, you’ve already got anti-malware software, and you should keep it. But that software is inherently a blacklist approach, meaning it can’t detect threats that the vendor hasn’t yet programmed into it. Someone is always the first to get hit; with AppLocker, you can whitelist the applications that should run, and deny everything else.

 

Second of all, we want to enforce change management on our servers. Server applications should remain fairly constant over time. Sometimes, an eager administrator will want to install a quick utility or make some other change that seems like a good idea at the time, but that ultimately contravenes the organization’s change management process and the stability of the server. AppLocker is a way to put a few brakes on that. While it’s impossible to entirely deny an administrator the ability to install software on a server, you certainly can put a couple of hurdles in the way to make it clear that the change isn’t appreciated unless it first goes through the process.

 

Third, and related to the second goal, we want to improve (or at least maintain) servers’ stability and performance. Installing software is a top reason for servers to become less stable, or to perform poorly, over time, and by stopping that from happening we can help ensure that our servers remain healthy.

 

There’s a fourth goal, and that’s about licensing compliance. We tend to worry a lot about whether or not ever copy of Office is licensed, but server software is just as much of a concern (or even more so, since it tends to be more expensive). Nobody should be installing that extra copy of SQL Server unless it’s been paid for, and perhaps AppLocker, with its ability to block Windows Installer packages as well as applications, can provide an answer. We shall see.

 

 

Setting Up AppLocker on a Server

 

Microsoft tends to speak of AppLocker and Group Policy objects (GPOs) in the same breath. If you’re deploying AppLocker to protect client computers, GPOs make a good way to do that. Servers, however, are rarely going to be entirely consistent with one another, meaning we’d have to have a whole slew of GPOs in order to define what each server was allowed to run. In fact, if you wound up with one GPO per server, it wouldn’t be surprising. That’s why local policy (can we call them LPOs?) are probably a better idea. Although they’re not centrally managed, we’re not anticipating a lot of frequent changes to them, so it shouldn’t be a big burden. Keep in mind, however, that it’s pretty easy for an Administrator to change the local security policy and – for example – temporarily shut off AppLocker. We’re not out to create a system that completely stops Administrators from exercising their privileges; we’re just putting some brakes on that kind of change.

 

Start by reconfiguring your servers to automatically start the Application Identity Service. New in Windows Server 2008 R2 (and Windows 7), this is the bit that actually implements AppLocker. Configuring the service through a GPO that applies to all of your servers is fine; you need not configure AppLocker itself in the same GPO.

 



Figure 1 – Application Identity Service

 

The next step is to configure AppLocker by choosing to enforce its rules. You have two ways in which to do that: Having it actually enforce the rules, meaning it will block applications that aren’t specifically allowed, or putting it into “Audit Only” mode. In that mode, the service will write event log entries when an application is blocked, but that’s all. It’s a way to test the system and make sure it’s not going to block anything critical, before you turn on full enforcement. You’ll find the configuration under the Computer section of the local security policy. The accompanying video shows you exactly where to drill down to find the AppLocker settings.

 



Figure 2 – AppLocker Rules

 

You’ll also want to decide what to enforce rules on. Your choices are:

  • Executables. Definitely – this is the core of what makes an application work.
  • Scripts. Perhaps not – you may want administrators free to run scripts.
  • Windows Installer packages. You’ll probably enable this, but be aware that it won’t block all software installations. SQL Server, the example I used earlier, doesn’t use Windows Installer because its installation is so complex.
  • DLLs. Definitely not. For one, monitoring DLLs will trash server performance. For two, you don’t usually need to. DLLs don’t execute alone; they have to be called by an executable. By controlling executables, you’re more or less implicitly controlling DLLs. It isn’t watertight – but it’s close enough.

 



Figure 3 – DLL Rule Collection

 

Next, you’ll likely want to set up a default set of rules. Three rules will be created by default:

  • Allow everything in the Windows folder. Leave this one, because it makes Windows itself work.
  • Allow everything run by members of Administrators. You’ll probably want to delete or modify this rule, since we’re explicitly out to control Administrators’ activities.
  • Allow everything in the Program Files folder. Again, you’ll likely want to remove this one and replace it with more-specific, per-application rules.

 

Finally, you’ll be ready to automatically generate rules. This is done by scanning a folder for executable files, and creating an individual rule for each one found. This is the quickest way to generate a set of rules that will allow everything currently installed on the server, and nothing more. You can then go on to manually create rules. The most useful kind of rule is a publisher rule, which will allow any application that’s been digitally signed using a certificate from a designated publisher (e.g., allow everything signed by Microsoft or by your company’s internal developers). That kind of rule is immune to application changes like patches, meaning you’ll have less ongoing maintenance. Signed applications are also immune to malware-based tampering, making signing a good practice in the first place.

 



Figure 4 – Automatically Generate Rules

 

With your rules in place, set AppLocker to “Audit Only” mode and keep an eye on it for a few days. It’ll log blocking events to an AppLocker-specific event log, which you can configure to forward to another machine if you prefer. Make sure you’re not seeing any unwanted block messages, and if you are create new rules to allow those applications.

 

 

AppLocker on a Server: Weak Points

 

We’ve run into two things that I consider to be major weak points. First, we’re putting hurdles in the way of administrators, but not really stopping them from installing and running unwanted applications. It’s simply too easy to stop the Application Identity service, reconfigure AppLocker rules, and so forth. If you’re after a system that will help honest people stay honest, then AppLocker is probably sufficient. If you want anything more, then you’ve simply gone beyond what AppLocker was designed to provide, and you may want to instead look at third-party application management software.

 

The second and more serious failing is in license management. Actually, I shouldn’t say “failing” because AppLocker wasn’t designed, and isn’t advertised, as a way to manage software licenses. It would certainly be nice, though, to be able to have servers at least report what applications they’re running, so that we could have a central report of what’s running and buy licenses appropriately. That’s not only a way to stay compliant with license purchases, but also a way to save money: You might be surprised, for example, to discover that in some cases you own more licenses than you’re actually using. In those cases, you can scale back on software maintenance contracts, make smaller upgrade purchases in the future, and so on. But you can’t do it with AppLocker: You’ll need third-party software management tools to gain those benefits.

 

 

Does AppLocker Belong on Your Servers?

 

AppLocker is certainly a useful tool, once you understand its basic limitations. Because servers tend to be less dynamic than clients, many of AppLocker’s weaknesses aren’t as bothersome, and the technology certainly does provide some advantages. Servers are perhaps the most locked-down machines in our environment, and AppLocker supports that attitude. It isn’t billed as an end-all, be-all software management solution, though: It doesn’t include license management features, and it’s not specifically designed to place strong restrictions on all-powerful Administrators. Supplementing AppLocker with broader software management tools can give you that extended feature set, and in some cases save you money in the long run.

Anonymous