Generally you don't need 95% of the stuff that's running. Use the bare minimum. Compile the server you're using, say Nginx, from source with only the bare minimum of options and modules you need. Disable all the services/ports and then selectively enable the ones you need.

Best of all, don't have anything worth stealing. Don't keep the credit cards on your servers, parrot them through a vendor. Don't keep user credentials on your system, us OAuth, Fb or Google auth. If you've got nothing valuable to steal, they'll likely not break in.

But then again, if the Fed's want in, they'll just pull your box from the rack. Don't forget that you can literally freeze a DIMM and dump it and all the encryption keys to another mobo. So, as is the CIA's policy, if you don't want anyone to know something, don't let it touch a computer. ;)

You can monitor exploit sites, but zero days are always possible and what will lead to serious hacks like this. So no, you can never be sure.

The best thing is to keep your eye on the culture of the developers and how seriously they take security - for instance the Ruby on Rails developers ignored exploits/reports until people blew them wide open. Now, if some other hacker had known about that before the disclosure, they could have owned any RoR sites.

From my experience, Django seems to be the best, and has not had any unfixed vulnerabilities for a while (though, due to it's complexity, it's completely possible that 0days exist). However, if I'm running Django sites and some do get owned, I can tell my boss/client/self/whatever that I did everything possible to prevent it happening.

There is no such thing as 100% secure, however, it's fairly reasonable to be hardened to all but the most dedicated crackers.

With an attack like HTP's, there's no fucking way anyone could have been expected to prevent, without running their entire own infrastructure, because they owned registras, Linode's LISH shell (so they get near-physical access to your Linode), and various other crap. If your boss were to fire you for getting owned in this attack, despite it preeetty much being zero of your own fault, they would be in the wrong (unless you have the resources to not depend on anyone).

No. Even if you could write a 'secure' RoR app, at some point the RoR framework becomes the weakest link. ( Or the Linux kernel, or the door of the datacenter.) And more general, security implies always a certain attack scenario, a strong password does not help against stolen hardware and a nuclear bunker does not help against a zero day. On the other hand, you can be quite secure against a plausible attacker, that is a attacker who is not willing to blow zero days against your personal blog. ( Or im general is not willing to spend a lot more than he can gain in the attack.)

The question is not if it can't be cracked, but who will be able to crack it. If a security analyst will be able to break it you should not worry that much as long as you adhere to good practices, but if a person without the proper knowledge will be able to break it, because it's a trivial vulnerability (ex. SQL injection via GET parameters), you should be really, really worried, because it means that something is wrong and it should be fixed soon.

It's ultimately unknowable but I think it's possible to have a very secure system. You just have to take a holistic approach and look at everything in the stack from top to bottom, keep on top of security updates and use the right security procedures. After all that you'll still never know whether it's secure or not...

Only if the server is switched off and disconnected from the network.