1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
# Appendix: Best practices references
[[!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!*
Obviously, every security/privacy level requires that you keep your
software up to date to the current knowledge of security issues.
## Mail
* [IPs in headers](http://riseuplabs.org/privacy/postfix/) the user's home IP address should not appear in any email headers. *level 2*
* if it does appear, users must be informed about this *level 1* perhaps use server IP instead of localhost for [riseup hack](http://riseuplabs.org/privacy/postfix/)
* The connection between the server and the user is always encrypted. *level 2*
* optional unencrypted communication between user and server are visibly marked as insecure *level 1*
* [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*
* Private keys are only stored encrypted and off-site *Level 3*
* Stream-based communication uses only a well-established set of cryptographic parameters (ciphers, message digests, asymmetric encryption algorithms, etc). See best practices documents for details. *Level 1*
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*
* Logs contain no user identifiable information. *level 3*
Apache logs have no IP addresses: [mod_removeip](http://riseuplabs.org/privacy/apache/)
Under Debian with Apache2:
<code>
apt-get install libapache2-mod-removeip
a2enmod removeip
/etc/init.d/apache2 force-reload
</code>
* Logs containing information about non-individual user activities are stored encrypted or only in memory. *level 1*
* Logs contain no information about non-individual user activities. *level 2*
* System logs (not related to user activities) is stored encrypted or only in memory. *level 2*
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*
|
