I took a look at the Canonical Topics ServerFault has and sadly the one I was after "Apache vHost" was on the list of unanswered questions. I found this a little surprising as there are loads of people asking just that question.
Anyway, my question isn't so much about "how" but rather what are the "best practises" to use in a Virtual Host configuration file? I have the following virtual host:
<VirtualHost *:80>
ServerName example.com
DocumentRoot /home/webmaster/examplesite.com/htdocs
ErrorLog /home/webmaster/examplesite.com/logfiles/error.log
CustomLog /home/webmaster/examplesite.com/logfiles/access.log combined
</VirtualHost>
It does the job and gets things working, however I wanted to know if I could improve on it. In particular I would like to make sure that the following issues are dealt with:
- How secure is my site?
- I would like to have an "uploads" folder where users can post images to. Do I need to add something to the vHost file?
- Does the above setting optimise my website, or can I optimise it further?
- Anything else I may have missed?
Storing your logfiles so they are potentially publically accessible is a bad idea. Error message printing should be off in production, so attackers are blind (they can't use error messages against you[1]). With access to the error logs, they have a stronger chance of trial and error.
You want to place uploads outside the document root, to reduce the chance that a user can upload a script (e.g. PHP) and then browse to it, and run it. Naturally this isn't the only protection you should have, but it's certainly one of the components.
You can't really optimise your website that much with a vhost - that's Apache level configuration (outside the scope of this question.)
It's difficult to tell, to be honest. Everyone has different requirements. For example, if your website is
example.com
- would you expectwww.example.com
to work too? If so, you're missing aServerAlias
.[1] Imagine they could generate an 'invalid SQL' error. The they know they have found an input which is not cleaned, and have quickly found a way to break into your website. The worst part is: these kinds of attacks can be automated.