Umbraco Security Best Practices

As part of a project we're just completing we had the occasion to review some of the file level security for Umbraco.  What we found was quite encouraging - namely that an Umbraco installation can be made secure very easily.  The one issue that came up is that a user, following the Umbraco installation guide, is left with some less than ideal security settings that could, potentially, result in a compromised installation.  Taking cues from project team members and loads of installation scenarios, I created the following brief security guide.  The guide is intended to get a new Umbraco installation to a more secure state than it would be otherwise, it is far from being comprehensive.  As always, we value your input.

<><><><><><><><><><><><><>

Umbraco Security Best Practices for Installations

<><><><><><><><><><><><><>

After an Umbraco installation is completed you may find that some security settings are left as less than optimal.  Following is a brief guide to making some simple changes that will help make your Umbraco installation more secure.  There are two sections following; the Quick Guide, which every Umbraco site owner should read and implement, and the Full Guide outlining additional steps to be considered.

Quick Guide:

1. Set (or reset) Acl's as follows:
a. For the web site's Application Pool Identity :
  i. Generally the Application Pool's identity is Network Service, but if you are using shared hosting this may not be the case
   1. From IIS Manager each Application Pool will have its identity set as a property
    ii. Set the Acl for the file <web site root>\web.config to Read (Make sure to remove Full Control, Modify, and Write)
    iii. Set the Acl for the following directories to Read (Make sure to remove Full Control, Modify, and Write)
     1. <web site root>
     2. <web site root>\bin
     3. <web site root>\umbraco
    iv. For the following directory set the Acl to Read & Execute
     1. <web site root>\app_code
     2. <web site root>\usercontrols
    v. For the following directories set the Acl to Read, Modify
     1. <web site root>\config
     2. <web site root>\css
     3. <web site root>\data
     4. <web site root>\masterpages
     5. <web site root>\media
     6. <web site root>\python
     7. <web site root>\scripts
     8. <web site root>\xslt
2. Remove the <web site root>\install directory
3. Set strong passwords for the Umbraco Database User or use Integrated Security (if using SQL Server or SQL Server Express) to connect as the web site's Application Pool identity
4. Set strong passwords for Umbraco users

Full Guide:

1. Set Acl's and password recommendations as above
2. Follow the recommendations outlined here http://tehchnet.microsoft.com/en-us/library/dd309461.aspx for setting secure Acl's
3. Follow the detailed recommendations outlined in this excellent whitepaper (.NET 2.0) http://msdn.microsoft.com/en-us/library/ms998372.aspx - most of the recommendations here are implemented by Umbraco and are applicable to .NET 3.5 as well

Note:  This is a brief guide that outlines only the most basic tasks to help secure your Umbraco installation.  In a production and/or critical environment we strongly recommend using a hardening protocol (such as the IIS Security Planning Tool or other available resources) that is outside the scope of this guide. 

9 comment(s) for “Umbraco Security Best Practices”

  1. Gravatar of Casey
    Casey Says:
    ACL settings are a touchy subject. In many systems, you want to lock down folders like bin and app_code. However, since umbraco has a package installer that relies on copying files to these and other locations, it is not prudent to lock them down for novice users.

    The umbraco, usercontrols, and a few other select folders do not have a reason to be locked down specifically as things can be loaded from a variety of locations.

    It is a matter of determining what is necessary and what is reasonable for new users. A security best practices guide should be provided to users, or even embedded into the core to warn developers that they should secure things on a production site.

    There is no right answer here.
  2. Gravatar of PeterD
    PeterD Says:
    In many situations you need to have loose ACL's at first because you are starting a new site. When the site is finished, you probably don't install packages that often anymore. ACL's should then be locked down further.
    Perhaphs something in the line of the Web PI, it sets the ACL's on installing. Would it be an idea to give a choise of ACL when installing and have a seperate Web PI-installer that secures things down when you chose to have open ACL?
    Just thinking out loud here.
  3. Gravatar of Jason
    Jason Says:
    Thanks for the info. Regarding DB and integrated security, that is only applicable when the db is on the same server as IIS, correct?
  4. Gravatar of Paul
    Paul Says:
    Jason - Integrated security is simply the concept od using the App's run-as user (AppPool identity) to connect to the db - applicable on single server, differeent servers, server farms, etc....

    -Paul
  5. Gravatar of JessicaFATS
    JessicaFATS Says:
    Great point and very interesting food for thought. I'm not sure I have any clients I can replicate this with, but will bear in mind for the future. Regards
  6. Gravatar of Matt Perry
    Matt Perry Says:
    Paul,

    You could also add this to the web.conig httphandlers section to stop XSLT's being served and viewable to all.

    < add path="*.xslt" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" / >
  7. Gravatar of Paul
    Paul Says:
    Matt -

    Excellent, I'll add it, thanks!
  8. Gravatar of Arianafuet
    Arianafuet Says:
    hi, thanks,The article was very well written, very helpful to me
  9. Gravatar of Ativan
    Ativan Says:
    Save up up to 50, and more. Generic best price Ativan
    And at the end don't forget to say thanks amigo