VoIP server security

A VoIP softswitch is a valuable target. If attackers can send calls through it, they can generate large bills to expensive destinations in a few hours. If they can reach its database, they can see customers, rates and call records. This lesson covers practical security measures for a VoIP server, from the network edge to backups. It describes principles; adapt the exact commands and tools to your own system.

Know what attackers try

• SIP scanning: automated tools sweep the internet looking for anything that answers SIP, then send OPTIONS or REGISTER requests to identify the software.
• Credential guessing: repeated REGISTER or INVITE attempts with common usernames and passwords.
• Toll fraud: once an account or gateway is compromised, sending calls to premium or high-cost destinations.
• Management access: trying to reach the admin client port, web portals, SSH or the database with weak or default passwords.
• Denial of service: flooding the server with SIP requests so legitimate calls fail.

Layer 1 – Firewall: default deny

The single most effective control is a firewall that blocks everything by default and allows only what is needed.

• SIP signalling: allow only the IP addresses of your customers and vendors. Wholesale interconnects are usually IP-based, which makes this practical.
• RTP media: allow the media port range the switch uses; restrict to partner addresses where your setup allows.
• Management (admin client, web admin, SSH, database): never open to the whole internet. Allow only from a VPN or a small set of office addresses.
• Database: should only listen locally or on a private network.
• Review rules whenever a partner is added or removed, and remove addresses that are no longer used.

Moving SIP or SSH to a non-standard port reduces noise from basic scanners, but it is not a security control on its own — a whitelist is.

Layer 2 – Whitelists inside the switch

Even behind a firewall, configure the softswitch to accept calls only from the IP addresses defined on each customer’s mapping gateway. Avoid wide ranges. If a customer must use username/password registration, combine it with strong credentials and, where possible, an IP restriction.

Layer 3 – Automatic blocking (fail2ban and similar)

Tools such as fail2ban read log files and temporarily block IP addresses that show abusive patterns, such as many failed SSH logins or repeated failed SIP registrations. Good practice:

• Enable protection for SSH and any web login pages.
• Where the softswitch logs failed SIP authentication, add a rule for those too.
• Whitelist your own office and partner addresses so they are never blocked by mistake.
• Check blocked addresses occasionally to make sure a real partner was not caught.

Layer 4 – Strong passwords and access control

• Change every default password on the operating system, database, admin client and web portals.
• Use long, unique passwords stored in a password manager, not in spreadsheets or chat.
• Prefer SSH keys over passwords and disable direct root login over SSH.
• Give each staff member their own admin login with only the permissions they need, and remove access promptly when someone leaves.
• Use two-factor authentication for VPN and email accounts that can reset other passwords.

Layer 5 – Limits that contain damage

Assume that one day an account will be misused, and limit how much damage it can do:

• Concurrent-call limits per customer and per gateway.
• Prepaid billing or tight credit limits for new customers.
• Blocking of high-risk destinations unless a customer specifically needs them.
• Alerts when spend or call volume jumps compared with normal (see Lesson 7).

Layer 6 – Updates and hardening

• Apply operating-system security updates on a regular schedule, after testing.
• Run only the services you need; disable everything else.
• Keep the softswitch on a version supported by its vendor and apply their security fixes.
• Synchronise the server clock (NTP) so logs and CDRs line up with partners.

Layer 7 – Backups you can restore

Your switch configuration and CDR database are the business. Protect them:

• Back up the database and configuration automatically, at least daily.
• Keep copies off the server, in a separate location, encrypted.
• Keep several generations, so a problem discovered late can still be rolled back.
• Test restores regularly on a separate machine. A backup that has never been restored is only a hope.
• Back up before every major change, and write down how to roll back.

Layer 8 – Logging and monitoring

• Keep system, SIP and admin-action logs for an agreed period.
• Watch for spikes in failed authentication, new source addresses and unusual destinations.
• Monitor disk space; a full disk can stop CDR writing and break billing.
• Run monitoring and analysis on a separate server where possible, so the switch stays lean.

A short security checklist

1. Firewall default-deny, with partner and admin whitelists.
2. No management interface open to the internet.
3. No default passwords anywhere; individual admin accounts.
4. Automatic blocking of brute-force attempts.
5. Call and spend limits on every account.
6. Regular updates.
7. Daily off-server backups, with tested restores.
8. Alerts on unusual traffic.

Monitoring platforms like VoxInspector are designed to run their heavy processing on a separate server with data retention controls, keeping the softswitch itself as small and protected as possible.

Examples in this course use invented names (Vendor X, Customer Y, Country Z) and documentation IP ranges. Menu names and options differ between softswitch versions; always check your own system and vendor documentation.