Using Subnet Filtering for Enhanced SSRF Protection

Today I'd like to share a new feature that we've added to the open source Svix server to protect against server-side request forgery (SSRF): subnet filtering. Customers of the hosted Svix service have always been protected against SSRF attacks, but now open-source customers have an additional tool at the application level to fight attackers.

What is SSRF?

Briefly, SSRF attacks occur when an attacker coaxes a server into returning sensitive information residing on the server itself or in its internal network. A casual perusal of logs on any public-facing server will show you some common ways these attacks happen:

• Attempts to have a server return internal resources, such as locally-stored credentials files
• Attempts to invoke common web-admin scripts that should be accessible only by an admin with proper privileges
• Attempts to access internal resources on the server's local network, e.g., an unsecured database running at localhost:27017

The possibilities are endless, which is why it's critical that your servers are hardened to prevent such attacks.

Because Svix is an open-source platform that enables you to perform secure, reliable webhook delivery to endpoints across the Internet, it's critical that our platform is not vulnerable to malicious actors. And given that a central feature of our platform is allowing users to register arbitrary URLs as endpoints to receive webhooks, we have to ensure that we protect against SSRF attacks in particular.

SSRF Protection Solutions

SSRF attacks are relatively simple to perform. Fortunately, these attacks are also straightforward to protect against.

Svix recommends a multi-tiered approach to security, meaning that you take a security-first approach at all layers of your stack. For example, you should restrict your applications' access to only the internal resources it actually needs. At the network layer, this can be accomplished by:

• Network segmentation using VLANs, or separate VPCs in a cloud environment
• Firewall rules and cloud network security groups.

But you should also protect your applications against inadvertently serving requests to unauthorized resources in the first place, which is where Svix's subnet filtering comes in. While the solution for a webhook platform is simple -- Don't make requests to private IP addresses! -- the actual implementation details are a bit more involved, for a couple reasons:

1. There are scenarios where endpoints in private IP space are desirable: For example, for testing, as well as for clients using open-source Svix internally and for whom private endpoints are not a security risk. Therefore, whether to allow private IP-space endpoints should be configurable.
2. Because determining whether a URL resolves to a private IP address requires making decisions based on the results of DNS queries, we're required to customize our HTTP client beyond what most use-cases would required. The technical details here will likely be discussed in a future blog post.

How to use it?

In the open-source Svix platform, you don't need to do anything additional to protect yourself against SSRF attacks, as protection is enabled out of the box! However, if you need to whitelist any internal IP addresses, you can do so by specifying an array of addresses or subnets in CIDR notation in the whitelist_subnets configuration parameter (SVIX_WHITELIST_SUBNETS environment variable). For example, to allow the individual addresses of 127.0.0.1 and all IP addresses resolving to 10.x.x.x in your Svix deployment, set the configuration parameter to the following value:

[ 127.0.0.1/32, 10.0.0.0/8 ]

This will allow webhooks to be made to any endpoint specifying either an IP address in those ranges or a URL that resolves to an IP in those ranges.

While not recommended, if you understand the risks, are only using Svix in an internal network, and are sure you don't want to limit the subnets at all, you can completely disable SSRF protection by configuring the parameter as follows:

[ 0.0.0.0/0 ]

This will disable any restrictions against creating Svix endpoints that resolve to internal IP addresses.

Closing words

Attackers are clever and always looking for new ways to steal your data. To better safeguard against unauthorized access to your internal networks' data, you should always take a multi-tiered approach to security. This multi-tiered approach should always include network restrictions that only allow your application servers access to the internal resources they actually need. At the application level, open-source Svix makes the fight against attackers a bit easier by preventing SSRF protections out of the box.

For more content like this, make sure to follow us on Twitter, Github or RSS for the latest updates for the Svix webhook service, or join the discussion on our community Slack.