VoIP Security: Where Attacks Actually Happen in a Business Phone System

Most attacks on a business phone system start at the signalling and media edge, not inside the call server: an exposed SIP port, a trunk whose authentication is weak, an inbound call route that accepts from anywhere. Defending the PBX itself is the second step, not the first. Order the work accordingly.

Definition: VoIP security in a business phone system is the set of controls that limit who can place or receive calls, encrypt or authenticate the signalling and media paths, and reduce the physical exposure of the equipment — applied in the order that actually removes risk, starting at the network edge.

Where Toll Fraud Actually Enters a Business Phone System

Toll fraud is usually described as an attack on the PBX. It is more accurately an attack on the path into the PBX. If a SIP trunk accepts registration attempts from anywhere on the internet, the weakness is the trunk's authentication and the SBC's rules, not the configuration of the IP-PBX sitting behind it.

The realistic entry points are worth separating, because each one needs a different control.

• Weak or missing trunk authentication. A trunk that accepts a registration from any source address lets an outsider attempt to register as a trunk endpoint or as an extension, depending on how the branch handles routing of that attempt.
• Open administration interfaces. A web interface or telnet service reachable from the internet is the shortest path to full control of the device, including its routing table.
• Unauthenticated invitation and forwarding requests. Session-initiated calls that pass unsolicited inbound requests to extensions can be used to place calls the business pays for.
• Internal call forwarding abuse. A legitimate extension forwarding to a paid premium or international destination is not a break-in at all. It is an ordinary feature used badly, and it is one of the most common routes to unexpected charges.

What the SBC is actually for

A session border controller sits between the internet and the private voice network. Its value is that it makes the boundary a policy point: it decides which calls may enter, which may leave, and what may traverse the middle. For VoIP fraud prevention, the useful controls are the ones that reject unwanted attempts before they ever reach the IP-PBX — not the ones that merely log them afterwards.

One point of confusion is worth clearing up. An SBC that hides your internal addressing is reducing information exposure, not stopping fraud. Hiding NAT addresses is good practice and it is listed among the access-control features of New Rock's enterprise SBC, but toll fraud is prevented by the combination of access control, call-blocking rules, and the boundary position itself. Each feature does one job.

Signalling and Media Encryption

Encryption in VoIP applies to two separate streams, and they are frequently confused. Signalling is the SIP conversation: registration, invitation, negotiation. Media is the audio stream itself. Encrypting one does nothing for the other.

The New Rock enterprise SBC, the OM1000-SBC (SX3000), is specified with signalling and media separation and TLS/SRTP encryption, with the important condition that both must be enabled together. That condition is the practical point for anyone deploying it: a configuration that turns on TLS for signalling while leaving SRTP off still carries unprotected audio, and vice versa.

TLS and SRTP: what each one protects

TLS protects the signalling path. It authenticates the far end of the SIP conversation and encrypts the control messages, which is where call routing decisions, credentials, and headers travel. Without it, an on-path observer can read registration traffic and see account details and target numbers.

SRTP protects the media path. It encrypts the audio itself, so a party to the call who should not be on it cannot simply listen in on the RTP stream. Signalling encryption without media encryption leaves the conversation itself exposed to anyone with access to the media path.

Two deployment details are worth planning for. First, encryption only protects traffic between two points that are configured to speak it; a device that terminates plaintext at one end ends the protection there. Second, an SBC handling encrypted media must also handle the corresponding media negotiation and transcoding behaviour for the codecs you use. The SX100 SBC, aimed at small and medium businesses, lists TLS/SRTP among its supported protocols along with SIP/IMS, RTP/RTCP/MSRP, IPv4/IPv6, UDP/TCP, HTTP/HTTPS and NTP/SNTP, together with codec work covering G.711 A-Law and U-Law, G.723.1, G.729a/b, iLBC, G.722, G.722.1, G.722.2, AMR, H.264 and H.265.

One boundary condition on the SX100 is worth noting for capacity planning: it supports 1000 user registrations, 120 concurrent sessions, and 70 media transcoding channels. Transcoding is a resource-holding operation, so a site that negotiates many codec combinations consumes more of it than one that standardises on fewer.

SBC Features That Block Unwanted Calls

These are the controls that determine how much unauthorised calling an SBC will tolerate, and they are the ones to configure before anything else in a security review.

• IP table access control. Which source addresses may attempt to register or call in. This is the first filter and it should be as narrow as the operating reality allows.
• Blocking untrusted calls. The SBC rejects calls from sources it does not recognise as legitimate, rather than passing them to the internal network for the PBX to decide.
• Hiding NAT addresses. Internal numbering and addressing are not exposed to the outside. This limits what an external party learns from a rejected or answered call attempt.
• Web brute-force protection. Repeated failed login attempts on the administration interface are detected and handled, which slows the cheapest automated credential attack against the device.
• Password complexity enforcement. The device rejects weak administrative passwords rather than accepting them, which removes a decision from the administrator who would otherwise be tempted to make it under time pressure.
• Telnet and SSH enable/disable control. Administrative access paths can be switched off individually. On a device that only needs web administration, leaving SSH enabled for convenience is an unnecessary exposure.
• Web and Telnet whitelists. Administrative interfaces accept connections only from listed source hosts. The limit worth planning around: up to 30 whitelist entries, and each entry is a single host IP — network ranges are not supported, so a whitelisted subnet has to be expressed as its individual hosts.

Connection limits and packet handling on the enterprise SBC

Two specifications affect how the SBC behaves under hostile or misconfigured traffic, and both belong in a capacity discussion rather than only a security one. The OM1000-SBC connects to a maximum of 5 SIP servers, which bounds the signalling topology it can hold. And it supports signalling packet fragmentation with an MTU of 1500 bytes, which matters for how large messages travel and how they are handled on the way.

The SX100 covers the internet-facing flood problem at the same time as it handles session control: it processes internet DoS and DDoS attacks and UDP/TCP floods, which is the layer that keeps volumetric traffic from consuming the voice capacity of the system behind it. That protection is a property of the device's network handling, so it applies to traffic passing through it — traffic that bypasses the device is not covered by it.

Where Each Control Sits in the Stack

Mapping the exposures against the controls makes the gaps visible. The table below lists the layers where unwanted activity enters a business phone system, the control that addresses each one, and where in the New Rock range that control is implemented.

Two patterns in that table are worth noting. The administrative and signalling controls sit on the same enterprise SBC, which means the boundary policy can be managed in one place rather than split across devices. The physical controls sit at the opposite end of the path, at the point where lines enter the building, and they respond to a different class of event entirely. Reviewing the stack in this order also tells you where a gap matters most: an unwitelisted administration interface sits at the top of the list because it exposes the device that enforces everything else.

Physical Layer Protection for the Rack

Logical controls are irrelevant if the wiring outside the equipment is unprotected. Telecom lines entering a building are exposed to surges from lightning and from switching transients on the external network, and the phone lines are the most likely path for such an event to reach your equipment.

New Rock's PT4800 patch panel provides 48 RJ11 ports, 12 RJ45 ports, and 48 RJ11 connections for the CO or telephone lines, with built-in surge protection. The PT2400 covers the smaller case with 24 RJ11 ports, 6 RJ45 ports for equipment, and 24 RJ11 connections for CO or telephone lines, also with built-in surge protection. Putting the surge protection at the point where the external lines terminate protects the equipment downstream from a surge that arrives on the wiring.

At the device level, the OM series IP-PBX systems carry Class I lightning protection, which addresses the same category of event at the equipment end rather than at the entry point. The two are complementary: the panel handles what arrives on the external lines, and the device handles what reaches it.

What the physical layer cannot do

Surge protection is damage limitation. It reduces the chance that a transient turns into a failed board, and it does nothing against an attacker who has legitimate physical access to the cabinet, or against a misconfiguration that leaves a service exposed. It belongs in a layered plan alongside the access controls above, and it should not be used to argue that the logical layer matters less.

A Practical Security Checklist

If you do only three things, do the first three. They address the paths that toll fraud and unauthorised access actually use, and they are cheap relative to everything after them.

1. Close the administrative exposure. Place the web interface and Telnet behind the SBC's whitelist, disable the access paths you do not use, and enforce password complexity so weak credentials cannot be set. The whitelist has a hard limit of 30 entries and supports host IPs only, so plan the list around that constraint rather than around the address range you wish you had.
2. Constrain who can reach the voice path. Apply IP table access control, block untrusted calls at the SBC, and enable both TLS and SRTP together on every path that carries real traffic. Verify the setting on each side of every boundary, since encryption is only meaningful end to end.
3. Audit outbound dialling. Review who can reach an external destination, what route codes are reachable from an extension, and whether forwarding is permitted to international or premium destinations. This step catches the toll fraud route that no amount of perimeter work will block, because it uses legitimate credentials on purpose.

Then work through the rest.

• Place an SBC at the internet edge. It limits flood traffic from consuming voice resources, and it gives you a single policy point instead of per-device rules. Confirm that no path around it exists.
• Protect the external lines. Use a surge-protected patch panel such as the PT2400 or PT4800 where CO or telephone lines terminate, and keep the OM series lightning protection in place at the device.
• Review management access continuously. Whitelists and disabled services decay as teams change. Re-check them whenever a new administrator is added, an address is reused, or a device is replaced.
• Check the signalling layer behaviour. Know the SIP server connection limit for your SBC model — 5 on the OM1000-SBC — and the fragmentation and MTU behaviour, because both affect how the device behaves under abnormal signalling conditions.
• Keep recording and call data in scope. Recording and call detail systems inherit the sensitivity of the conversations they hold. They belong in the same access control review as the voice platform itself.

VoIP Security FAQ

Does enabling TLS on signalling automatically protect the audio?

No. Signalling and media are separate streams, and each needs its own protocol. The OM1000-SBC (SX3000) is specified with TLS/SRTP encryption requiring both to be enabled together, which is the configuration to aim for. Signalling encryption alone leaves the conversation unprotected on the media path.

Is hiding NAT addresses a real security control?

It is a real control against information exposure, and it is listed among the enterprise SBC's access-control features alongside IP table access control and blocking of untrusted calls. It is not a substitute for those. Hiding addressing reduces what an external caller learns; access control determines who may attempt a call in the first place.

How many addresses can I put in the SBC whitelist?

Up to 30 whitelist entries for the Web and Telnet interfaces, and the entries are host IPs only — network ranges are not supported. A whitelisted subnet therefore has to be entered as its individual hosts, so keep the administrative source list short and controlled rather than attempting to cover a whole range.

Can an SBC stop voice packet floods on its own?

The SX100 SBC handles internet DoS and DDoS attacks, UDP/TCP floods and other abnormal service requests, and also supports whitelist and blacklist entries, topology hiding and a voice firewall, so traffic passing through the device is subject to that handling. Traffic that routes around the device is not covered, which is why the placement of the SBC relative to the internet path matters as much as the feature list.

Do I need encryption on calls inside the building?

That depends on what you are protecting against and where the endpoint is. Internal calls between handsets are not exposed to the same interception risk as calls crossing the internet boundary, and encryption adds configuration and capability requirements. Encrypting the boundary paths, where traffic leaves the building, addresses the larger exposure with less operational complexity.

Does surge protection on the patch panel stop telephone fraud?

No, and the two address different problems. The PT2400 and PT4800 patch panels carry built-in surge protection to limit damage from transients arriving on external telephone lines, and the OM series carries Class I lightning protection at the device. Toll fraud comes from signalling access, not from electrical surges, and it needs the access controls and dialling audit described above.

Conclusion

VoIP security in a business phone system is mostly a question of where the boundary is and what is allowed through it. The first three actions that matter are closing administrative exposure with whitelists, disabled access paths, and enforced password complexity; constraining the voice path with IP access control, blocked untrusted calls, and TLS and SRTP enabled together; and auditing outbound dialling, which catches the fraud route that perimeter work cannot touch.

Everything after that is reinforcement: an SBC handling flood traffic at the edge, surge-protected panels and lightning protection for the physical path, and a regular review of who can reach the administration interfaces. Write the whitelist limits and the administrative access rules down where the next administrator will find them, because the control that decays without documentation is the one you will lose.