Web server security
I often wonder if people are really bothered that much about security. On many forums we see endless posts like 'Hey! What's this in my access logs?!', or 'Help! database hacked?!', etc, etc..
My first approach to setting up any server, is to ask myself 'what is it serving?' Mostly this process in itself will eliminate any issues. How? I'll give a few examples and say no more.
1. Serving images.
For large websites it's best to host images on separate image servers. On these I only run Nginx. To be fair, I've found little difference in performance between Nginx and a stripped-down Apache, so why Nginx? It's simply much easier using Nginx to have a small configuration section like:
## Deny access to any host other than (www.)mydomain.com
server {
server_name _; #default
return 444;
}
## Only allow these file types to document root
location / {
if ($request_uri ~* (^\.gif|\.jpg|\.png)$ ) {
break;
}
return 444;
}
## Only allow GET and HEAD request methods
if ($request_method !~ ^(GET|HEAD)$ ) {
return 444;
}
Simply put, if the request isn't for www.mydomain.com, drop it. Also if the requested resource isn't one of the file types listed, drop it. Finally, drop all request methods except GET and HEAD.
Much easier than fiddling around with Apache, and in fact Nginx doesn't return a 444 status to the client, just an empty tcp reset packet, which will do nicely.
Any requests not matching the above are therefore rubbish, and can be immediately dropped.
2. Databases - usually MySQL these days
Why have one database user? I have one user with all permissions, and another with only READ access (SELECT etc..). Only use the latter when accessing web pages and you've eliminated many possible attacks immediately.
Obviously if you're offering user feedback, and data based on that feedback is destined to be input to your database, then a little extra data filtering is required, and the database (web)user requires more permissions, but is UNION required? There is still room to restrict permissions wherever possible.
I could go on, probably will in a later post, but you probably get the idea by now anyway.
