Webserver-Front (DMZ Replica)

Webserver-Front is a read-only replica of the Mugnsoft Webserver designed to be exposed in a DMZ or to untrusted networks. It serves the dashboards and reports to end users without exposing the internal control plane, the probes, or any credentials.

Overview

Property	Value
Role	Read-only DMZ replica of the Webserver UI
Build	`go build -tags front` (the `front` build tag)
License	None required — fed entirely by the licensed ADMIN
Data source	One-way encrypted push from the ADMIN Webserver
Static assets	Served from disk (`./web-front/`), not embedded
Listens on	Web UI on the WEB port, replication receiver (mTLS) on the API port

Throughout this page, ADMIN is the normal (licensed, internal) Webserver and FRONT is the front-tagged replica.

Why a separate replica? The ADMIN Webserver holds secrets (probe addresses, integration tokens, Vault credentials) and can reach every internal component. Exposing it directly to the internet is a large attack surface. FRONT receives only a sanitized, read-only copy of the data needed to render dashboards — and has no network path back to ADMIN or the probes.

Webserver-Front read-only dashboard with replication freshness indicator

Architecture

   INTERNAL NETWORK                     DMZ / UNTRUSTED
 ┌──────────────────┐                ┌──────────────────────┐
 │  ADMIN Webserver │                │   FRONT (replica)    │
 │  (licensed)      │                │   (no license)       │
 │                  │  mTLS + JWT +  │                      │
 │  replication ────┼──  AES-GCM  ──►│  /replicate receiver │
 │  pump            │   one-way push │        │             │
 │                  │                │        ▼             │
 │  probes ◄────────┤                │   local KV + disk    │
 │  integrators     │                │        │             │
 └──────────────────┘                │        ▼             │
                                     │   read-only Web UI ──┼──► end users
                                     └──────────────────────┘

ADMIN always initiates the connection and pushes. FRONT never opens a socket toward ADMIN or any internal component. If FRONT is compromised, the attacker gains a read-only dataset and no route inward.

Security model

Every /replicate request must pass three independent layers before a single byte is written to FRONT:

Layer	Mechanism
1. mTLS	The receiver requires a CA-verified client certificate (`RequireAndVerifyClientCert`). A peer without a certificate signed by the replication CA never reaches the handler.
2. JWT	A revocable RS256 component token, signed by ADMIN’s dedicated replication key and verified against `ReplPubKey`. This keypair is separate from the user-login keypair.
3. AES-GCM	The payload itself is encrypted and authenticated with the shared `ReplKey`. A wrong key or any tampering fails the GCM tag and the batch is rejected.

The web UI served to end users runs under ordinary server TLS; only the replication receiver enforces mutual TLS.

What is replicated

FRONT receives a whitelist of data — only what the dashboards need:

Category	Buckets / data
Applications	`app_data`, `status_change`, `sla_monthly`, `bRule_change`
Monitor status	`url`, `api`, `tcp`, `udp`, `ping`, `nslookup`, `db`, `snmp`, `wmi`, `sys`, `tag`, `disabled_state`
Users	`user` (replicated verbatim — FRONT needs the bcrypt hash to authenticate logins; user records carry no probe addresses)
Components	`server` (sanitized — only name, type, status)
Hosts / devices	`host`, `snmp_device`, `wmi_device` (device + status)
Discovery	`hist`, `alerts`, `status`, `change`
Metrics	`cpu`, `loadavg`, `memory`, `uptime`
Files	Discovery topology files under `./discovery/*` (read from disk by the UI)

What is never replicated

The setting, apiKeys, jwt, and integrator-configuration buckets stay on ADMIN.
Sensitive JSON fields are stripped from every value before it leaves ADMIN: tokens, passwords, secrets, API keys, Vault tokens, LDAP bind passwords, private keys — and anything that could carry an internal endpoint (ip, port, sched, endpoint, integratorEndpoint).

Live monitor types show as UNKNOWN on FRONT. The Webserver is a real-time proxy: for url, api, tcp, udp, ping, nslookup, db, and sys monitors it fetches the current status live from the probe on each request (see Platform Overview). Those types have no persisted per-item status to replicate, so they appear as UNKNOWN in FRONT’s application-dependency graph. Device and discovery status are persisted and replicated, and display normally.

FRONT application-dependency graph showing live monitor types as UNKNOWN

Replication mechanisms

ADMIN pushes data two ways, both fire-and-forget through a disk-backed retry buffer so ADMIN never blocks on FRONT:

Mechanism	Description
Periodic reconcile	A full snapshot of the whitelisted buckets (+ discovery files) every `FrontReconcileMins` minutes (default `5`). This alone keeps FRONT correct and self-heals any missed update.
On-change push	An optional low-latency push wired at a few high-value status-update sites, for near-real-time updates between reconciles.

If a push fails (FRONT briefly unreachable), it is persisted to a disk-backed buffer and retried by a background worker, so a transient outage never loses data. FRONT also self-tunes a staleness indicator: the reconcile cadence is stamped on every batch, and FRONT flags the feed as stale if no batch arrives within a multiple of that interval.

Status grace period

By default FRONT shows status changes as soon as they replicate. Optionally, FrontGracePeriodMins (default 0 = off) delays a non-OK application status from reaching FRONT’s end users for a configurable window after a fresh OK → non-OK transition. This gives operations teams a few minutes to react before the outage becomes visible on the public dashboard.

The grace period affects only the FRONT-bound snapshots. ADMIN’s own real-time views, status history, SLA calculations, and alerting are never delayed.

Configuration

Replication material is provisioned out-of-band in webserver.json on both hosts — it never travels over the replication channel or the Settings UI.

On ADMIN

{
  "FrontEnabled": "true",
  "FrontEndpoint": "front-host:8050",
  "FrontReconcileMins": "5",
  "FrontGracePeriodMins": "0",
  "ReplKey": "<hex AES-256 key>",
  "ReplClientCert": "<PEM client cert presented to FRONT>",
  "ReplClientKey": "<PEM client key>",
  "ReplCACert": "<PEM CA verifying FRONT's server cert>",
  "ReplSignKey": "<PEM RSA private key signing /replicate tokens>",
  "ReplPubKey": "<PEM RSA public key>"
}

If exposed in the ADMIN Settings UI, the operational fields can also be managed there:

ADMIN Settings: Webserver-Front replication configuration

On FRONT

{
  "ReplKey": "<same hex AES-256 key as ADMIN>",
  "ReplCACert": "<PEM CA verifying ADMIN's client cert>",
  "ReplPubKey": "<same PEM RSA public key as ADMIN>"
}

Field	Side	Description	Default
`FrontEnabled`	ADMIN	`"true"` to push to FRONT	`""`
`FrontEndpoint`	ADMIN	FRONT host:port (replication receiver)	`""`
`FrontReconcileMins`	ADMIN	Full-snapshot cadence in minutes	`5`
`FrontGracePeriodMins`	ADMIN	Delay non-OK app status to FRONT (minutes)	`0` (off)
`ReplKey`	both	Shared hex AES-256 key for payload encryption	required
`ReplClientCert` / `ReplClientKey`	ADMIN	TLS client cert/key presented to FRONT	required
`ReplCACert`	both	CA verifying the peer	required
`ReplSignKey`	ADMIN	RSA private key signing `/replicate` tokens	required
`ReplPubKey`	both	RSA public key verifying `/replicate` tokens	required

Boot warning: if ReplPubKey is missing on FRONT, the receiver rejects every request and ADMIN pushes fail silently — FRONT logs a loud warning at startup so the misconfiguration is caught early.

What FRONT does not run

The front build deliberately starts none of ADMIN’s outbound or control subsystems. It runs only the replication receiver (mTLS, API port), the read-only web UI (WEB port), and a local retention purge. It does not start:

probe status pumps or component token resync
the replication pump (that is ADMIN-only)
LDAP, SMTP, or integrator-outbound
license validation (FRONT carries no license)

Building Webserver-Front

# Linux DMZ host
GOOS=linux GOARCH=amd64 go build -tags front -o webserver_front

# Windows
go build -tags front -o webserver_front.exe

The static UI assets are served from ./web-front/ on disk and are not embedded in the binary — update them in place on the FRONT host.