Security

By nature, a TURN server accepts packets from the internet and forwards them to other addresses. Therefore, an improperly secured TURN server can become a target for two threats: unauthorized bandwidth consumption by third-party applications and SSRF attacks against internal infrastructure. In Slyber Turn Server, both issues are resolved at the architectural level.

Slyber Turn Server does not store a user database on disk and does not require database queries on every connection. It uses the industry-standard WebRTC ephemeral token scheme:

When a client connects to the TURN server:

You can flexibly combine 4 layers of protection for the credential issuance endpoint:

A request can include the X-Turn-Secret: <your_TURN_SECRET> or Authorization: Bearer <your_TURN_SECRET> header.

If ALLOWED_IPS is configured (for example, 198.51.100.25, 10.20.0.0/16), requests without a secret key are permitted only from the specified IPv4/IPv6 addresses or CIDR subnets (all others receive 403 Forbidden).

If a request comes directly from a browser (without a secret key and without a strict ALLOWED_IPS restriction), the server validates the Origin header:

For all requests without a secret key, a built-in per-IP rate limiter based on the Token Bucket algorithm is enforced:

The server is protected against X-Forwarded-For and X-Real-IP header spoofing: it trusts these headers only when the physical TCP connection originates from a local interface (127.0.0.1 / ::1, i.e., from your local Nginx instance) or when the request is authenticated with a valid X-Turn-Secret.

In the TURN protocol, the client specifies which IP address (Peer IP) the server should forward a packet to. An attacker might attempt to specify the internal address of your database (10.0.0.42), a local server port (127.0.0.1), or a cloud metadata service like AWS/GCP (169.254.169.254) instead of a peer's address.

Slyber Turn Server includes a built-in PeerFilter that inspects every permission request (PermissionHandler) and separates blocked addresses into two categories:

Attempts to reach these addresses are strictly blocked, increment the turn_ssrf_blocked_total attack counter, are logged to the security audit log, and add the client's IP to the offender list (top_offenders) with a 5x penalty weight:

When establishing a WebRTC connection, browsers often mistakenly attempt to probe a peer's local home addresses (such as 192.168.1.1) through the TURN server. This is not a malicious attack, but standard WebRTC ICE behavior. To avoid cluttering the security log with false alarms, PeerFilter drops these packets silently and increments a separate lan_skipped counter instead:

At the same time, the filter explicitly allows forwarding packets to the server's own public address (PUBLIC_IP). This is required for TURN Hairpinning scenarios - when both call participants are behind strict NATs and both are connected to the same TURN server, forwarding media streams between two relay ports on that server.