Cloud Scrubbing Integrations
Auto-divert traffic to upstream scrubbing providers when attacks are detected
Overview
Cloud scrubbing integrations connect Flowtriq to upstream DDoS mitigation providers. When an attack is detected, Flowtriq calls the provider's API to activate traffic scrubbing. When the attack resolves, scrubbing is automatically deactivated and direct routing resumes.
This is different from firewall rules (which run firewall commands on your server). Cloud scrubbing diverts traffic at the network level before it reaches your infrastructure.
Supported Providers
| Provider | Mechanism | Cost | Best For |
|---|---|---|---|
| Cloudflare Magic Transit | BGP prefix advertisement via API | On-demand pricing (pay only during attacks) | Any infrastructure with /24+ IP space |
| OVH DDoS Protection | Permanent mitigation mode toggle via API | Free (included with all OVH dedicated servers) | Game servers and apps hosted on OVH/SoYouStart |
| Hetzner Firewall | Hardware firewall activation via Robot API | Free (included with all Hetzner dedicated servers) | Apps hosted on Hetzner dedicated servers |
| AWS Shield Advanced | Subscription status verification via SigV4 API | $3,000/mo + data transfer fees | AWS-hosted workloads needing L3/L4/L7 protection |
| Cloudflare WAF (Under Attack Mode) | Zone security level toggle via API | Included with Cloudflare plan | Web applications behind Cloudflare proxy |
| DigitalOcean Cloud Firewall | Firewall rule replacement (lockdown) via API | Free (included with all Droplets) | Droplets and Kubernetes on DigitalOcean |
| Vultr Firewall | Firewall rule management (default-deny) via API | Free (included with all instances) | Instances hosted on Vultr |
| Linode/Akamai Cloud Firewall | Firewall rule lockdown via API | Free (included with all Linodes) | Linodes and LKE clusters on Akamai Cloud |
Setup: Cloudflare Magic Transit
Prerequisites
- A Cloudflare account with Magic Transit enabled
- At least one IP prefix (/24 or larger) configured in Cloudflare
- An API token with Account:IP Prefixes:Edit and Account:Magic Transit:Edit scopes
Configuration Steps
- Go to Dashboard → Integrations
- Select Cloudflare Magic Transit (Scrubbing) from the type dropdown
- Enter your API Token, Account ID, and Prefix ID
- Enable Auto-divert to automatically announce the prefix when attacks are detected
- Click Add Integration
- Use the Test button to verify credentials and prefix access
Finding Your Prefix ID
After adding the integration, click Test - the response will show how many prefixes are on your account. To get specific prefix IDs, use the Cloudflare API:
curl -X GET "https://api.cloudflare.com/client/v4/accounts/{account_id}/addressing/prefixes" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json"
How It Works
- Flowtriq detects an attack on one of your nodes
- Flowtriq calls
PATCH /accounts/{id}/addressing/prefixes/{prefix_id}/bgp/statuseswith{"advertised": true} - Cloudflare begins advertising your prefix via BGP (convergence takes 30-90 seconds)
- Traffic is routed through Cloudflare's scrubbing network
- When the incident resolves, Flowtriq withdraws the prefix (
{"advertised": false}) - Direct routing resumes
- "Forbidden" or 403 error: Your API token is missing the required scopes. Go to Cloudflare API Tokens and make sure the token has both Account:IP Prefixes:Edit and Account:Magic Transit:Edit permissions.
- "Zone not found" error: The Account ID is wrong. Find it in the Cloudflare dashboard sidebar (not the Zone ID).
- Prefix ID not found: Use the cURL command above to list your prefixes and copy the correct ID.
Setup: OVH DDoS Protection
Prerequisites
- An OVH, SoYouStart, or Kimsufi dedicated server
- OVH API credentials (Application Key, Application Secret, Consumer Key)
Getting API Credentials
- Go to api.ovh.com/createToken
- Log in with your OVH account
- Set the validity period to Unlimited
- Add all 5 of these access rules exactly as shown (each one is a separate row on the OVH form):
GET/ipGET/ip/*GET/ip/*/mitigation/*POST/ip/*/mitigationDELETE/ip/*/mitigation/* - Click Create keys
- Save the Application Key, Application Secret, and Consumer Key immediately. The consumer key is only shown once.
GET /ip (without wildcard) or entering the rules on the wrong HTTP method. You must add each rule as a separate entry. Go back to api.ovh.com/createToken and generate a new token with all 5 rules.Configuration Steps
- Go to Dashboard → Integrations
- Select OVH DDoS Protection (Scrubbing)
- Enter your Application Key, Application Secret, Consumer Key
- Select your API endpoint (EU, CA, or US)
- Enter the IP address to protect
- Enable Auto-mitigate for automatic activation
How It Works
OVH already has built-in DDoS detection, but it operates on a higher threshold and slower detection cycle. Flowtriq detects attacks faster and can force-enable OVH's "permanent mitigation" mode via API, which applies stricter filtering to your IP.
- On attack:
POST /ip/{ip}/mitigationwith{"ipOnMitigation": "{ip}"} - On resolution:
DELETE /ip/{ip}/mitigation/{ip}(restores auto mode)
Setup: Hetzner Firewall
Prerequisites
- A Hetzner dedicated server with firewall configured in the Robot panel
- Robot API credentials (separate from Hetzner Cloud API)
Getting Robot API Credentials
- Log in to robot.your-server.de/preferences
- Under Webservice access, create a new login
- Save the username (format:
#ws+xxxxx) and password
Important: Configure Firewall Rules First
Flowtriq activates/deactivates the Hetzner firewall - it does not create rules. You must configure your firewall rules in the Hetzner Robot panel before enabling this integration. When Flowtriq detects an attack, it sets status=active; when the attack resolves, it sets status=disabled.
Configuration Steps
- Configure firewall rules in the Hetzner Robot panel (Firewall tab for your server)
- Go to Dashboard → Integrations
- Select Hetzner Firewall (Scrubbing)
- Enter your Robot login, password, and server IP
- Enable Auto-activate firewall
- "Invalid credentials" error: Hetzner Robot API credentials are different from your Hetzner Cloud (cloud.hetzner.com) credentials. You need the webservice login from Robot → Settings → Webservice access. The username starts with
#ws+. - "Server not found" error: The server IP you entered does not match any server in your Robot account. Use the main IPv4 address shown in Robot, not a failover or floating IP.
- Firewall activates but traffic is not filtered: Flowtriq only toggles the firewall on and off. You must configure the actual firewall rules in the Robot panel first. Go to Robot → Server → Firewall tab and add your rules before enabling this integration.
Setup: DigitalOcean Cloud Firewall
Prerequisites
- A DigitalOcean account with at least one Cloud Firewall
- A personal access token with read + write scope
Configuration Steps
- Generate a personal access token at cloud.digitalocean.com/account/api/tokens with read + write scope
- Find your Firewall ID in the DigitalOcean dashboard (Networking → Firewalls → click your firewall → the ID is in the URL)
- Go to Dashboard → Integrations
- Select DigitalOcean Cloud Firewall (Scrubbing)
- Enter your API token and Firewall ID
- Enable Auto-activate
- Lockdown mode: When activated, Flowtriq replaces all inbound firewall rules with a single SSH-only rule (port 22). This blocks all other inbound traffic including your application.
- Original rules are not preserved: When deactivated, Flowtriq restores permissive rules (allow all inbound). Your original firewall rules are not saved or restored. Re-add your custom rules after deactivation.
- "Invalid API token" error: Make sure you generated a Personal Access Token (not an OAuth app token) with read + write scope.
Setup: Vultr Firewall
Prerequisites
- A Vultr account with at least one Firewall Group
- An API key from the Vultr control panel
Configuration Steps
- Generate an API key at my.vultr.com/settings (API section)
- Make sure API access is enabled and your IP is whitelisted if you use the IP allowlist feature
- Find your Firewall Group ID in the Vultr dashboard (Products → Firewall → click your group → the ID is in the URL)
- Go to Dashboard → Integrations
- Select Vultr Firewall (Scrubbing)
- Enter your API key and Firewall Group ID
- Default-deny: Vultr firewall groups use a DROP policy by default. When activated, Flowtriq deletes all existing rules (default-deny takes effect) and adds a single SSH rule to prevent lockout.
- Original rules are not preserved: Same as DigitalOcean, your existing rules are not saved. Re-add them after the attack.
- "Forbidden" error: Your Vultr API key may have IP allowlist restrictions. Make sure your Flowtriq server IP is whitelisted in the Vultr API settings.
Setup: Linode/Akamai Cloud Firewall
Prerequisites
- A Linode (Akamai Cloud) account with at least one Cloud Firewall
- A personal access token with Firewalls read/write scope
Configuration Steps
- Generate a personal access token at cloud.linode.com/profile/tokens with Firewalls: Read/Write scope
- Find your Firewall ID in the Linode dashboard (Network → Firewalls → click your firewall → the ID is in the URL)
- Go to Dashboard → Integrations
- Select Linode Cloud Firewall (Scrubbing)
- Enter your API token and Firewall ID
- "Invalid token" error: Make sure your token has the Firewalls: Read/Write scope. Tokens with only Read access will fail on activation.
- Firewall must be attached: The firewall must be associated with at least one Linode for the rules to take effect. Unattached firewalls will update via API but won't protect anything.
- Lockdown mode: Like DigitalOcean and Vultr, activation replaces all inbound rules with SSH-only and sets the default inbound policy to DROP.
Manual Controls
Each scrubbing integration has manual control buttons in the integrations list:
- Test - Verify API credentials and connectivity
- Activate - Manually start scrubbing (announce prefix / enable mitigation / activate firewall)
- Withdraw - Manually stop scrubbing (withdraw prefix / disable mitigation / deactivate firewall)
Auto-Withdraw Safety
When an incident resolves, Flowtriq checks if there are other active incidents for the same workspace before withdrawing. If multiple attacks are in progress, scrubbing stays active until all incidents resolve. This prevents flapping where scrubbing is withdrawn during a brief lull in a multi-wave attack.
Combining with Firewall Rules
Cloud scrubbing and firewall rules serve different purposes and work well together:
| Feature | Firewall Rules | Cloud Scrubbing |
|---|---|---|
| Where it acts | On your server (via agent) | Upstream (via provider API) |
| Response time | < 1 second | 1-90 seconds (depends on provider) |
| Handles volumetric floods | Limited (link can still saturate) | Yes (traffic diverted before reaching you) |
| Handles application-layer | Yes (iptables, nftables, etc.) | Depends on provider |
Recommended setup: Use firewall rules for immediate local protection (iptables rate limiting, protocol drops), BGP mitigation for network-level FlowSpec/RTBH at your border routers, and cloud scrubbing for upstream volumetric protection. All three trigger automatically on the same incident.