One of the things I speak about most frequently is Security and SharePoint. I have focused on hacking SharePoint, all the way to trying to secure it better for the many different types of environments that I see.
An important part of securing SharePoint is really the hardening of the underlying services and operating systems. There are many documents out there from Microsoft and others that outline how to harden Windows Servers.
In my demonstration environments, I now always use Server Core for SQL and also for the domain services. This not only gives me great performance on the smaller spec’d machines but helps reduce the overall footprint of the servers themselves. However right now, you have to do a full operating installation, GUI and all for SharePoint to work, too many dependencies for Server Core right now.
So the question is how do we make the attack surface a little smaller?
This brings me to a features that may not be so well known in Windows called “AppLocker“. This was introduced a few Windows versions ago, and is available in Server 2012 R2 which is what I am using within my SharePoint 2013 environment. “AppLocker” is not enabled by default, so we need to enable this through the “Local Security Policy” configuration.
To enable it open up the “Local Security Pool” tool using “gpedit.msc“.
Once this loads we need to expand the following.
Expanding and then Clicking on “AppLocker” will display the following in the right and left panels.
In order to use the “AppLocker” a service needs to be changed from “manual” to “automatically” start. You can see the name of the service listed in the “Configure Rule Enforcement” box.
So to change that services, open up “services.msc” and make the change.
Ensure the service is “Started” then we start configuring the rules.
In the right panel, we now need to click on the “Configure Rule Enforcement” options and for this demonstration I am going to enable check the following options.
Once we apply this we can now start to apply policies for specific applications that will be allowed to work. However firstly the easiest approach is to run an automatic check to generate rules for us that we can modify later.
Expand the “AppLocker” node on the left, and then right click on “Executable Rules” and choose “Automatically Generate Rules”
The wizard will then take us through the process of creating rules based on locations of applications.
For this we are choosing “File Hash” as the match though path location could be used. Once the wizard runs it will report back the number of applications, and allow you to review what they are.
As you can see from this list, it has found many executable and each one is selected telling “AppLocker” to create a rule that will allow the application to run.
If we were to uncheck them, then that application would not be allowed to run on the server. Finally we click “Create” and the core rules are generated for us.
When prompted to create the default rules, simply select “Yes“.
As you can see the rules have been created.
Right now as an Administrator, I can run any applications I want and this is due to the following rule.
However we need to add a specific rule with an exception to a specific location and executable then I am not able to launch that application at all. For this I copied “ulsviewer.exe” from its location to a folder called “C:\Blocked“. Editing the rule allows us to set properties to the specific executable. To create a new rule right click on “Executable Rules“, and choose “Create New Rule“.
For this rule we will choose “Deny” as the action and the “User or Group” will be “Everyone“.
We will choose the “Publisher” as we know that this application is signed by Microsoft.
Next we select the file “ulsviewer.exe” as the file and choose “Create“.
Once completed we should now have a single “Deny” rule listed.
Now when I try to launch the application I get the following message.
We should also see in the event viewer, an entry saying it was blocked, along with other that say they have been allowed to run.
With the “Automatic” generation of rules on a SharePoint Server, the majority of rules work as expected with no errors. There are however components that may need to manually configure. As an example running “Central Administration” works and I get an entry listed for allow.
Of course with most things, testing is important to ensure that all the components you need are functioning as expected. Enabling “AppLocker” is a great way to stop other processes from being run on the servers, stopping those “pesky” developers (just kidding) from dropping random code executables on the server and running them. It does bring an extra level of management, but for hacking exploits that require an executable to be ran this can go a long way to block that.
Well, as long as you log in as an admin account, which you more often than not would do for patching/maintenance or adding customizations like WSP packages (yikes!), couldn’t you have the permissions to change the applocker rules anyway? Unless you can lock the bitlocker somehow 🙂
As I am sure you know, logging is Administrator for administration would be a “no-no” anyway. Using separate install and configuration account outside of Administrator is recommended. For this you would of course have an Administrator account that can do anything, and my default a rule is added for that account to do anything. The setup/install/farm account would not have that permission and should only have the required permission. That account would not be able to modify the AppLocker rules. Then every other account would use the standard rules defined to restrict what accounts could do what.
You must log in to post a comment.