Protecting a Solana RPC Node with SP// WAF

Decentralization is a goal of Web3. Yet, Remote Procedure Call (RPC) nodes present single, centralized, points of failure for Web3 projects. If an RPC node fails, the project goes offline for users, damaging your credibility and success.

Security, then, needs to be addressed in the project’s ideation phase, planning for attacks and vulnerabilities, such as:

• Malicious L3, L4, and L7 DDoS attacks: Will your RPC node stay up if someone buys or commits an attack against its publicly facing URL?
• Bots and other automated traffic: Can you mitigate massive request volumes within a short period, such as during an NFT mint, to protect RPC node uptime and keep bots from having an unfair advantage over human users?
• High volumes of legitimate, benign traffic: Can your RPC node handle an overwhelming volume of legitimate requests?

Fortunately, securing RPC nodes can be quick and easy.

You don’t want this:

How WAF can protect your RPC node

If you aren’t familiar with Web Application Firewalls (WAF), they are hosted security solutions that protect web applications from attackers by analyzing and filtering traffic. A WAF should absolutely be used to secure your project’s web2.0 domain.

Typical Web2.0 deployment of WAF:

But WAF can also be used to secure RPC nodes, since they can be thought of as traditional API endpoints that act as on-ramps to decentralized ledgers like the Ethereum and Solana blockchain.

Primarily, an RPC node needs some sort of rate limiting to protect it from abuse and misuse. The deployment illustrated below uses SP// WAF to efficiently apply rate limiting for RPC nodes in SP// edge locations. It also provides DDoS protection so long as the protected IP address remains private.

RPC protected by SP// WAF:

1. The DNS request resolves to an Anycast IP address, which resolves to the SP// edge location closest to the user. In most cases, this is an internet exchange that can be reached within 5ms.

2. The WAF then analyzes the request. Is it part of a DDoS attack? Is the IP address rate limited? Does it violate an IP address reputation rule?

3. If approved, the request traverses the SP// private network backbone to the RPC node. The RPC node processes the request and responds, and the response flows backward.

SP// WAF Advantages

Sure, there is more than one way to address rate limiting and more than one WAF in the market. But SP// WAF has real advantages over other solutions.

No additional response time

First, thanks to the SP// private network’s speed advantage over the public internet and the performance and global distribution of SP// WAF, adding WAF protection doesn’t increase net response time. In testing, the deployment above has the same response time as using a public RPC node provided by the Solana foundation: request to response time from Dallas to an RPC node in Miami takes about 80ms to 100ms, round-trip.

No additional expertise

Second, SP// WAF is designed to provide enterprise-class protection without needing enterprise-grade security expertise, with:

• Quick setup: Quickly configure and finetune rate limiting to your project’s needs.
• Global scalability: Enable security that can grow massively and seamlessly with your project.
• Easy management: Access data and controls through our customer portal or developer-friendly APIs

Here’s how easy it is.

Set Up and Configure SP// WAF

1. Create a StackPath account.
2. Create a site.
3. Add WAF to the site.
4. Configure WAF with the following settings:

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, and 8443. In this case, we will be using 8080 as our RPC port.

5. Set up your RPC as an API endpoint.

By adding your RPC node as though it is an API endpoint, 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.

6. Set up a rate-limiting rule.

As configured, this example rule will only allow up to 50 requests from the same IP address within a span of 3 minutes. The WAF will block any additional requests for the remainder of the 3 minutes, and then the counter resets.

Set Up Your RPC for WAF

If you’re setting up an RPC on StackPath, check out our guide for setting up a node on StackPath first.

1. Configure your infrastructure provider’s network policies.

In the SP// Solana portal, ports 8000-8020 have been opened for TCP/UDP for Solana and ports 8080–8081 for the RPC.

2. Set up a local firewall.
Deny access to the RPC ports and, therefore, the RPC to anyone except StackPath IP addresses. This way, requests will have to come through the StackPath WAF to communicate with the RPC. 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/tcp
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.

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. Enable UFW and check status.

You did allow ssh, right? Now enable UFW with:

sudo ufw enable

Check that all the rules are enabled with:

sudo ufw status

You should see StackPath’s IP addresses and ports 8000:8020 open for business.

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

--rpc-port 8080 //

--public-rpc-address 0.0.0.0:0000 //

--no-port-check //

The RPC port should be configured to 8080–dynamic-port-range 8000–8020 // There is flexibility here, but it should match the ports you allowed in UFW and the infrastructure provider’s network policies

When you use 0.0.0.0:0000 as your public-rpc-address, Gossip shows the RPC public address as “None” without the –private-rpc flag enabled

And without no-port-check enabled, checks to 0.0.0.0:8080 will cause an error.

Test

Now that it’s up let’s look at it in action.

vscode:

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 IP address hammering away and the WAF blocking it:

(IP address redacted)

I can even drill down into each instance of a triggered rule:

(Private information redacted)

And that’s it! Your RPC node, performance, project, credibility, and success are protected. Not bad for a single blog’s work.

You can sign up today if you’re ready to get started with a Solana RPC node on SP// and SP// WAF, you can sign up today. If you’d like to learn more and dig into details, hit up me or anyone on our team, and we’ll set up a time to talk.

We’re passionate about blockchain and security and can’t wait to help as many as possible take advantage of Web3.