Securing SharePoint 2010 Web Servers
This was one of the best topics I’ve seen so far at the conference. The amount of concrete information was impressive (and to be honest a bit too much to post here) but there was some great information on how to harden your Web Servers.
SharePoint 2010 Security Features
There are a whole load of new features and changes to the SharePoint 2010 product for security.
- ASPX Pages are gone for contributors. You can no longer upload ASPX pages into document libraries unless you have "Designer" permissions! The main reason this becomes possible is because the new Wiki Pages are so much more extensible than they were.
- Anonymous Users Lockdown feature now works for Web Services and WSS (SharePoint Foundation 2010)!
- PowerShell Access – you can now delegate remote scripting rights through PowerShell, so you no longer need the Setup account to perform PowerShell commands. This can be delegated to farm administrators!
- XSS (Cross Site Scripting) protection is now in place through the headers (although you can turn it off). This can be even be locked down to individual web part properties (through development)!
- Application Page settings can now be controlled more granularly, so that you can set the master pages used and even swap out individual pages (such as the Error Page). This makes lock downs and branding of these far easier, without breaking the supported state of your environment, and without extensive development!
There was then whole load of recommendations for hardening your environments. It’s a bit of a list so apologies for that, but a lot of information to get through:
Hardening your Web Application
- Place your web application directories on a non-system volume. If you have any issues with logging or file access then the I/O operations (or even disk space requirements) could damage the Operating System!
- Change the IIS header. By default this will include the SharePoint version number (which means any attacker knows which service packs and critical patches you have installed!). Removing this reduces your public footprint
Hardening your Web Servers
Windows Server 2008 takes care of most of the previous recommendations for hardening automatically, but there are still some things that you should do:
- Restrict remote administration of the Registry (no-brainer, but a lot of people forget to do this)
- Rename Administrator account
- Delete / Disable unused accounts (again, make sure your dev and test accounts don’t hang around on the web front ends)
- Use the IUSR instead of IUSR_<serverName>
The IUSR account is a "built in" account so therefore it doesn’t have a password and no-one can login using that account. This makes it much more secure than the Server specific IUSR account that gets created!
There’s a whole load about this on the internet. The only one to mention here is change the port number! There are a lot of viruses and malware that will specifically target this port.
Hardening your Network
Again, none of this is SharePoint specific, but goes a long way to making sure that your network in general is secure (which is of course best practice for SharePoint systems).
- Block unused protocols and ports (see ports required, below)
- Screen Traffic (e.g. ICMP)
- Intrusion Detection should be in place
- Use packet filtering policies
- Log your permitted / denied traffic, and make sure those logs are checked (using alerts)
- Make sure perimeter networks are firewall secured, effectively providing end to end firewall security.
- Disable any unused services in the switch
- Do not overly trust VLANS. Just because your traffic is isolated to a VLAN doesn’t mean you shouldn’t still block off the relevant ports and protocols.
Ports Required for Web Servers
Note – When SharePoint is installed the communication ports are automatically opened on the Windows Firewall!
- Http 80 / TCP
- HTTPS 443 / TCP
- SMTP 25 / TCP
- HTTP 32843/TCP
- HTTPS 32844 / TCP
- TCP 32845 / TCP
- SMB 445 /TCP|UDP
* note that "internal" means Web Application –> Service consumtion over WCF. It does not include SQL or inter "server" communications.