I’m currently working on updating the company’s VoIP topology. Our setup includes a couple of Asterisk servers, several SIP trunks with different DIDs, and so on.
The current connection is point-to-point: PSTN > Carrier Router > Distribution Switch > Asterisk Server.
From what I’ve read and referenced, this isn’t recommended and poses several security risks. I’ve seen that it’s recommended that the device receiving the SIP trunk be an SBC (Session Board Controller), which acts as a “VoIP firewall” and routes traffic to the server.
However, I’d like to hear about the community’s experience with this, as implementing an SBC in an appliance or cloud is expensive, and open-source tools seem extremely complex.
What are the alternatives, and what’s the best way to securely receive trunks from the carrier?
On Wednesday 29 April 2026 at 21:52:47, dti.voip wrote:
PSTN > Carrier Router > Distribution Switch > Asterisk Server
From what I’ve read and referenced, this isn’t recommended and poses several
security risks
Citation Needed
Unless you do not trust your carrier’s router, where is the security risk in
the above network connection?
what’s the best way to securely receive trunks from the carrier?
Authenticate by IP address. Simple, non-spoofable, extremely common.
Use TLS. More complex, requires certificates and certificate checking (not
to be taken for granted, some services simply accept anything with a
certificate), your carrier may not support it.
Antony.
–
“Have you been drinking brake fluid again? I think you’re addicted to the
stuff.”
“No, no, it’s alright - I can stop any time I want to.”
I’ve mainly read about hiding the network topology so an attacker can’t see it, preventing the masking of data packets like SIP traffic, and handling DDoS attacks.
Difficult to spoof. Can be done, to some extent, by:
compromise to local systems, particularly routers and switches;
poisoning of core internet routing table;
transmitting blind with false source addresses
With all things security you have to consider the specific threats to your organisation, e.g. if you are going against the US government, in a cyber warfare context, I think you should treat poisoning of routing tables as a realistic possibility.
I’ve never really understood the purpose of SBCs, except as a new revenue stream for equipment suppliers. If it is security, they need to be very simple, otherwise they introduce a new pool of vulnerabilities, but also have to be very thorough, otherwise the exploit will get straight through.
You are reading either Cisco documentation or AI or other posts that are screen scrapes of Cisco documentation. The SBC idea came about because in the early days of VoIP people bought standard Cisco routers and ran VoIP code on them then configured back to back dial peers on the router and tied them together since it was easier to troubleshoot a router to SIP provider and router to PBX connection than a PBX to SIP provider connection especially since the early PBXes were often limited in diagnostics. Cisco caught wind of the hack and invented the SBC concept out of whole cloth, adding additional licensing so as to make more money. They made a ton of money off of these until they decided they could make more money pushing customers to put their PBX into the cloud which applied the golden handcuffs and also allows them to sell back end analysis of customer phone number calling patterns to marketeers.
If you learn nothing else about security learn that the more you overengineer the plumbing the easier it is to stop up the drain. Complicated networking is a paradise for crackers the more points in there the higher the chances to find a weakness. K.I.S.S. is the rule, here.
I really like your approach, and you’re right. I’ve been reading about this topic based on concepts obtained through AI and posts on various internet portals “specialized” in VoIP… Your response gives me a new perspective on a solution because, up until now, the information I’d found was, to put it mildly, very generic.
Pooh is basically right that the “default” model (carrier IP-auth SIP trunk straight into Asterisk) is extremely common and not automatically insecure if it’s tightly controlled. The real issue isn’t the physical chain, it’s exposure and trust boundaries: if your SIP interface is reachable from anywhere other than the carrier, that’s where risk starts. A practical middle ground many operators use is a lightweight edge SBC layer (could be a VM running Kamailio or OpenSIPS) just for SIP validation, rate limiting, and topology hiding, then forward clean traffic to Asterisk on a private network. You don’t necessarily need a full enterprise SBC appliance, but you do want at least one hardened “edge” point that is the only public SIP endpoint, with Asterisk fully internal and not directly exposed.
