> For the complete documentation index, see [llms.txt](https://docs.layeronecloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.layeronecloud.com/network-monitor/security.md). # Security management connection to a Proxmox node. * Sensor connections are outbound-only. The central server never opens a management connection to a Proxmox node. * Agent API keys are random and host-scoped. They are shown only when created or rotated; Django stores a SHA-256 digest and a short non-secret display prefix. * The key is read from `/etc/l1-monitor/agent.key`, owned by `root:l1-monitor` with mode `0640`. It is sent only in the HTTPS Authorization header and is never accepted in a URL, command-line option, telemetry body, or log field. * Rotation immediately invalidates the previous key. Revoking an agent rejects its key without deleting historical measurements. * Desired configuration is declarative. It contains interface names, LAN/WAN roles, optional detection settings, collection intervals, and at most 128 site-owned application-boundary CIDRs, never executable paths or commands. Application CIDRs are independent of DDoS protected targets. * The sensor runs with `NoNewPrivileges`, `CAP_NET_RAW`, a read-only filesystem, a private temporary directory, and access only to its state directory. * Continuous port discovery is active, not passive: the hypervisor probes all TCP and UDP ports on current running guests assigned to that node in the cached Pulsar inventory. The source is bound to the WAN IP-owning interface and revalidated locally. Plans cannot contain commands, ranges or arbitrary observed peers. Nmap service identification probes confirmed open ports; no vulnerability, brute-force or operating-system scan is requested. Only bounded service/product/version labels and open-port evidence are uploaded, not raw banners or script output. Probes can appear in guest logs and firewall counters; this view describes reachability from the hypervisor, not a promise of reachability from the public Internet. * Port scanning runs in a separate, low-priority systemd service with one logical CPU of aggregate quota, 512 MiB maximum memory, no swap, and 64 tasks. Missing or relaxed cgroup v2 limits prevent scanning. Hosts become eligible for refresh hourly, but running scans have no elapsed-time cutoff. Host pressure defers new work and stops active probes; those resource limits do not apply to normal capture or telemetry. Neither a pressure pause nor a killed scanner implies closed ports. * DDoS detection is observational. Neither the sensor nor the control plane modifies nftables, iptables, routing, or provider ACLs, and the sensor is not granted `CAP_NET_ADMIN`. Future automated mitigation must be implemented as a separately authorized action with an auditable rule lifecycle and must not turn unverified or low-coverage source estimates directly into permanent blocks. * Packet payload is normally held only long enough for bounded metadata parsing. The application inspector retains at most the first 4 KiB of client-flow data in bounded memory to recognize TLS SNI, HTTP Host, or CONNECT targets; the DNS parser separately retains matched A, AAAA, and CNAME answers until their TTL. A pinned Public Suffix List reduces hostnames to registrable domains on the sensor before spooling; full hostnames and inspected payload bytes are not included in normal telemetry. The control plane repeats that reduction with its own pinned, offline Public Suffix List. If the sensor knows a suffix newer than the server's list, the server conservatively keeps only the final two labels rather than rejecting the entire minute; suffix-only values are still rejected. When no domain is known, telemetry contains a canonical remote IP and server port. QUIC content is not decrypted; only separately observed DNS evidence may name a QUIC destination. Application telemetry additionally contains canonical client/service IP pairs and minute byte totals for retained TCP/UDP flows. The control plane keeps this pair detail in separate tables with a 24-hour API cutoff and hourly expiration cleanup (physical deletion can lag by up to one maintenance interval). Late telemetry cannot restore expired pairs. Application totals retain their existing policy. Source/client and destination/service roles are inferred from observed flows; port labels alone do not prove a particular product or login. When an operator enables DDoS evidence capture for a capture domain, the sensor keeps a protected 30-second rolling buffer and preserves at most the first 256 bytes of matching frames. Those bytes can include initial payload after the transport headers. * Evidence is capped at 250 MiB or ten minutes per incident and 1 GiB per sensor. Completed chunks use checksum-bound, short-lived uploads to a private, server-side-encrypted S3-compatible bucket and expire after seven days. * Only configuration administrators may obtain 60-second evidence download URLs. Every download request is audited; read-only operators can view only incident metadata. * Operator login requires a password followed by TOTP or a one-time recovery code. An active operator without TOTP is guided through enrollment after their password is accepted. The setup secret is encrypted at rest, and the one-time recovery codes are shown once and stored only as salted hashes. * The Twilio Auth Token is entered in the console and stored Fernet-encrypted; only a four-character suffix is displayed. The Account SID, caller ID, and on-call numbers are ordinary configuration and are shown in full. * Call webhooks are unauthenticated by necessity, so each one verifies Twilio's HMAC-SHA1 request signature against the stored Auth Token and the callback URL built from `L1_PUBLIC_URL`. An unsigned or mis-signed callback is refused, and the identifier in the URL is an unguessable per-call UUID. * Acknowledging by phone or text records the number; acknowledging in the console records the operator. Read-only operators can see alerts but cannot change alerting, add on-call numbers, place test calls, or acknowledge. * The inbound message webhook is the one alerting endpoint an arbitrary sender can reach, because anyone can text the Twilio number. A message from a number that is not a configured on-call recipient is answered with nothing at all, so it can neither acknowledge an alert nor be used to bill outbound replies. * Texting is refused until Twilio confirms the caller ID is a number the account owns and can send messages from. Changing the account or caller ID discards that confirmation, so a new sender must be re-tested before it can text. * Pulsar's VM destroy notice is the only inbound Pulsar endpoint; every other exchange is outbound under the Admin API token. It is unauthenticated by necessity like the Twilio callbacks, so it verifies an HMAC-SHA256 signature over `"." + raw body` against a separate Fernet-encrypted signing secret before reading anything in the body. The secret is generated by the console rather than typed, shown once, and never readable back. A timestamp more than five minutes from the server's clock is refused, so a captured notice cannot be replayed against a guest that has since been rebuilt. What a valid notice can do is bounded: it retires inventory, releases address claims and archives devices, and it deletes nothing. A device that is observed again afterwards comes back, so a forged notice could at worst hide a running guest from the console until its next packet. * Django's password-only administration route is not exposed; operator and agent-key lifecycle changes use the application UI or management commands. * LayerOne Aegis telemetry is an outbound server-to-server integration using the existing encrypted Operations Admin API credential. Fresh authorized IP allocation generations select the exact source address and minimum observation time; only mapped clusters are eligible. The receiver independently rechecks current ownership and rejects changed generations and ambiguous sources. Queries never export site/interface totals or share a device-MAC aggregate between customer addresses. Application direction must identify the assigned IP as the local endpoint; only application names, byte totals, and negotiated transport/service-port identities leave the monitor, without remote IPs, domains, packet evidence, or other clients' rows. Application lifetimes follow the last outbound observation on that assigned IP and service port, expiring after 24 hours; inbound probes and delivery times cannot renew them. Customer browsers continue to authenticate exclusively to Operations. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.layeronecloud.com/network-monitor/security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.