DDoS Sensor Detail
There is no standalone DDoS sensor page in the FluxBilling admin panel. Use the Activity Log for security visibility and your network provider for mitigation.
What a sensor is in this platform
There is no separate DDoS sensor object in the admin panel. What plays the role of a sensor is a monitored network device: a switch, router, firewall, PDU, access point or load balancer that the platform polls over SNMP and reports on. Each of those devices has its own detail page, and that page is the per-sensor view — it is where you read traffic rates per port, watch utilisation climb, set the thresholds that raise alerts, and see the alerts that device has produced.
This article covers that page: how to open it, what every panel on it means, and how to read it when you suspect an attack. For the wider picture of where mitigation happens, start with DDoS Protection.
Note: This is a read-and-alert view. It shows you traffic and raises alerts; it does not filter, rate-limit or blackhole anything. Mitigation is delivered by your upstream provider or by the firewall on the affected host.
Opening a device
- Click the Monitoring icon in the top header bar of the admin panel. It appears only for administrators whose role permits it, and only when the Monitoring module is enabled and available on your plan.
- Open the Devices tab and find the device — use the
Search devices...box if the list is long. - Click the row. The device's own page opens.
Devices come from Inventory. A switch, router or firewall that has not been added there will not appear in Monitoring, and it has no detail page.
The device header
The top of the page names the device and shows its type, model, how long it has been up, and a Last polled timestamp. Three buttons sit on the right:
| Control | What it does |
|---|---|
| Poll Now | Asks the device for a fresh reading immediately instead of waiting for the next scheduled poll. Use it when you want to confirm a spike is still happening. |
| Thresholds | Opens Device Thresholds — the warning and critical levels that raise alerts for this device (see below). |
| View Device | Opens the equipment record behind the device, where its name, address and connection details are edited. |
Tip: Last polled is the first thing to check. A page full of calm numbers means nothing if the reading is an hour old — a device that has stopped answering is itself a symptom worth chasing.
Health gauges
Four cards sit under the header and show the device's current condition. The first three fill with colour as they rise — amber at the warning level, red at the critical level:
- CPU — processor use as a percentage.
- Memory — memory use as a percentage.
- Temperature — in degrees Celsius.
- Status — the fan and power-supply state, each reading ok, a warning value, critical, or N/A when the device does not report it.
During a flood the giveaway is usually CPU climbing on a router or firewall while traffic climbs with it. CPU climbing on its own, with flat traffic, points at something else.
Charts
Three charts follow, each drawn over the range you pick from the selector: 1 Hour, 6 Hours, 24 Hours or 7 Days.
- Aggregate Traffic — total in and out across the device. This is the chart you compare against your provider's own traffic graph.
- CPU & Memory — the two health figures over time, so you can see whether load followed the traffic or preceded it.
- Temperature — useful for separating a heat or fan problem from a traffic problem.
Tip: Start at 1 Hour to see what is happening right now, then switch to 7 Days to judge whether the level is genuinely abnormal for this device. A link that always runs near its ceiling at the same hour every evening is a capacity conversation, not an attack.
The ports table
Below the charts, every port on the device is listed, with a count of how many are up in the heading (for example 18/24 up). The columns are:
| Column | What it shows |
|---|---|
| Port | The port name, or its index number if the device reports no name. |
| Status | A coloured dot with up (green) or down (red). |
| Speed | The port's link speed in Mbps, or a dash if it is not reported. |
| In | The current inbound rate. |
| Out | The current outbound rate. |
| Utilization | A bar and a percentage for the busier of the two directions — green below 70%, amber from 70%, red from 90%. |
The ports table is the most useful part of the page during an incident, because it tells you where the traffic is arriving. An inbound flood usually shows as one uplink port at red utilisation while the customer-facing ports stay ordinary. Traffic leaving one customer port at an unusual rate points the other way — at an outbound flood originating on a machine you host.
The Speed column matters when you read utilisation: 400 Mbps is unremarkable on a 10 Gbps uplink and saturating on a 1 Gbps one.
Alerts for this device
The last panel lists the alerts this device has raised, with a count of how many are still active in the heading. Each row shows a severity badge, the kind of alert, the port it concerns where relevant, the alert message and the time it was raised.
- An alert that is still active and has not been picked up yet offers an Acknowledge button — use it to signal that someone is on it, without pretending the condition has gone away.
- An alert that has since cleared shows a Resolved badge.
- When there is nothing to show, the panel reads No alerts with the note This device has no alerts.
To work through alerts across all devices at once, and to resolve or delete them in bulk, use the Alerts tab on Monitoring.
Setting thresholds so an attack pages you
Alerts only fire against thresholds you have set, so this is the part of the page that turns a chart you have to remember to look at into something that tells you. Click Thresholds in the header to open Device Thresholds. Each row has a tick box to switch that check on or off, a W (warning) value and a C (critical) value, in the unit shown at the end of the row.
| Section | Threshold | Unit |
|---|---|---|
| Traffic | Inbound Utilization | % |
| Outbound Utilization | % | |
| Error Rate | per minute | |
| Discard Rate | per minute | |
| Health | CPU Usage | % |
| Memory Usage | % | |
| Temperature | °C |
Click Save to store them, or Cancel to close without changing anything. Values set from a device page apply to that device alone and override the platform-wide defaults. The same dialog opened from the Monitoring page without a device selected sets those defaults instead, and the dialog says which of the two you have open: Device Thresholds or Global Thresholds.
Tip: Inbound Utilization is the threshold that behaves most like a DDoS alarm. Set it well above your normal evening peak so it does not cry wolf, then leave Discard Rate and Error Rate enabled as well — a link that is dropping packets is already past the point where utilisation alone tells the story.
Reading the page during a suspected attack
- Check the poll is fresh. Look at Last polled, and press Poll Now if it is stale.
- Look at Aggregate Traffic over 1 Hour. A near-vertical rise that has not come down is the shape you are looking for.
- Find the port. Sort your eye down the Utilization column. One uplink in red with the rest ordinary means traffic is arriving from outside; a single customer port in red means it is leaving from inside.
- Compare against 7 Days. Confirm the level is genuinely unusual for this device before you escalate.
- Escalate to the layer that can stop it. Contact your upstream provider or data centre with the port, the direction and the rate, and apply firewall rules on the affected host. The panel cannot filter this traffic for you.
- Acknowledge the alerts you are working on, and resolve them once the condition clears, so the Active Alerts count on Monitoring stays meaningful.
- Write the incident down. The Activity Log records what your team changed and when, which is what you will need afterwards.
When the pressure is on your panels, not your network
Not every flood is volumetric. Waves of sign-in attempts, scraping and form abuse hit your admin panel and client portal rather than your switches, and they will not show up on this page at all. For those, use IP Ban to block the offending addresses and to auto-block after repeated failed sign-ins, and Security to put a captcha and two-factor authentication in front of the login and registration forms.
Related
- DDoS Protection — where mitigation happens and how the panel fits around it.
- Monitoring — device list, alert queue and topology.
- Monitoring Device — the full device-page reference.
- IP Ban — block abusive addresses from your panels.
- Activity Log — audit trail of administrative actions.
