On this page
The Attacks tab shows what Clouduxe Prism dropped in front of your server. Some of the figures on it are exact counts and some are estimates rebuilt from a sample of the traffic, and knowing which is which decides what you are allowed to conclude from them.
An attack here is an incident, not a signature
The filter logs individual dropped packets. The page groups those logs into incidents: one incident is one attack, bounded in time, containing whatever vectors the attacker threw while it ran.
- A quiet gap longer than 5 minutes ends one incident and starts the next.
- Each incident gets an ID, a severity, a source count, a vector count, and a duration. Open one for its full breakdown.
- The list is split into Ongoing and Earlier. An ongoing row is not clickable: its ID is derived from its own contents and keeps changing while it runs, so there is nothing stable to open yet. The panel says so on the row: "Attack in progress. The full breakdown unlocks the moment it ends." The list refreshes itself, so an attack moves into Earlier on its own.
Not every drop becomes an incident. A hit from 20 or more distinct sources is always listed, because that shape matters however small it is. Below that threshold an incident is listed only if it reaches about 1,000 estimated packets, sustains at least 20 packets per second across its duration, and the filter registered an attack at some point in that window. Everything under that is background noise that was already handled and does not need a card.
The fields behind every number
Every figure on this tab is built from drop events, and a drop event carries these fields and no others:
| Field | What it is |
|---|---|
| Time | When the packet was dropped. The Time column in the drop tables |
| Source address | Where the packet came from. The Source column |
| Destination port | The port it was aimed at. Shown in the Target column with the protocol |
| Protocol | TCP, UDP, or ICMP |
| Attack type | Which check dropped it. The Signature column, and the engine names in the breakdowns |
| TCP flags | The decoded flags on a TCP packet. Not shown as a column of its own, they are what classifies Attack composition |
These are real per-packet values, read off the wire. What a drop event does not carry is not invented for it: an event holds no country, no network operator, and no byte count, so nothing built from the drop events breaks down by any of those. A source list is what exists, so a source list is what you get, and there is no map.
TCP flags are the one field that is often missing rather than wrong. UDP and ICMP have none, and a packet dropped before the TCP header was read has none either. Those land in Other under Attack composition instead of being guessed at, and the card tells you when most of a window is unclassified for that reason.
The figures that are exact
Dropped
The Dropped figure in the header is an exact count. Every dropped packet increments it, with no sampling involved.
Read the small line under it, though: it says since agent start, and that is literal. It counts from the moment the on-host filter last started, not over the range you selected above it. A routine restart of the filter puts it back to near zero. On one server it read about 289 million during an attack and about 66 half an hour later, purely because the filter had restarted for a software rollout.
Address lookup
Address lookup answers one question exactly: was this address filtered before it reached my server, and which protection acted. The panel states the guarantee in the card itself: "Counts are exact, not sampled."
That makes was not filtered a real answer rather than a gap in the sample, which is why this is the right tool when you need certainty about one address. One caveat is built into how the ledger works: it publishes after an attack ends, so a lookup run during an active attack can legitimately come back with nothing yet. Run it again once the wave is over.
The traffic charts
The two charts under the Range bar are drawn from a separate time series with 30 days of retention, not from the drop-event log, so they stay accurate across wide windows where the breakdowns below them do not. When the selected range reaches further back than the loaded drop events, the page says so in a banner and reminds you that the charts still cover the whole window.
Two things to know about them. The passed line is worked out by subtracting dropped from received rather than counted on its own. Bandwidth series are shown only where the edge reports byte counters, and where they are absent the series is hidden rather than drawn as a flat zero.
The figures that are sampled estimates
Everything built from the drop-event log is an estimate, and the panel marks
each one with a leading tilde (~).
That includes Top source IPs, Top destination ports, Attack engines, and Protocol mix in the Breakdowns card, the Dropped column in Port activity, Attack composition, and on an incident's own page, Top attack sources, Targeted ports, the per-vector packet counts under Vectors in this attack, and the rows in Logged drops.
The tilde is worth reading closely in the attack list. An incident's packet total is taken from the exact counters when the traffic series covers its window, and the panel then prints it without a tilde. A total that still carries one fell back to the sampled figure, which on an older incident means the series no longer reaches that far back.
Why the estimates run low
The filter logs 1 dropped packet in every 64, and the panel multiplies each logged event back up by 64. That is an unbiased estimate when the sampling holds. Under a real attack it does not hold, for two compounding reasons:
- The sample rate itself collapses. The buffer the filter writes into overflows under load and drops log entries. In one incident, 542,276,100 packets were actually dropped while 51,840 events were logged. That is 1 in 10,460, not 1 in 64.
- The event log is capped. The page loads the newest 5,000 drop events within the last 7 days. At 64 packets an event, the arithmetic saturates at about 320,000 no matter how large the attack was.
- One dropped packet in this many is logged, as designed
- 64
- One in this many was logged in that incident
- 10,460
- Newest drop events the page loads, within 7 days
- 5,000
On that same incident the breakdowns reported about 320,000 packets against 542 million actually dropped, roughly 1,694 times under. The bigger the attack, the further under they read.
The shape survives the undercount because the sampling is uniform. If one source sits at the top of the list and the next is a tenth of its size, that ratio is meaningful even when both numbers are far too small.
Port activity
Port activity lists every port that has a rule, plus any port the drop log saw without one. A port with a rule and no attack still gets a row, so a quiet port reads as quiet rather than as unprotected. Rows carry a no rule badge where drops arrived on a port nothing is configured for, which is worth a look: that is either a scan or a service you forgot to declare.
The Dropped column is a sampled estimate, like the rest of the breakdowns. There is no passed figure per port anywhere on the page, and that is deliberate: the filter counts passed packets for the server as a whole and never per port, so any number in such a column would have been invented.
Choosing a range
The Range control at the top drives every breakdown and both charts. It
offers 30m, 1h, 6h, 24h, and 7d, plus Custom for a fixed window.
The longest preset is 7 days, because attack history is pruned at 7 days and a
longer one would mostly be empty.
Two things the range does not touch: the Dropped header figure, which counts since the filter last started, and the grouping of incidents, which is done once over everything loaded so an incident keeps the same ID whichever range you view it from.