TELIPHONES

Security / Controls and evidence

Narrow access.
Explicit limits.

An encrypted connection is a starting point, not the whole security model. Identity, approved services, local authority and verified cleanup each have a separate job.

Authentication says who.
Authorisation says what.

Installing or enabling TELIPHONES grants no remote access. A full FreePBX administrator must approve a workstation request over HTTPS. The page and action endpoints require full-administrator permission, CSRF validation and a fixed action allow-list.

WireGuard authenticates the network peer but does not admit a management session. The root broker atomically grants a short-lived lease, accepts heartbeats and enforces the configured occupancy limit (default one) in firewall policy. Abandoned leases expire; restart recovery reconstructs admission state. A rejected workstation can complete tunnel authentication but cannot reach management services.

Managed SSH separately requires the enrolled signing identity, an approved existing account, a fresh certificate and pinned host/CA checks. Web access still requires normal FreePBX sign-in. Approval binds a key, address, service set and lifetime; it is not a general trusted-network exception. External support components cannot create or extend the PBX's authority.

Private keys stay
with their originating device.

WireGuard encrypts workstation-to-PBX traffic and authenticates peers by public key. Windows stores its WireGuard private key in Windows Credential Manager; the PBX's own key is root-only on the PBX. Pairing exchanges public information and request bindings, not private keys.

The workstation gets only the PBX tunnel /32 route. Forwarding to other networks is dropped. Workstation and Remote Support traffic use different interfaces and address ranges.

Distinct key roles in managed My PBXs SSH.
MaterialPurpose and handling
WireGuard identityAuthenticates the network peer; Windows Credential Manager holds its private key.
Permanent workstation SSH identityDPAPI-encrypted on Windows; signs authenticated certificate requests, not used as a session certificate subject.
Ephemeral session keyFresh in-memory signing capability for a launch, process-bound and destroyed after one authentication signature.
PBX CA and host identityRoot-controlled on the PBX; public identities are pinned during trusted pairing.
Certificate and known-host dataPublic runtime material. Deleting these files is cleanup, not private-key destruction.

A certificate for a different key.
Not a reusable administrator secret.

For each managed SSH launch, Windows creates an ephemeral key distinct from the permanent workstation identity. The permanent identity signs a one-use challenge, fresh session ID and ephemeral public key using the request/2 protocol. WireGuard membership alone is not enough.

The PBX verifies that signature and issues a certificate bound to the session key, source address and expected principal. It lasts at most 300 seconds, capped by the original pairing expiry. Windows checks the bindings and independently verifies the CA signature before launching OpenSSH.

A private named-pipe agent accepts only the owned SSH process and signs once for the exact account/certificate, then clears its disposable signing capability. No session private key is exported to a file, command line, log or shared system agent.

Strict pinned host checking and certificate-only authentication are mandatory. Unsupported existing account, Match, multi-factor or forced-command policies fail closed rather than being weakened. System SSH configuration and unrelated sessions are not intentionally changed.

The application owns its console/helper/SSH Job. Disconnect or local authorisation expiry terminates that owned process group. This is separate from the PBX's own per-workstation systemd/cgroup lifecycle.

Locked memory and process-access restrictions do not defend against a compromised OS, administrators/debug privileges or already privileged handles. Logical key destruction does not guarantee erasure of every library/OS copy, paging file, dump or storage block.

A fixed privileged interface.

The web application runs as asterisk. A root bootstrap stages trusted module code into a root-owned location and installs the broker and helper services. The broker listens on a restricted local Unix socket and checks the caller's user ID.

The browser cannot supply arbitrary shell commands or paths. It can ask for fixed operations such as pairing, revocation and status. Dependency installation is limited to wireguard-tools after approval, from the configured Debian repositories.

This boundary still trusts FreePBX application integrity: code running as the FreePBX service account can use the broker as that account. It is not containment for an already compromised web application.

Verify policy.
Then admit the peer.

The broker validates the complete owned inet teliphones_workstations nftables policy before admission. Its ownership marker is the hookless teliphones_owner_v1 chain, not a table comment that Debian 12 readback may omit.

Both enforcement layers restrict approved management TCP ports to authorised peers at the PBX tunnel address. Defaults are 80/443; configured alternatives include 8080/8443. Managed SSH-approved peers additionally receive the WireGuard-bound certificate API on TCP 8765 and only their dedicated 22000 + IPv4 last octet listener. For Locked pairings, protocol 9 binds those services to the dedicated tunnel interface and address. New managed pairings do not receive ordinary TCP 22; legacy version-1 SSH-approved pairings retain it. SIP, RTP, AMI, databases, forwarding and IPv6 are not workstation service grants.

Locked pairings use a unique WireGuard interface, tunnel subnet and UDP port. The source allowlist is enforced before WireGuard admission with an explicit drop for all other public sources on that port. The peer key is excluded from the shared listener, so that listener cannot bypass the lock. Allowed entries may be IPv4/IPv6 addresses, CIDRs or domains; DNS failure denies the failed name rather than retaining stale permissions or broadening access. Unlocked pairings continue to use the shared roaming listener. Windows Allowed List and unlock requests travel through the admitted, identity-bound control channel and do not relax policy before explicit FreePBX administrator approval.

Listener migration revokes the management lease, leaves only the session-control path on the old listener and retires it after the same WireGuard identity acknowledges the new configuration. A stale tunnel cannot use an obsolete shared listener to reach management services. This protocol is covered by local broker regression tests; native Windows and live firewall acceptance remain outstanding.

The marked jump belongs inside fpbxfirewall, after recognised direct INPUT Fail2Ban hooks. It is not interface-filtered so dedicated interfaces can use the same hook; every ACCEPT in the owned chain is restricted by exact interface, peer and PBX addresses, and port. FreePBX owns generated listener-zone rules; the broker does not compete with it or place rules above its INPUT hook.

UDP reachability does not trust a public IP or grant web/SSH access. WireGuard cryptographically authenticates paired devices; management permissions remain peer-specific. Reject zones, blacklists, Fail2Ban and normal FreePBX authentication are preserved. An arbitrary SSH key is not a pairing or an approved certificate identity.

Atomic ownership records precede service mutations, permit interrupted-operation recovery and remain until deletion is verified. Read-only inspection checks generated IPv4 service/zone rules; it does not prove every earlier packet-path decision. Stable reconciliation avoids rule changes, and transient errors disable tunnel access and retry. The nft monitor and periodic checks provide detection and recovery, not a guaranteed deadline.

No Custom Rules enablement or firewall disablement is required. Local namespace packet tests exercise the allowed/denied listener sources and dedicated interface service filtering, but do not validate real WireGuard authentication or a live FreePBX installation. External privileged flushes or reordered Fail2Ban hooks may create a gap before detection; the system does not promise zero exposure.

Historical findings, ownership and read-only acceptance checks ↗

Expiry is not one single event.

Certificate expiry

Refuses new SSH authentication. It does not kill an existing authenticated shell. A persistent pairing's established session may outlive the five-minute certificate.

Authorisation expiry or revoke

Ends the pairing's authority. Owned PBX services/processes must be stopped and cleanup verified; this real systemd/cgroup behaviour still needs full validation.

Temporary pairing deadlines are absolute and never renewed by reconnect or broker restart. Persistent pairings remain valid until revoked. Removing a local Windows profile or closing a terminal does not revoke the PBX approval.

There is no server-pushed revocation channel. Windows reachability checks can lag, or an established flow may remain reachable. A client display or closed terminal is not proof that the server cgroup is empty.

Do not turn failure
into apparent success.

Unverifiable enforcement prevents admission. A namesake table without exact recognised ownership is not overwritten. If the interface cannot be disabled or removed, restrictive policy and recovery information are retained rather than discarded.

Monitor failure is reported and triggers an attempt to disable access. Cleanup/uninstall errors abort with recovery state. Missing FreePBX hooks or unsafe ordering produce an integration status, not a blanket ACCEPT rule.

These are implemented controls with local failure-injection tests. They do not establish that every platform fault or competing privileged manager is contained. Never resolve a conflict by flushing unrelated rules or loosening file/socket permissions.

What has been shown.
What has not.

Local development baseline: 4 November 2026. Earlier native/live observations remain distinct; no external evidence was fetched for this website.

Implemented, locally tested and observed on a real system are separate.
EvidenceResultBoundary
FreePBX modulePHP/module and JavaScript regression tests passed.Models the FreePBX API and framework; this is not genuine PBX execution.
Gateway suite184 tests: 183 passed, one skipped because wg is unavailable.Includes Linux OpenSSH and simulated FreePBX packet tests; systemd/cgroups are substituted.
Windows portable buildAll eight portable CTest groups passed, including credential crypto and layout checks.Does not compile or execute native MFC/Win32 UI, service, installer or WireGuard integration.
0.6.0 packageCurrent module archive and checksum rebuilt and passed local package validation.Extraction, metadata, source equality and integrity do not prove installation on FreePBX or public availability.
Firewall packet labsBoth iptables backends passed. The source-lock lab checks allowed/denied UDP sources and dedicated-interface TCP service filtering.FreePBX API/daemon and WireGuard identity are models. Packet tests do not establish authenticated WireGuard roaming or a live PBX.
Earlier native/live observationsOperator reported ten native SSH tests passing and Windows 0.7.0 SSH into FreePBX 17 with module 0.4.0; owned terminal closed on disconnect.No independent run evidence fetched here. These observations do not validate the current 0.6.0/0.8.0 changes.
Production readinessNot established.Real WireGuard roaming, watchdog behaviour, Apache/TLS custom ports, systemd lifecycle/recovery and native Windows execution remain outstanding.

The 0.6.0 package is a locally validated experimental test installation. Full revocation/expiry, reboot, upgrade/rollback/uninstall, unrelated-service preservation and end-to-end Remote Support still require representative acceptance testing.

What TELIPHONES does not do.

  • It does not replace FreePBX Firewall or automatically close public management ports.
  • It does not provide a relay, universal NAT traversal or hosted Connect/Checker/Console service.
  • Workstation WireGuard tunnel addresses are IPv4; IPv6 addresses, CIDRs and DNS results may still appear in public-source allowlists. Other desktop operating systems are not supported.
  • It does not protect against a compromised root account, authorised workstation or OS.
  • It does not guarantee protection from another root process flushing the firewall.
  • It does not inspect every possible nested/alternative Fail2Ban layout.
  • It does not make an unsafe existing account privilege model safe.
  • It has no claimed independent audit or production-security certification.

Use a disposable test PBX and retain independent console access. Normal SIP/RTP and unrelated management traffic require explicit acceptance testing during connection, rebuild, revocation and uninstall.

Security concerns deserve
a private channel.

Report suspected vulnerabilities privately through FreePBX UK support, not a public issue. Include versions, workflow, sanitised errors and reproduction steps. Do not include private keys, credentials, complete pairing strings or grants.

Collect useful, limited diagnostics →