Read attack events

When DDoS Shield drops traffic to one of your floating IPs at a high rate, it records an attack event: which address was hit, why we dropped the traffic, how large the attack was and how long it lasted. The Events tab of DDoS Shield lists these events, and each one opens to show the senders and a few sampled packets.

• Events exist only for floating IPs. DDoS Shield does not filter a server's shared address, so attacks on it leave no event (How DDoS Shield works).
• An address in Passthrough mode records no events, because we drop almost nothing on it.
• The events of a floating IP disappear from the list when you cancel the floating IP.

An event records traffic that DDoS Shield dropped for one reason, such as a reflection port or a rate limit, on one address. The routers at our points of presence that filter traffic, which the dashboard calls scrubbing nodes, each record their own events. One attack can therefore show as several events: one for each reason, each address and each node that received it.

• An event starts once a node drops at least 100 packets per second, or 1 Mbps, of one kind of traffic to the address. We filter smaller amounts all the same, but they make no event.
• Drops by the SYN or ICMP rate limits make an event only when they come from 10 or more senders, or reach 20,000 packets per second, so one busy client does not show as an attack.
• An event ends once that kind of traffic has stopped for about 45 seconds, so its duration includes those seconds.
• When the same kind of traffic hits the same address at the same node again, we update the earlier event instead of adding a new one. The event keeps its first start time, its peak becomes the highest seen, and it keeps its earlier end time until the new attack ends. Recorded shows when the event last changed.

1. In the dashboard, select DDoS Shield, then the Events tab.
2. Choose how far back to look: 24 hours, 7 days, 30 days or All time. The tab opens on 7 days, and the window goes by when each event first started.
3. To narrow the list, choose an address in the All addresses list or a type in the All attack types list.

Each row shows:

• Started: the date and time the event started, and how long ago that was.
• Address: the address that was attacked. For a subnet, it is the host.
• Attack: the type of traffic we dropped, such as Reflection or SYN rate limit, with the drop reason under it.
• Peak: the highest rate in packets per second, with bits per second under it.
• Duration: how long the event lasted. While the event has no end time, the duration keeps counting.
• Status: Mitigating while the event has no end time, and Mitigated once it has one.

The tab loads the 200 newest events across your addresses. When the filters match none of them, it shows No matches, and Reset filters clears both lists and sets the window to All time. When there is no event at all, it shows No attacks yet.

Select a row to open it, and select it again to close it. On a phone, each event is a card: select Show details.

What happened

• Drop reason: why we dropped the traffic, as in Attack types.
• Why: the same reason as a code, such as udp_src_port_in_reflection_blocklist.
• Ports hit: the dashboard shows — here. The API's payload.top_src_ports lists the busiest source ports (With the API).
• Unique sources: how many different senders the node saw among the packets it sampled.
• Peak: the highest packets and bits per second in any one second at that node. The bits per second can be an estimate from the packet rate and the average packet size.
• Duration: as in the list.
• Volume: the peak rate multiplied by the duration. It is an upper estimate, because an attack rarely stays at its peak.
• Scrubbing node: the number of the node that recorded the event.
• Recorded: when we last updated the event.

Heaviest sources

A row for each of the busiest senders, up to five. The dashboard shows — in place of each address and rate, so read the senders from the API's top_sources and payload.top_sources.

Sampled packets

Up to eight packets the node sampled, each as source:port → destination:port, such as 198.51.100.20:53 → 203.0.113.10:41822.

The dashboard writes each type in words, such as SYN rate limit for syn_rate_limit, and the Why row shows its code:

• An event means we dropped the traffic. When your service keeps working, there is nothing to do.
• When the service is down while an attack goes on, follow Get help during an attack.
• When an event shows that we dropped traffic you want, such as firewall_deny for your own users or a rate limit that a busy service goes over, change the address's rules or limits on its Shield tab (Change a floating IP's DDoS protection). Limits of your own apply only in Custom mode.
• When reflection events hit the replies to DNS or NTP requests that your machine sent, see Reflection ports.

An attack took a service down, and no event shows

The traffic went to a server's shared address, the address is in Passthrough, or the attack passed our checks and limits because it looked like real traffic. An earlier event of the same kind may also have taken the attack in, as How we record an event explains: choose All time and look for a recent Recorded time. Then follow Get help during an attack.

One attack shows as several events

Each scrubbing node records its own event for each reason and each address. Compare their Started times to see which belong together.

An event shows Mitigating long after the attack ended

The dashboard shows Mitigating for any event without an end time, and an event can stay without one when its node stopped sending updates. The API's active field turns false once we have had no update for two minutes, and that is the reliable sign that the event is over.

Heaviest sources or Ports hit shows only —

The dashboard does not read these parts of the event. Read top_sources, payload.top_sources and payload.top_src_ports from the API.

The list stops before the event you want

The tab loads the 200 newest events. Ask the API for more with a higher limit.

Could not load the events

Select Try again. If it keeps failing, contact support.

• How DDoS Shield works
• Change a floating IP's DDoS protection
• Get help during an attack
• Order and use a custom profile

GET /api/v1/client/shield/events returns the attack events on your floating IPs, newest first. limit sets how many come back, 50 by default, and each floating IP contributes at most 500. Send a limit of 1 or more.

curl "https://api.coritan.com/api/v1/client/shield/events?limit=200" \
  -H "Authorization: Bearer $CORITAN_TOKEN"

{
  "events": [
    {
      "id": 90211,
      "node_id": 3,
      "session_key": "214:7:cb00710a",
      "subject_id": 214,
      "subject_kind": "service",
      "ip_service_id": 214,
      "inventory_id": 5120,
      "address": "203.0.113.10",
      "attack_type": "reflection",
      "drop_reason_id": 7,
      "drop_reason": "reflection",
      "pps": 184000,
      "bps": 1510000000,
      "unique_sources": 3120,
      "top_sources": "[\"198.51.100.20\", \"198.51.100.21\"]",
      "started_at": "2026-09-25T14:02:11",
      "ended_at": "2026-09-25T14:09:56",
      "received_at": "2026-09-25T14:09:56",
      "active": false,
      "payload": "{\"classification\": \"policy_drop\", \"why_hint\": \"udp_src_port_in_reflection_blocklist\"}"
    }
  ]
}

The example shortens top_sources and payload. Both arrive as JSON text, so parse them before you read them.

subject_id, subject_kind, session_key and inventory_id identify the event on our side. payload, once parsed, holds the node's details:

{
  "classification": "policy_drop",
  "drop_reason_id": 7,
  "drop_reason": "reflection",
  "effective_mode": "standard",
  "top_sources": [{"ip": "198.51.100.20", "packets": 41}, {"ip": "198.51.100.21", "packets": 39}],
  "top_src_ports": [{"port": 53, "packets": 7410}, {"port": 123, "packets": 1590}],
  "top_protocols": [{"proto": 17, "packets": 9000}],
  "samples": [
    {"src_ip": "198.51.100.20", "dst_ip": "203.0.113.10", "ip_proto": 17, "src_port": 53, "dst_port": 41822, "ttl": 54, "pkt_len": 1242, "tcp_flags": null, "udp_len": 1208}
  ],
  "why_hint": "udp_src_port_in_reflection_blocklist"
}

The example leaves out threshold_snapshot, which records the node's own settings. The DDoS Shield API reference lists every field.