

Ask HN: Is this hosting setup 'unhackable'? - bikamonki

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
1) 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
1) 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
That 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
Thx, you helped me see a broader picture!

------
MichaelCrawford
Remove 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
But 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
Containers 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.

~~~
cpach
So something like Docker?

~~~
dagw
Docker works, but there are lots of ways to get the same result. I'm not
trying preach any specific method.

