0

Say you do not trust the data center technicians (or management) but have no other option than hosting your web application with them.

Also, say you want to keep certain files inaccessible to people who do have access to the server in an on-rack (live) and off-rack (turned-off) capacity.

Question
How effective would the following setup be in securing the source code and other sensitive files?

Method of protection:

Presume the application uses the following stack: LEMP + Redis + Node (Websocket)

A. One time config

  1. Disable autostart of Nginx, Redis and MySQL
  2. Create a root directory for a RAMDISK partition: mkdir -p /media/private
  3. Change MySQL's data directory to /media/private/mysql

B. After each reboot

  1. Create and mount a RAMDISK partition:
    mount -t tmpfs -o size=2048M tmpfs /media/private/
  2. Create required sub directories under /media/private
  3. Upload MySQL data files, Nginx config file, SSL cert files, Redis config file, PHP source files, and node app files to the appropriate directory under /media/private
  4. Start Redis server with custom config
  5. Start MySQL server
  6. Start Nginx with custom config
Improve this question
4
  • I'll update my answer if you clarify what you mean by "have access to". At some level, and attacker with "enough access" always wins, so you'll need to be a bit more clear about how far you're willing to go to protect against rogue admins. Commented Jul 26, 2018 at 18:56
  • @MikeOunsworth by 'have access to' I mean having physical access to the hardware, both while it is working (on-rack, live) by attaching a console to the server, and the ability to remove it and access the hard disk directly (off-rack). I believe attempting a cold boot attack on the RAM sticks is too frantic and not worth trying to counter (not much could be done about that anyway). I hope that is enough clarification; if not please let me know. Commented Jul 26, 2018 at 19:28
  • Yeah, that helps. Do you also want to protect against installation of malicious software, BIOS, firmware, or chips on the motherboard? In the security world, "attacker with unrestricted physical access" is generally considered a Game Over because the possibilities are endless :P Commented Jul 26, 2018 at 19:30
  • @MikeOunsworth I guess, both the cold boot attack and spyware chips could be part of an evaluation of effectiveness of the proposed method by agreeing or disagreeing that the method is effective in non-extreme attacks, but could not provide protection against these more sophisticated methods ... Commented Jul 26, 2018 at 19:40

2 Answers 2

Reset to default
0

[I still think my frame challenge answer holds, so I'm posting a second answer addressing the clarification in comments]

If I'm understanding your question properly;

Security Goal: prevent someone with physical access to the server (either while running, or while powered off) from accessing any files within the OS.

Proposed Solution: Don't store anything on disk. On boot, create a ramdisk and upload all sensitive files directly into ramdisk.

(correct so far?)

First off, you are introducing a massive single point of failure in that bulk upload after reboot. How is that secured? Where are the files coming from? What security hardening and practices are on that machine? Can an attacker block the upload to DoS your server? etc etc.

Next, your solution may protect against your sensitive info ending up in disk images, but why roll your own rather than use standard solutions to this problem like full-disk-encryption? Your cloud provider will offer encryption at rest that interfaces with their key management system (AWS for example), and/or enable disk encryption at the linux kernel level requires a password at boot.

Finally, your solution does not protect against memory dumps (maybe via physical access like cold boot attack, by taking a live snapshot / memory dump via the hypervisor, others?). Again, don't roll your own, but maybe look into memory encryption?

Improve this answer
5
  • A few points. The goal is not "prevent(ing) someone ... from accessing any files within the OS". The files we want to protect are quite few, not everything. Only these are uploaded to the RAMDISK directory. Uploading will be done by SCP and files come from developer's machine. DoS attacks intervening with the upload is not an issue. On why rolling my own solution instead of using a standard one; well, the main reasons is lack of resources. As I said, we are limited to what's on offer at providers like Linode, DigitalOcean, Vultr and the like. Commented Jul 26, 2018 at 20:37
  • Since I named some businesses in the comment above, I think it is important to clarify that I am not accusing them of not being professional. So my question's opening should be read as while I do not distrust them, I do not know them enough to have a blind trust in them either. Commented Jul 26, 2018 at 20:44
  • So the ssh keys to your prod environment are sitting on a developer machine? You know what, I'm not gonna go there. My professional opinion is that turning on disk encryption in the server's kernel is both less effort and less error-prone than building your own solution. Commented Jul 26, 2018 at 21:48
  • I'm also gonna challenge the assumption that protecting /media/private means you don't need to protect everything else. Say a Linode admin mounts your disk image and adds a line to .bashrc to scp -R /media/private to the attacker's machine. Next time a dev logs in to a running system, you're hosed. Commented Jul 26, 2018 at 22:17
  • You're quite right. /media/private cannot be protected without minding all the public space on the server. And this empties the solution from what little value it still had to me. No security is better than illusion of security; Thanks. Commented Jul 27, 2018 at 0:05
0

I think you're going about this backwards; you're outlining a solution and asking if it's secure against people "with access to the server", but haven't told us what level of "secure" you're aiming for.

Let's unroll that; secure against what? Which levels of access are you trying to block, and at what point are you willing to let it go?

  • Secure against network admins hitting your VM's ports? You probably had that already.
  • Secure against sysadmins who can access your VM's disk image? This may help, though there may be more off-the-shelf solutions, like providing a full-disk-encryption password at boot.
  • Secure against sysadmins who can get ssh keys to your VM? This probably doesn't help.
  • Secure against sysadmins who can take direct memory dumps of your running VM? This probably doesn't help, though you may look into memory encryption.
  • Secure against datacentre employees who can rip the RAM sticks out of the machine and dunk them in liquid nitrogen in a cold boot attack? This probably doesn't help, though you may look into memory encryption.

So I suggest you go about this the other way: define the level of security you want, and then design a solution that attains it.

[sorry for a giving a non-answer, but I feel like this needs a frame-challenge]

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.