Audit VICIdial SSH, firewall and service access

1. Build an access map before changing a control

Complete one row per service: intended client, address family, server listener, controlling firewall path, permitted test and denied test. The result is a verified access map and a specific change/recovery record; it is not a claim that a server is secure because a checklist was completed.

1. Record whether this is a single server or a cluster, its installed release, and which host provides web, database and telephony roles. Identify any VPN, load balancer or upstream firewall.
2. Keep a working administrative session and open the provider console or other recovery path before changing SSH or network access. Confirm the owner and maintenance window for each proposed change.
3. Use the checks below on your own host. Replace every example user, hostname, address and zone; never copy the historical lab’s listener ports or source lists as a deployment policy.

Service / host / port / protocol:Intended client and source range (IPv4 / IPv6):Observed listener and service owner:Effective zone / source / interface / upstream control:Permitted-source test / time / result:Denied-source test / time / result:Difference or UNKNOWN:Proposed change / original value / rollback / owner:

You should seeYour next action is tied to a specific service and access expectation. Continue with SSH because it is the recovery route for later changes.

2. Prove key access and inspect effective SSH policy

A successful key login does not prove that password or keyboard-interactive login is disabled. OpenSSH also supports included configuration files and Match blocks, so editing a commented line with sed is not a reliable policy change. Keep any required MFA workflow intact.

1. From your workstation, confirm the host key through your trusted inventory, then test the assigned key with the command below. Substitute your administrator account and server; keep the original session open. A private-key passphrase prompt is different from the server account password.
2. In the new session, run sudo -v to verify the expected privilege path. If login or sudo fails, stop before changing authentication.
3. On the server, run sudo sshd -t to check syntax and inspect sudo sshd -T. If Match rules apply, use sudo sshd -T -C user=ACTUAL_USER, addr=ACTUAL_CLIENT_IP, host=ACTUAL_CLIENT_HOSTNAME, laddr=ACTUAL_SERVER_IP, lport=ACTUAL_SSH_PORT with the real connection context. Read pubkeyauthentication, passwordauthentication, kbdinteractiveauthentication, authenticationmethods and permitrootlogin.
4. For an approved policy change, first back up every configuration file you will edit to a new private backup path. Use sudoedit on the actual controlling file or include, preserving unrelated settings. For key-only access, confirm PubkeyAuthentication yes and PasswordAuthentication no; disable KbdInteractiveAuthentication only if it is not required for your MFA policy. Choose PermitRootLogin no only after named sudo accounts work; prohibit-password still permits root keys.
5. Run sshd -t and the connection-specific sshd -T check again. Only after both match the intended policy, use the installed service’s supported reload procedure in the approved window. Open another fresh connection and test both the permitted authentication path and the intended rejection path before closing recovery access.

ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no ACTUAL_ADMIN@ACTUAL_SERVER 'id -un'

You should seeRecord the observed effective policy and fresh-login results. If a reload breaks access, restore the exact changed file(s) from the open session or console, validate syntax, reload through the supported procedure and retest. MaxAuthTries and LoginGraceTime limit attempts/time within a connection; they are not an IP ban system.

3. Identify the installed firewall and actual SIP transport

Do not reuse another guide's firewall commands without checking what this server actually runs first. This build ships firewalld and its own helper, VB-firewall; it has no ufw installed, and a ufw command simply fails with command not found here. Detect the backend before you act on it, on any VICIdial host, ViciBox or otherwise.

The SIP port your firewall rule needs is a build-specific fact, not a VICIdial constant. Asterisk's own transport configuration decides it, and this build loads chan_pjsip and chan_sip at the same time. Confirm your own with `sudo asterisk -rx 'pjsip show transports'`, then cross-check with `sudo ss -lnup | grep asterisk` before writing any rule below — on this build that shows PJSIP's transport-udp bound to 0.0.0.0:5061 while chan_sip still answers 5060, the pre-activation state PJSIP_SUPPORT.txt's own activation steps describe. Present 5061 as this build's value, never as a fixed VICIdial port, and inventory every configured transport and loaded service; one PJSIP driver can expose several transports, so investigate only sockets you cannot map to that configuration.

Once you know the backend, note which zone carries VICIdial's own traffic. The zones that matter here are public (the default), external and drop — external is the one that already allows Apache, Apache over TLS, the stock asterisk service, RTP and SSH — but other software on the box can register zones of its own, so read `--get-active-zones` for what it actually lists rather than expecting exactly these three.

# 1. Which firewall tools does this host actually have installed?command -v firewall-cmd; systemctl is-active firewalldcommand -v VB-firewallcommand -v ufw; command -v iptables # 2. Which port does PJSIP actually use on this build? Never assume 5061 or 5060.sudo asterisk -rx 'pjsip show transports'sudo ss -lnup | grep asterisk # 3. Firewalld's own state, without dumping the default zone's full ruleset.sudo firewall-cmd --statesudo firewall-cmd --get-default-zonesudo firewall-cmd --get-active-zones

• Detect firewall-cmd, VB-firewall, ufw and iptables before assuming which one is active.
• Run pjsip show transports and cross-check with ss before writing a rule that names a port.
• Note this build's active firewalld zones; do not assume external is universal without checking.

4. Inspect the complete access path before admitting a carrier

On the recorded ViciBox lab, ViciWhite and the dynamic portal populated source ipsets used by a trusted zone. Membership can admit every service allowed by that zone, including management services; it is not automatically a SIP-only permission. Review the actual implementation before adding a carrier address to a broad trusted list.

Runtime and permanent firewalld configurations are separate. A reload replaces runtime-only state with permanent configuration and can affect dynamically populated ipsets. Do not use reload as a diagnostic shortcut or assume a service-name list contains the whole policy.

1. Use --get-active-zones to identify the zones selected by source and interface. For each relevant zone, replace ACTUAL_ZONE below and inspect the full runtime and permanent listings, including sources, services, ports and rich rules.
2. Use --info-service for each named service to expand its actual ports/protocols. Review source ipsets, direct/policy rules supported by the installed firewalld version and upstream firewalls with their owner; inspect IPv6 as well as IPv4.
3. Compare the carrier’s published signaling/media requirements with the actual Asterisk listeners and the intended source ranges. A UDP listener on 5061 is not proof of TLS; transport and port are separate facts.
4. If a rule is missing, prepare the exact source/protocol/port/zone change and its inverse with the network owner. Test a narrowly scoped runtime rule in the approved window, verify both permitted and denied paths, then persist only the reviewed change. Avoid promoting unrelated runtime state wholesale.
5. If access fails, identify whether DNS, routing, NAT, the source-to-zone mapping, an upstream policy or the service listener is responsible before changing another rule.

sudo firewall-cmd --get-active-zonessudo firewall-cmd --zone=ACTUAL_ZONE --list-allsudo firewall-cmd --permanent --zone=ACTUAL_ZONE --list-allsudo firewall-cmd --info-service=asterisk

You should seeThe change request names the minimum required access and how it will be tested and reversed. The recorded 5061/udp gap is a lab observation, not a command every VICIdial host should run.

5. Validate login-failure signals before enabling a ban rule

The recorded lab did not have fail2ban installed. Check your own build and firewall before choosing any action; the checklist below is not a deployable jail.

The Admin and Agent login paths can log failures differently. A filter matching every POST to the Agent page also matches legitimate requests and must not be deployed as a failure detector. Find an installed-version-specific failure signal and validate the filter against successful and failed test logins first.

Use the actual installed transport ports and log path when evaluating an Asterisk filter. For web logins, confirm whether a rejected login produces a distinct web-server status or only an application event. No deployable Admin or Agent jail is established by this article.

Before enabling a ban rule:1. Identify the installed version’s log entry for a failed Agent login.2. Collect sanitized successful and failed test log lines.3. Test the proposed filter offline: failed logins must match and successful requests must not.4. Verify the ban action, log path, reverse-proxy address handling and recovery path in a test environment.5. Enable only after an authorized test confirms the intended block and a permitted login still works.

• Run rpm -q fail2ban first; it was absent from the recorded lab, which does not establish the package state of every ViciBox installation.
• Confirm which port(s) this build's own SIP transports use before setting the asterisk jail's port list.
• Confirm the installed log path and actual failure event; do not assume a rejected application login always produces HTTP 401.

6. Compare listeners with allowed and denied client paths

A listener address, database account and firewall rule answer different questions. Binding to 0.0.0.0 means all IPv4 interfaces; it does not establish remote reachability. A loopback listener reduces the network path but does not prove account security. Clusters and approved integrations can legitimately require private remote database, FastAGI or AMI access.

1. Read current TCP listeners with the command below. Attribute each relevant port to its process and host role. If your service uses a different configured port, add that actual port to the review.
2. For each listener, compare its intended clients with the complete firewall/upstream path from the previous step. Do not infer protection from only --list-services or --list-ports.
3. From one permitted and one deliberately non-permitted network you control, test the selected host/port during the agreed window. For a TCP reachability check, nc -vz -w 3 ACTUAL_HOST ACTUAL_PORT reports whether a connection opens; it does not authenticate or establish application correctness. Record both results and source networks.
4. For HTTPS/WSS, additionally perform normal certificate verification and the actual supported application login. For database or AMI, use the approved client and least-privilege identity. Do not expose a management service merely to make a test convenient.
5. Unexpected access from the denied source is a failed control. A timeout from the permitted source is also a failure to investigate; neither should be relabeled as secure.

sudo ss -lntp | grep -E ':(3306|4577|5038|8088|8089)\b'

You should seeThe access map now separates listener state, network reachability and authenticated application behavior. Only the observed source/path is established by each test.

7. Find unsafe web-file writers without guessing ownership

Checking only for numeric mode 777 misses other world-writable modes and ACL permissions. A directory’s write permission can allow replacing entries beneath it; file ownership alone does not prevent that. The recorded restore convention wwwrun:www is not a universal prescription for a live web tree.

1. Confirm the actual VICIdial web-root path from the web-server configuration. Replace the sample path if it differs.
2. Inspect the root and find world-writable files/directories below it. If getfacl is available, inspect ACLs on the root and each finding; a clean Unix mode check alone does not exclude additional ACL writers.
3. For each finding, identify the writer: deployment account, web process, recording job or another documented task. Propose the least required owner/group/mode or ACL for that specific path, with its prior metadata recorded for recovery.
4. After an approved permission correction, repeat the mode/ACL check and test the affected workflow with synthetic data, such as a recording move or an Admin action. Restore the recorded metadata if the required workflow fails. Do not run recursive chmod/chown across the web tree as a generic fix.

stat -c '%U:%G:%a %n' /srv/www/htdocs/vicidialfind /srv/www/htdocs/vicidial -xdev -perm -0002 -printf '%M %u:%g %p\n'getfacl -p /srv/www/htdocs/vicidial

You should seeEach permission change has a known writer, exact path, before/after metadata and functional test. Broad ownership conventions are not a substitute for this evidence.

8. Review database identities separately from network reachability

An account host qualifier controls which client identities can authenticate as that account; it does not change the server’s bind address or open a firewall. A cluster may need explicit remote application accounts. A wildcard host or anonymous identity warrants review against the topology, rather than an assumption that every installation must use localhost.

1. Open a private MariaDB administrator client on the database host using its established authentication method. Do not use the reporting connection to widen access to mysql.user.
2. Run the inventory below and compare account host qualifiers with the documented application and cluster hosts. Identify the actual astguiclient account name privately; include it in the review if it is not cron/custom.
3. Have the database owner inventory each relevant account’s direct privileges, roles, routine access and proxy grants without exporting authentication columns. Create a read-only database account for safe VICIdial queries gives the concrete metadata queries for its separate lesson account. Confirm which application features require writes or schema changes before proposing a narrower application grant.
4. Treat an unexpected wildcard/anonymous account or unnecessary privilege as a specific change request. Before revocation, find its consumers, record the existing grant privately and rehearse the least-privilege replacement. Test the affected application after an approved change.
5. Repeat the permitted/denied network and authenticated-client tests after a restore or topology change. A changed bind-address setting alone cannot settle which clients can authenticate.

SELECT User, Host, plugin FROM mysql.user WHERE User IN ('cron', 'custom', 'root') OR User = '';SHOW VARIABLES LIKE 'bind_address';

You should seeThe account review distinguishes authentication scope, privilege scope and network exposure. For a new reporting-only lab identity, use the separate read-only-account recipe.

Create and verify a dedicated read-only lab account →

9. Close the audit with evidence and a recovery record

1. Re-run the relevant permitted and denied checks after each approved change, then once after the combined changes. Include IPv6 and upstream controls where they apply.
2. Keep the exact before/after SSH files, firewall rule text, file metadata or private database grants for each changed control. Roll back only that change using its owning tool; do not disable the firewall or restore a broad old configuration to fix one uncertain rule.
3. If SSH authentication fails after a change, use the still-open session or verified console to restore the edited configuration, validate it and apply the supported reload before testing again. If a ban caused the failure, first identify the actual installed jail and source; do not copy a guessed unban command.
4. Mark every access-map row PASS, FAIL or UNKNOWN with its timestamp and tested source. A failed or unknown control needs an owner and next check. Retest after an upgrade, migration, restore or policy change.

You should seeThe finished artifact is a tested access map with concrete findings and reversible changes. It establishes the checks performed, not a blanket guarantee of server security.

• Recovery access was opened and tested before changes.
• SSH behavior was tested on a fresh session against the effective configuration.
• The intended source-to-listener paths were tested from allowed and denied clients.
• World-write/ACL findings and database grants were reviewed against actual consumers.
• Each change has its own saved original value, verification and rollback; unresolved checks remain visible.