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!

 

Hardening SQL 

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).

 

Routers:

  • Block unused protocols and ports (see ports required, below)
  • Screen Traffic (e.g. ICMP)
  • Intrusion Detection should be in place

 

Firewall

  • 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.

 

Switches

  • 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!

 

External:

  • Http 80 / TCP
  • HTTPS 443 / TCP
  • SMTP 25 / TCP

 

Internal*:

  • 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.

  • Martin Hatch

    Anon,

    TBH very few companies I have worked with have actually been interested or properly engaged to test this properly.. it just doesn't seem to be a priority for many implementations.

    For those that do, typically they would bring in a specialist security company to do a threat analysis and testing on the farm (both black box and white box).

    Personally I'm not a security expert so I don't know what exact techniques which would be used in such tests

  • Anonymous

    Did you have any testing in place post hardening to verify settings/changes etc.? If so, how did your testers go about that?

  • Martin Hatch

    Hi anon!

    Those ports are indeed internal to the farm (i.e. server to server communications between the SharePoint servers in the same farm).

    The port numbers are for SharePoint 2010, and were taken during the (pre-Beta) SharePoint Conference 2009 back in October, so it is possible that these values changed by RTM (although I would doubt it .. otherwise, why tell us at the conference?)

    cheers

  • Anonymous

    What do you mean with the note on "Internal"? Are those the ports required for server communication in a farm, or is that something else? If I remember correctly, I think the ports for inter-server communication in MOSS 2007 was 56737, 56738 or something like that.

  • Chris

    Thanks so much for posting this. Really good stuff here! -Chris