Document Synapse Server Hardening Best Practices

[brainscar]

Hi,

I was wondering what the best practices are for hardening a Synapse server?

For example, I noticed Synapse listens on http://127.0.0.1:8008

Does it make sense to get a local certificate to change it to https://127.0.0.1:8008 ?

I hope we can share ideas.

Thank you.

[brainscar]

I can write a wiki article if everyone helps with ideas.

[yang202]

想知道怎么查看已经安装的synapse的版本 还有就是怎么版本控制

[Willt125]

I second this request; it will make version management a bit easier, since we won't have to guess how out-of-date our rooms are.

On Thu, May 23, 2019 at 9:15 PM yang202 notifications@github.com wrote:

想知道怎么查看已经安装的synapse的版本 还有就是怎么版本控制

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/matrix-org/synapse/issues/5141?email_source=notifications&email_token=ACBYGLK7336VZOWHPA7LT2LPW46S3A5CNFSM4HK4GBO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWD4QYA#issuecomment-495437920, or mute the thread https://github.com/notifications/unsubscribe-auth/ACBYGLK7HYQX7YOQKUPD3STPW46S3ANCNFSM4HK4GBOQ .

[KnightWhoSaysNeeeowWumPing]

It's been a while but since I still can't find any good source on hardening a synapse server to this day, I want to share my personal thoughts on securing a matrix/synapse instance - Maybe it's of use to anyone...

DISCLAIMER: This is no guideline or professional advice of any kind! Just some random internet-guy's ideas

General hardening

• SSH hardening (key-based login only, change port, etc.)
• Basic firewall (using iptables in my case) - As far as I've figured out, the following configuration is necessary for a matrix server to work properly (suggestions for further restrictions/improvements are very welcome!):
  • incoming https rule for basic server functionality, e.g. iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
  • outgoing rule for https (the server has to "speak" to other homeservers), e.g. iptables -A OUTPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
  • for also reaching homservers that were set up without a reverse proxy the outgoing port 8448 is needed (although there seems to be some uncertainty, whether this kind of setup is recommended, see #2438), e.g. iptables -A INPUT -p tcp --dport 8448 -m conntrack --ctstate NEW -j ACCEPT
  • a rule on both chains to allow all established connections, e.g. iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT, iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
  • a loopback rule on both chains to allow internal connections, e.g. iptables -A INPUT -i lo -j ACCEPT, iptables -A OUTPUT -o lo -j ACCEPT
  • and of course don't forget a rule for your SSH connection before changing the overall policies to deny or otherwise you're going to lock yourself out, e.g. iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT (change SSH port accordingly)
• Furthermore I've heard that - for security reasons - it was not advisable to run a frontend (e.g. Element) on the same server synapse is running on - I just don't have the source of this information at hand, atm
• ... (there are tons of other general - non synapse specific) security measures to consider, like AppArmor or SELinux - if you're not working on a VPS - or IDS/IPS like rkhunter, CrowdSec, etc.)

Hardening the nginx configuration

I'm running synapse on nginx basis, so these are some measures I successfully applied to my nginx configuration:

• Improved SSL security:
  • Removed support for the old/insecure protocol versions 1.0 and 1.1; activated support for the most recent version 1.3; disabled som insecure ciphers Since I used Let's Encrypt for certificate generation, I had to change these settings not only in the nginx configuration file (/etc/nginx/nginx.conf - it contains a SSL section!) but also within the Let's Encrypt config file (/etc/letsencrypt/options-ssl-nginx.conf)

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

    I also checked (via cat /etc/nginx/sites-available/* | grep ssl_protocols) if there were any overrides of the protocol version, but there were none in my case

  • Created my own Diffie-Hellman group for SSL (This may take several minutes!) openssl dhparam -out dhparams.pem 4096 sudo mkdir -p /opt/cert && sudo cp dhparams.pem /opt/cert/ Added the following line to the nginx configuration file (/etc/nginx/nginx.conf):

    ssl_dhparam /opt/cert/dhparams.pem;

• Added some best practice header information to the nginx configuration file (/etc/nginx/nginx.conf):

  add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
  add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
  add_header X-Frame-Options "SAMEORIGIN";

Resources

• https://geekflare.com/nginx-webserver-security-hardening-guide/
• https://www.acunetix.com/blog/web-security-zone/hardening-nginx/
• https://libre-software.net/tls-nginx/

There are a lot more nginx specific security settings covered in these resources, e.g.

• disabling any unwanted HTTP methods
• controlling resources and limits

But since I'm not that much into synapse, I don't know which HTTP methods synapse uses and how to set good resource values to still support sharing images and videos on the matrix homeserver.

Maybe there's someone out there who is willing to experiment and maybe even wants to help writing a community guide for hardening synapse.

[H-Shay]

Thanks for adding this! I wonder if you would be willing to open a PR against our docs with this information?

[richvdh]

The intended action here was for someone on the Synapse team to write something here, possibly based on the contributions in #11758.

I think we could easily create a "Security best practices" list on https://matrix-org.github.io/synapse/latest, containing a list of bullet points like:

• use a reverse-proxy and don't have synapse listening on public ports
• make sure you don't have open registration (consider disabling registration altogether)
• maybe a link to https://matrix.org/blog/2019/11/09/avoiding-unwelcome-visitors-on-private-matrix-servers
• any config settings that you should enable? or not enable (hopefully our settings default to secure?)

It doesn't need to be perfect - just a placeholder that we can extend over time would be a great start.

(I don't think we should include general server-hardening best practices like locking down SSH access and using a firewall - we're not here to teach people server administration)