> ## Documentation Index
> Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# DDoS mitigation activation and customer comms

> A NetFlow anomaly flags a volumetric attack on a hosted customer. Confirm in FastNetMon, activate upstream mitigation, advertise RTBH where appropriate, and keep the customer informed through the whole event.

FastNetMon detects 38 Gbps of UDP reflection traffic aimed at one of the ISP's hosted customer prefixes. The NOC needs to confirm the attack, activate upstream mitigation with the ISP's transit providers, protect the rest of the subscribers without blackholing the victim unnecessarily, and keep the customer informed so they don't see their own website blackholed and open a panic ticket.

## Systems involved

| System                                          | Role                                        |
| ----------------------------------------------- | ------------------------------------------- |
| FastNetMon                                      | Source detection.                           |
| NetFlow / sFlow collectors                      | Confirm pattern, identify attack signature. |
| Core routers (Juniper MX / Cisco ASR)           | BGP flowspec, RTBH, policer announcements.  |
| Transit provider portals (Cogent, Lumen, Telia) | Upstream scrubbing request.                 |
| Cloudflare Magic Transit / Arbor TMS            | Scrubbing centre diversion.                 |
| Slack `#security`                               | Internal channel.                           |
| Customer portal / Gmail                         | Customer-facing comms.                      |
| Splynx / Sonar                                  | Customer record and contact lookup.         |

## Walkthrough

<Steps>
  <Step title="Confirm the attack signature">
    FastNetMon raises the alarm. Copilot pulls the NetFlow top-flows, confirms UDP reflection on source ports 123 and 11211, and identifies the destination prefix — a single /28 hosted for a customer named ACME Gaming.
  </Step>

  <Step title="Decide the mitigation posture">
    The prefix is hosting live game-matchmaking. RTBH blackholes the customer, which is the attacker's goal. Copilot proposes transit scrubbing first, flowspec policer second, RTBH last-resort — and lists the phone numbers for each transit provider's NOC.
  </Step>

  <Step title="Engage transit scrubbing">
    Through the Lumen scrubbing connector, request diversion for the affected /28. Cogent has no connector yet — Copilot drafts the email template with attack signature, prefix, customer identifier, and contact phone.
  </Step>

  <Step title="Push flowspec at the edge">
    SSH to the core routers. Stage the flowspec rule: drop UDP/123 and UDP/11211 traffic to the victim prefix. Approval prompt shows the exact match and action. Push and monitor.
  </Step>

  <Step title="Notify the customer">
    Copilot pulls the customer's technical contact from Splynx and drafts a short email through Gmail: attack detected, scrubbing active, their service may see brief rerouting, the NOC is monitoring, next update in 30 minutes. Sent.
  </Step>

  <Step title="Internal channel">
    Open a Slack thread in `#security` with the timeline, flow samples, scrubbing status, the customer contact state, and the escalation tree. Every action in the incident posts there automatically.
  </Step>

  <Step title="Monitor effectiveness">
    Copilot watches the FastNetMon attack-graph and the core-router interface counters. Scrubbing brings the attack from 38 Gbps to 180 Mbps of legitimate traffic within six minutes.
  </Step>

  <Step title="De-escalate">
    When the attack falls below the policer threshold for 15 minutes, withdraw the scrubbing diversion, remove the flowspec rule in reverse order, and validate the customer's service is normal. Send the customer the all-clear email.
  </Step>

  <Step title="Post-event report">
    Generate a Markdown attack-event report: timeline, peak bps and pps, signature, mitigations applied, effectiveness curve, recommendations. Attach to the internal ticket and email to the customer for their records.
  </Step>
</Steps>

## Where Studio earns its keep

* The decision — scrub vs. flowspec vs. RTBH — happens with the customer's service impact visible on the same screen as the attack signature.
* Transit-provider engagement happens from inside the workspace with the exact attack details ready to paste, not from scratch in a browser.
* The customer gets a coherent update before they file a panic ticket, which preserves the relationship.
* The post-event report writes itself from the flow data and the action timeline, which is the artifact insurance and regulators want.

## Related

<CardGroup cols={2}>
  <Card title="AI Copilot" icon="sparkles" href="../../ai-copilot" arrow="true" cta="Set posture">
    Keep Planning mode on while DDoS decisions are active — every action deserves a visible approval.
  </Card>

  <Card title="Connectors and MCP" icon="plug" href="../../connectors-and-mcp" arrow="true" cta="Wire carriers">
    FastNetMon, transit scrubbing portals, and Splynx as connector calls.
  </Card>
</CardGroup>