...
Kids, here is how you secure a financial server:
...
Here's another couple of ideas:
1) Don't follow anyone's cookie-cutter solutions...particularly if they are good ones (because if they are, they will be popular.)
2) If you are serious about security, don't advertise your genius ideas.
No, virtually every secure server uses those concepts.
This is what I do: I disable root login locally AND through ssh (local root disable is borderline security through obscurity though, you have to know the l/p of people who can su before you can cause any real damage), and I disable ssh login with passwords (key only), and I also use keys with passphrases only (so even if they steal the key from me physically, they can't use it).
Installing a firewall (ie, a handful of iptables rules) is somewhat overkill, you should only be running software that can be told to listen on specific IPs (ie, listen locally only). iptables kills network performance, so only use it if you must.
Running the actual httpd/db/maild/etc on a vm that itself is stored on an encrypted image is rather popular. You can boot the machine and do basic maintenance on the VM (ie, back up everything), but you can't start it or read the image unless you have the passphrase. Its basically a ghetto way of doing LOM cheaply, especially if your VM has its own IP and the host isn't masquerading for the VM.
Bare metal over VPS only stops one single attack: host reading VM memory. Which, for financial things, is worth it for some people.
Having your own hardware coloed instead of leasing a dedi is not going to increase security: others still have causal physical access to your rack, so you'll need to rent your own locked cage if you want to take paranoia the whole 9 yards.