Deploy: StackPath’s web application firewall to protect your Solana RPC

7 min readMay 1, 2022

StackPath is a member of the Solana foundation’s server program. The author is a StackPath employee.

web3 security

In the friendly pastures of web3 builders lean far forward into whatever glass they’re chewing. Scaling comes with success and success from credibility. At any point in your execution into the global jungle of the mainstream an attack might damage your credibility. As a projects credibility can make or break it’s success, security must then be considered a domain problem in the ideation phase.

Web3 security is a broad topic. This post will focus specifically upon securing RPC nodes. RPC nodes can be thought of like traditional API endpoints which act as on-ramps to decentralized ledgers like the Ethereum and Solana blockchain. Even though decentralization is a goal of web3 there still exists centralized points of failure in RPC nodes. If there is a failure in a projects RPC node, the project can go offline from a users perspective. Projects need to consider the following issues:

“Organic” DDoS attacks: legitimate users spamming requests that overwhelm your RPC node.
Bots performing massive amounts of requests in a short period of time such as during an NFT mint. Not only does this pose a risk to your RPC node, it also creates a situation where bots have an unfair advantage against legitimate users!
l3/l4/l7 DDoS attacks against your public facing URL. If someone buys a darknet DDoS attack against http://api.mainnet-beta.solana.com (or whatever URL your RPC is at), will your RPC stay up?

All of these can take an RPC node, and therefore the project, offline. Outages can burn the credibility of a project. Why wait until an attacker finds a reason to pick you as prey? Solve this problem before it becomes a problem. Securing your RPC node from attacks can be done quickly and easily.

How WAF can protect your RPC

A firewall is a term so ubiquitous it’s lost some meaning. In this case, a web application firewall (WAF) is a hosted security component that protects web applications from attackers by analyzing and filtering traffic. A WAF should absolutely be used to be secure your projects web2.0 domain, but it can also be used to secure your RPC.

Primarily, an RPC node needs some sort of rate limiting to protect it from abuse and misuse. There are a few ways to skin the cat of rate limiting, but using SP//’s WAF as a rate limiting guard dog has some advantages over other solutions.

Quick setup. Quickly configure and fine tune rate limiting to your projects needs.
Scale like you need to. Massively, globally, seamlessly.
Easy GUI management and analytics. Or use our developer friendly API back end.

Overview of WAF + RPC Architecture

This deployment provides an efficient application of rate limiting for RPC nodes. It also provides DDoS protection so long as your IP address remains private.

The DNS request resolves to an anycast IP address. An anycast IP address resolve to the closest physical SP// location to the user. In most cases this resolves to a SP// WAF instance operating in an internet exchange within 5ms of distance of the user.
The WAF than makes a determination whether to approve the request. Is it part of a DDoS? Is the IP address rate limited? Does it violate a IP reputation rule? Etc.
If approved, the request travels across SP//’s private network backbone to the RPC node. The RPC node processes the request and responds, and the response flows backwards. There is a latency advantage in SP//’s private global network when compared to the request traversing the public internet.
In my testing this entire process has the same response time as using a public RPC node provided by the Solana foundation. Response times from my location in Dallas to my RPC in Miami are taking about 80–100ms round-trip.

Setup: WAF on the StackPath Portal

Create a StackPath account.
Create a site.
Add WAF to site.
Configure WAF with the following settings.

4a. The “origin” address is the public IP address of your RPC. Note the port number :8080 The WAF only works on the HTTP(S) ports of 80, 443, 8080, 8443. In this case we will be using 8080 as our RPC port.

4b. Setup your RPC as an API endpoint. By adding your RPC node as an API you are telling the WAF that requests to this URL are not from a browser. The WAF will not challenge these requests with captchas and javascript verifications.

5. Setup a rate limiting rule.

As configured this rule will allow from an IP address 50 requests in a 3 minute period and block any requests from an IP address that has made more than 50 requests within a 3 minute period. After 3 minutes is up the counter resets.

Setup: WAF on your RPC

If you’re setting up an RPC on StackPath, checkout my guide for setting up a node on StackPath first.

Configure your infrastructure provider’s network policies.

In StackPath’s Solana portal I’ve opened up 8000-8020 for TCP/UDP for Solana and 8080–8081 for the RPC.

2. Setup a local firewall to deny access to the RPC ports, and therefore the RPC, to anyone except StackPath IP addresses. This way, to communicate with the RPC, requests will have to come through the StackPath WAF. I’m using UFW and a quick bash script to white/green-list StackPath IP addresses because it’s easy in Ubuntu.

2a. Grab a list of SP// IPs through the API or our static page.

curl --request GET \--url 'https://gateway.stackpath.com/cdn/v1/ips?response_type=PLAIN_TEXT' \--header 'Authorization: Bearer yourtokenhere'###

2b. Save the output as a text file. (stackpathiplist.txt in my example)

2c. Create a bash script to add each IP address to the firewall rules.

#!/bin/bash
for i in $(cat stackpathiplist.txt);
do 
sudo ufw allow from "$i" to any port 8080
done
sudo ufw allow 8000:8020/udp
sudo ufw allow ssh

This script will iterate through each line of the text files and add the IP addresses to the firewall rule set.

Notice I also allowed 8000 through 8020 for TCP and UDP. This is for the Solana protocols. Also, please double check that ssh is allowed before you enable ssh.

2d. Once run, the bash script should take a minute to add all the rules. You only need to run it once, and the rules should persist after reboots.

3. You did allow ssh right? Now enable UFW with sudo ufw enable. Check to make sure all the rules are enables with sudo ufw status.You should see StackPath’s IP addresses as well as ports 8000:8020 open for business.

4. Finally, start your RPC with the following options enabled.

--rpc-port 8080 // The RPC port should be configured to 8080--dynamic-port-range 8000–8020 // There is flexibility here, but it should match what the ports you allowed in UFW and the infrastructure provider's network policies--public-rpc-address 0.0.0.0:0000 // I noticed when you use this as your public IP address it shows the RPC public address as "None" in Gossip even without the --private-rpc flag enabled--no-port-check // Otherwise it will attempt to check 0.0.0.0:8080 and cause an error

Testing

Now that it’s up, lets look at it in action.

I used a bash script to run requests until it triggered the block rule I created. While the rule is triggered, I can’t make requests on my RPC and the WAF returns an error code of my choosing.

In the SP// portal I can see my my IP address hammering away and the WAF blocking it.

I can even drill down into each instance of triggered rule.

And that’s it! In my next post I will detail a full NFT mint using a website hosted on SP// CDN and an RPC hosted on SP//. All protected by WAF.

If you’re interested in using SP// WAF, you can sign up today at www.stackpath.com.

If you’re interested in a free trial of WAF or other SP// products, reach out to me on twitter @ https://twitter.com/J_Shelby_J