Alerts
Kismet uses alerts to communicate wireless intrusion events and critical Kismet server events.
Alerts are generated both as text messages on the messagebus and as dedicated alert records.
For real-time monitoring of alerts, see the eventbus API.
Alert severities
Alerts severities are categorized by numerical value; a higher number is more severe.
| Severity | Defintion | Use |
|---|---|---|
| 0 | INFO | Informational alerts, such as datasource errors, Kismet state changes, etc |
| 5 | LOW | Low-risk events such as probe fingerprints |
| 10 | MEDIUM | Medium-risk events such as denial of service attempts |
| 15 | HIGH | High-risk events such as fingerprinted watched devices, denial of service attacks, and similar |
| 20 | CRITICAL | Critical errors such as fingerprinted known exploits |
Alert types
Alerts are categorized by type; alert types are free-form strings, but include:
| Type | Use |
|---|---|
| DENIAL | Possible denial of service attack |
| EXPLOIT | Known fingerprinted exploit attempt against a vulnerability |
| OTHER | General category for alerts which don’t fit in any existing bucket |
| PROBE | Probe by known tools |
| SPOOF | Attempt to spoof an existing device |
| SYSTEM | System events, such as log changes, datasource errors, etc |
Alert configuration
readonly/alerts/definitions.json/alerts/definitions.ekjson/alerts/definitions.prettyjsonGETAll alerts
Kismet retains the past N alerts, as defiend by alertbacklog in kismet_memory.conf.
By default, Kismet retains 50 alert records.
readonly/alerts/all_alerts.json/alerts/all_alerts.ekjson/alerts/all_alerts.prettyjsonGETRecent alerts
This endpoint returns alerts since the exact timestamp of seconds and milliseconds.
A more efficient and reliable method is to use the eventbus websocket.
readonly/alerts/last-time/{TIMESTAMP}/alerts.json/alerts/last-time/{TIMESTAMP}/alerts.ekjson/alerts/last-time/{TIMESTAMP}/alerts.prettyjsonGETPARAMETERS
TIMESTAMP
number (double)
REQUIREDTIMESTAMP.UTIMESTAMPRecent alerts (wrapped)
This endpoint functions identically to the recent alerts endpoint, but wraps the return in a JSON object including the timestamp when the server generated the report.
This can be used for polling UI implementations to know the exact time pass in the next alert query.
A more efficient and reliable method is to use the eventbus websocket.
readonly/alerts/wrapped/last-time/{TIMESTAMP}/alerts.json/alerts/wrapped/last-time/{TIMESTAMP}/alerts.ekjson/alerts/wrapped/last-time/{TIMESTAMP}/alerts.prettyjsonGETPARAMETERS
TIMESTAMP
number (double)
REQUIREDTIMESTAMP.UTIMESTAMP and the exact timestamp
of the return generation.