I'm currently at a client where we're building an extranet solution for partners to login and collaborate with internal employees. Security is a significant concern because of the nature of the collaboration, and documents being shared.
The architecture we went with is rather interesting. It features two Web Front End servers that are in a DMZ (DMZ #2), and another web front end inside the internal network. This made it possible to keep internal users from needlessly leaving the network, while still preventing external users from entering the internal network.
Also, DMZ #2 is protected by another DMZ with Unified Access Gateway (UAG) for endpoint protection (DMZ #1). UAG will actually check the endpoint (laptop, mobile device, etc) for viruses, OS patches, etc, BEFORE it can access the resource(s). Additionally, there are hardware firewalls between the internal network and DMZ #2 and the internet and DMZ #1, as well as between the two DMZs. The figure below shows how this architecture looks pictorially:
There's obviously some detail not in the picture like DNS, AD DS and AD LDS instances, etc, but you get the idea.
While this is a pretty solid infrastructure from a security perspective, I also wanted to do some hardening within the SharePoint front ends themselves. The web front ends are in dedicated OU(s) in Active Directory. There's a group policy (GPO) on that OU that controls the IIS roles/features that are installed and configured. Additionally, there are other settings outside of IIS that from a security perspective I'm also checking off. Below is the "Checklist" I use when setting up the web front ends for hardening purposes, as well as for on-going maintenance:
GPO |
|
Uninstall all IIS roles and features that aren't used. Note: authentication modules that aren't being used are the most important to have disabled. |
|
FTP & SMTP services are not installed. |
|
Auditing is enabled in the GPO. |
Web.Config security Settings |
|
Request Filtering configurations present in web.config |
| |
Custom errors are enabled in web.config so unhandled errors aren't displayed remotely ("On" or "RemoteOnly" – not "Off"). |
| |
A custom code access security policy is specified in the web.cofig, granting full control to internally built DLLs, and unique IPermissions for third parties, per their requirements. |
IIS General Settings |
|
Each website is running in their own application pool. Each app pool has it's own, dedicated credential. |
|
Anonymous accounts on Web sites and applications are explicitly denied access |
|
All web sites are hosted on a drive other than the C drive |
|
Block access to the Site Data web service on all web front ends. Use a dedicated web front end for search crawling, that external traffic is not hitting and the Site Data web service is not blocked. |
Operating System Settings |
|
Windows firewall is configured, and all ports are blocked except 389, 80, and 443 |
|
No third party DLLs are in the GAC! If they are professionals, they will give you a code access security policy that defines what resources they need to have access to. |
|
Symantec Antivirus software installed and running. |
|
Forefront Security for SharePoint installed and configured. This scans documents for viruses as they are being uploaded. |
|
Local Administrator and Guest accounts have strong passwords (renamed if possible). |
|
Windows update running and patching OS (or under domain schedule) |
While I'm sure this list isn't exhaustive, it seems to be a pretty good start. The Windows Server team has done a lot to make most of this defaulted, but as the years go by, it's important to understand what you don't want to let "slip".
Phil