Using Flowtriq as your mitigation
layer with Kentik

Back to Blog

Why Pair Kentik with Flowtriq

Kentik ingests flow data (NetFlow, sFlow, IPFIX) from your routers and switches, giving you network-wide visibility into traffic patterns and anomalies. It is one of the best platforms available for detecting DDoS attacks across an entire network from a single pane of glass. But detection is only half the problem. Once Kentik tells you something is wrong, you still need to stop the attack.

Flowtriq sits on the other side of that equation. It detects attacks at the host level with per-second granularity, and more importantly, it acts on them: kernel-level rate limiting via iptables/nftables, FlowSpec filters pushed to upstream routers, and RTBH blackhole routes for the worst-case scenarios. Each of these mitigation actions is automatic, driven by escalation policies you define once.

Kentik recently added webhook notification channels to its alerting system. Flowtriq now accepts those webhooks at a dedicated endpoint. The integration is straightforward: Kentik fires a webhook when it detects an anomaly, Flowtriq receives it, maps the alert severity to a mitigation action, and pushes the appropriate rule to your infrastructure.

The result is that Kentik's network-wide detection triggers Flowtriq's host-level mitigation in seconds. This is not about replacing one tool with the other. Kentik keeps doing what it does best (observability, capacity planning, flow analytics), and Flowtriq keeps doing what it does best (fast, automated mitigation). The webhook is the bridge between them.

How It Works

The data flow from detection to mitigation follows five steps:

1. Kentik ingests flow data from your routers and detects an anomaly based on your alert policies (volume thresholds, protocol anomalies, dimensional analysis, etc.).
2. Kentik fires an alert notification via its webhook notification channel, sending a JSON payload that includes the alarm ID, severity, policy name, dimensions (target IP, protocol, port), and current state.
3. Flowtriq's webhook endpoint receives the alert at POST /api/v1/webhooks/kentik, authenticated with your deploy token.
4. Flowtriq maps the alert severity to an escalation level and creates a mitigation rule for the target IP. The mapping is configurable, but the defaults are sensible for most deployments.
5. The rule propagates to your infrastructure via whichever adapter you have configured: ExaBGP, GoBGP, or BIRD 2 for BGP-based mitigation, or directly to the ftagent on the target node for kernel-level rules.

The default severity mapping works like this:

Kentik Severity	Flowtriq Action	What Happens
minor	Kernel rules	iptables/nftables rate limiting on the target node
major	FlowSpec filter	Surgical upstream filtering via BGP FlowSpec
critical	RTBH blackhole	Drop all traffic to target at the upstream edge

Setup: Kentik Side

In the Kentik portal, navigate to Alerting > Notification Channels > Add Channel and select Webhook as the channel type.

Configure the channel with the following settings:

• Webhook URL: https://flowtriq.com/api/v1/webhooks/kentik
• Method: POST
• Authorization header: Bearer YOUR_FLOWTRIQ_DEPLOY_TOKEN
• Content-Type: application/json

Save the channel. Then assign it to your DDoS detection alert policies. A typical Kentik alert policy for DDoS detection looks something like this:

{
  "policy_name": "DDoS Detection - Volumetric",
  "alert_type": "threshold",
  "conditions": [
    {
      "metric": "bits_per_second",
      "direction": "dst",
      "threshold": 500000000,
      "duration_minutes": 1,
      "severity": "major"
    },
    {
      "metric": "bits_per_second",
      "direction": "dst",
      "threshold": 2000000000,
      "duration_minutes": 0,
      "severity": "critical"
    }
  ],
  "dimensions": ["IP_dst", "Protocol"],
  "notification_channels": ["flowtriq-webhook"],
  "alarm_clear_after_minutes": 5
}

The key dimensions here are IP_dst and Protocol. Flowtriq uses IP_dst to determine which server to mitigate, and Protocol to build a more targeted rule when possible.

You can assign multiple notification channels to the same policy. Keep your existing Slack or PagerDuty channels for visibility, and add the Flowtriq webhook for automated mitigation.

Setup: Flowtriq Side

On the Flowtriq side, there is very little to configure. The webhook endpoint is always available, and it uses your existing escalation policy to determine how to mitigate.

You will need two things:

1. A deploy token. Find this in Settings > API > Deploy Token in the Flowtriq dashboard. This is the same token used for agent enrollment and API access.
2. At least one mitigation adapter (if you want FlowSpec or RTBH escalation). Flowtriq supports ExaBGP, GoBGP, and BIRD 2 as BGP adapters. Configure your adapter under Settings > Mitigation > BGP Adapters.

For kernel-level rules (the minor severity mapping), no additional adapter is needed. The ftagent running on the target node executes iptables or nftables rules directly. If you already have ftagent deployed on your servers for Flowtriq's native detection, kernel-level mitigation from Kentik webhooks works out of the box.

No additional Flowtriq configuration is required for the webhook itself. The endpoint maps Kentik alerts to mitigation rules using whatever escalation policy you already have in place. If you have not customized your escalation policy, the defaults in the severity mapping table above apply.

API Reference

Endpoint

POST /api/v1/webhooks/kentik
Authorization: Bearer <deploy_token>
Content-Type: application/json

Kentik Payload Format

Kentik sends an alert payload when an alarm fires or clears. The relevant fields that Flowtriq consumes are:

{
  "AlarmID": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
  "AlarmPolicyName": "DDoS Detection - Volumetric",
  "AlarmSeverity": "critical",
  "CurrentState": "alarm",
  "StartTime": "2026-06-23T15:42:30Z",
  "Dimensions": {
    "IP_dst": "203.0.113.50",
    "Protocol": "17",
    "port_dst": "53"
  },
  "Baseline": {
    "current_bps": 2147000000,
    "baseline_bps": 45000000
  }
}

When the alarm clears, Kentik sends the same payload with "CurrentState": "clear". Flowtriq uses this to withdraw the mitigation rule if the TTL has not already expired.

Flowtriq Response Format

// On success (alarm state):
{
  "status": "ok",
  "action": "rule_created",
  "rule_id": "fr-20260623-154231-a1b2c3",
  "target_ip": "203.0.113.50",
  "intent_type": "rtbh",
  "escalation_level": "blackhole",
  "ttl_seconds": 3600,
  "adapter": "exabgp-primary"
}

// On success (clear state):
{
  "status": "ok",
  "action": "rule_withdrawn",
  "rule_id": "fr-20260623-154231-a1b2c3"
}

// On duplicate (rule already exists):
{
  "status": "ok",
  "action": "already_exists",
  "rule_id": "fr-20260623-154231-a1b2c3"
}

Override Fields

You can include optional override fields in the Kentik webhook payload to control how Flowtriq handles the alert. Add these as top-level keys alongside the standard Kentik fields:

• flowtriq_intent_type : Override the mitigation intent. Values: rate_limit, flowspec, rtbh.
• flowtriq_escalation_level : Override the escalation level. Values: kernel, flowspec, blackhole.
• flowtriq_adapter_id : Force mitigation through a specific BGP adapter by ID.
• flowtriq_ttl_seconds : Override the default rule TTL. The rule auto-withdraws after this many seconds.

Testing with curl

curl -X POST https://flowtriq.com/api/v1/webhooks/kentik \
  -H "Authorization: Bearer YOUR_DEPLOY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "AlarmID": "test-001",
    "AlarmPolicyName": "DDoS Detection",
    "AlarmSeverity": "minor",
    "CurrentState": "alarm",
    "Dimensions": {
      "IP_dst": "203.0.113.50"
    }
  }'

Severity Mapping and Overrides

The default mapping between Kentik severity and Flowtriq mitigation action covers the most common deployment patterns:

Kentik Severity	Flowtriq Intent	Escalation Level	Default TTL
minor	rate_limit	kernel	1800s (30 min)
major	flowspec	flowspec	3600s (1 hour)
critical	rtbh	blackhole	3600s (1 hour)

These defaults work well for most setups, but there are situations where you want to override them. For example, if Kentik sends a critical severity alert but you would rather apply a FlowSpec filter instead of a full blackhole (because RTBH drops all traffic to the target, including legitimate), you can add an override to the webhook payload:

{
  "AlarmID": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
  "AlarmSeverity": "critical",
  "CurrentState": "alarm",
  "Dimensions": {
    "IP_dst": "203.0.113.50",
    "Protocol": "17",
    "port_dst": "53"
  },
  "flowtriq_escalation_level": "flowspec",
  "flowtriq_ttl_seconds": 7200
}

In this case, even though Kentik classified the alert as critical, Flowtriq will create a FlowSpec filter instead of an RTBH route, and the rule will auto-withdraw after 2 hours instead of the default 1 hour.

The flowtriq_ttl_seconds field is worth paying attention to. Every mitigation rule created from a Kentik webhook has a TTL. When the TTL expires, Flowtriq withdraws the rule automatically. If Kentik sends a clear state before the TTL expires, the rule is withdrawn immediately. This ensures that mitigation rules do not persist indefinitely if the Kentik clear notification is lost or delayed.

What Happens During an Attack

Here is a realistic timeline showing both systems working together during an 800 Mbps UDP flood:

Time	Event
15:42:03	800 Mbps UDP flood hits your edge router, targeting 203.0.113.50
15:42:04	ftagent on 203.0.113.50 detects the anomaly (1-second detection window)
15:42:05	ftagent applies kernel-level rate limiting via nftables, stabilizing the server
15:42:30	Kentik detects the anomaly from sFlow data (typical 15-30s latency for flow-based detection)
15:42:31	Kentik fires a critical severity webhook to Flowtriq
15:42:31	Flowtriq receives the webhook and creates an RTBH route for 203.0.113.50 via ExaBGP
15:42:32	Upstream routers install the blackhole route, dropping all traffic to the target at the edge

The important thing to notice here is the layering. The ftagent on the target server detected and mitigated locally at 15:42:05, just 2 seconds after the attack started. That kept the server stable and responsive for the 27 seconds it took for the flow-based detection path (Kentik) to fire. Then the Kentik webhook triggered upstream RTBH, which offloads the attack traffic entirely so it never reaches your network.

Both layers add value. The local kernel rules protect the server during the detection gap. The RTBH route protects your upstream bandwidth and transit costs. If you only had Kentik without Flowtriq, the server takes the full impact for 30 seconds before any mitigation happens. If you only had Flowtriq's agent without the Kentik webhook, you get fast local mitigation but no upstream offload for attacks that saturate your transit links.

Flowtriq deduplicates here. When the Kentik webhook arrives and ftagent has already created a kernel-level rule for the same target, Flowtriq does not create a conflicting rule. Instead, it escalates: the webhook triggers the RTBH route as an additional mitigation layer on top of the existing kernel rules.

Testing the Integration

Before relying on this in production, test the full path with a simulated alert. Use curl to send a test payload:

curl -X POST https://flowtriq.com/api/v1/webhooks/kentik \
  -H "Authorization: Bearer YOUR_DEPLOY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "AlarmID": "test-001",
    "AlarmPolicyName": "DDoS Detection",
    "AlarmSeverity": "minor",
    "CurrentState": "alarm",
    "Dimensions": {
      "IP_dst": "203.0.113.50"
    }
  }'

Expected response:

{
  "status": "ok",
  "action": "rule_created",
  "rule_id": "fr-20260623-...",
  "target_ip": "203.0.113.50",
  "intent_type": "rate_limit",
  "escalation_level": "kernel",
  "ttl_seconds": 1800,
  "adapter": null
}

Verify the rule was created by checking your Flowtriq dashboard under Mitigation > Active Rules, or query the API directly:

curl -s https://flowtriq.com/api/v1/mitigation/rules \
  -H "Authorization: Bearer YOUR_DEPLOY_TOKEN" | jq '.rules[] | select(.source == "kentik")'

To test the cleanup path, send a clear notification for the same alarm:

curl -X POST https://flowtriq.com/api/v1/webhooks/kentik \
  -H "Authorization: Bearer YOUR_DEPLOY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "AlarmID": "test-001",
    "AlarmPolicyName": "DDoS Detection",
    "AlarmSeverity": "minor",
    "CurrentState": "clear",
    "Dimensions": {
      "IP_dst": "203.0.113.50"
    }
  }'

The response should confirm the rule was withdrawn, and the active rules list should no longer include it.

FAQ

Does this replace Flowtriq's own detection?

No. Flowtriq's per-server agent (ftagent) detects independently at 1-second latency using packet-level analysis. Kentik webhooks add network-wide flow-based detection as a second trigger source. Both run in parallel, and Flowtriq deduplicates when both detect the same attack.

What if both Kentik and Flowtriq detect the same attack?

Flowtriq deduplicates mitigation rules. If a rule for the same target IP and intent type already exists (from ftagent's native detection), the webhook returns "action": "already_exists" without creating a duplicate. If the Kentik alert maps to a higher escalation level than the existing rule, Flowtriq escalates rather than duplicating.

Can I use this without ftagent on the target server?

Yes. The webhook creates mitigation rules through your configured BGP adapters (ExaBGP, GoBGP, BIRD 2). ftagent is only needed for kernel-level rules that execute on the server itself. If you set the minimum severity mapping to major (FlowSpec), you can run the integration entirely through BGP without any agent on the target.

What Kentik plans support webhooks?

Kentik's webhook notification channels are available on all paid plans. Check Kentik's documentation for the latest details on notification channel availability.

What happens if the Flowtriq webhook endpoint is unreachable?

Kentik retries failed webhook deliveries according to its retry policy (typically 3 retries with exponential backoff). On the Flowtriq side, the webhook endpoint runs on the same infrastructure as the dashboard and API, so availability matches Flowtriq's overall uptime SLA.

Back to Blog

Related Articles