6 ms·
Ask HN: Is this hosting setup 'unhackable'?
Static site hosted on S3 + route 53 DNS mngmnt.
Provided that:
1. Permissions on the bucket are properly setup.
2. Registrar and AWS password is not compromised.
- smt88 12y ago1) Nothing can be proven to be "unhackable". Some programs (e.g. OpenSSH) have turned out to be hackable after as much as several decades in production on hundreds of millions of machines. 2) "Properly set up" is too ambiguous. Is the whole bucket public? Is the whole bucket private? Are the permissions more fine-grained? 3) Some registrars, like GoDaddy, have been hacked with social engineering. Are you using a registrar that allows password resets over the phone? 4) A password is not enough. You need to enable two-factor authentication on AWS.
- bikamonki 12y ago1) Agree. Let's say 99,99% "unhackable", meaning known threats, meankng AWS would need to be hacked. 2) The whole bucket is public for open/download, all files are static resources (html, js and css). So hacking in this case means defacing or taking the site down. 3) and 4) Will double check but let's assume pwds cannot be broken.
- smt88 12y agoThat sounds fine as far as what you have control over. After that, you're relying on the security of AWS. That means 2FA is your only line of defense in this case. Your main points of failure are: AWS, your password manager (if you use one), your OS (if you have malware), and your internet connection. For AWS, you can enable 2FA and optionally get a physical device that is not your phone. That would help, since your phone is something you carry around a lot and possibly lose. For your password manager, if you're using a cloud-based manager, you could easily be vulnerable. Who knows if those services are really as secure as they say. For your OS, you certainly need to have excellent anti-malware software, as well as good security practices (no Java enabled in your browser, up-to-date plugins, no running of unknown/pirated programs or games). For your internet connection, you should get an HTTP Everywhere-like plugin for your browser. You can't do a whole lot else.
- bikamonki 12y agoThx, you helped me see a broader picture!
- MichaelCrawford 12y agoRemove all the executables on your servers that don't actually need to be there. Any executable at all is a potential toehold for an intruder. Especially remove your compilers. Consider that the Morris worm, as well as lots of malware, enables portability by distributing itself in source code form.
- cpach 12y agoBut if OP use S3, he’s not running the OS himself, right? Otherwise it sounds reasonable to keep compilers away from the production servers. On that note, what are some good schemes for installing self-compiled software to a server? For example, let’s say I run Ubuntu on my servers. On dev host X I have compiled a specific version of Ruby on Rails. Then I want to install that version of Rails to production server Y. I could make a .deb package, but I get a feeling there are other good alternatives as well?
- dagw 12y agoContainers of some kind. Once you have a working system on your dev machine, copy the whole setup from your dev machine to your production machine. This way you are absolutely sure that everything is identical and that you aren't accidentally running different versions of some binary and end up with a situation where you have a bug on your production machines that you cannot reproduce on your test machine. I learnt that lesson the hard way once when I was running python 2.7.3 on my test machine and python 2.7.2 in production.
- 12y ago