SENTRADOCSSign in

Service hardening and network exposure

How SENTRA's own services run with the least privilege and the smallest network exposure.

Least-privilege services#

Service Hardening
Licensing Authority Own system user without a login shell; code owned by root and read-only to the service; data folder readable only by the service; listens on 127.0.0.1 only; systemd sandbox: no capabilities, NoNewPrivileges, read-only system (ProtectSystem=strict), private /tmp and devices, kernel and control-group protection, restricted address families and namespaces, a system-call filter that forbids privileged calls, private umask, no core dumps
Release builder Its own unprivileged user; can write only its work folder; can't read the vault; runs product tests with a temporary home folder and a minimal environment; never signs
Release server Static files only, on 127.0.0.1, behind SENTRA AI Threat Shield; only the release paths answer, everything else is 404
SENTRA AI Threat Shield Runs as its own service user under systemd with NoNewPrivileges and ProtectSystem=strict, holding only the capability it needs to bind web ports

Web hardening of the Licensing Authority#

  • Strict Content-Security-Policy (no inline scripts or styles), HSTS with preload, X-Frame-Options: DENY, nosniff, no referrer, cross-origin isolation headers, a restrictive permissions policy, noindex.
  • API answers are never cached; request bodies are size-limited; the whole service is rate-limited per address.
  • An optional allow-list restricts the console to listed networks (the system API stays reachable for check-ins).

Network exposure#

Public name Served by Behind
licensing.sentra-ai.com Licensing Authority on 127.0.0.1:8640 SENTRA AI Threat Shield (TLS, inspection, automatic bans)
updates.sentra-ai.com Release server on 127.0.0.1:8641 SENTRA AI Threat Shield

Neither service is reachable directly from the internet. SENTRA's own public services are protected by the same product SENTRA sells.