How to Harden MagnusBilling on Debian – Full VoIP Security Guide

An internet-facing VoIP server is continuously exposed to automated scans, brute-force attempts, malformed SIP traffic and fraud attempts. Hardening is not one setting: it is a layered operating practice that combines a small network surface, strong authentication, current software, monitoring and tested recovery.

This guide restores the complete scope of the original MagnusBilling security article and updates it for MagnusBilling 8, which uses Asterisk 20 and PJSIP. Apply changes in a maintenance window, keep a working recovery path and verify each layer before moving to the next one.

Security checklist

• Reduce exposure and use non-default ports only as a secondary noise-reduction measure.
• Serve the panel through a dedicated domain with HTTPS.
• Enable two-factor authentication for administrators and other privileged users.
• Restrict MagnusBilling panel access by IP authorized over SSH.
• Enable reCAPTCHA on the login screen when it fits your deployment.
• Place OpenSIPS or Kamailio in front of Asterisk for high-exposure production environments.
• Authenticate stable SIP peers by IP where possible; use strong unique credentials for dynamic endpoints.
• Use SSH keys and disable password authentication only after verifying key access.
• Keep the host firewall and Fail2Ban active and monitored.
• Apply MagnusBilling and Debian security updates in a controlled maintenance process.
• Replace default credentials, avoid predictable administrators and use strong unique passwords.
• Keep tested backups outside the production server and review security logs regularly.

1. Use non-default ports carefully

Changing a default port can reduce commodity scan noise, but it does not make a vulnerable service secure. Firewall policy, access allowlists, authentication and monitoring remain the real controls.

• If firewalld is the active firewall, allow the new SSH port before changing sshd.
• Validate the SSH configuration with sshd -t before reloading the service.
• After the new connection works, update Fail2Ban and monitoring rules to follow the new SSH port.
• MagnusBilling 8 uses PJSIP. Do not copy the legacy chan_sip bindport setting from older guides. Change the managed PJSIP transport only after checking how your installation generates Asterisk configuration, then update the firewall, trunks, endpoints and external signaling settings together.
• After a SIP change, confirm the transport with asterisk -rx "pjsip show transports" and test inbound and outbound calls.

# Example only when firewalld is the active firewall
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload

# Validate before reloading SSH
sshd -t
systemctl reload ssh

2. Enable two-factor authentication

A password alone should not protect an administrator account. Enable a maintained two-factor authentication method that is compatible with your MagnusBilling installation and require it for privileged users.

• Make 2FA mandatory for administrators.
• Enable it for resellers, support staff and other users with sensitive access.
• Store recovery codes offline and test the recovery process.
• Do not let multiple people share one administrator account; individual accounts preserve accountability.

3. Use a domain and HTTPS

Do not operate the administrative panel over plain HTTP. Assign a dedicated hostname, issue a trusted certificate and redirect browser traffic to HTTPS. Port 80 may remain available for ACME validation or a strict redirect; the authenticated session belongs on HTTPS.

apt update
apt install certbot python3-certbot-apache -y
certbot --apache

4. Enable reCAPTCHA

reCAPTCHA can add friction to automated login abuse, but it complements rather than replaces strong credentials, 2FA, rate limiting and IP restrictions. Create the required keys for the exact panel hostname and enter them in the MagnusBilling configuration.

• Use the production hostname when registering the site.
• Confirm that the login remains usable after enabling it.
• Document a recovery path in case the external verification service is unavailable.

Settings → search for "recaptcha"

5. Put a SIP proxy in front of Asterisk

For a serious public VoIP environment, deploy OpenSIPS or Kamailio at the SIP edge instead of exposing the Asterisk backend directly.

• Filter malformed or unwanted signaling before it reaches Asterisk.
• Apply rate limits and flood controls at the edge.
• Hide backend topology and expose only the required signaling paths.
• Centralize routing, access lists and observability for multiple backends.

Internet
   ↓
OpenSIPS / Kamailio
   ↓
Asterisk 20 + MagnusBilling 8

6. Prefer SIP authentication by IP for stable peers

When a carrier or trusted peer has documented, stable source addresses, IP-based identification removes the password-guessing path for that relationship. Limit the rule to the smallest verified address ranges.

• Do not use broad provider networks when precise ranges are available.
• Keep a documented process for provider IP changes.
• Mobile users and dynamic endpoints usually still need digest authentication; give every endpoint a long, random, unique secret.
• Combine authentication with ACLs, rate limiting, endpoint limits and fraud monitoring.
• Test emergency, inbound and outbound routes after changing trunk identification.

7. Use SSH key authentication

Install and test a key before disabling password login. Ed25519 is a strong default for new keys; keep RSA only where compatibility requires it.

ssh-keygen -t ed25519 -a 100
ssh-copy-id -p 2222 root@SERVER_IP

# /etc/ssh/sshd_config
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password

sshd -t
systemctl reload ssh

8. Keep the firewall, Fail2Ban and software current

MagnusBilling 8 installations include Fail2Ban and host firewall configuration. Review their status after network or port changes, and investigate repeated authentication failures instead of assuming automated bans cover every attack.

• Back up the database, /etc/asterisk and local customizations before an update.
• Review release and migration notes before changing a production server.
• Run updates during a maintenance window and keep a tested rollback path.
• After updating, verify the panel, cron jobs, PJSIP endpoints, trunks, inbound and outbound calls, billing and logs.
• Apply Debian security updates regularly and reboot when kernel or critical library changes require it.

/var/www/html/mbilling/protected/commands/update.sh

9. Replace default administrative access

Change the initial password immediately. Create a named administrator for each operator and confirm it works before disabling or deleting a default account.

• Avoid predictable usernames and shared administrator accounts.
• Grant only the permissions each operator needs.
• Remove or disable accounts that are no longer used.
• Restrict each panel user to IP addresses authorized from SSH when that operating model fits your team.

Restrict panel access by IP authorized over SSH→

10. Generate strong, unique passwords

Use a password manager and a unique secret for every panel account, SIP endpoint, database user and integration. A generated secret of at least 16 characters is a practical baseline; privileged and machine credentials should be longer.

• Never reuse the panel administrator password for SIP, SSH or database access.
• Do not send credentials through tickets, chat messages or screenshots.
• Rotate any secret that may have been exposed and review logs for misuse.
• Keep secrets out of source code, shell history and public configuration examples.

openssl rand -base64 24

A layered production baseline

A hardened MagnusBilling deployment combines HTTPS, 2FA, panel IP restrictions, SSH keys, a restrictive firewall, Fail2Ban, safe PJSIP authentication, a SIP edge where appropriate, current software, strong secrets, monitoring and recoverable backups. No individual control replaces the others.

Internet-facing VoIP infrastructure will be probed. The goal is to reduce reachable attack paths, make unauthorized access difficult, detect abnormal behavior early and preserve a tested recovery route if a control fails.

Original article and version note

This rewritten guide restores every topic from the archived article while replacing legacy chan_sip-era advice with MagnusBilling 8 and PJSIP guidance. Confirm commands and generated configuration paths against the exact version installed before changing a production server.

Read the archived original article→