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, detection policies, or traffic classifications.
• The Manage DDoS Mitigation permission is required to configure or test response connectors and BGP, change mitigation exclusions, 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

For a connected RouterOS device, select the router and apply the read-only managed collector endpoint. ISPbills discovers the router’s observed public exporter address, enables Traffic Flow, keeps one collector target and refreshes NetFlow v9 templates frequently enough for prompt collector recovery. The native ISPbills C++ sensor keeps each exporter’s template and baseline state separate on the managed UDP endpoint.

The source stays pending until ISPbills decodes a real flow record. Its card then shows the recognizable router, management endpoint, API port, observed exporter address, latest flow-record rate and last verified record time. A successful API call or an arriving UDP packet by itself is not treated as healthy 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. The first-party managed collector decodes NetFlow v5/v9 and IPFIX. sFlow, SPAN and cloud logs use a deployed sensor or log adapter that normalizes observations into the authenticated sensor contract. 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 decoded records or the adapter report successfully.

For a RouterOS device already connected to ISPbills, use Configure Traffic Flow in one step from Telemetry. 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 it under Response & BGP. This is the only response workspace: RouterOS peers, session state, active route count, external endpoints and mitigation exclusions are not repeated elsewhere.

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 the native ISPbills RouterOS BGP peer in one step

Each connected RouterOS 7 device has a Configure ISPbills BGP peer action. ISPbills uses the saved RouterOS API connection to create a dedicated router instance, inbound exact-host blackhole policy, outbound deny policy, and eBGP multihop session to the first-party ISPbills speaker. Multihop is intentional: the endpoints may communicate across routed hops and do not need to share a directly connected subnet.

The configured ISPbills peer must be a real IPv4 endpoint reachable from the router on TCP/179. The speaker may bind behind DNAT, but cloud security groups, host firewalls and NAT must permit the session before one-click router provisioning can report Established. An explicitly routed private/VPN endpoint is supported only when that transport already exists; ISPbills no longer assumes an unprovisioned shared-space address.

The router card identifies the real RouterOS record and management endpoint, both BGP endpoint addresses and ASNs, multihop mode, live session state, and active announcement count. A connector is Ready only when RouterOS and the ISPbills speaker both report Established. Standard API 8728 and API-SSL 8729 are supported.

An approved incident may announce only the detected IPv4 /32 with blackhole community 65535:666; the router input policy rejects wider prefixes and the speaker withdraws the route at expiry. The tenant suspended-user pool is always rejected from BGP because it remains controlled by permanent RouterOS input and forward firewall drops.

The collapsed advanced form remains available only for an external BGP neighbor, contracted scrubber, blocklist or webhook. RouterOS local exact-host blackhole remains available as a non-BGP fallback.

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.

The Automatic safety perimeter also discovers tenant router, OLT, switch and radio management addresses, gateways, collector/BGP endpoints, connector addresses and the full suspended-user pool. ISPbills rechecks this inventory at proposal, approval, sensor claim and final RouterOS/BGP execution, so an essential address added after a request was created still cannot be blackholed.

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	Current bandwidth and packet rates, attack workload, BGP peer state and announced-route count
Traffic	Selectable bandwidth, packet-rate and flow-rate time series for 1 hour through 7 days
Destinations	Direction-aware Facebook/Meta, YouTube/Google, TikTok, Cloudflare, Amazon/AWS, BDIX, major-AS and exporter/uplink traffic
Connectivity	Inferred or selected ASN, observed path adjacency, IPv4/IPv6 visibility, announced prefixes, RPKI state and declared exchange presence
Attacks	Actionable incident evidence, target, confidence, observed rates, response and lifecycle state
Analytics	Clean-period baseline and policy coverage, or peak attack metrics, timeline, vector/severity mix, affected devices, attacking IP evidence, RIR/community context and routing-security signals
Sources	Ranked source addresses with correct public origin ASN ownership; private and CGNAT addresses remain unassigned
Targets	Ranked protected destinations with bandwidth, packet, flow and traffic-share evidence
Protocols	IP protocol and destination-port distributions decoded from flow records
Telemetry	Source definitions, observed health, and sensor connection details
Detection	Recommended presets and custom BPS/PPS/FPS policies
Response & BGP	Router BGP peers, session state, active route count, external connectors and mitigation exclusions
Runbook	Printable incident sequence for triage, response, verification, and recovery

Classify content, exchange and uplink traffic

Destinations separates outbound traffic from protected networks to an external address from inbound traffic arriving from it. Public content origins are labelled from observed ASN data for Facebook/Meta, YouTube/Google, TikTok/ByteDance, Cloudflare and Amazon/AWS; BDIX route-server traffic and other major ASNs are shown when present. A provider with no observation in the selected period remains at zero rather than receiving demonstration data.

Local delivery paths are specific to the ISP. Open Classify local CDN, IIG, BDIX and uplink traffic and add the exact ASN or CIDR supplied by the network team. Use CIDR for an embedded/on-net cache and ASN for a routed provider, exchange, international gateway or transit path. The longest tenant CIDR match takes precedence, followed by a tenant ASN and then the built-in public service ASN. Exporter/uplink visibility shows the traffic received per configured telemetry source; it does not claim to identify a physical circuit unless the operator has labelled that path.

Investigate an attack

Attack Analytics correlates target and source IPs with tenant-scoped routers, OLTs, switches, wireless devices, static assignments, customers, live RADIUS sessions and access sites. An internal attacking source is labelled as possible self-DDoS, misconfiguration or compromise for investigation rather than automatically declared malicious.

Public sources use IANA’s RDAP bootstrap to reach the authoritative APNIC, ARIN, RIPE NCC, LACNIC or AFRINIC service. Licensed abuse.ch Feodo Tracker and Emerging Threats data adds expiring community evidence. RIR ownership is not reputation, and a community match can never authorize mitigation.

When Local ASN and public protected prefixes are configured, RPKI validity and globally observed BGP origins/paths provide possible hijack or route-leak warnings. These labels require network-engineer validation; flow telemetry alone cannot prove either condition. Chart points, bars and evidence rows reveal exact values by mouse, keyboard focus and touch.

The Connectivity workspace accepts any valid ASN. When none is entered, ISPbills uses the network profile ASN or infers the public origin from a connected router address. It shows RIPE routing observations and RPKI validation alongside PeeringDB declarations. “Paths entering” and “paths leaving” describe position in observed collector paths; they are not presented as proof of a commercial provider, peer or customer relationship.

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.