More automation needed
Although I've managed to configure the server such that there's a fair amount of automation for appropriate tasks (phone homes, automated monitoring and basic defenses), the time needed daily to monitor/maintain it still adds up...and is unreasonable collectively.
Looks like I'll have to look into further automating some of the tasks...
DNS rebinding defense with Nginx
DNS rebinding's a particularly nasty attack, having similar characteristics as CSRF attacks where the user's browser can be used to access/attack sites on behalf of the attacker.
I'm not going to describe how it works here, there's plenty of literature out there that talks about it. And if that's not enough, Google Is Your Friend.
One of the simpler ways to defend against it is to have the server only serve requests with legit Host headers, which is what Wikipedia says anyway. (No I didn't edit that portion myself) This can be simply done with virtual hosts (HTTP/1.1), and can work for servers serving one domain, or two, or three, or many many many.
For nginx, a default catchall virtual host might look like this:
server {
listen 80 default;
server_name can-be-anything-not-served;
access_log /path/to/log/weird/access.log;
error_log /path/to/log/weird/error.log;
root /path/with/only/an/empty/index/html/file;
index index.html;
}
Note that this is configured to be the default listener on port 80 for this virtual host. Make sure your actual virtual host(s) configuration does not have the 'default' option.
The server_name can be anything other than the actual virtual host(s) that the server is serving on port 80.
I usually put nothing (only empty index.html files) in that root folder for this catchall virtual host,but you're free to put other files to serve indicators to your users, or just to taunt them when they get subjected to DNS rebinding attacks unknowingly. Just kidding about the taunting.
With this default catchall virtual host in place, you have a simple yet effective defense against DNS rebinding attacks! Now watch the attacks get thwarted like eggs against a steel wall.
Note that this is helpful in situations where you don't expect HTTP/1.0 requests, which is usually the case in today's world. If you have a case where you have work with HTTP/1.0 requests, then you really shouldn't use this defense method in the exact same manner.
Restoration
Finally restored the blog in 2.5 hrs, after a stupid mistake following a botched WordPress install.
Lesson learnt: even if tools like WordPress Automatic Upgrade helps you to perform backups, make sure you know everything is backed up before you do a delete!
Even though all the posts have been restored, I think I will not restore any more of the lost images, so there.