Re: [Dovecot] Encryption solution for messages at rest
Currently our dovecot servers are on our webhosting linux boxes. We are using the LAMP stack to host websites, and also doing email with postfix & dovecot on these systems. We provide this as a hosting setup for 100+ accounts/websites on a single server (a multi-tenant setup). Each customer has anywhere between 1-100 email accounts which Dovecot services.
If a customer has vulnerable PHP code on a website, some of these will allow a remote file upload. I have seen cases where they upload a PHP script that is a sort of web-based console/shell to the server (file-system, etc.). It provides several tools which all run through the uploaded PHP script to try to brute force and do other attacks. I've seen attempts at a root exploit. We've never had a root exploit and any such case of a customer's site being hacked has been easily contained by simple filesystem permissions being correct (and the fact that we have apache setup to run all scripts as the user who is the owner of the script files, which confines the script to that users' permissions). Still nobody loves the idea of bad guys trying to hack on your box.
So.... given that type of scenario, if filesystem permissions weren't correct, or some new exploit surfaced that allowed someone bypass or elevate to root, then they could theoretically have access to the entire fileystem including where emails are stored.
I hope to never have this sort of thing happen. We patch our systems regularly and have other security measures we follow to prevent this. We also are managing most of the PHP scripts customers use ourselves now and are updating those for the CMS' and other systems proactively.
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker.
This type of encryption is ideal and some regulations prefer (although don't require) it.
Doug Mortensen Network Consultant Impala Networks P: 505.327.7300
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Michael Orlitzky Sent: Monday, October 28, 2013 11:52 AM To: dovecot Subject: Re: [Dovecot] Encryption solution for messages at rest
On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
Hi,
We have clients with various security & compliance requirements. Although not required, it would be ideal to have messages encrypted at rest.
You can rule out a lot of the crazier options by answering the questions,
(a) What attack scenario do you have in mind?
(b) How will encryption help?
Am 28.10.2013 20:14, schrieb Douglas Mortensen:
So.... given that type of scenario, if filesystem permissions weren't correct, or some new exploit surfaced that allowed someone bypass or elevate to root, then they could theoretically have access to the entire fileystem including where emails are stored. I hope to never have this sort of thing happen. We patch our systems regularly and have other security measures we follow to prevent this. We also are managing most of the PHP scripts customers use ourselves now and are updating those for the CMS' and other systems proactively.
how would enryption help here?
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it
impossible and useless if someone comes that far he can also read whatever configuration containing the keys
encryption is nice in case of disks got stolen but not for protection against intrusion on the running machine
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Michael Orlitzky Sent: Monday, October 28, 2013 11:52 AM To: dovecot Subject: Re: [Dovecot] Encryption solution for messages at rest
On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
Hi,
We have clients with various security & compliance requirements. Although not required, it would be ideal to have messages encrypted at rest.
You can rule out a lot of the crazier options by answering the questions,
(a) What attack scenario do you have in mind?
(b) How will encryption help?
On 2013-10-28 20:23, Reindl Harald wrote:
Am 28.10.2013 20:14, schrieb Douglas Mortensen:
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it
impossible and useless if someone comes that far he can also read whatever configuration containing the keys
In principle, this can be addressed by employing asymmetric key encryption.
You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail.
In practice, it's probably not that easy:
I suppose you'd have to be careful to not break features like server-side searching though. If you only store encrypted mail, the only moment where the system sees the plain mail is when it's received. So you'd probably need to index it at that point and then use that index for subsequent queries. Once the mail is written to disk, the server never sees the real data anymore.
Different mail storage formats probably work differently well. mbox is right out, with Maildir it might not be acceptable to encode the raw mail file - I don't know whether Dovecot uses any actual contents of files with Maildir (as opposed to the Dovecot-specific indices and the file name). If it does, then you should maybe just encrypt just the body but no headers or similiar.
There's surely more to consider, but I think this is anything but "impossible and useless". Accessing sensitive data which is stored on an untrusted system is an old and solved problem, I wouldn't be surprised if you just have to consider implementation details in the case of a mail server.
-- Frerich Raabe - raabe@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
On 28/10/13 23:22, Frerich Raabe wrote:
On 2013-10-28 20:23, Reindl Harald wrote:
Am 28.10.2013 20:14, schrieb Douglas Mortensen:
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it
impossible and useless if someone comes that far he can also read whatever configuration containing the keys
In principle, this can be addressed by employing asymmetric key encryption.
You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail.
In practice, it's probably not that easy:
I suppose you'd have to be careful to not break features like server-side searching though. If you only store encrypted mail, the only moment where the system sees the plain mail is when it's received. So you'd probably need to index it at that point and then use that index for subsequent queries. Once the mail is written to disk, the server never sees the real data anymore.
Different mail storage formats probably work differently well. mbox is right out, with Maildir it might not be acceptable to encode the raw mail file - I don't know whether Dovecot uses any actual contents of files with Maildir (as opposed to the Dovecot-specific indices and the file name). If it does, then you should maybe just encrypt just the body but no headers or similiar.
There's surely more to consider, but I think this is anything but "impossible and useless". Accessing sensitive data which is stored on an untrusted system is an old and solved problem, I wouldn't be surprised if you just have to consider implementation details in the case of a mail server.
Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server.
Incoming mail would be automatically encrypted with the public key, then stored.
When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly.
Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection.
Mike.
On 2013-10-30 16:03, Miquel van Smoorenburg wrote:
On 28/10/13 23:22, Frerich Raabe wrote:
You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail.
[..]
Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server.
Incoming mail would be automatically encrypted with the public key, then stored.
When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly.
Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection.
The whole idea of using asymmetric encryption was that the server *does not* have the private key. It only has the public key, so it can store incoming mail encrypted using the users public key (which requires no password). Dovecot would then just serve the encrypted mail, all encryption would happen on the client side using the private key which only the client has.
In the case of Maildir, I suspect (but I don't know) that Dovecot doesn't treat the individual files as plain data: it does look into them when serving (not only when indexing) to parse some headers or so. So I guess you cannot just encrypt the raw file on disk but you rather have to "rewrite" the mail so that only the body is encrypted but the headers are left untouched. This means that a hostile root user could see the headers, but at least not the body of the message.
-- Frerich Raabe - raabe@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Quoting Miquel van Smoorenburg <miquels@cistron.nl>:
On 28/10/13 23:22, Frerich Raabe wrote:
On 2013-10-28 20:23, Reindl Harald wrote:
Am 28.10.2013 20:14, schrieb Douglas Mortensen:
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it
impossible and useless if someone comes that far he can also read whatever configuration containing the keys
In principle, this can be addressed by employing asymmetric key encryption.
You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail.
In practice, it's probably not that easy:
I suppose you'd have to be careful to not break features like server-side searching though. If you only store encrypted mail, the only moment where the system sees the plain mail is when it's received. So you'd probably need to index it at that point and then use that index for subsequent queries. Once the mail is written to disk, the server never sees the real data anymore.
Different mail storage formats probably work differently well. mbox is right out, with Maildir it might not be acceptable to encode the raw mail file - I don't know whether Dovecot uses any actual contents of files with Maildir (as opposed to the Dovecot-specific indices and the file name). If it does, then you should maybe just encrypt just the body but no headers or similiar.
There's surely more to consider, but I think this is anything but "impossible and useless". Accessing sensitive data which is stored on an untrusted system is an old and solved problem, I wouldn't be surprised if you just have to consider implementation details in the case of a mail server.
Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server.
Incoming mail would be automatically encrypted with the public key, then stored.
When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly.
Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection. Mike.
Or someone that has your email password. Basically, it's no different than unencrypted mail on an encrypted filesystem. Doing more work != more secure - that's why Lavamail was nothing more than a marketing ploy. Imagine going to your bank to put things in your lockbox, and giving your personal items to the teller who then runs an obstacle course before getting to the vault. Are your things more secure than you putting the items in the lockbox you have the key for?
Use GPG, and make sure the user understands that full text search is not available. For the client, either they run it locally, use the gpg Chrome plug-in, or the site implements opengpg.js. Then all decryption occurs client-side. http://openpgpjs.org/
You could come up with some custom public/private key exchange, but why? If you're going to encrypt and decrypt it locally anyways, what does it matter? The equivalent to the Lavabit hack, without the pointless runaround, would be to use the Dovecot zip module to encrypt the data so only the Dovecot process can read it - though you could still trivially log the user's password for direct data access. IMHO, logging a password you receive in plain text is far from a hack. To me a hack requires a little complexity or inginuity.
Rick
On 28/10/2013 19:14, Douglas Mortensen wrote:
So.... given that type of scenario, if filesystem permissions weren't correct, or some new exploit surfaced that allowed someone bypass or elevate to root, then they could theoretically have access to the entire fileystem including where emails are stored.
...
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker.
This type of encryption is ideal and some regulations prefer (although don't require) it.
OK, but encryption will only help if the bad guy, who gets elevated to root, can not access the decryption keys. But you initially suggested Dovecot has to decrypt the mails, so I would think root access would be able to obtain keys and run (in some manner) suitable decryption, even if offline back in its lair.
And this brings me to something I wanted to ask from your first post - and please forgive a basic question. Why does Dovecot need to decrypt the messages? Why could not the messages be encrypted, and only the clients decrypt them - this way only the clients would have the decryption keys and the bad root-guy can't get the keys.
Is true that Dovecot needs access to mails in clear? If yes, what part of the mails does Dovecot need in clear - might clear 'headers' be sufficient for its purposes, so that message content remains encrypted?
Such a scenario might require all users (or, maybe, just those users that wanted this facility) to ensure they had suitable clients, maybe Thunderbird with a suitable plug-in, or maybe a special-purpose client. And whatever public email server you (or the customers) are running would have to encrypt public email on receipt, and decrypt on public transmission, but 'in-company' email within each customer could remain encrypted, anyway.
Such a scheme would depend, though, on the extent to which Dovecot does require access to mail 'content' (in addition to Dovecot housekeeping data such as time of receipt, read status, index value, etc).
Hence the question, does Dovecot need access to mail in clear?
regards, Ron
On 10/28/2013 03:14 PM, Douglas Mortensen wrote:
If a customer has vulnerable PHP code on a website, some of these will allow a remote file upload. I have seen cases where they upload a PHP script that is a sort of web-based console/shell to the server (file-system, etc.). It provides several tools which all run through the uploaded PHP script to try to brute force and do other attacks. I've seen attempts at a root exploit. We've never had a root exploit and any such case of a customer's site being hacked has been easily contained by simple filesystem permissions being correct (and the fact that we have apache setup to run all scripts as the user who is the owner of the script files, which confines the script to that users' permissions). Still nobody loves the idea of bad guys trying to hack on your box.
If an attacker gets root, the entire exercise is pointless, because he can get the decryption key. So you "don't have to worry" about that case =)
A suggestion, not dovecot-related:
The web users -- in our case, www.example.com -- shouldn't have access to anything outside of the web root. You can achieve this within PHP by placing everything that the website will need under one directory, and setting (in apache):
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
Personally, I don't trust PHP at all, so we create a separate web user for each vhost and run them under mpm-itk <http://mpm-itk.sesse.net/>.
So.... given that type of scenario, if filesystem permissions weren't correct, or some new exploit surfaced that allowed someone bypass or elevate to root, then they could theoretically have access to the entire fileystem including where emails are stored.
Who has access to the maildirs on your systems? On ours, everything is owned by deliver:deliver, with mode 700 or 600. The dovecot 'deliver' user is the one who reads and writes all mail. (It is in fact a misnomer now that we use LMTP). You can achieve the same by setting mode=600 everywhere in dovecot.conf, but this depends on your setup.
Suppose someone gains access to the 'deliver' user. That user is the one who reads and would decrypt the mail; therefore the attacker can read the mail anyway. But if they don't gain access to the 'deliver' account, what can they do? Barring incorrect permissions or a kernel bug, nothing.
The permissions are handled by dovecot, which ostensibly you trust. And if there's a kernel bug, you have bigger problems.
Am 28.10.2013 20:49, schrieb Michael Orlitzky:
On 10/28/2013 03:14 PM, Douglas Mortensen wrote:
If a customer has vulnerable PHP code on a website, some of these will allow a remote file upload. I have seen cases where they upload a PHP script that is a sort of web-based console/shell to the server (file-system, etc.). It provides several tools which all run through the uploaded PHP script to try to brute force and do other attacks. I've seen attempts at a root exploit. We've never had a root exploit and any such case of a customer's site being hacked has been easily contained by simple filesystem permissions being correct (and the fact that we have apache setup to run all scripts as the user who is the owner of the script files, which confines the script to that users' permissions). Still nobody loves the idea of bad guys trying to hack on your box.
If an attacker gets root, the entire exercise is pointless, because he can get the decryption key. So you "don't have to worry" about that case =)
A suggestion, not dovecot-related:
The web users -- in our case, www.example.com -- shouldn't have access to anything outside of the web root. You can achieve this within PHP by placing everything that the website will need under one directory, and setting (in apache):
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
oh no - do *not* place the sesiondata anywhere inside open_basdir this is one of the badest things you can do because any otherwise harmless script bypassed whatever security restriction will be able to read *any* session data
but hey, also PHP upstream a few years ago had no clue about session-security
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/28/2013 04:10 PM, Reindl Harald wrote:
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
oh no - do *not* place the sesiondata anywhere inside open_basdir this is one of the badest things you can do because any otherwise harmless script bypassed whatever security restriction will be able to read *any* session data
You have a point, but I wouldn't go as far as to say it's one of the worst things you can do. If a vulnerable PHP script allows an attacker to (at least try to) read arbitrary files, then it's possible to read session data that lies within open_basedir. Note that they can already read your database credentials out of config.php at that point.
But, if you put the session data under open_basedir, then it's easy to restrict access to the entire /var/www/example.com hierarchy to the one user that needs it: www.example.com. In the scenario I described, I'm able to tell our customers that their websites are "physically" separated from our other customers.
If there's a vulnerability in someone else's site, the kernel (via filesystem ACLs) will prevent it from affecting yours. The web user for example.NET truly cannot even traverse /var/www/example.COM, where everything important to you is stored. This is robust against Apache, Ruby, Python, etc. vulnerabilities as well -- not just PHP.
I already mentioned that I don't trust PHP. Our sites would be just as secure if open_basedir stopped working tomorrow, since the filesystem ACLs are what we trust to work. So, we trade the potential to read sessions for that peace of mind. Not trying to downplay your complaint, just pointing out another POV.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux)
iQIcBAEBAgAGBQJSbvzxAAoJEBxJck0inpOi2AUQAJCnroIfBiaB1EIeV+X0wfE4 drfac6wdp16bQxRBQOj2if0qhG363bK3jVTwirEsSeWgmE9FBMDiiQeLe3txL4Nb 7NffcX/ThxM9i7Xwpd13ZMsmOlJiTbRg54AeLaBP7oUVnRd5wyaby60KyFDF9raN LP8aYtVs2GR8tCG1tEbwfoOZGmAtRx8Ku7HiYHlUBiyHdFFg86svV//ShiHpp9+N 4m+1uDEyLsRZ8o9U7x7p/mAwB6sHLcRlQNIA5lHdI8eGqy3J/H+O61u9zs1a4YPS XKUY6wkLc9ksuD56N+an+jT51+0KybyJTOh8m4ZjEhZLBdkhzkeLQkAkQ4XG0MLW 7IsEq6SpY7j/0jSI/DoXBu/dsY275J9BpciRisKBmmZQEybZqzrgUWyHrWSKa72R OjiCnYCrnQj8q71k+U3jUKL+b4xChtrN6+JzIAbCdVjfu7UTaBquz0cN29EnopnB HqzWLwqP1aXlBzlVBGvyVN8mQWDEbtKIMcH0FvT5UYR+YGKxhaEadVFRcqx2t+p/ zifIN1g4hn66V4nxv1ULi3nM1rze8RUbjj9cJL1xP+iEstJdfdo+Fz5GNnp2dq0t E3lvghfv5fL9syaq7eanHU4W0sfF9IbtJ4cqbyzAKi5zBwWuk2tueQ1N1GX++CxG mMFqEPKR6gkUGX/ooEIc =iaNf -----END PGP SIGNATURE-----
On 29/10/2013 10:10, Michael Orlitzky wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/28/2013 04:10 PM, Reindl Harald wrote:
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
oh no - do *not* place the sesiondata anywhere inside open_basdir this is one of the badest things you can do because any otherwise harmless script bypassed whatever security restriction will be able to read *any* session data
You have a point, but I wouldn't go as far as to say it's one of the worst things you can do. If a vulnerable PHP script allows an attacker to (at least try to) read arbitrary files, then it's possible to read session data that lies within open_basedir. Note that they can already read your database credentials out of config.php at that point.
But, if you put the session data under open_basedir, then it's easy to restrict access to the entire /var/www/example.com hierarchy to the one user that needs it: www.example.com. In the scenario I described, I'm able to tell our customers that their websites are "physically" separated from our other customers.
If there's a vulnerability in someone else's site, the kernel (via filesystem ACLs) will prevent it from affecting yours. The web user for example.NET truly cannot even traverse /var/www/example.COM, where everything important to you is stored. This is robust against Apache, Ruby, Python, etc. vulnerabilities as well -- not just PHP.
I already mentioned that I don't trust PHP. Our sites would be just as secure if open_basedir stopped working tomorrow, since the filesystem ACLs are what we trust to work. So, we trade the potential to read sessions for that peace of mind. Not trying to downplay your complaint, just pointing out another POV.
Some time ago, we too, evaluated the pros and cons given our design, and we too, decided on the lesser evil and keep it under open_basedir, have done for many many years without problem, of course I'm not so naive to think it may never one day be a problem for a single host, when running shared hosting there are always risks, in everything.
Michael Orlitzky skrev den 2013-10-28 20:49:
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
so dont create tmp upload dirs in webroot, this is classic way of showing no care
On 10/30/2013 09:01 AM, Benny Pedersen wrote:
Michael Orlitzky skrev den 2013-10-28 20:49:
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
so dont create tmp upload dirs in webroot, this is classic way of showing no care
DocumentRoot is /var/www/$domain/$host/public.
Am 30.10.2013 15:54, schrieb Michael Orlitzky:
On 10/30/2013 09:01 AM, Benny Pedersen wrote:
Michael Orlitzky skrev den 2013-10-28 20:49:
php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
so dont create tmp upload dirs in webroot, this is classic way of showing no care
DocumentRoot is /var/www/$domain/$host/public
and so open_basedir should be the same and *not* include "upload_tmp_dir" and "session.save_path", otherwise this all is nonsense from security point of view
and to come back to topic: do *not* install a public webserver on your mailserver - period
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 28.10.2013 20:14, schrieb Douglas Mortensen:
Currently our dovecot servers are on our webhosting linux boxes. We are using the LAMP stack to host websites, and also doing email with postfix & dovecot on these systems. We provide this as a hosting setup for 100+ accounts/websites on a single server (a multi-tenant setup). Each customer has anywhere between 1-100 email accounts which Dovecot services.
If a customer has vulnerable PHP code on a website, some of these will allow a remote file upload. I have seen cases where they upload a PHP script that is a sort of web-based console/shell to the server (file-system, etc.). It provides several tools which all run through the uploaded PHP script to try to brute force and do other attacks. I've seen attempts at a root exploit. We've never had a root exploit and any such case of a customer's site being hacked has been easily contained by simple filesystem permissions being correct (and the fact that we have apache setup to run all scripts as the user who is the owner of the script files, which confines the script to that users' permissions). Still nobody loves the idea of bad guys trying to hack on your box.
So.... given that type of scenario, if filesystem permissions weren't correct, or some new exploit surfaced that allowed someone bypass or elevate to root, then they could theoretically have access to the entire fileystem including where emails are stored.
I hope to never have this sort of thing happen. We patch our systems regularly and have other security measures we follow to prevent this. We also are managing most of the PHP scripts customers use ourselves now and are updating those for the CMS' and other systems proactively.
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker.
This type of encryption is ideal and some regulations prefer (although don't require) it. - Doug Mortensen Network Consultant Impala Networks P: 505.327.7300
you shouldnt host mail/imap services on the same servers with massive http hosting, i dont see a real connection between php bugs etc and dovecot, it more a question of setup design you have choosen what makes thing more bad then they have to be
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Michael Orlitzky Sent: Monday, October 28, 2013 11:52 AM To: dovecot Subject: Re: [Dovecot] Encryption solution for messages at rest
On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
Hi,
We have clients with various security & compliance requirements. Although not required, it would be ideal to have messages encrypted at rest.
You can rule out a lot of the crazier options by answering the questions,
(a) What attack scenario do you have in mind?
(b) How will encryption help?
Best Regards MfG Robert Schetterer
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSb2mWAAoJEP8jBObu0LlEWkAH+gImez3F9cz1c5TcbgWTMdP6 onrp2Swd5gw6bKNkj2R6bzvtNPTNtrCUxVNU8c8YIIyeMK+fq3d6YxjB8p5nwrrR AqL82xo97CbjPluldrcUAZUzBSUMrIjXC4dKAQvpD/Nhl7QMmPmeCcvZ8B39urcs 4AT2vSDI5wvuMtpKzj2ohA5P9UAwDPmm6beihWn73IubCWeUcO47sJj4W0dnO2bv OZ2k6TwLfRbdkqH3wH0JEGqnYgrRxm9czkidH1C5JJM5MAosJoTn21dSbLZoqD8O pmdT7jqUfyZ1GkUDO2OqEHl1V04RQhlP0wxAKTh39ahvQrXZgPzTwhxw6T0cZoM= =zZYc -----END PGP SIGNATURE-----
I think your problem can be more generically restated as:
- Untrusted users have access to the mailstore, eg employees who maintain the server, attackers who break into the system as untrusted user accounts
- There is some trusted process to get access to decryption keys and largely this process is secure (obviously except attacks which succeed to escalate to root, or if employees typically get root access)
- How to extend this secure key access process to dovecot
So Exchange offers this feature where you can encrypt the mail and grant specific users access to decrypt subsets of the mail. This means that employees managing the mail server may not have access to decrypt the messages for their boss, etc (without at least using trickery to bypass and escalate their privileges - of course this is always possible, especially with physical access, but it reduces the attack surface)
Off the top of my head it seems like any attempts to do this using block disk encryption layers substantially boil down to equivalent to standard file permissions. eg adding ecryptfs on the mail store means you need to prevent access to the mounted decrypted files, which given the mail store is a long running process, is largely equivalent to just using file permissions, MAC, grsec, etc to protect the dir?
Timo's suggestion to incorporate in Dovecot opens up possible solutions. ie now files can be decrypted *as* they are required by the mail server. decryption key can probably be stored in userdb without loss of privacy (since if you can get the password for the account you can just pickup the emails via imap?). Bonus marks if you design some encrypted key store, but is seems challenging to add value here, possibly against more specific attacks, eg you don't want your database DBA to be able to get access to the decryption keys, hence a separate (simple) database just for decryption keys moves the problem sideways.
Using Timo's filter this all seems very do-able, but performance will obviously be impacted. Modern processers are very fast at certain types of encryption opts though..?
I'm interested to see what you produce. Seems interesting, but as many have already commented, it really only defends against a limited attack surface and not at all if the dovecot process or root/dovecot user is compromised. I think corporates would quite like this feature though
Ed W
On 28/10/2013 19:14, Douglas Mortensen wrote:
Currently our dovecot servers are on our webhosting linux boxes. We are using the LAMP stack to host websites, and also doing email with postfix & dovecot on these systems. We provide this as a hosting setup for 100+ accounts/websites on a single server (a multi-tenant setup). Each customer has anywhere between 1-100 email accounts which Dovecot services.
If a customer has vulnerable PHP code on a website, some of these will allow a remote file upload. I have seen cases where they upload a PHP script that is a sort of web-based console/shell to the server (file-system, etc.). It provides several tools which all run through the uploaded PHP script to try to brute force and do other attacks. I've seen attempts at a root exploit. We've never had a root exploit and any such case of a customer's site being hacked has been easily contained by simple filesystem permissions being correct (and the fact that we have apache setup to run all scripts as the user who is the owner of the script files, which confines the script to that users' permissions). Still nobody loves the idea of bad guys trying to hack on your box.
So.... given that type of scenario, if filesystem permissions weren't correct, or some new exploit surfaced that allowed someone bypass or elevate to root, then they could theoretically have access to the entire fileystem including where emails are stored.
I hope to never have this sort of thing happen. We patch our systems regularly and have other security measures we follow to prevent this. We also are managing most of the PHP scripts customers use ourselves now and are updating those for the CMS' and other systems proactively.
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker.
This type of encryption is ideal and some regulations prefer (although don't require) it.
Doug Mortensen Network Consultant Impala Networks P: 505.327.7300
-----Original Message----- From: dovecot-bounces@dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Michael Orlitzky Sent: Monday, October 28, 2013 11:52 AM To: dovecot Subject: Re: [Dovecot] Encryption solution for messages at rest
On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
Hi,
We have clients with various security & compliance requirements. Although not required, it would be ideal to have messages encrypted at rest. You can rule out a lot of the crazier options by answering the questions,
(a) What attack scenario do you have in mind?
(b) How will encryption help?
participants (11)
-
Benny Pedersen
-
Douglas Mortensen
-
Ed W
-
Frerich Raabe
-
Michael Orlitzky
-
Miquel van Smoorenburg
-
Noel Butler
-
Reindl Harald
-
Rick Romero
-
Robert Schetterer
-
Ron Leach