Digital Ocean: Ubuntu, Nginx, Unicorn, Rails

     # if you compiled --with-http_spdy_module
     listen 443 ssl spdy;

     # amusing how many of these you'll get
     location ~*\.php {
       add_header "Not Found" 404;
     }

     # pretty sure you need to do this to have keepalive working
     # between nginx and the upstream
     proxy_set_header Connection "";
     proxy_http_version 1.1;

     # buffer writes to disk (for a busy site, you can use much larger values than 1K)
     access_log /var/log/nginx/access.log buffer=1K;

     # cache the ssl connction parameters
     ssl_session_cache shared:SSL:20m;
     ssl_session_timeout 10m;

I'm also a fan of running `sshd` on an off-numbered port to add another layer of protection against zero-day attacks. Most worms spread by compromising a service on a host, and then hitting everything around that host, but (to my knowledge) most of these depend on targeted services living on their default ports.

It won't buy you anything against a direct attack, but security is all about layers of defense, not just having a hard outer shell.

[1] http://www.unixlore.net/articles/five-minutes-to-more-secure...

The first step is to have separate user accounts for everybody that's going to be deploying apps. You really don't want shared accounts (like a single 'deployer' user), because you get no audit trail on who-does-what, and you effectively lose access control to your machines.

The second step is to run the app itself as a limited-privilege user -- no write permissions to anything except for logs and tempfiles. A lot of attacks depend on your app being able to overwrite parts of its own code; if that can't happen, the attack fails.

As for DO upload your/a pubkey for root access to the control panel and have it installed for you in new images.

1. Change SSH port

2. Block all password logins

3. Disable root login (namely, a non-root user must login via a key, then su or sudo to root)

4. Lock down everything with IPTables

5. Allow only encrypted connections to the few ports open via IPTables (normal exception is port 80 for http).

6. Segment the network (with DO private networking your machines are open to anyone within the same facility, so you need to isolate your private network from other DO customers)

7. Lock down each running service/daemon per it's standard configuration. For example, if you're running Postgres, then lock it down per pg best practices.

8. Create individual, non-privileged users for each service that you're starting. ex. If you're running an app server, then it should have its own user.

9. Sandbox everything that can be.

10. Turn off everything that is not being used, then uninstall it.

11. If you don't need them, then uninstall build tools such as compilers. Have a separate build machine.

12. Only open edge of network machines to the outside world. On DO, turn off eth0 on all machines that customers do not directly interact with.

13. All services that are internal user only should have public networking totally disabled. Ex. Redis should only run on a private IP, should have the public interface disabled, and should only be accessible via a secure connection (ideally with some type of true authentication, replay protection, etc. Or, just run these services on a trusted network and pray that nobody penetrates your network deep enough to find out that you're totally unprotected once inside your network.

14. Don't keep private keys/certs in places that they are not needed.

15. Have a map of each service, the user that it runs under, what resources that user has access to, and a general map of what sequence someone has to follow to control your network. If you catch someone mid-attack, you can start to lock off parts of your network.

16. Logging! And monitor them for attacks. And ship logs off the machine in question so that you can review logs even if a machine is compromised.

There's lots more, but this is a basic list that should be configured via Ansible/Chef/Puppet/Salt for each box.

One other item I've heard is that some people like to run heterogeneous networks.

From my side, I've got a fantastic Ansible setup for databases, security, ssl certificate distribution, and so on, and so Heroku doesn't really buy me anything for the extra money.

https://launchpad.net/~chris-lea/+archive/ubuntu/nginx-devel

Only those who have never experienced a corrupted backup or failed slaves think a database is something that is relatively trivial to manage.

You're much better off looking at platforms like RDS, MongoHQ, Cloudant etc.