VICIdial hardening priorities and their limits

Begin with an auditable threat boundary

List each exposed Admin, Agent, API, report and recording URL. For each one, test an account that should be allowed and one that should be denied; record the result before changing access rules.

Fast answer: start where a dialer actually gets attacked, which is the ports it exposes to the Internet and whether it accepts anonymous SIP calls, then work up through least-privilege accounts, tested two-factor authentication (2FA), verified route-level Internet Protocol (IP) controls, protected secrets and audit review. Hardening is a staged program, not a checkbox or a promise of security.

An Internet-facing Asterisk server is scanned continuously. The two failures that cost real money are toll fraud, where an attacker places calls through your trunk at your expense, and an exposed management port such as the Asterisk Manager Interface (AMI) on 5038 or the MariaDB database on 3306. Both are network problems before they are application problems, which is why the firewall comes before the admin settings.

An API is an application programming interface; a route is one web, report, media or API entry point. This lab's Admin showed 2FA and IP-list settings present; both 2FA validity-hour settings were at zero at the time of writing — confirm yours. Treat that as an environment observation, not a statement about your deployment.

Terms are defined in VICIdial terminology for complete beginners: users, phones, campaigns and leads.

• Before changing access, identify who can restore the server and confirm that a console connection works independently of SSH.
• Non-goal: do not claim certification, compliance or immunity from attack after these checks.
• Identify admin, agent, report, API, media and integration entry points.
• Record the installed revision and which test routes currently allow or deny access; omit addresses and credentials from the record.

Roll out 2FA with recovery tested first

The official feature supports admin and agent 2FA with configured email, phone-call or SMS delivery, system-level validity hours and per-user override. Delivery channels introduce operational dependencies: sender reputation, message latency, clock synchronization, attempt limits and account recovery all need testing.

Use this synthetic-cohort scorecard in a change record. PASS means every stated test succeeded for the test account; BLOCK means do not extend enforcement. The placeholders <TEST_ADMIN_USER> and <TEST_AGENT_USER> are labels only, never real user names or phone numbers.

Create a small test cohort and a documented break-glass process held outside the normal account path. Do not put SMS URLs, provider tokens, phone numbers or authorization codes in configuration exports, tickets or this publication.

<TEST_ADMIN_USER>: expiration PASS / recovery PASS / lockout PASS<TEST_AGENT_USER>: delivery PASS / logout PASS / recovery PASSBREAK-GLASS: independently tested PASSRESULT: BLOCK if any required test is not PASS

• With a test account, try an expired code, repeated invalid codes, logout, account recovery and an unavailable delivery method; record each result.
• List the test users with per-user overrides, compare each override with the intended access, and remove only overrides confirmed unnecessary.
• Test account recovery through the documented console or recovery account without disabling access controls for all users.

Verify IP controls on every sensitive route

IP lists are an administrative capability, not evidence that every web, report, API, media or integration route enforces the intended allow/deny policy. Build a route inventory and test each route from an allowed and a denied, controlled test network.

Two controls do most of the work here, and neither lives in the VICIdial web interface. On a ViciBox install the host firewall is firewalld, not ufw: its external zone allows only a short list of named services — the web server, SSH, RTP audio and an asterisk service — and only from source addresses in ipsets that are loaded at runtime rather than configured as static rules: whiteips and whitenets, plus dynamiclist. whiteips and whitenets are fed by VICIdial's own IP List named ViciWhite (Admin → IP Lists); dynamiclist is fed separately by ViciBox's dynamic portal, which adds an address only after someone authenticates through it. VB-firewall (/usr/bin/VB-firewall) is the tool that loads all three ipsets, run from root's crontab at boot; it has no status or carrier subcommand of its own, so confirm its effect through firewalld directly, and never run a bare firewall reload afterward (see the checklist below). The stock asterisk service definition covers 5060/udp, 4569/udp and 8089/tcp only — it does not include 5061/udp, so confirm your own PJSIP bind port and channel driver first, with the checks in the sample below, before assuming an existing rule already covers it. On a cloud VPS the provider security group sits in front of all of this and must permit the same traffic, or nothing arrives regardless of what firewalld allows.

Use route labels, never deployed addresses, in any record you keep. EXPECTED DENY means the controlled denied test receives no protected content; an unexpected response is a stop condition. Put a reverse proxy, firewall or segmentation control under the network team's change process where appropriate, then verify that application and infrastructure policies agree.

# 1. Read the safety-critical check first: is an anonymous/guest call path open on either channel driver?asterisk -rx 'pjsip show endpoint anonymous' 2>/dev/nullasterisk -rx 'sip show settings' 2>/dev/null | grep -iE 'unknown access|guest|anonymous' || echo 'no guest/anonymous access line matched in sip show settings output on this build' # 2. Confirm this build's actual PJSIP bind port before assuming 5060 or 5061 either way.asterisk -rx 'pjsip show transports'ss -lntup | grep -E ':(80|443|3306|4577|5038|5060|5061|8088|8089)\b' || echo 'none of those ports are listening' # 3. Identify the firewall backend in front of Asterisk. ViciBox ships firewalld with VB-firewall layered on top, not ufw.if firewall-cmd --state >/dev/null 2>&1; then  echo 'firewall backend: firewalld'  command -v VB-firewall >/dev/null 2>&1 && echo '  VB-firewall present: loads the ViciWhite/dynamic ipsets into firewalld (no status subcommand of its own)'elif command -v ufw >/dev/null 2>&1; then  echo 'firewall backend: ufw (an Ubuntu/Debian install, not the ViciBox default)'else  echo 'no recognized firewall backend found'fi # 4. Confirm which SIP channel driver(s) are loaded, for context on which part of step 1 applies to this build.asterisk -rx 'module show like chan_'

• Compare the allowed ports and source ranges in the provider security group with the host firewall; investigate any mismatch.
• Test Admin, Agent, reports, Non-Agent API and media/export paths.
• Check the proxy configuration for trusted source addresses; test that a direct request cannot impersonate a trusted proxy using forwarded headers.
• Never run a bare firewall reload after VB-firewall has loaded whiteips/whitenets/dynamiclist — it empties those ipsets until VB-firewall runs again.
• Keep an out-of-band console/recovery route under controlled access.

Reduce secret exposure and privilege

Use dedicated, least-privilege identities for API clients, database maintenance, report delivery and external providers. Rotate a credential through its approved secret store and configuration deployment mechanism; never place it in source, shell history, browser URLs or diagnostic output.

On a dialer the highest-value secrets are the SIP credentials your trunk uses, because they convert directly into fraudulent calls. Give every SIP endpoint a long unique password, never reuse the extension number as its secret, and keep AMI and MariaDB bound to localhost or a private interface rather than a public address. If an integration genuinely needs remote AMI or database access, carry it over a VPN or an SSH tunnel instead of opening the port.

Guard database access regardless of storage format; confirm the target build’s handling without exposing the values. On this lab, system_settings.pass_hash_enabled is 0, which means vicidial_users.pass and phones.conf_secret are plain text rather than a hash — never SELECT either column, screenshot one, or paste one into a ticket, even for read-only troubleshooting, because a plain-text value is the credential itself.

Review settings containers, scheduled jobs, integration endpoints and backup destinations because these often bridge the web application to external services. A read-only report can still create an audit-log write, so account scope and retention matter.

• Separate human, API and service identities.
• For each credential, record who rotates it, how to revoke it and the next rotation date; do not record the secret.
• Test failures using non-sensitive observability, not live credentials.

Audit authorization and retain a safe reversal

Route audit should test authentication, authorization, campaign/group/report scope, session behavior and audit-log evidence independently. UI hiding is not authorization; sensitive endpoints and fragment routes need their own checks.

Stop rollout if a break-glass path is untested, a necessary integration fails, or audit evidence cannot distinguish test from production activity. Roll back the narrow configuration or policy change after preserving sanitized evidence, then investigate without weakening unrelated controls.

• Use an independent reviewer for route tests and access review.
• Re-test after upgrades, reverse-proxy changes and new integrations.
• Do not represent this checklist as a certification, penetration test or compliance determination.