Skip to content
Operate

Dashboard and Notifications

Reach InnerWarden's local dashboard and set up notification channels (Telegram, Slack, Discord, webhook, web push) with plain-language explained alerts.

Dashboard and Notifications

For: operators who want to see what InnerWarden is doing and get told when something matters.

InnerWarden gives you two windows onto itself: a local dashboard for sitting down and investigating, and notifications (Telegram, Slack, Discord, webhook, web push) for getting pinged on your phone when there is something to look at. Both speak plain language, every alert explains what happened and why it matters, not just a raw detector name.

Where to configure each channel (the actual keys and tokens) is owned by Configuration; the commands to set them up live in CLI Reference. This page is what each surface is and how to reach it.

The dashboard

The dashboard is a local, authenticated web UI served by the agent. By default it binds to loopback only (127.0.0.1:8787), which is the secure default: nothing on your network can reach it, only something already on the box.

One command tells you everything about how to reach it:

innerwarden dashboard

That prints the bind address, the URL, the login, and a ready-to-paste SSH-tunnel command. You do not edit systemd units to manage access anymore, it is one command:

innerwarden dashboard tunnel              # print the exact SSH local-forward command (nothing exposed, safest)
innerwarden dashboard open                # expose it securely: generates a login if none exists,
                                          #   sets the bind, and firewall-locks to YOUR current SSH client IP
innerwarden dashboard open --allow <ip>   # lock to a specific IP instead (--public widens to any IP, less safe)
innerwarden dashboard close               # back to localhost only

The safest way to view it remotely is the SSH tunnel: nothing is ever exposed, you forward the port over your existing SSH session and open http://127.0.0.1:8787 on your own machine. open is there when you genuinely want it reachable, and it refuses to expose the dashboard without credentials, so an exposed dashboard is always password-protected. The flags for all of these are detailed in CLI Reference.

Authentication note: a loopback connection bypasses the login (you are already on the box). The moment the bind is non-loopback, credentials are mandatory, the agent will not serve a network-reachable dashboard without them.

The tabs at a glance

You do not need to learn all of these to get value; the first two carry most of the day-to-day work.

  • Sensors: the live HUD. A card per collector with ACTIVE / DETECTED / NOT FOUND status and event counts, the eBPF programs, and a colour-coded timeline of activity. This is "is everything watching, and what is it seeing right now."
  • Threats / Investigate: the investigation surface. Entity timelines, attacker journey viewer (entry vector, access status, privilege status, containment, honeypot), pivots by IP / user / detector, incident clusters, and snapshot export. This is where you handle a live incident visually; the workflow is in Responding to Incidents.
  • Report: operational metrics, day-over-day trends, anomaly hints, top IPs, incidents by type.
  • Health: service health plus a metrics-drift view (incidents/hour by severity, blocks/hour, gate suppression, and more) so you can see if something has shifted.
  • Honeypot: captured decoy sessions: the credentials attackers tried, the commands they ran, the IOCs they revealed.
  • Intelligence: per-attacker profiles with risk scores and behavioral DNA, detected campaigns (clustered by shared infrastructure), cross-layer attack chains, baseline-learning status, and MITRE coverage.
  • Monthly: the auto-generated monthly threat report: executive summary, top attackers by risk, MITRE heatmap, geographic spread, and honeypot intel.
  • Compliance: ISO 27001 control mapping, SHA-256 audit-chain verification, data-retention policy, and the admin-actions audit trail. The compliance mapping is explained in ISO 27001 Mapping.

You can also block an IP, suspend a user, or mark an IP Trust (monitor-only) directly from the dashboard, each with a mandatory reason field and a confirmation modal that shows whether you are in DRY RUN or LIVE mode. Marking Trust keeps the entity detected, logged, and notified, it only suppresses the auto-block, the same monitor-only meaning everywhere in InnerWarden. The safe way to build a trust list is in Safe Observe and Allowlist.

Notifications

Notifications are how InnerWarden reaches you when you are not looking at the dashboard. Every channel applies the same gate, so you are not spammed: for each incident InnerWarden decides to send now (an uncontained active intrusion, pushed to every enabled channel), fold into the daily briefing (low-severity or already-handled), or drop (test traffic, an allowlisted IP, or something already notified in the cooldown window).

A few things hold across all channels:

  • Every alert explains itself. A plain-language "what happened and why it matters" line, with the MITRE technique, not a snake_case detector name.
  • Every alert names the server. On a multi-box fleet you can always tell which machine an alert came from.
  • Bursts collapse. When 50+ threats are auto-blocked in an hour, you get one "heavy attack, all contained" summary that breaks down the attack types, not 50 pings.

Telegram (the full control surface)

Telegram is the richest channel: it is not just alerts, it is a remote control for InnerWarden from your phone. You get push alerts for High/Critical incidents, and you can act on them with inline buttons (Block / Ignore / Dismiss) right from the alert. Beyond that:

  • /mode guard | watch | dryrun flips the guardian mode live, from your phone, no SSH needed. This is the lever for a lay operator who cannot get to a shell: switch the whole host between observe (dry-run), watch, and active enforcement.
  • /unblock <ip> reverses a containment from the same surface that blocked it.
  • /status, /incidents, /decisions, /posture, /ask <question> query the box conversationally; free text routes to the AI for a plain answer. /menu opens an inline keyboard.
  • Settings buttons (profile, sensitivity) actuate at runtime and persist, they do real things, not print a CLI hint.
  • The menu is profile-aware: a non-technical operator sees a tiny 5-command menu in plain language (status · threats · mode · ask · help); the technical profile gets the full set.

Sensitive actions (mode changes, unblock) can require a TOTP second factor, configured with innerwarden config 2fa. The inbound side fails closed: a misconfigured chat id drops all updates rather than authorising a stranger.

Slack and Discord

Slack (Incoming Webhook, Block Kit) and Discord (Incoming Webhook, colour-coded embeds) get full parity with Telegram for what matters: incident alerts, post-action reports ("Threat neutralized, Blocked ..."), burst summaries, and the once-a-day Security Briefing. They render the same explained-alert story and name the same server. One channel failing never blocks the others.

Webhook and web push

  • Webhook posts every qualifying incident as HTTP JSON to any endpoint you give it, with a severity filter, fired in real time on the fast tick. This is the SIEM / automation hook.
  • Web push delivers browser notifications (RFC 8291 / VAPID), with a configurable minimum severity. Useful when you live in a browser, not a chat app.

The daily Security Briefing

Once a day, InnerWarden sends a boss-readable briefing to your chat channels (Telegram, Slack, Discord): a plain bottom-line verdict (Quiet day, Busy day, all contained, or N items need your decision), what it blocked and the top attacking sources, how many automatic decisions it made, and how many items still need you, reconciled to the exact same "Needs review" number the dashboard shows. No raw detector names, no "more decisions than events?" confusion. It leads with the server name so a shared channel stays legible across boxes.

Explained Alerts

This is worth calling out on its own because it is the difference between an alert you trust and noise you ignore. Every dispatched notification, and every incident in the terminal and dashboard, carries a plain-language explanation fused from a curated detector catalog and the live MITRE mapping. So kernel_devnode_exposed reaches you as a sentence a human can act on, with the technique it corresponds to. It is communication-only: it changes nothing about detection, severity, or whether the alert was sent, it only makes what InnerWarden already decided legible to you.

Setting it all up

Configure any channel with the matching command (each writes the TOML for you):

innerwarden config telegram --token <T> --chat-id <C>
innerwarden config slack --webhook-url <URL>
innerwarden config discord
innerwarden config webhook --url <URL>
innerwarden config dashboard --user <U> --password <P>
innerwarden config 2fa

The exact flags are owned by CLI Reference, and the full set of config keys (including min_severity, the daily-summary hour, and the notification gate's thresholds) is owned by Configuration. To fire a one-off test to every configured channel, use the test-alert command shown in CLI Reference.

See also