search

element-hq / synapse

Synapse: Matrix homeserver written in Python/Twisted.
https://element-hq.github.io/synapse
GNU Affero General Public License v3.0
1.07k stars 128 forks source link

Document Synapse Server Hardening Best Practices #5141

Open matrixbot opened 7 months ago

matrixbot commented 7 months ago

This issue has been migrated from #5141.

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.

maltfield commented 3 months ago

I discovered this ticket when googing "synapse install hardening", which brought me to this old ticket from May 2019

Looks like there's been a lot of interest from others in the past 5 years (see link above)

Has there been any progress with this task that can be updated in this ticket?

maltfield commented 3 months ago
  • use a reverse-proxy and don't have synapse listening on public ports

@richvdh would you mind elaborating on what exactly a "public port" is? Or did you mean for orgs with VPNs to have to connect to the intranet first (but wouldn't that break federation)?

And what exactly are the security benefits to having a reverse proxy in-front of synapse?

richvdh commented 3 months ago
  • use a reverse-proxy and don't have synapse listening on public ports

@richvdh would you mind elaborating on what exactly a "public port" is? Or did you mean for orgs with VPNs to have to connect to the intranet first (but wouldn't that break federation)?

I just meant: don't have Synapse listening directly to the internet; all inward communication should be via a reverse-proxy. Normally that means configuring Synapse to listen on localhost rather than a public IP address, but if your reverse-proxy is on a separate machine to Synapse, you'll need some sort of private network or VPN between the reverse-proxy and Synapse.

And what exactly are the security benefits to having a reverse proxy in-front of synapse?

Put bluntly, a reverse proxy is likely much more hardened against odd-shaped or malicious HTTP traffic than Synapse, because that's a key part of their job (whereas Synapse has a lot of other things to worry about). We're not aware of any vulnerabilities on Synapse's HTTP stack, but a reverse-proxy is good practice as a layer of protection.