So typically, what I do when I deploy a site to the live environment is the list below. Anything else I need to remember?
- In the web.config I change the connection string to the new database environment. I SHOULD really encrypt the database credentials. - Set umbracoDebugMode to false - Set umbracoDisableVersionCheck to false (I can decide for myself when it is time to upgrade and don't want editors to be seeing the upgrade pop-up). - In the system.web section I set custumerrors mode="RemoteOnly" so I can still debug when logged into the server
Of course I meant true.. grrr, I hate double negations, just like the != operator!
Ah, good one, I've never actually set debug to false, Umbraco is pretty damned fast already... If you use XSLT instead of ONLY using usercontrols.. ;-)
I'd set trace to false as well, just to be on the safe side. I'd also set up a custom error page, and set the web.config to use it, so that users don't get to see the YSOD if your site breaks.
If you're particularly security minded, you can restrict access to the /umbraco folder in IIS to just the IP addresses of the company using it and yourself, to prevent unauthorised access to the back end.
Why does the umbraco worker process user need all these database role memberships, particularly db_ddladmin & db_securityadmin, which doesn't make it particularly secure if the site gets hacked?
I intend to make my server more secure than the default umbraco installs - by using Windows Authentication instead of SQL Authentication, by using a specific Windows account to run the website worker process instead of NETWORK SERVICE or whatever Win2K8 assigns you (I'm using 2003 at the mo though), and by restricting permissions in SQL to just the stored procs and tables that it needs to execute/read/write to
db_datareader and especially db_datawriter usage is also not very secure as the umbraco service account can then write (delete) any data it likes.
I'm completely new to umbraco, not trying to be over-critical of it I just genuinely don't know if/why it needs these database priviliges so if anyone can help me out and educate me it would be much appreciated, cheers.
Unfortunately my database security skills are almost non-existent. In fact, I usually run sites with a user that has db_owner, just to make sure that everything works. It should be fine if the user is restricted to that database only.
I am not sure why Umbraco being able to delete tables would be a big problem, this makes life much easier for package developers who need to create new tables and delete them when an uninstall is done.
I'm sure you could lock down the database much more than is usually done though, I just don't think many people have tried to do so.
Turning Umbraco's logging off (/config/umbracoSettings.config) and deleting the current log (TRUNCATE TABLE [dbo].umbracoLog) speeds things up quite a lot, as well as reducing the size of the DB.
Best practices for live deployment
So typically, what I do when I deploy a site to the live environment is the list below. Anything else I need to remember?
- In the web.config I change the connection string to the new database environment. I SHOULD really encrypt the database credentials.
- Set umbracoDebugMode to false
- Set umbracoDisableVersionCheck to false (I can decide for myself when it is time to upgrade and don't want editors to be seeing the upgrade pop-up).
- In the system.web section I set custumerrors mode="RemoteOnly" so I can still debug when logged into the server
Anything else I need to consider?
"Set umbracoDisableVersionCheck to false"
You mean you set it to true right?
You're forgetting the <compilation debug="false" />, I can't imagine you're not setting it to false ;-)
Of course I meant true.. grrr, I hate double negations, just like the != operator!
Ah, good one, I've never actually set debug to false, Umbraco is pretty damned fast already... If you use XSLT instead of ONLY using usercontrols.. ;-)
I'd set trace to false as well, just to be on the safe side. I'd also set up a custom error page, and set the web.config to use it, so that users don't get to see the YSOD if your site breaks.
If you're particularly security minded, you can restrict access to the /umbraco folder in IIS to just the IP addresses of the company using it and yourself, to prevent unauthorised access to the back end.
Thanks Tim! I'm putting all this in a wiki article.
Hi folks. Just been reading the Installing wiki at http://our.umbraco.org/wiki/install-and-setup/how-to-install-umbraco-on-windows-server-2008 and this forum thread seemed an appropriate place to add my comments.
Why does the umbraco worker process user need all these database role memberships, particularly db_ddladmin & db_securityadmin, which doesn't make it particularly secure if the site gets hacked?
I intend to make my server more secure than the default umbraco installs - by using Windows Authentication instead of SQL Authentication, by using a specific Windows account to run the website worker process instead of NETWORK SERVICE or whatever Win2K8 assigns you (I'm using 2003 at the mo though), and by restricting permissions in SQL to just the stored procs and tables that it needs to execute/read/write to
db_datareader and especially db_datawriter usage is also not very secure as the umbraco service account can then write (delete) any data it likes.
I'm completely new to umbraco, not trying to be over-critical of it I just genuinely don't know if/why it needs these database priviliges so if anyone can help me out and educate me it would be much appreciated, cheers.
Unfortunately my database security skills are almost non-existent. In fact, I usually run sites with a user that has db_owner, just to make sure that everything works. It should be fine if the user is restricted to that database only.
I am not sure why Umbraco being able to delete tables would be a big problem, this makes life much easier for package developers who need to create new tables and delete them when an uninstall is done.
I'm sure you could lock down the database much more than is usually done though, I just don't think many people have tried to do so.
For maximum security settings on the file system, have a look at this blog post by Chris Houston.
Two other suggestions for live.
is working on a reply...