Docs Reference
Security
How Lantern protects your devices, your credentials and your sign-ins, and what is still open in the preview.
Read-only to your devices
- The SNMP collector sends only GET, GETNEXT and GETBULK. The SNMP interface every collector and monitor uses has no SET at all.
- An automated test inspects the source and fails if any code adds an SNMP SET or an HTTP write to a device or controller. The only outbound HTTP writes allowed are notifications to webhooks an administrator configures and the OpenID Connect token exchange with the identity provider an administrator configures.
- SSH sessions are opened and typed by a technician. Lantern relays and records them and never sends commands of its own.
Credentials
- SNMP communities and passphrases in
snmp.json, LDAP and cloud sign-in secrets, and notification passwords are encrypted with AES-256-GCM. Each key is a separate file in the data folder (credentials.key,auth.key,monitoring.key), so a copied configuration file or database alone does not reveal secrets. - Secrets are never sent back to the browser: the settings pages show only whether one is saved.
- Device passwords for SSH sessions are typed in the terminal, used for that one login, and never stored or logged. Recordings are redacted.
Sign-in
- Every API request needs a signed-in session; the server checks the person's role on each request.
- Local passwords are stored as bcrypt hashes and must be at least 12 characters.
- Failed sign-ins are throttled per address and per username, and the message never says whether the username exists.
- Directory and cloud passwords never reach Lantern's storage. Cloud sign-in uses the authorization code flow with PKCE and a nonce, and the ID token's signature, issuer, audience and expiry are verified.
- The first administrator can only be created from the collector machine itself, or with a one-time setup token from it.
- Every sign-in, failure and settings change is recorded in the sign-in activity log.
The web UI
- A strict Content Security Policy: Lantern's pages load only Lantern's own scripts, styles and fonts, with nothing from other sites.
- Changes must come from Lantern's own pages (same origin, JSON requests), so another web page cannot drive Lantern through a technician's browser.
- Lantern answers only to its IP addresses,
localhostand the names you list with-hosts, which blocks DNS rebinding. - Pages cannot be framed, and session cookies are HttpOnly, SameSite=Lax, and Secure over HTTPS.
Where your data is
Everything stays on the collector machine, in its data folder. Lantern has no cloud service and sends nothing to us. The only outbound connections are to your devices, your identity provider (cloud sign-in only), your directory (LDAP only), and the email server or webhooks you configure for notifications.
Open items in the preview
| Item | Status |
|---|---|
| Builds and scripts are not code-signed | Verify downloads against the published SHA-256 checksums. Signing comes with the release. |
| Multi-factor authentication | Use cloud sign-in to get your identity provider's MFA. Local and LDAP accounts use a password only. |
| Cloud sign-in is new | It has been tested against Lantern's own OpenID Connect test provider; validation against real Entra ID, Google Workspace and Okta tenants continues. Keep a local administrator account. |
| Encryption keys sit on the same disk as the data | Protect the collector machine and its backups accordingly. |
| SSH host keys are trusted on first use | A changed host key is not yet flagged. |
| Change history is in memory | Snapshots start again when Lantern restarts. |