SharePoint Security: Server Hardening

Security is important. We all want it. When we're children, security can take the form of our favorite "woobie." As we get older, our woobies change. Our SharePoint servers want security, too.

Although SharePoint security takes the form of something less embarrassing than a pink blanket, it too can change over time as threats change. This article discusses some of the things your SharePoint server needs to be secure. Even if you've taken security measures in the past, this article might open your eyes to more ways in which you can improve SharePoint security.

Applied Lessons

Whenever I talk about security, I'm reminded of the lessons I learned in two security talks I heard while in the Army. Although those discussions were in the context of physical security, their principles are every bit as applicable to SharePoint.

The first lesson is that the whole point of security is not necessarily to make yourself impenetrable, but to make yourself a tougher target. Locking the door to your house doesn't mean that it's impossible for someone to get in, but it does make doing so more difficult. SharePoint is the same way. You shouldn't abandon a security measure just because it won't stop 100 percent of attacks. The harder a target your SharePoint server is, the more likely an attacker will move on.

The second security lesson I learned is to always trade convenience for security. Unlocking the door to your house is less convenient than just walking right in, but that inconvenience gets you increased security. I like to think of security as a line, with "convenient" on one end and "secure" on the other. For any given situation, a different point on that line is appropriate.

You can make things so secure that they're too tough to use, such as requiring user passwords to be 14 or more lowercase and uppercase characters, numbers, symbols, and two guttural noises -- oh, and making users change it every day. I think we've all worked at a company that has that type of policy. Although a password like that would be hard to hack, it would also be so inconvenient that people either wouldn't use the service or would write down their passwords. It's also possible to make a password policy so easy that it provides no security whatsoever.

As you're assessing your SharePoint farm and reading security articles, evaluate each solution and determine its place on the convenience-security spectrum.

Account Security

One of the first things you can do to harden your SharePoint farm against attackers is to install and configure it by using a least-privilege approach. Give each function that SharePoint performs its own account, and give each account only the permissions that it needs to do its job -- nothing else.

That way, if the account is compromised, the attacker will have access to only a small footprint. (To get started, read my blog post on SharePoint service accounts.) When you start here, your processes will have good isolation; if any accounts are compromised, the damage can be contained. For instance, if your sp_serviceapps account is hacked, the attacker will have limited permissions on the server and probably won't be able to take over the entire machine.

This method is less convenient than using one account for everything, but it provides good security boundaries. The major inconvenience that comes from a least-privilege approach is keeping track of all those darned passwords.

If you follow the blog post that I mentioned earlier, you'll start out with nine accounts, which means nine passwords. Coming up with nine passwords that aren't pass@word1, pass@word2, and so on is difficult enough, but then you'll need to change them. (Of course, changing your service account passwords frequently -- every three to six months -- is another good way to make your SharePoint farm more secure.)

Although I can't help much with the password generation, I can help with the change process. In another blog post, I walk through each of the accounts and how to change each password with minimal downtime.

Before we move on from accounts, there's another thing you can do to make your system more secure: Stop logging in as the Farm account when you do general administrative tasks. It's a bad habit that we all get into, but it opens up our SharePoint farms to attack.

If we do day-to-day admin activities, we run the risk of hitting any number of exploits that are out there. Running those exploits as a regular user is bad enough; running them as a user with elevated privileges in SharePoint is even worse. It also makes auditing difficult. Instead, each SharePoint server administrator should have a privileged account to use when performing tasks in the farm.

Unfortunately, SharePoint has many little places where account permissions must be provided for administration. (Get full directions for this approach at my blog.)

Machine Security

SharePoint requires a large cast of characters -- including Windows, Microsoft IIS, SQL Server, and Active Directory (AD) -- to pull off its magic. Although those characters are important, security problems with any of them can spell disaster for a SharePoint farm. Keeping those pieces secure is part of a good SharePoint administrator's job, too.

Unfortunately, doing so isn't as easy as setting Windows Update to do its thing and then walking away. Windows Update is an important part of keeping your servers updated, but you must be careful when using it with SharePoint servers.

Windows Update updates more than Windows; in some cases, it can patch SharePoint. For example, a recent SharePoint security patch, MS12-050, snuck out in a Windows Update. It patched an important security hole but took many SharePoint administrators by surprise. Admins didn't realize that their SharePoint servers had been patched, and even worse, they didn't know that they needed to run the Configuration Wizard to finalize the patch's installation.

SharePoint 2010 handles this type of issue pretty well, but stability problems can occur, and you can't manually install any patches until the Configuration Wizard has been run successfully. There were a lot of very secure but very unhappy SharePoint farms after that patch came out.

To keep your SharePoint infrastructure safe and operational, you need to leverage Windows Update, but you also need to be vigilant about researching each patch. For example, before patching SQL Server, make sure that patch won't negatively affect SharePoint. Patching is an important part of hardening a server but must be done with due consideration.

Part of a good patching process is having a test environment. Your test environment will never exactly mirror your production environment, but you should get it as close as possible: Use the same version of Windows, use the same version of SharePoint, and configure the test environment to be as like your production environment as possible.

SharePoint gets cumulative updates every other month. These updates are generally bug fixes, not necessarily security fixes. Install these patches only if they patch a security concern or fix a specific issue that you're having with SharePoint.

Don't install the patches just because they're available or because you want to impress your buddies with how current your SharePoint farm is. The patches aren't as rigorously tested as you might want.

In a couple cases, a cumulative update has had such significant issues that it was pulled. I suppose you could argue that a server that can't serve pages is incredibly secure, but I think we can agree that it isn't a good situation.

Another way to keep your SharePoint server secure is by blocking ports that SharePoint isn't using. Doing so reduces the chance that a random exploit can be used to penetrate your server. Table 1 shows some of the common inbound ports that SharePoint servers use.

Windows 2008 and Windows 2008 R2 include a Security Configuration Wizard (SCW) that can help you lock down the Windows part of your SharePoint server. You can find a link to the SCW under Administrative Tools or in Server Manager. The SCW walks you through the process of determining which roles your server is performing and which ports it's using.

Run the SCW after SharePoint is installed and configured. When the SCW finishes running, it gives you a security profile that you can apply to your server. This is a relatively easy way to lock down your server, but be careful: You can lock it down too tightly.

Make sure you understand how to roll back any changes that the SCW makes. Also be aware that running the SCW on a production server during business hours might result in users meeting you outside your office door with pitchforks and torches. It's best to run the wizard during scheduled downtime.

If you choose not to use the SCW, make sure your SharePoint servers have the appropriate inbound and outbound ports open. I don't typically lock down ports until after I have SharePoint up and running correctly. That approach helps in troubleshooting.

If everything worked fine right up until I locked down the ports, then I know that the lockdown was probably the issue. If I have all the ports locked down initially, and I can't get the Managed Metadata Service application to work, it might not be obvious that the problem is because port 32843 on my application server isn't accepting connections from my web front ends.

Security issues are notoriously difficult to troubleshoot. In an effort not to give bad guys much information on what went wrong, security errors don't give the good guys much information either.

If you want to take your network security up another level, introduce a reverse proxy between your servers and end users. This approach adds another level of protection because the bad guys can't probe your SharePoint servers directly to figure out exploits.

Your reverse proxy (or other network device) might also be able to perform more complicated scanning on requests that come in, to help determine whether they are malicious. Although this might seem redundant (a bit like wearing a belt with suspenders), it can make your SharePoint environment more secure and might take some computational burden off your SharePoint servers.

Reverse proxies can also terminate SSL connections or perform load balancing, meaning your SharePoint servers don't need to. They'll have more resources to do the thing they love most: rendering those beautiful SharePoint pages.

Antivirus Software

Any discussion about keeping your Windows server secure must include a talk about antivirus software. In the context of SharePoint, we need to have that talk twice: once for the server and once for your SharePoint content. As you'll see, the implications for each are very different.

Let's start by talking about machine antivirus. This is the antivirus software we've all grown to love on our Windows PCs and servers. It's usually managed at an enterprise level, and you should be running it on all your SharePoint servers.

However, when you run file system antivirus on a SharePoint server, it's important to exclude some SharePoint directories from the scans. These scans can interfere with SharePoint's ability to quickly read and write files and can give false positives.

The Microsoft article "Certain Folders Maybe Have to be Excluded from Antivirus Scanning when You Use a File-Level Antivirus Program in SharePoint" has the full list of directories to exclude. The list is quite extensive. Antivirus software needs to be running on your servers, but not in such a way that it impedes SharePoint from doing its job.

The second aspect of antivirus software is the SharePoint-aware antivirus software that you can run on your SharePoint servers to scan documents as they are uploaded and downloaded. SharePoint itself doesn't come with antivirus software, but it does contain hooks for third-party software, which can then scan files on upload, download, or both.

That software can also run periodic scans of the files in the farm, in case new antivirus definitions sniff out infected files that were missed previously. Some third-party antivirus software also lets you scan with multiple engines.

Although this software does offer protection, it doesn't protect your SharePoint servers, only the desktops that are downloading the documents. Having multiple layers of protection is good, and this type of antivirus scan is another example of "belt and suspenders" protection.

In a perfect world, the endpoint's antivirus software would catch any infected files that users downloads from SharePoint, but we all know this isn't a 100-percent solution. Virus definitions might be slow to roll out to desktops.

Worse yet, you might not have control of the desktops, which might not have any antivirus software at all. You might be thinking that isn't your concern as the SharePoint administrator, but if a home user's machine becomes infected by a PDF document from your SharePoint farm, it's your site that will get a bad name.

To be a responsible SharePoint administrator, you should consider scanning the documents in your farm for viruses. This scanning uses resources on your server; take that into consideration when sizing out your servers and planning your antivirus-scanning approach.

You want to keep your farm free of creepy-crawlies, but not at the expense of overall performance. As with all security measures, you need to find the right balance between secure and convenient.

Make Your Security Stretch

Security is a wide topic, stretching into many corners of SharePoint. In this article, we covered some ways that you can make your SharePoint servers more secure by locking down ports, securing service accounts, and running antivirus software. (The Microsoft article "Plan Security Hardening (SharePoint Foundation 2010" offers additional details.)

Hopefully, these security techniques will fit into your existing security toolbox and help you keep your SharePoint servers safe and secure.

Table 1: Commonly Used Inbound Ports