I’ve found a variety of links on securing SharePoint servers. However, many of them date back to the first release, and others are just incomplete lists. My intent here is to aggregate an up-to-date list, and I’m seeking community feedback on keeping it current. This post is more of a prose format than a checklist format, but my intent is to refine the content first.

Most of the tricks to keeping a server in any role secure seem obvious: keep it patched, remove unnecessary services, etc. But even those things are easier said than done, and it’s all too easy to forget a step.

Are you considering a SharePoint deployment? Or do you already have one that’s been running for a couple of years? Take a look at this list and let me know what you think.

First, some general considerations.

Are you using at least Windows Server 2003? Yes, I know there are tons of Windows 2000 (W2K) machines still in deployment, but that technology is just too old to keep reliably secure in the face of modern threats. A vigilant sysadmin can probably do so for an intranet-only server, but then again his or her time would be better spent on other things, so why not spring for the upgrade (or better yet, just get rid of the physical hardware, outsource the whole service, and hold the vendor to this list)? Definitely don’t use W2K for an internet-facing server.

If possible, the server should be fulfilling just a single role, i.e. serving SharePoint. Small shops will host the site and its database on a single server, which is fine. Big shops will separate those roles for scalability reasons.

Yes, many SharePoint deployments are based on Windows Small Business Server (SBS), in which case the server is performing lots of roles, has lots of services running, and lots of ports open. If that applies to you, refer to the other points herein and do your best. But know that if you’re running SBS 2003, which includes Windows SharePoint Services (WSS) 2.0, you can still deploy WSS 3.0 and gradually migrate your data (see this link). That’s generally advisable in order to take advantage of the higher security bar that Microsoft applies (usually) to each successive version of its products.

Regardless of which version of Windows you’re running, is it fully patched? Small shops should configure automatic updates. Big shops have the infrastructure to do pre-deployment testing of those patches. In my experience, if you’re running the most recent version of a web applications such as SharePoint, and running it on a single-role server, compatibility problems with “Patch Tuesday” are very rare.

Is SharePoint itself fully patched? Per my previous comments, you’re hopefully running the latest version. However, some scenarios, such as Team Foundation Server and SBS, have a dependency on WSS 2.0. In any case, ensure you’re running the latest service pack and patches for whichever major version you’re supporting.

Now to drill down a bit.

Is your SharePoint server running Terminal Services in application mode with NT4 security compatibility enabled? Check out this TechNet article. If you are, it’s essentially impossible to keep your server secure. Ditto if you’re not using NTFS, by the way.

Regarding IIS configuration, is a separate anonymous user (IUSR) account set for each virtual web site? That’s a good role separation and defense-in-depth measure.

Regarding the database, are you using SQL or MSDE? Smaller shops are probably using the latter, unless you installed SQL on the machine before installing WSS. In either case, be sure to check whether default passwords are still in use for the database.

Now onto specific SharePoint configuration considerations.

First, WSS exposes an administration website on a separate high TCP port (i.e. as opposed to the standard HTTP/80). This list applies to the admin port:

1. The admin website should be configured to require server authentication (HTTPS/SSL/TLS). Otherwise, admin passwords may be traversing your network in plaintext.
2. The Windows firewall, or a comparable product, should be enabled.
3. The WSS admin port should be protected by a firewall rule which filters inbound traffic. Try to limit that number of workstations that can send traffic to that port, for example.
4. The admin site should require Integrated Windows Authentication (IWA), that is, NTLM or Negotiate. Don’t use Basic authentication if you can avoid it, even if you’re protecting the channel with SSL.

What about the main SharePoint site itself? Well, speaking of SSL, similar considerations apply to the main site. After all, your users are likely uploading and downloading sensitive corporate information to and from WSS on a regular basis.

1. At least allow HTTPS on the WSS user site. If the server load bears it, require HTTPS on that site.
2. Use integrated auth on the main site (see above).

For internet-facing servers, has a special role been created to give Everyone browse access? This is a WSS administration best-practice.

On intranet-facing servers, has anonymous access been disabled? On the LAN, all clients should be required to connect via IWA.

Finally, here’s a list of potential issues cited for SharePoint v1. I haven’t confirmed whether they still apply – can anyone comment?

1. Can users connect directly to the Search Proxy virtual server? They don’t need to be able to in order to have full functionality, so better to block it.
2. Is the File System Object (FSO) enabled? It’s not required, so disabling it is a good measure to reduce the attack surface of potentially malicious scripts running on the server.
3. Is the Windows Script Host enabled? See previous.

Other SharePoint security links:

• http://www.microsoft.com/technet/prodtechnol/sppt/SharePnt/stssecur.mspx
• http://www.sharepointsecurity.com/
• http://www.shavlik.com/products/netchk-limited.aspx
• http://msdn.microsoft.com/en-us/sharepoint/bb851470.aspx

No Comments »