Console - Official FreePBX® Hosting, Licences, and Support

DOCUMENTATION

Console

This documentation covers two related topics: how to access and manage your FreePBX UK instance via the browser-based console, and the results of the security assessment conducted against the FreePBX UK hosting platform. Both are relevant to anyone operating a FreePBX UK instance in a production environment.

The console section explains how access works, how to enable SSH if you need it, and what to do if you are locked out. The security section documents the testing methodology, results, and conclusions from a live penetration test conducted against two production-grade instances.

Part 1: Console Access

Console How the Console Works

✓

AccessOpen your instance from the My Products page in the portal at my.freepbx.uk. Click the Console button to launch a terminal session in your browser.

The console is available at all times, regardless of your FreePBX firewall configuration. It does not require port 22 to be open.

✓

SecurityConsole sessions use HMAC-signed tokens with a 60-second validity window. The session is proxied server-side through our secure console infrastructure at my-console.freepbxhosting.uk.

Tokens are bound to your specific instance IP. They cannot be shared, reused, or redirected to another instance. This is fundamentally more secure than a persistent session URL.

✓

FirewallThe console server is whitelisted in your FreePBX firewall from day one. Console access is never blocked by your default firewall configuration.

my-console.freepbxhosting.uk is added to the internal zone during provisioning. You do not need to add it manually.

✓

SessionSessions time out after 30 minutes of inactivity. Closing your browser window ends the session immediately.

No persistent session remains on the server after you close the console.

SSH Enabling and Disabling SSH Access

✓

SSH is disabled by default. Use the commands below to enable or disable SSH access from your console. Enabling SSH is a deliberate action and should only be done when you specifically need it.

Enable SSH

sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config.d/50-cloud-init.conf
passwd root
systemctl restart sshd

✓

Step 1Allows root to log in with a password. By default, root login is restricted to key authentication only.

✓

Step 2Enables password authentication in the cloud-init SSH config override file.

✓

Step 3Sets a root password. Choose something strong. This is the password you will use to SSH in.

✓

Step 4Restarts the SSH daemon so all changes take effect immediately.

Disable SSH

sed -i 's/PermitRootLogin yes/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config.d/50-cloud-init.conf
passwd -l root
systemctl restart sshd

✓

Step 1Restores root login to key-only authentication, blocking password-based root SSH.

✓

Step 2Disables password authentication in the cloud-init SSH config override file.

✓

Step 3Locks the root password so it cannot be used for authentication even if password auth were somehow re-enabled.

✓

Step 4Restarts the SSH daemon so all changes take effect immediately.

Once SSH is enabled, you are responsible for securing access. We recommend disabling SSH again when you no longer need it, and using the FreePBX firewall to restrict SSH to trusted IP addresses only. See Clause 9 of your hosting agreement.

Warning Fail2Ban Lockout

⚠

Fail2Ban is active on every instance and will ban your IP after repeated failed SSH login attempts. If you are locked out, you will not be able to connect via SSH or the WHMCS console until the ban is lifted.

The ban is applied at the iptables level via the ssh-iptables jail and affects all inbound connections from your IP, including the console proxy.

⚠

To recover from a lockout, you must raise a support ticket at my.freepbx.uk. FreePBX UK will unban your IP via the server console on your behalf.

You do not have access to the DigitalOcean infrastructure console. Recovery requires a support request.

⚠

FreePBX uses two separate SSH jails. If one unban does not restore access, both sshd and ssh-iptables jails may need to be cleared.

Important If the Console is Not Working

The console requires my-console.freepbxhosting.uk to be in the internal zone of your FreePBX firewall. If you have removed it, the console will not be able to connect.

You can re-add it via the FreePBX GUI under Admin, System Admin, Firewall, by adding my-console.freepbxhosting.uk to the internal zone. Alternatively, run the command below if you have another way into the server.

fwconsole firewall add internal my-console.freepbxhosting.uk

If you are unable to restore console access yourself, raise a support ticket at my.freepbx.uk. Do not attempt to modify the DigitalOcean Cloud Firewall rules directly as this may conflict with the provisioning system.

Terms Your Responsibilities

✓

SSH access is a self-service facility. By enabling SSH you accept full responsibility for securing access to your instance. Clause 8 of the FreePBX UK Hosting Agreement sets out your security responsibilities in full.

✓

We recommend restricting SSH to trusted IP addresses using the FreePBX firewall, and disabling SSH entirely when it is not in active use.

✓

FreePBX UK retains the ability to access your instance via console-level infrastructure access for maintenance and support purposes. This is described in your hosting agreement and does not constitute monitoring of your PBX activity.

✓

You must not attempt to remove, disable, or circumvent the FreePBX UK console access mechanism. Doing so constitutes a material breach of your hosting agreement.

Part 2: Platform Security Assessment

The following documents the results of a live penetration test conducted on 15th April 2026 against two production-grade FreePBX UK instances. Tests were conducted instance-to-instance, simulating a scenario where a customer attempts to access another customer's infrastructure. All major attack surfaces were tested across IPv4, IPv6, public interfaces, and the shared VPC network.

Both instances were provisioned from the standard FreePBX UK snapshot. Tests were conducted with firewalls in both active and disabled states to establish a clear baseline in each condition.

Test 1 Network Isolation

✓

MethodICMP and TCP ping across public IP, DigitalOcean private range, VPC range, and IPv6.

✓

Public IPReachable via internet routing as expected.

✓

DO Private RangeDestination Host Unreachable. DigitalOcean blocks cross-instance access on the private range at the network level without explicit VPC configuration.

✓

VPC RangeReachable between instances in the same infrastructure VPC. This is the 20tele.com internal network. Customer instances are not placed into shared VPCs with other customer instances.

✓

IPv6Fully reachable, 0% packet loss, correct addressing confirmed on both instances.

✓

FindingDigitalOcean enforces network-level isolation between instances by default on the private range. Customer instances are provisioned into isolated environments and are not placed into shared VPCs. VPC isolation is enforced through provisioning logic, not assumed.

Test 2 SSH Access

✓

MethodSSH connection attempted across public IP, VPC IP, and IPv6 with password authentication explicitly disabled.

✓

ResultAll three attempts returned "Permission denied (publickey)". No access was granted on any interface or protocol stack.

✓

FindingThe snapshot correctly enforces key-only authentication with password authentication disabled at the OS level. Without the specific private key authorised on a given instance, SSH access is not possible regardless of network path or protocol version.

Test 3 Web Interface Credential Testing

✓

MethodAutomated POST requests to the FreePBX admin interface using a dictionary of common default credentials including admin, password, freepbx, sangoma, 1234, root, toor, changeme, and others.

✓

ResultAll attempts returned an Invalid response and were redirected back to the login page. No credentials produced a successful login.

✓

FindingNo default or common credentials are present on provisioned instances. The FreePBX admin interface correctly rejects all invalid login attempts.

Test 4 SIP Exposure

✓

MethodSIP device scanning using SIPVicious svmap and svwar across public IP, VPC IP, and IPv6, with the FreePBX firewall both active and disabled. Extension enumeration attempted across the range 100 to 300.

✓

Firewall DisabledSIP device identified as FPBX-17.0.28(22.8.2) on both public IP and VPC IP. Firewall-off exposure is expected and documented for transparency.

✓

IPv6 (Firewall Off)Ports open but SIP not visible. Asterisk does not bind to the IPv6 interface for SIP by default, providing additional obscurity.

✓

Firewall ActiveSIPVicious returned "found nothing" across all interfaces and protocol stacks. The instance was completely invisible to SIP scanners.

✓

FindingThe FreePBX firewall is the definitive control for SIP security. With the firewall active, no SIP attack surface exists on any interface. The contrast between firewall states was proven conclusively through live testing.

Test 5 Full Port Scan

✓

MethodFull TCP port scan across all 65,535 ports against the public IP of an instance with the FreePBX firewall active.

✓

ResultAll 65,535 ports reported as filtered with no response. Scan completed in 131 seconds with zero open or closed ports identified.

✓

FindingWith the FreePBX firewall active, the platform presents no exposed services on the public internet. The firewall silently drops all unsolicited traffic, preventing confirmation of any running services.

Test 6 IPv6 Security Parity

✓

MethodFull repeat of port scanning, SSH access attempts, and SIP enumeration over IPv6, with firewall both active and disabled.

✓

ResultWith firewall active: all ports filtered, SIP not visible, SSH denied. DNS resolution verified for internal hostnames and external domains. End-to-end IPv6 connectivity confirmed with 0% packet loss.

✓

FindingThe FreePBX firewall applies equally to IPv6 traffic. There is no degradation of security posture on the IPv6 stack. IPv6 DNS and connectivity are fully operational.

Test 7 Console Proxy Isolation

✓

ArchitectureThe console proxy runs as a Node.js WebSocket-to-SSH service on a dedicated instance at my-console.freepbxhosting.uk. Access requires a valid HMAC-signed token generated by WHMCS at the point of request. The token contains the target instance IP, a client identifier, and a 60-second expiry timestamp.

The master SSH key used to connect to customer instances resides exclusively on the console instance and is never transmitted to or stored on the customer instance.

✓

Connection AttemptSSH to the console proxy from a customer instance returned "Permission denied (publickey)". The customer instance holds no key authorised on the console proxy. Jump host pivot was not possible.

✓

Token SecurityA token can only be used to connect to the specific instance IP embedded within it. Altering the IP invalidates the HMAC signature. A token cannot be reused after the 60-second window expires.

✓

FindingThe console proxy correctly isolates customers to their own instances. The master key is not accessible to customers and is not usable outside the controlled proxy session. Cross-customer access via the console is not possible without a full compromise of the console infrastructure itself.

Summary Test Results

Test	Method	Firewall State	Result
Network isolation	ICMP / TCP ping	N/A	Pass
SSH access IPv4	Direct SSH attempt	Down	Pass
SSH access IPv6	Direct SSH attempt	Down	Pass
Web credentials	Dictionary attack	Down	Pass
SIP exposure	SIPVicious svmap	Down	Exposed (expected)
SIP exposure	SIPVicious svmap	Up	Pass
Full port scan	nmap 65535 ports	Up	Pass
IPv6 parity	Full repeat over IPv6	Both	Pass
Console proxy	Architectural review and connection attempt	N/A	Pass

Recommendations What You Should Do

✓

FirewallEnable the FreePBX firewall as the first step after receiving your instance. With the firewall active, the platform is invisible to external scanning on all interfaces and protocol stacks.

The firewall is not enabled by default, in keeping with standard FreePBX deployment practice. You are responsible for enabling and configuring it.

✓

SIPUntil a SIP trunk is configured, port 5060 is not exposed on the public interface. Once a trunk is configured, the FreePBX firewall is your only protection against SIP scanning and toll fraud.

✓

SSHLeave SSH disabled unless you specifically need it. If you enable it, restrict it to trusted IP addresses using the FreePBX firewall and disable it again when you are done.

✓

ConsoleDo not remove my-console.freepbxhosting.uk from the FreePBX firewall's internal zone. Doing so will lock you out of the console and require a support request to restore access.

✓

VPCDo not add your instance to a shared VPC with other instances. Customer instances must remain isolated. This is enforced through provisioning but worth understanding.