Secure an Asterisk PBX before adding paid calling

Start with exposure and authority

List every listening service and who actually needs to reach it. Management, SIP signaling, media and application interfaces have different audiences. Restrict management to a controlled administrative path and avoid publishing unrelated services with a broad firewall rule.

Use individual administrative identities where the surrounding platform supports them. Keep handset, trunk and management credentials distinct. A compromised extension should not reveal the credentials used to administer or restore the PBX.

Separate administration, signaling and media

Review the dialplan as a permission system

Check where calls enter and what each context can reach, including included contexts. Carrier-originated traffic should only access intended inbound destinations. Internal users should receive the minimum external calling permissions needed for their role.

Before activating a trunk, test both allowed and denied destinations. Arrange carrier-side spend monitoring or limits where available. These controls reduce financial exposure if a local permission mistake or credential compromise occurs.

Harden the operating workflow

Track Asterisk and operating-system maintenance. Restrict access to configuration, logs, recordings and backups. Remove unnecessary modules and integrations through a documented change process, with awareness that disabling a dependency can interrupt features.

Treat TLS and SRTP as components of a security design, not a label proving complete end-to-end protection. Verify the actual negotiated paths and the behavior of intermediaries.

Rehearse an incident

Write down how to constrain an affected extension, suspend carrier calling and preserve evidence. Keep an alternative communications channel for the response team. Restore exercises should run in isolation so copied credentials cannot create competing registrations. Record what was recovered and what still requires manual reconfiguration.