Hardening self-hosted Supabase with CrowdSec

Supabase is an open-source Firebase alternative that provides instant out-of-the-box APIs, authentication, and real-time subscriptions. For a long time people used Fail2Ban to block some malicious activity on their servers.

CrowdSec is an alternative to Fail2Ban that provides extra features and enhanced capabilities: 

  • Better performance
  • The ability to detect highly sophisticated attacks 
  • Designed for modern cloud-native workflows 

In the following guide, we’ll learn how to secure your self-hosted Supabase deployment via docker-compose using CrowdSec and a dedicated detection scenarios collection created for Supabase docker-compose deployment, available on our scenario hub: https://hub.crowdsec.net/author/crowdsecurity/collections/supabase-compose

This guide assumes you’ve self-hosted Supabase via docker-compose. See this guide, if you want to quickly self-host. 

The high-level steps in this process will be:

  • Installing CrowdSec
  • Parsing Supabase logs
  • Detecting attacks 
  • Remediating/blocking attacking IPs using CrowdSec’s firewall bouncer

Let’s get right into it!

Installing CrowdSec

Installing CrowdSec’s repositories

On the machine having Supabase deployed, we’ll install CrowdSec’s repositories by running the following command:

For Ubuntu/Debian users

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

For RHEL/CentOS/Amazon Linux users

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash

Installing CrowdSec

For Ubuntu/Debian users

apt install crowdsec 

For RHEL/CentOS/Amazon Linux users

yum install crowdsec

Configuring CrowdSec to read Supabase logs and detect attacks

Reading logs

In this step we’ll set up CrowdSec’s log acquisition, so it can read Supabase’s logs.

Create the `/etc/crowdsec/acquis.d` directory if doesn’t exist via:

sudo mkdir /etc/crowdsec/acquis.d 

Create /etc/crowdsec/acquis.d/supabase.yaml file with following contents:

source: docker
- supabase-db
 type: postgres
source: docker
- supabase-kong
 type: nginx

Installing Supabase Collection

A collection regroups parsers, scenarios, and sometimes other collections that provide appropriate detection of malicious behaviors on the exposed services in a given context.

Our community has developed a collection specifically for this Supabase self-hosted context.

This collection mainly enables parsing postgresql and kong logs which are the public-facing services in a Supabase deployment.

Use the following command to install it: 

sudo cscli collections install crowdsecurity/supabase-compose

Then reload CrowdSec to take the new collection in acco running the following command:

sudo systemctl reload crowdsec

You can verify whether everything is working as expected by: Generating few logs by either trying to connect to Supabase’s DB or by accessing Supabase’s Studio. Then, check whether crowdsec is parsing these logs by running the following command:

sudo cscli metrics 

As you can see from the image, CrowdSec is indeed able to parse logs from Supabase’s services.

Blocking attackers using remediation components

We’ve set up CrowdSec till now, so that it can detect attacks by reading the logs of Supabase’s services. Now we need to block these attackers. This is where remediation components step in. We can block these attackers at various levels ranging from CDNs like Cloudflare, web server, to packet level using iptables/nftables.

We’ll be using the iptables remediation component to block the attackers at the packet level. 

Install the bouncer

For Ubuntu/Debian users
sudo apt install crowdsec-firewall-bouncer
For RHEL/CentOS/Amazon Linux 
sudo yum install crowdsec-firewall-bouncer

Testing it all!

Time put on hacker hats on and try to attack our Supabase deployment. Make sure that you are using some alternate IP as very soon you’re going to get blocked by Supabase host thanks to CrowdSec.

For simplicity, we’re going to bruteforce the postgresql database. You can use any tool to do this, for the demo we’ve used hydra.

You can check for detected attacks by running the following command on Supabase Host.

sudo cscli decisions list

As you can see CrowdSec has detected an attack from our IP. 

We can verify that this detected IP is blocked from accessing the Supabase Host. This can be done by trying to ping Supabase Host from the attacking machine.

Next Steps

We learned how to protect self-hosted Supabase using CrowdSec. This setup can be modified further as required in case you have a dedicated postgresql for example. Due to its architecture, CrowdSec can be configured in such a way that detected attacks can be remediated across multiple hosts spread across multiple networks. You can learn more about it here

If you have any feedback, or feature requests or need any help please don’t hesitate to ping us on Discord

And we’re looking forward to discussing with you about more malicious behaviors we could detect on Supabase.

Find out more about creating parsers and creating scenarios

You may also like

Protect Your Applications with AWS WAF and CrowdSec: Part I

Protect Your Applications with AWS WAF and CrowdSec: Part I

Learn how to configure the AWS WAF Remediation Component to protect applications running behind an ALB that can block both IPs and countries.

Protect Your Serverless Applications with AWS WAF and CrowdSec: Part II

Protect Your Serverless Applications with AWS WAF and CrowdSec: Part II

Learn how to protect your serverless applications hosted behind CloudFront or Application Load Balancer with CrowdSec and the AWS WAF.

Securing A Multi-Server CrowdSec Security Engine Installation With HTTPS

Securing A Multi-Server CrowdSec Security Engine Installation With HTTPS

In part II of this series, you learn about the three different ways to achieve secure TLS communications between your CrowdSec Security Engines in a multi-server setup.