Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Encryption Network Networking Privacy

Ask Slashdot: How Would You Implement Site-Wide File Encryption? 151

Posted by EditorDavid from the news-for-network-operators dept.
Recently-leaked CIA documents prove that encryption works, according to the Associated Press. But how should sys-admins implement site-wide file encryption? Very-long-time Slashdot reader Pig Hogger writes: If you decide to implement server-level encryption across all your servers, how do you manage the necessary keys/passwords/passphrases to insure that you have both maximum uptime (you can access your data if you need to reboot your servers), yet that the keys cannot be compromised... What are established practices to address this issue?
Keep in mind that you can't change your password once the server's been seized, bringing up the issue of how many people know that password. Or is there a better solution? Share you suggestions and experiences in the comments. How would you implement site-wide file encryption?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Would You Implement Site-Wide File Encryption? More

Ask Slashdot: How Would You Implement Site-Wide File Encryption?

Comments Filter:

  • Virtual Private Raid (Score:3, Interesting)

    by Zemran ( 3101 ) on Sunday March 19, 2017 @06:54AM (#54068543) Homepage Journal
    I wish that someone would develop a version of raid for use with servers. Have 3 VPSs in Switzerland, Russia and Holland and each one gets only a 3rd of each file. The chances of any government seizing all 3 is zero.

    • Re: Virtual Private Raid (Score:1)

      by Anonymous Coward

      But the chance of losing your data is triple.

      • Re: (Score:1)

        by allo ( 1728082 )

        RAID5 may help.

        • Re: (Score:3)

          by Zemran ( 3101 )
          It can be RAID as high as you like as RAID 10 could still be hosted on 3 servers. The idea is to make any one site irrelevant but the data secure.
        • RAID5 may help...agreed.

      • Re: Virtual Private Raid (Score:4)

        by flargleblarg ( 685368 ) on Sunday March 19, 2017 @09:23AM (#54068855)

        But the chance of losing your data is triple.

        I was about to say, "That's not how probability works!" but it turns out that you are actually correct.

        If each site has a 1% chance of being seized, then it means each site has a 99% chance of not being seized. Multiplying these probabilities together gives .99^3 = .970299 or about a 97.03% chance that no site will be seized — which means that you've got about a 3% chance of having one or more site seized.

        The key here is that 1 – (1 – x)^3 is very close to 3x for small x.

        • But the chance of losing your data is triple.

          [because] each one gets only a 3rd of each file

          I think the meaning was if you spread your data across 3 nodes, but you need 3/3 nodes to access the data then the chance of losing all your data is times three.

          If you used a parity system like RAID 5 across 3 nodes, then you could lose 1 node but still access your data. Losing 2 or more nodes means all data is lost, but also means the party performing the seizure needs 2/3 servers to recover the data.

    • However the chances of your kneecaps giving way is very high.

    • Re: (Score:1)

      by Anonymous Coward

      Hmm...
      3x Linux Network Block Devices through device mapper
      1 RAID-0 array through the device mapper with nbd members
      Make an ext4 filesystem...
      Let's see:
      # mount /dev/md4 /mnt/vpraid
      # ls -a /mnt/vpraid
      . .. lost+found

      It works, so I think it already exists. Personally I'd probably use RAID-5 or RAID-6 if I wanted to use this regularly.

      • Re: Virtual Private Raid (Score:1)

        by Anonymous Coward

        How do you ensure you are not being keylogged when you enter the passphrase on reboot?

        • 1. You could boot the system from the flash drive that is removed after boot. The part of the key resides on the same flash, the second part is entered. It's quite possible to do, at least for FreeBSD. THEY need both a keylogger in a keyboard or bios and a seizure of the boot flash. Additionally there is no place on the disk where THEY could implant a child pornography if THEIR other efforts fail.
          2. You could setup the security system that signals the systems to erase the keys and shutdown on intrusion so y

          • Re: (Score:2)

            by AmiMoJo ( 196126 )

            The best way to secure the BIOS:

            1. Remove BIOS chip and discard
            2. Burn your own BIOS chip
            3. Enable write protect if available
            4. Physically remove the write enable pin, or even better apply high voltage until the FET fails
            5. Replace chip and test
            6. Glue chip into motherboard

            You have to make sure you have a CPU without backdoor features though, or sabotage them somehow.

    • Re:Virtual Private Raid (Score:4, Informative)

      by Anonymous Coward on Sunday March 19, 2017 @09:35AM (#54068883)

      I wish that someone would develop a version of raid for use with servers. Have 3 VPSs in Switzerland, Russia and Holland and each one gets only a 3rd of each file. The chances of any government seizing all 3 is zero.

      GlusterFS supports striping across volumes that can be hosted on different servers: https://gluster.readthedocs.io/en/latest/Quick-Start-Guide/Architecture/

    • It's called vSphere. Learn about it.

    • Re:Virtual Private Raid (Score:4, Informative)

      by GameboyRMH ( 1153867 ) <gameboyrmh@@@gmail...com> on Sunday March 19, 2017 @02:22PM (#54069743) Journal

      Sounds like Tahoe-LAFS.

    • What you want for this is some variation on Shamir's Secret Sharing algorithm. Yes, he's the Shamir in RSA.
      https://en.wikipedia.org/wiki/... [wikipedia.org]
      What this does is break a secret up into n different parts, but unlike raid, you can break it up in such a way that there is a threshold for the number of parts required to reconstruct the secret. So, for example, you could break a secret up into 6 parts and specify that any 4 parts will reconstruct the original data. If you have only 3 parts, then the secret is complet

    • In the SAN/NAS world, this is called bay redundancy. A few vendors have geo separation options that would meet your criteria, but network latency would be a factor just as it is with layer 2 tunneling.
      Openstack SWIFT has something via zones, but the complete copy is present on all three redundancy nodes as it's mirroring so that's not what you want unless you use a disk adapter that supports encryption, but that's still the full copy in one place.
      However, you can also set up DRBD with this, but the encrypti

      • Re: (Score:2)

        by rtb61 ( 674572 )

        Would it not be simpler just to go with parrallel networks. One purely internal with all data secured and encrypted and the other open to the internet for internet communications. The secure network has only one point of digital data input, by network security staff. Who take in new data, scan and validate it, prior to loading onto the internal secure network. Smart terminals on the secure network with only manual data input, no possibility of adding data digitally to the secure network.

        The comms network o

    • This already exists. It is called "dispersed storage", and is developed by a company called Cleversafe (which has since, IIRC, been bought by IBM. Version 1.x was open source and you can still get the source from here: https://fossies.org/linux/misc... [fossies.org] (the dsnet-* archives).

    • Re: (Score:2)

      by jeek ( 37349 )

      I think this is a major part of TAHOE-LAFS. https://tahoe-lafs.org/trac/ta... [tahoe-lafs.org]

      Tahoe-LAFS is a system that helps you to store files. You run a client program on your computer, which talks to one or more storage servers on other computers. When you tell your client to store a file, it will encrypt that file, encode it into multiple pieces, then spread those pieces out among multiple servers. The pieces are all encrypted and protected against modifications. Later, when you ask your client to retrieve the file,

    • It's not hugely hard, all of the code is out there, just graft the raid-5 code onto XtreemFS [xtreemfs.org], throw some money there way and they may even do it for you.

  • Full Spectrum Problem (Score:4, Insightful)

    by packrat0x ( 798359 ) on Sunday March 19, 2017 @07:21AM (#54068613)

    The choices include encrypting files (tar/gz/bz archives), directories, whole user directories, whole physical volumes, whole logical volumes, etc. One large enrypted volume means single point of failure: One key/password gives access to every file. More divisions means more keys/passwords, but less access if one is compromised. Therefore, server level encryption is appropriate if one person is responsible for the entire contents on the server(s).

    • Ensure that ONLY the users of the data have the keys, with all encryption/decryption done on the users computer. If the users computer is compromised they already have full access, but there is no reason to give the server farm maintainers access. Have different keys for each user of the system. A shared drive/folder with shared keys can allow easy file transfers between users, because if you don't make it easy they will use sneakernet or email to transfer unencrypted files.

  • LUKS (Score:2, Interesting)

    by Anonymous Coward

    - Linux servers
    - LUKS full-disk encryption
    - All network traffic tunneled tunneled through some form of SSL (e.g. SSH or OpenVPN) with client authentication, and a decent IDS.
    - Tiny custom binary in the initramfs that loads the "password" (a random 1024 bit binary string) from a USB serial device
    - BIOS boot options locked down (no removable media boot, password required to change settings)
    - Arduino with 6x AA batteries for power backup, a 3-axis accelerometer/gyro, an ambient light sensor & the sensor fr

    • That sounds really complex, and potentially expensive as the number of devices scales. Also, fragile and difficult to maintain.

      The easiest way is just use LUKS and a secure passphrase.

      If you want to restrict knowledge of the passphrase to admins but allow users to reboot, that's a harder problem. However, If you have a TPM chip, you can use it to secure a random LUKS passphrase that unlocks only in a verified clean boot. You'll need trustedGRUB and tpm-luks, but it does secure against fairly sophisticat

      • Re: (Score:2)

        by Lehk228 ( 705449 )
        they'll just take you to an overseas black site and torture you until you remember the passphrase.
    • This reminds me of the HSM appliances we've used to store credit cards.

  • But how should sys-admins implement site-wide file encryption?

    I guess I would start with a search for "full disk encryption"

    Or with raising the middle finger and telling to encrypt that.

    Depends on the day.

  • Why would you want to encrypt the entire filesystem, there isn't anything of interest in /usr/bin or other standard system directories. Encrypt /home , /var and wherever else you have sensitive data. the decryption key should be kept on a off-site server that hands your init.d script (or system.d whatever you are using) the key once it passes a IP address lookup and ssh authentication. If moved off site, the servers will not be able to receive the decryption key because the ip's won't match (you could simp
    • Because by encrypting everything, you A. prevent an attacker from knowing the layout and structure of the filesystem and B. prevent anybody from tampering with your binaries without knowing the password. For example, you don't have to worry a police agent alters /bin/ls or so behind your back, and nuking just the bootloader is much easier than trying to replace the entire unencrypted filesystem afterwards.
      • If you ever manage to get your systems back, you would have to be pretty stupid to trust they haven't been tampered with, whole disk encryption or not. They could have modified the Bios, Raid controllers or even the firmware on the drives themselves.There is no chance I would ever plug in those systems back to a network connection ever again. Take the data and start over, is the only way to be safe!

        • You cannot assume the system was shutdown before the attack occurs. You would still want to protect the integrity of the entire file system. The goal of this encryption would be so that any part of the system that doesn't have the encryption key cannot get to the encrypted data. So if I can attack at the bios of the HD, or HD controller, I could re-write /usr/bin/passwd... if those were not encrypted, to then allow the running system to give up encrypted data once that program is accessed by any process

    • Because the file /usr/bin/child_pornography.jpg could magically appear out of nowhere if your filesystem is in wrong hands.

  • Trying to draw the specification for this or not . (Score:5, Interesting)

    by burni2 ( 1643061 ) on Sunday March 19, 2017 @08:10AM (#54068675)

    If you decide to implement server-level encryption across all your servers,

    This is basically simple you can build a server that does all encryption in ram, meaning the OS is loaded once then the encryption key is used to have it decrypt the content for the outside.

    To stop tempering you could setup such a server yourself and equip it with various sensors that detect presence of people or tempering, and if detected it could shut down not compromising the encryption key to forensics.

    Firewire(because of its DMA) needs to be disabled and unkown devices need to trigger a shut down event and must otherwise be ignored

    con:
    However this type of server would still emit the key data as radio spectrum.

    con2:
    The requesters question is quite sketchy, I suggest writting a specification first with the neccessary "must haves" and possible use cases.

    my iscsi-encryption approach
    So I can only explain my private approach, I got a root server with big harddrives and those harddrives are exported via iscsi that iscsi-connection is tunneled through ssh.

    I de-/encrypt & mount the drives only on my home server and sync the directories with rsync. The harddrives are double encrypted meaning I have two encryption devices and two dependend keys.

    This sounds slow, but it isn't I get nearly the full upload bandwith of my connection.

    Meaning my root server never "knows" what data is backed up on it - its a "dumb" server

    I would suggest a similar approach for the requesters situation, because it solves a first step, separating the encryption key from the encrypted data.

    And a second step having two encryption keys making it more difficult to get all two if separated (which is contrary to my use case)

    I would expand my approach there to have a "data" server, a level1 encryption server and a level2 encryption server.

    level1 decryptes the first encryption layer and level2 does it with the data provided by level1

    Usecase:
    If only the data server is seized, shut down at least one of the intermediate servers along with its key and the data is inaccessible. And it doesn't matter which "key keeper" server you kill, its a fail-one-fail-all system.

    The drawback is however the level2 encryption server shall not be compromised, because there all pure data is accessible.

    encrypted backup
    With todays highspeed connectivity the servers can be backed up by just cloning the harddrives over iscsi for example, that works quite well.

    another idea
    Most encryption providers from linux and bsd provide the possiblity of having more than one master key.

    Iscsi can also work on image files so you can provide many independed iscsi-volumes and encrpytion can be outsourced to the users computers.

    • I'd like to suggest something like trevisor [uni-erlangen.de], a hypervisor for a single guest VM. Where the user enters a passphrase on boot, and the encryption keys are only stored in debug registers. Though this probably needs some additional work to be production ready.

    • Re: (Score:2)

      by dknj ( 441802 )

      This sounds slow, but it isn't I get nearly the full upload bandwith of my connection.

      So you 6gb/s ssd drives are limited to a whooping 100mbps. That's slow, bruh. Unless your drives are all IDE this does not scale.

  • Its biggest issue is to my knowledge it omly works with windows, but for making life had for leakers this is probably the best bet. When you open documents your computer requests the key for ad, the benefit here is if the user cant connect to AD (i.e. They are at home) the whole process wont work. You can also define users who can decrypt data before emailing if they do meed to share the info. It works well as long as you are tied to the windows ecosystem.

    • Re: (Score:2)

      by swb ( 14022 )

      I really wouldn't want to ever implement and manage WinRM site-wide though until it was super mature.

      Some kind of key management fuckup and you're left with a pile of encrypted gibberish.

      • 14 years and a solid v4.2 on the SDK ... what exactly is your definition of mature? Microsoft's big failure wrt RMS is their inability to automate roll-outs. It is way too painful to get set up the first time, but once you have done it a few times, it can be done on a demo network in less than 4 hours. RMS is the only solution that covers your entire corporate data and security stack from authentication to network transport to data-at-rest. Adoption success rate is less than stellar though, not inherent

  • Simple way... (Score:1)

    by Anonymous Coward

    Implement a blind-password vault. To access data, everyone supplies the vault password. This password, however, does not decrypt data. The vault retains a randomly generated key and the vault software retrieves and decrypts the file. If data is stolen, even those with passwords cannot access it. Further, the vault keys can be backuped and restored on-demand.

  • It depends what you mean by 'site wide' (Score:3)

    by Assmasher ( 456699 ) on Sunday March 19, 2017 @09:22AM (#54068853) Journal

    If you want your files encrypted 'at rest' so that if someone comes and pulls your HDD (or software equivalent) then you can implement a strategy similar to:

    (a)Encrypt all content with individual symmetric keys (one key per piece of content) - prefix each piece of content with a key ID (for key lookup on exit) - there are many ways to associate content with a key - prefixing is just the simplest
    (b)Encrypt those keys (which you'll need stored locally for performance reasons) with a randomly generated one-time pad stored on a removable hardware device (HSM/USB for example)
    (c)Decrypt files as appropriate as they exit your webserver - observe the key ID of the content, ask a process on your machine to give you the symmetric key for that ID, decrypt the content, send it back to the requesting connection.

    Don't store the master key and/or one time pad locally, simply have a daemon/service/long running process on your web server require (at startup) you to plugin your hardware device (e.g. read a file from a mount that is only there when you plug the thing in.) This means that stealing the content doesn't do them much good (if they crack a key it's only for that particular piece of content, they'll have to crack lots of keys), and if they get the locally stored symmetric key file it doesn't do them much good either because you're protecting that with a VERY strong key and/or cipher which is stored air-gapped - they'd have to not only steal all the files involved, they'd have to inject into the service/daemon that issues symmetric keys.

    This type of approach has performance implications of course, and to make it truly close to unbreakable requires more specifics (process injection prevention, signing and impersonation attack prevention, both on the key request side and the service/daemon unlocking scheme, et cetera) - this would be quite a discouraging system to attempt to break.

    My $0.02, YMMV

  • Put it behind 7 proxies. I hear that works. https://m.youtube.com/results?... [youtube.com]

  • hire someone (Score:5, Insightful)

    by ooloorie ( 4394035 ) on Sunday March 19, 2017 @09:36AM (#54068885)

    How Would You Implement Site-Wide File Encryption?

    Hire someone who knows what they are doing. Seriously, if this is for a business, there are lots of complex issues with compliance and audits in addition to availability and the possibility of sabotage. And this causes enough work that you'll probably need to hire someone anyway, so it might as well be someone who knows this stuff.

    Dealing with those requires experience. And the very first thing you need to come to terms with is: what risks are you actually trying to protect against? What tradeoffs are you willing to make and what risks (mainly of data loss) are you willing to accept? How much are you willing to spend on this?

    • How Would You Implement Site-Wide File Encryption?

      Hire someone who knows what they are doing.

      Stop with the crazy talk! This is slashdot- we have standards and we expect you not to exceed them.

  • I would tell them to use encryption for everything all the time or they would be beaten like a rented mule. Then I would randomly beat an employee or two just to drive home the point.

    Note that the directive would apply to ALL communication, including asking a coworker where he/she wanted to go to lunch. For example:

    Coworker #1: "aZqk jhwf89 489c32r8934 hfh7 246eg6sd17?"

    Coworker #2: "KSJED894nc&HE#%32jhdi."

    Coworker #1: "$R^WJFC8ewm4f8u(Y3em90r4c987!!"

  • While encryption itself is an issue to be worked out, the real question is key/encryption password management: How do you keep the keys off of a server that you worry about being stolen or physically compromised? Specialized hardware [wikipedia.org] exists specifically for this. There are network versions of hardware security modules and you would put one of these in a secure location, apart from your server, but available to your server over a network so if you need to restart the server, it can access its encryption keys
  • The fact you mention disk passwords leads me to believe that you are familiar with consumer grade encryption, but probably not enterprise grade encryption management. Microsoft offers some good tools for this, so do many of the other security vendors. Most of these tools have complex, rolling recovery keys for whole disk encryption and assigned users are still able to log in with their normal AD, but you can go the route of additional factors or ways of protecting the identities. If you have need of an add
  • Do what CryptoLocker did - bots can do the site-wide encryption. Have triggers on servers and local devices, as needed. You can pick the type of files to encrypt, which cryptography to use, and where to store the key(s) - hopefully in a safe place off site. Users will be the most vulnerable part of the process. They have to be clear about the techniques to access and save the files. Which brings to mind another can of worms...
  • The problem with encryption software is that most of it isn't designed to be centrally managed. I am an OpenBSD user and I use full disk encryption which is slick as owl shit but there is no way to centrally manage, say, several OpenBSD machines. In order to change the passphrase or key I have to go to each and every machine. There are some commercially available software packages that will implement central management tools but I do not trust them. When it comes to encryption, if I cannot see the source c
  • Thanks to everyone who took the time to suggest their ideas. — OP

  • What type of attack is being mitigated against and how does the risk of failure of the encryption solution compare to that of the attack vector? There are many ways encryption can fail, including loss of keys or too much exposure to the passwords for these keys.

    For example, are we talking about hardware theft or software based intrusion?

    For hardware theft, then you would probably want to find a solution where no one needs to know the keys, but it is part of the local infrastructure. This would mean that onc

  • Just one word: Tahoe-LAFS [tahoe-lafs.org]. Deploy, use, relax.

  • I see a number of good ideas already for home-brew solutions so here's one for an enterprise out of the box solution. (usual crypto caveats apply, if you don't build it yourself, how do you know there's no backdoors... otoh, if you do build it yourself, assuming your not Bruce Schneier, how do you know you got it right? Take as directed, evaluate your risks before using)

    I've had good success with Gemalto's protectfile product in this space. The NAE device handles the master key storage, temporal keys are

  • The best solution is simply ZFS with encryption which is live now. Or VERY soon. Easy peasy. Everything is convoluted, difficult, and will end in tears.

  • This may be slightly off-topic, but I use free Let's Encrypt certificates for my httpS websites. Personally, I have never had problems with them, however some browsers and mobiles throw up the same OMG WARNING HAXXXORS screen that you get when using a self-signed cert. This has forced me to turn off server-forwarding rules I had in place to direct folks to the httpS site when they used the http URL.

    The irony is that these ill-conceived browser warning messages are herding them to use the un-encrypted site,

  • Disclaimer: I am the author of the following projects. At Red Hat, we have been researching this problem for the last few years. This has resulted in the creation of the Clevis[1] & Tang[2] projects for automating decryption. This currently ships in Fedora and we plan to ship it in a future RHEL release. This project currently supports both root volumes and removable storage, as well as any other data you want to encrypt and then automatically decrypt. We are working on adding support for non-root vol
  • Its their web, the world wide wiretap. From a smart phone to a Room 641A https://en.wikipedia.org/wiki/... [wikipedia.org]
    So be aware of how the security services seek out your data.
    The NSA and GCHQ will try and add their hardware your hardware as a brand imports hardware.
    One at a hardware level in a company any network belongs to the security services.

    CIA, MI5 also understand the human dimension. Social engineering or a new relationship, new staff.
    The amazing new friend, skilled new staff member, potential clie

  • Turn off IPS/IDS etc. (Score:3)

    by Drishmung ( 458368 ) on Sunday March 19, 2017 @07:03PM (#54070653)
    Just turn off all IPD/IDS, firewall and anti-virus. In an hour or so the ransomware should have the entire site thoroughly encrypted.
  • Enforce encryption client-side. Server just hosts encrypted files and has no way to decipher them.
  • If this is for a serious business and you need to ask /. how it is done then back the fuck away from the keyboard and hire someone that understands this or you will be walking into a world of pain. First check what you are really doing justifies encryption, remembering encryption does not protect you from people installing malware, people social engineering access, unsecured buildings, unpatched systems etc etc and this is usually what is being exploited. First you need to get your businesses tech security

Slashdot Top Deals

If all else fails, lower your standards.

Close