diff options
| -rw-r--r-- | best_practices.mdwn | 143 |
1 files changed, 97 insertions, 46 deletions
diff --git a/best_practices.mdwn b/best_practices.mdwn index ed2bdc5..bcabdf7 100644 --- a/best_practices.mdwn +++ b/best_practices.mdwn @@ -4,12 +4,104 @@ Translations: [[Castellano|best practices_es]] [[!toc levels=3 startlevel=2]] -*This appendix contains the text of the policy with specific best - practices added below relevant sections. It is a work in - progress. Please help expand!* +Portuguese version: https://pad.puscii.nl/p/Practice-pt +Spanish version: https://pad.puscii.nl/p/Practice-es -Obviously, every security/privacy level requires that you keep your -software up to date to the current knowledge of security issues. +*This appendix contains the text of the policy with specific best practices added below relevant sections. It is a work in progress. Please help expand!* + +Obviously, every security/privacy level requires that you keep your software up to date to the current knowledge of security issues. + +## Mail + +### Exim + +#### Level 1 + +##### [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) starttls with other compliant servers’, certs verified against cacert/… + +### If the server adds the IP address of a user sending a mail through its service anywhere in the email, the user is informed about this. + +### The connections between the user and the server are always encrypted. + +### Use StartTLS to exchange mails with other servers whenever available. + +## The server must have its own SSL certificate signed by one of a given set of certificate authorities. See best practices documents for details. + +#### Level 2 + +##### [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) tls is required with other compliant servers’, certs verified with fingerprint + +### Postfix + +#### Level 1 + +##### If the server adds the IP address of a user sending a mail through its service anywhere in the email, the user is informed about this. + +Not a matter of server configuration: you should use your communication channels to pass this information to your existing users (e.g. newsletter, announcement mailing list). New users should be informed as part of the account signup process. You may additionally explain this on your website. + +##### The connections between the user and the server are always encrypted. + +* Server Side: [Configure Postfix to use X.509 certificate](http://koti.kapsi.fi/ptk/postfix/postfix-tls-cacert.shtml) retrieved on Apr 3 2013 +* Client side: Kindly ask your provider for documentation :) + +##### Use (Start)TLS to exchange mails with other servers whenever available + +## The server must have its own X.509 certificate signed by one of a given set of certificate authorities. + +There are many problems with the X.509 ecosystem, partly explained here: http://lair.fifthhorseman.net/~dkg/tls-centralization/ + +Depending on how well your users understand X.509-certifcates, we recommend 4 different scenarios: + +a. Commercial Cert. Authority: usually costs money, but users do not get confused because their mail clients are shipped with commercial root certificates, so there will be no warning messages about untrusted certificate chains. Doesn't necessarily increase the connection security if the adversary can issue certificates because a certificate authority has gone rogue or is a state, for example. See the [Security Section on wikipedia](https://en.wikipedia.org/wiki/X.509#Security) for more details. + +b. CaCert: Users still need to validate and install CaCert's root certificates because it's not included in any mail client. But they might already have done that step for other providers. There is also a Debian package which makes it easy for Debian/Ubuntu users to install it. + +c. Self Signed certificates/Own Authority: con: not included in the default mail user clients of your users. They have to install the (root-)certificates. If they don't use certificate pinning and have other commercial authorities still installed you win nothing but confusion. You risk to teach your users into bypassing security warning messages. If properly applied by your collective of crypto-ninjas, it *can* be more secure. + +d. Monkeysphere: You can use openPGP keys (certifications) to authenticate services. This is technically an excellent solution, albeit not really supported in popular software. If you have power users, we recommend trying it out. More information on http://monkeysphere.info/ + +### Level 2 + +#### The server doesn't add the IP address of a user sending a mail through its service anywhere in the email. + +* [IPs in headers]( https://we.riseup.net/debian/mail#postfix ) + +#### TLS is required with other level 2 compliant servers. Certificates are verified with fingerprint. +An equivalent solution is to implement an IPsec link between relevant collectives which makes it unnecessary to use TLS. +In order to implement this, you need to know the up-to-date fingerprints of the certificates of the groups that you plan to cooperate with in this way. There are many ways to do this, but it depends too much on social and technical context so we will not detail them here, only state that it is a requirement. Pinning those fingerprints and updating them when changed can be a hassle (unless an automated and secure protocol and implementation for this purpose becomes available). +[Postfix TLS README](http://www.postfix.org/TLS_README.html ) + +### Level 3 + +#### Mail is also available as a hidden Tor service. +https://www.torproject.org/docs/tor-hidden-service.html.en adapt to the needs of a mailserver. +Client: [torbirdy](https://trac.torproject.org/projects/tor/wiki/torbirdy) is a useful Thunderbird extension to make use of such a hidden service. + +## Filesystems and Storage + +### Level 1 + +* User data that is not publicly accessible is stored encrypted, using a strong passphrase. See best practices documents for details. This includes mails, databases, list archives, restricted websites and others. +In GNU/Linux, cryptsetup: +* How to set up an encrypted filesystem in several easy steps? http://www.debian-administration.org/articles/469 +* Setting up an encrypted Debian system http://madduck.net/docs/cryptdisk/ + +### Level 2 + +* Swap is stored encrypted. +For this you can use said cryptsetup too. +* The operating system and its configuration is stored encrypted with a strong passphrase. See best practices documents for details. +Today you can use many OS installers that achieve this: Ubuntu alternative text installer? +Don't rely on hard drives that promote encryption on the disklayer, they are often not properly implemented or come with backdoors for example + +### Level 3 + +* Swap is encrypted with a random key on boot. +* Create an encrypted swap area http://www.microhowto.info/howto/create_an_encrypted_swap_area.html +https://we.riseup.net/debian/encrypted-swap +http://linux.die.net/man/5/crypttab -> section "swap" + +# Older best practices ## Mail @@ -21,25 +113,6 @@ software up to date to the current knowledge of security issues. * [StartTLS-postfix](http://metatron.sh/kmw/Transformers/PostfixCacertVerifyHowto) or [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) starttls with other compliant servers’, certs verified against cacert/... *level 1* * [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) tls is required with other compliant servers’, certs verified with fingerprint *level 2* -## Webmail - -* Secure connections: only encrypted connections between the server and the user *level 2* -* Optional unencrypted connections are visibly marked as insecure *level 1* -* Session cookies: all sessions must be stored as cookies. Session IDs cannot be in the URL. *level 2* -* IPs in headers: the user's home IP address does not appear in any email headers. *level 2* -* IPs in headers: if the user's home IP address remains in the email headers, then this fact is visibly marked as insecure. *level 1* -* Due to the fact that client-side scripting, such as Javascript, can reveal the client IP address (this is why users of Tor typically disable it), Webmail must be functional without it. *level 3* -* session data is deleted off the server within five minutes after logout or session expiration *level 2* -* the session ID algorithm and cookies do not use or store users' IP addresses, neither in plain text or some garbled form; sessions are not restricted to IP addresses (since this would prevent access with anonymity tools such as Tor). *level 3* - - -## Hosting - -* root access to hosting services is always encrypted *level 1* -* access to hosting services is encrypted by default (non-encrypted is allowed) *level 1* -* access to hosting services is always encrypted *level 2* -* access to hosting services is accessible via a hidden tor service or a tor exit enclave *level 3* - ## Certificates and keys for encrypted stream-based services * Private keys are only stored encrypted *Level 2* @@ -49,14 +122,6 @@ software up to date to the current knowledge of security issues. If you are using mod_ssl with apache and an RSA key for the server, somebody tentatively suggests: <code>SSLCipherSuite TLSv1:!MD5:!EXP:!LOW:!NULL:!MEDIUM:!ADH:!DSS</code> -## Filesystems and Storage - -* swap is encrypted *level 2* -* swap is encrypted with a random key on boot *level 3* -* the operating system and its configuration is encrypted with a strong passphrase: minimum 20 characters, including special characters, mixed case letters and digits *level 2* -* User data that is not publicly accessible is encrypted. This includes mails, databases, list archives, restricted websites and others. The encryption passphrase contains at least 20 characters, including special characters, mixed case letters and digits. *level 1* - - ## Logging * Logs containing user identifiable information are stored encrypted or only in memory. Otherwise the users are informed about this. *level 1* @@ -79,17 +144,3 @@ a2enmod removeip Comes with "Filesystem and Storage Level 2" * System logs (not related to user activities) are not stored. *level 3* - - -## Users - -* Advise users about good passwords and polices. For example: Never send them in clear text, never telling a password to anyone, etc. See [best practices](practices) for some good password strength information that can be used for this purpose. *level 1* -* Force users to use strong passwords by making the system impose a defined password policy. *level 2* -* Shell Sandbox: shell accounts for users only in vservers, separate boxes, or similar sandboxes. No end user should should have a login on a server that provides sensitive services. *level 2* -* Shell accounts isolated from other users: each user shell account exists in a chrooted environment that has no visibility into other user's environments (files, processes, etc.). *level 3* - -## Evaluation of policy compliance - -* yearly periodic self-evaluation: manually checking at least every twelve months that requirements supposed to be achieved actually are. *level 1* -* semi-yearly self-evaluation: manually checking at least every six months that requirements supposed to be achieved actually are. *level 2* -* quarterly self-evaluation: manually checking at least every three months that requirements supposed to be achieved actually are. *level 3* |