Prevent · Detect · Contain · Recover

FusionPBX & FreeSWITCH Toll-Fraud Security Monitor

A fail-closed operations platform for telephony security — not a public dashboard. It connects live ESL events to operator evidence, least-privilege containment, and controlled recovery on 127.0.0.1:8099.

For hosted-PBX operators, security teams and on-call engineers who need detection, lockdown and unlock runbooks — not another Grafana wallpaper.

Productized case-study delivery Scope-based estimator BYOC · Twilio · Telnyx · Sinch
Configure & request quote View case study Talk to architecture

Problems we solve

When outbound fraud and recovery are split across logs, firewalls and memory, teams typically hit:

  • Compromised SIP credentials become a stream of chargeable outbound calls
  • Detection lives in FreeSWITCH logs; containment lives in someone’s memory
  • Firewall changes happen after the bill, not during the incident
  • No durable incident record before someone hangs up channels
  • Application given root on the switch to “just block the gateway”
  • Unlock silently re-enables billing paths
  • Inbound traffic false-positives lock the wrong carrier
  • Operators need a readable email, not a JSON dump at 3am

One platform: CHANNEL_CREATE outbound → ESL normalize → Redis windows → fraud_incident row → broker lockdown → operator HTML email → two-step unlock (carrier re-enable separate)

Detect & explain

  • ESL normalization of outbound channel events
  • Redis velocity / concurrency / distinct-destination windows
  • Deterministic rules with named reasons and score cap 100
  • PostgreSQL security_event and fraud_incident audit
  • GET /health: policy version, ESL heartbeat, broker status
  • Honest: top-level ok is not a substitute for action_broker_ok

Contain & recover

  • Incident created before broker actions
  • Allowlisted commands only: reject, hangup, block IP, quarantine, lockdown
  • Least-privilege broker — not application root
  • Critical HTML + plain-text operator email with first-response checklist
  • Localhost POST lockdown / unlock with confirm=UNLOCK
  • Carrier reactivation is a separate gated procedure

Platform architecture

flowchart TB
  Prevent[Prevent: SIP ACL Lua dialplan] --> FS[FreeSWITCH ESL]
  FS --> Nest[NestJS orchestrator]
  Nest --> Redis[(Redis windows)]
  Nest --> PG[(PostgreSQL audit)]
  Nest --> Broker[Allowlisted broker]
  Nest --> Email[Operator HTML email]
  API[127.0.0.1:8099] --> Broker

Deployment: Cloud · VPS · On-premises · BYOC · Twilio · Telnyx · Sinch

Proven case study

This product is a productized delivery of the documented engineering case study — evidence stays on this page so you do not have to guess what was shipped.

  • Four sanitized evidence reconstructions (architecture, alert email, health JSON, unlock API)
  • July 2026 fail-closed MVP notes; August inbound UAT after a false-positive fix
  • Jest coverage referenced on the case study
  • No invented attack-volume or SMTP delivery SLAs
Prevent Detect Contain Recover architecture with validation timeline
Four layers with explicit boundaries.
Sanitized critical PBX security alert email with evidence table
Operator frontend is email — severity, evidence, localhost commands.
Sanitized GET health and risk-score JSON on localhost 8099
Heartbeat age and broker status — inspect both.
Incidents list and two-step unlock preflight API
Unlock requires incident UUID, reason and confirm=UNLOCK.

Full case study with video and FAQ →

Configure this scope & send RFQ →

Built for

Hosted PBX operators

Contain fraud without handing the app general root.

Security / on-call

Readable critical email with a first-response checklist.

FusionPBX admins

ESL rules plus independent Lua/ACL prevention.

MSPs

Per-instance monitor in the estimator — not a public GUI.

Integrated vs fragmented stack

Traditional setupThis product direction
Find fraud in the carrier invoiceESL + Redis windows while the call is still happening
SSH and iptables from memoryIncident row first, then allowlisted broker actions
App has root on FreeSWITCHLeast-privilege broker allowlist
Unlock reopens the gatewayUnlock clears lockdown; carrier re-enable is gated separately

Outcomes

Unifies alerting, explainable rules, durable PostgreSQL incidents and recovery that does not silently reopen billing. Call-path prevention (digest, ACL, Lua) stays independent if ESL, Redis or Postgres fail.

Deployment & carriers

  • Managed VPS — operate on your cloud account with runbooks.
  • Your cloud — AWS/GCP/Azure; you own the account.
  • On-premises — regulated or air-gapped cores (quote adjusted).
  • BYOC / own SIP — your carrier contract or trunks on the PBX we deploy.
  • Twilio / Telnyx / Sinch — CPaaS pass-through shown in the estimator (planning only).

Estimates are scope-based planning figures — not binding quotes. Taxes, carrier deposits, DIDs and third-party AI usage are scoped in discovery.

Frequently asked questions

Does this replace SIP authentication and firewalls?

No. Digest auth, ACL and Lua/dialplan guards stay independent of monitor health.

Is the API on the public internet?

Not in this design — bind 127.0.0.1:8099. Remote exposure needs a separate security design.

Does unlock re-enable outbound gateways?

No. Unlock clears lockdown after preflight and confirm; carrier reactivation is a separate procedure.

Do you claim fraud-savings metrics?

No. The case study does not invent attack volume or SMTP delivery stats.

Can you implement this on our FusionPBX?

Yes — ESL rules, broker containment and runbooks scoped to your carriers.

How many instances?

Per-instance pricing in the quote builder.

Production SMTP?

Optional requirement — outbox exists; production delivery is scoped.

BYOC only?

This product is BYOC / own SIP — CPaaS pass-through is not the fraud path.

Requirements

Request formal quote