DDoS Protection

The DDoS Protection panel is a control plane for detecting attack-shaped traffic, preserving evidence, and coordinating a reviewed response. Open DDoS Protection from the Group Admin or NOC navigation.

Access and permissions

• A tenant needs a paid DDoS Protection capacity plan or its one-time 14-day decision trial. The trial starts only when the Group Admin confirms it.
• Trial expiry pauses the panel and sensor API until the Group Admin chooses a plan or disables DDoS Protection. The trial never creates an invoice or starts a plan automatically.
• Group Admins can view and configure the complete workspace.
• NOC users can view the workspace. The Manage DDoS Policies permission is required to change setup, telemetry, policies, or connectors.
• The Manage DDoS Mitigation permission is required to update an attack lifecycle or propose, approve, and cancel response requests.
• The View DDoS Sensor Token permission is required before a NOC user can activate monitoring, rotate the token, or see its one-time value.
• Standard Operators, Sub-Operators, and Managers do not have access.

Set up monitoring

Use the Setup workspace to complete all six readiness steps.

1. Complete the network profile

Enter the organisation name, monitored capacity, baseline learning window, and NOC notification email. A first-seen attack creates an in-product owner alert and queues a summary to that NOC address. Add the local ASN if you plan to use a BGP-based response integration.

Choose the response approval mode deliberately:

Mode	Behaviour
Manual queue	An authorised responder explicitly queues each supported action
Single approval	A proposal waits for one authorised responder
Dual control	Two distinct authorised responders must approve
Verified automatic	Eligible critical detections can queue a verified automatic connector, subject to all other safeguards

2. Declare the protected scope

Add public or private IPv4 or IPv6 space that your organisation owns or is authorised to monitor and protect. Enter a CIDR or one host; a single host is saved as IPv4 /32 or IPv6 /128. This can include subscriber space, infrastructure ranges, point-to-point links, transit segments and private service networks. Protected scope defines where detection and approved exact-host response are permitted. It is not an allowlist, and adding an address does not announce, filter, or scrub it.

3. Add telemetry

Open Telemetry and define each source by type, name, site, exporter address, and listen port as applicable. Supported source types are:

• sFlow
• NetFlow v5 and NetFlow v9
• IPFIX
• SPAN or port-mirrored traffic observed by a managed sensor
• AWS VPC Flow Logs
• Google Cloud VPC Flow Logs

NetFlow is one supported telemetry protocol in this workflow; it is not a separate analytics product or workspace. Configure export on the network or cloud platform that owns the source, then use the DDoS panel to verify its observed health. A saved definition remains Pending until the integration reports successfully.

For a RouterOS device already connected to ISPbills, use Configure Traffic Flow in one step from Telemetry or Integrations. Select only the device and NetFlow v5/v9 or IPFIX. ISPbills assigns a stable six-character service ID, supplies the managed collector address and reserved port as read-only values, then enables Traffic Flow through the saved API connection. The same service ID is used by its RTBH connector. Standard API 8728 and API-SSL 8729 are both supported. The source stays Pending until collector records are independently observed.

The authenticated sensor contract also provides a low-cardinality Prometheus endpoint for control-plane health dashboards. Raw or per-flow export to ClickHouse or InfluxDB belongs in the separately deployed high-throughput sensor pipeline.

The optional sensor token is shown in a collapsed disclosure after activation or rotation. It is only needed for a sensor or collector that the tenant operates; a connected RouterOS device using the ISPbills-managed collector does not require the operator to handle it. If used, copy it directly into your secret manager. Rotating it invalidates the previous token immediately.

4. Configure detection policies

Open Detection to apply the capacity-based preset or create policies for:

• BPS — bits per second
• PPS — packets per second
• FPS — flows per second

Each policy has a scope, absolute threshold, baseline multiplier, evaluation window, and severity. Activation requires an enabled policy for all three metrics. Treat the recommended preset as a starting point and tune it against known traffic patterns after the baseline has matured.

5. Review response controls

Detection works without a response connector. If your operational design includes mitigation, configure connectors separately under Integrations. Available connector types include RouterOS local blackhole, BGP RTBH, a contracted scrubbing provider, blocklist, and webhook.

A new connector starts Pending and must be verified before it can be used. A generic external connector does not change a router. Selecting the explicit one-click RouterOS RTBH action applies only the named configuration described below; it does not announce a mitigation target during setup.

Configure RouterOS blackhole or BGP RTBH in one step

Select Configure connected router to expand the otherwise hidden response builder, then choose a RouterOS device already connected to ISPbills. ISPbills reads an existing BGP session and fills the shared six-character connector name, local ASN, neighbor ASN/address, session name, local address, router ID and address families when available. A BGP neighbor can be an internal mitigation speaker or an external RTBH service; it does not have to be a transit provider.

If no BGP neighbor is found, RouterOS local blackhole is selected automatically. ISPbills verifies route support through API 8728 or API-SSL 8729; after an approved detection it installs only the attacked IPv4 /32 or IPv6 /128 as a blackhole route and removes that route at expiry. No BGP is required, although traffic still consumes the path up to the selected router.

For BGP RTBH, review the real receiving neighbor ASN/address, accepted blackhole community and withdrawal time. Submitting creates or updates only ISPbills-named resources: an exact-host output policy, inbound deny policy, dedicated BGP session and managed announcement list. It does not edit unrelated peers. A TCP MD5 key is transmitted to the device for that request and is never stored.

The connector becomes ready only when the configured peer address and ASN are established. Mitigation advertisements remain restricted to an attacked IPv4 /32 or IPv6 /128 and include the configured withdrawal time.

Protect critical addresses from mitigation

Use Mitigation allowlist to add any public or private host IP or CIDR that must never be actioned. An entry does not need to be inside the declared protected scope or known elsewhere in ISPbills. Detection remains active where applicable, but both manual and automatic mitigation are rejected. Use this for peering and point-to-point addresses, authoritative DNS, management, monitoring and other infrastructure that must stay reachable.

6. Activate monitoring

Review the readiness list, then select Activate monitoring. Activation starts baseline learning and enables policy evaluation. It does not execute a connector. During the learning window, early detections may depend more heavily on absolute thresholds.

Workspace guide

Workspace	Purpose
Setup	Network identity, protected prefixes, approval mode, and activation readiness
Overview	Monitoring posture, telemetry freshness, enabled policies, and unresolved attacks
Attacks	Evidence, target, vector, confidence, observed rates, timeline, and lifecycle state
Telemetry	Source definitions, observed health, and sensor connection details
Detection	Recommended presets and custom BPS/PPS/FPS policies
Mitigation	Connector readiness, approval flow, blast-radius warnings, and response queue
Integrations	Response connector configuration and verification
Runbook	Printable incident sequence for triage, response, verification, and recovery

Investigate an attack

1. Confirm that telemetry is fresh and that the exporter, target IP, address family, and observation window are correct.
2. Compare peak BPS, PPS, and FPS with the learned baseline and with independent interface or device counters.
3. Change the lifecycle to Investigating or Monitoring while the signal is being validated.
4. Preserve the incident evidence and identify customer or service impact before choosing a response.
5. Mark the incident Resolved only after stability is confirmed, or False positive when the traffic is legitimate.

An empty attack queue does not prove that the network is attack-free. Check the workspace posture and source health before relying on it.

Use a controlled response

Before proposing a response, verify the exact target, protected scope, connector status, duration, expected impact, and rollback path. Prefer the narrowest supported control.

The response follows the workspace approval mode. Pending requests can be cancelled, while executed changes must be rolled back through the connector that applied them. Use the incident timeline and Runbook to record verification and recovery.

Health states and troubleshooting

• Pending source — confirm the source definition and sensor credentials, then wait for an observed heartbeat or record.
• Stale source — verify that the exporter and sensor path are still running and that clocks and network reachability are correct.
• Degraded profile — restore at least one healthy source before treating detections or an empty queue as reliable.
• Pending connector — complete the external configuration and verification; do not assume a saved connector is ready.
• Unexpected alert volume — compare against legitimate peaks, then adjust scope, threshold, multiplier, or evaluation window without deleting the incident history.

For a response procedure during an event, open DDoS Protection → Runbook.