Signaling server and brute force protection¶

In a similar way to the brute force protection provided by the Nextcloud server, nextcloud-spreed-signaling provides brute force protection to prevent attempts to guess the shared secret between the signaling server and the Nextcloud server.

When requests fail to be authenticated the responses to further requests coming from the same IP address are slowed down, and after certain threshold of failed authentications in certain period of time the requests from that IP address are blocked.

Trusted proxies¶

If there are proxy servers in front of the signaling server (which is the typical setup, with Apache or nginx providing the TLS termination) the IP address of the request belongs to the proxy server. However, it is expected that proxy servers provide the IP address of the original request in the X-Real-IP or X-Forwarded-For headers. Therefore, if a request comes from a configured trusted proxy (defined by trustedproxies in [app] in server.conf the IP address of the request will be got from those headers instead of using the actual IP address of the request (first X-Real-IP will be checked and, if not found, then X-Forwarded-For will be used).

By default, if no trusted proxy is configured, loopback and local addresses are seen as trusted proxies. That is, in the typical setup with a TLS termination proxy running in the same machine as nexcloud-spreed-signaling the proxy will be a trusted proxy, and the IP addresses of the requests will be got from the X-Real-IP or X-Forwarded-For headers.