Home - sparkycz1/honeypot-shelf GitHub Wiki
A fleet of decoys, watched from one browser tab β every fake login attempt lands here first.
Management and monitoring for a fleet of OpenCanary honeypots (Raspberry Pis, Debian, or Ubuntu boxes at customer sites β see Initialize for the six supported OS releases), scoped per company β every page needs a login (local, LDAP, or OIDC, plus TOTP/passkey 2FA), and what an account can see is gated by RBAC (see Authentication & RBAC). A honeypot is managed exactly like a machine in debcontrol (a sister project for Debian fleets, where this project's stack, layout, auth system, and SSH management layer were all ported from) β plus this project's own addition: an SSH poll reads OpenCanary's own events straight off each honeypot, and the Dashboard sums them per company. Full "what was reused vs. what's different" story in CLAUDE.md; this page is the map, not the territory.
flowchart LR
App(("π Honeypot Shelf"))
App --> Dash["π Dashboard"]
App --> H["π― Honeypots"]
App --> Map["πΊοΈ Map"]
App --> Notif["π Notifications"]
App --> Init["π± Initialize"]
App --> Sched["β±οΈ Scheduling"]
App --> Comp["π’ Companies"]
App --> Set["βοΈ Settings"]
H --> H1["Overview Β· Monitoring Β· Activity<br/>Updates Β· Terminal Β· Logs Β· Config"]
classDef hub fill:#1b2430,stroke:#f2a83a,stroke-width:2px,color:#fff
classDef leaf fill:#f2a83a,stroke:#1b2430,stroke-width:1px,color:#1b2430
classDef sub fill:#f4f4f4,stroke:#1b2430,color:#1b2430
class App hub
class Dash,H,Map,Notif,Init,Sched,Comp,Set leaf
class H1 sub
Note
Two independent "is it alive" signals per honeypot, and they mean
different things: is_reachable is a plain SSH-plane ping; last_seen_at
is "the SSH log poll last found OpenCanary itself alive." A honeypot
can be reachable with OpenCanary dead, or vice versa β see
Honeypot Management.
| Page | For when you need to... |
|---|---|
| π Installation | Stand the thing up β Docker, reverse proxy, backups |
| ποΈ Architecture | Understand why it's built this way β the hub for the pages below |
| π Authentication & RBAC | Logins, sessions, the company-membership model, 2FA, Impersonate |
| π― Honeypot Management | Provisioning, VPN, the Config tab, the data model, how events arrive |
| π Audit Log | Hash-chain integrity, retention, export, SIEM forwarding |
| π Notifications | Rules, scope, wording, push/chat channels, the webhook SSRF guard |
| π± Initialize | Provision a brand-new Raspberry Pi OS/Debian/Ubuntu device into a honeypot over SSH |
| π οΈ Development | Run it locally, add a feature, ship a migration |
Honeypot Shelf only ever speaks plain HTTP (port 8080) β it expects a
TLS terminator in front of it, always. Pick your fighter:
- Caddy β bundled, zero-config HTTPS. The easy button.
- nginx β you already run one for everything else.
- Traefik β you're already all-in on Docker labels.
| Tab | The highlights (not the whole story β see Architecture) |
|---|---|
| π Dashboard | Fleet counts (OpenCanary reporting/silent, SSH reachable, needs-updates), a trend sparkline, and a fleet-wide "activity by alert type" breakdown |
| π― Honeypots | Facts, packages, live monitoring (with an OpenCanary service up/down graph), a browser SSH terminal, log browsing, an Activity tab reading OpenCanary's own log over SSH, a Config tab (read-only-root toggle, a MAC address change β typed in or drawn for a chosen manufacturer β and a full editor for every OpenCanary module), a History tab (notes, update runs, outages and audited actions on one time line), tags & saved views (also for the Logs tab), bulk actions including tags, JSON/CSV export and an inventory CSV, updates with three strategies (full-upgrade, safe upgrade, security updates only), a changelog and a hold for each pending package, and update rollback if an upgrade goes sideways |
| π Events | Every OpenCanary event across the honeypots you may see, newest first β filter by source address (or a part of it), honeypot, type, country and time, click an address or type to narrow down, export CSV/JSON. Same filters in GET /api/v1/events. Ignored sources (/events/ignored): addresses or networks whose events are expected (a scanner, a monitoring probe) β still stored, but they send no notification and stay out of the dashboard, charts, map and totals |
| πΊοΈ Map | Where honeypot alerts actually come from β a real, pannable/zoomable world coastline with dots sized by event count, plus a top-countries table, company-scoped like the Dashboard. Needs Settings β GeoIP configured first |
| π± Initialize | Turns a blank Raspberry Pi OS/Debian/Ubuntu install into a working honeypot over SSH β auto-detected OS, packages, the OpenCanary service, NetBird, live streamed progress, a persisted run history |
| β±οΈ Scheduling | Cron any action against a honeypot/company/fleet β updates (optionally one honeypot at a time, rebooting only when the update needs it), power, custom commands, on-demand "force a sweep now" debug buttons β each schedule in its own time zone with a live next-runs preview, plus maintenance windows that mute notifications and pause scheduled tasks during planned work (see Notifications) |
| π’ Companies | Each company's own page (users + honeypots), a per-company syslog target for that company's own alerts, plus the "All honeypots" virtual company and its own fleet-wide alert target |
| π Search | One box in the header (press /) finds honeypots by name, address, hostname, tag or company, plus companies, scheduled tasks, your own notification rules and users by name β always within what the account may open. Also GET /api/v1/search?q=
|
π API docs (/api) |
Live Swagger UI over the full read/write REST API β everything the web UI can do, an API can too |
| βοΈ Settings | SSH key rotation, Checks & retention (background-check timeouts/intervals plus every retention policy, database-backed β no restart to change most of it), LDAP/OIDC/syslog/SMTP integrations, VPN (NetBird or WireGuard), GeoIP (a MaxMind-DB-format download source + a manual "Download now"), sign-in policy (session lifetime, lockout, network allowlist) and an encrypted backup & restore of the whole application |
| π Notifications | Self-service, named rules β pick a company or honeypot, which events, email, webhook, push (ntfy, Gotify, Telegram, Discord, Pushover) or team chat (Mattermost, Slack, Teams), and the wording β see Notifications |
Want the granular, paragraph-by-paragraph feature list this page used to carry? That level of detail lives where it belongs β next to the why, split across Architecture and its Authentication & RBAC, Honeypot Management, Audit Log, and Notifications companion pages β so this page stays something you can actually read in one sitting.
-
Who can create a company/honeypot/user? Superadmin only. A company
user (
READ/READ_WRITE) never creates a company or another user β aREAD_WRITEuser does manage the honeypots already in their own company (create/edit/delete, terminal, updates, power). Companies, Users, Settings, and the Audit log stay superadmin-only end to end. In the header they sit together under one Administration menu, with API docs for an account that has API access; the everyday pages (Dashboard, Honeypots, Map, Notifications, Initialize, Scheduling) stay in the bar. - Notifications: self-service, named rules in the nav bar β any user, regardless of access level, creates their own named alert rules, each scoped to a whole company (every honeypot in it, superadmin sees every company) or a single honeypot, by email, webhook, push app or team chat, with independent alert/unavailable/recovered toggles and their own debounce thresholds β plus a "Send test" button and their own notification history. Deliberately much simpler than a role/condition-based rules engine β see Notifications. The three syslog targets (global audit-only, per-company alerts, fleet-wide alerts β see Honeypot Management) remain the "forward to your own SIEM" path, unrelated to this.
- Retention defaults: events, audit log entries, and dashboard trend snapshots all default to 90 days β still adjustable from Settings.
- Impersonate: a superadmin can sign in as any other (non-superadmin) account for support/debugging, from the Users list β see Authentication & RBAC for the safeguards and audit trail.
- GeoIP / Map: an alert's (or a login's) source IP is resolved to a country/city/lat-long once, at write time, from a MaxMind-DB-format database the app downloads itself (never bundled β see Settings β GeoIP) β only ever for a public IP, never a private/internal one. The Map page plots it on a real, pannable/zoomable world coastline (traced from Natural Earth's public-domain land outline, no country borders/labels) plus a top-countries table, company-scoped like the Dashboard; the audit log shows the same resolved country next to each entry's IP. See Honeypot Management.