Jump to: navigation, search

Security and Privacy

Revision as of 18:34, 7 February 2016 by Gkiagia (Talk | contribs)

Security and Privacy

This page discusses the security mechanisms and the configurations we use to prevent malicious attacks. Note that the information here will be limited to prevent exposing possible vulnerabilities.

Intrusion Prevention Mechanisms

We use:

To Do


TODO: use some short of encryption for the content of our users.

Suggestion: Allow users to opt-in to a service where their entire inbox is encrypted with their GPG key regardless if the sender of the original e-mail used GPG.



  • Use non-default ports for ssh / imap? / ...
  • Block remote root login
  • Only allow ssh login using Private Keys
  • Renew (rotate) server ssh keys and use ECDHA/ECDSA
  • Automated security updates without human intervention
  • Setup reminders about expiring certificates
  • Webmin (w/ someone monitoring)
  • monit with good rules and e-mails to Xestra


  • Currently we have an amazingly insecure HTTPS setup with many security issues. In this link there is how to fix everything along with all the problems. A "good" server must get an A- at least on this test.
  • We run an "old" version of Apache (2.2.22) which has public [and private ;-) ] vulnerabilities. An upgrade is recommended. You may use the Debian Jessie version of Apache.

Additionally, our Root CA uses MD5 signatures which is long now obsolete and considered insecure.


  • Prevent outbound spoofing ( check if From: matches authenticated username )
  • Notify user with the spam filter if incoming e-mail is spoofed (invalid SPF / IP not in From: domain MX)
  • Install Roundcube Spam Plugin.
  • Use BlackHole MX.
  • Train SpamAssassin / Spam Filter with SpamFeed.Me.
  • Download remote images in the server and replace the remote links with server links.