SBC SIP security product

[biglebowski]

Has anyone looked at this SBC security product yet. Andrew Prokop seems to be involved (unpaid) and has written about it in his blog.

https://assertion.cloud/sbc/

https://andrewjprokop.wordpress.com/2022/08/01/real-time-voice-protection-with-sbc-guard/

Looks like an interesting solution, I used securelogix years ago but that is a very very expensive product.

 

[kyle555]

He advises them for free?

https://assertion.cloud/about-us/

 

[biglebowski]

Well he says he does and is listed as an advisor rather than a company member/director etc.

https://andrewjprokop.wordpress.com/2022/08/01/real-time-voice-protection-with-sbc-guard/[/URL]]It also doesn’t hurt that in my spare time I act as an unpaid technical advisor to Assertion and remain very close to the subject.

His blog has been fantastic and informative for a very very long time so I (personally) trust the guy's advice/knowledge.

 

[kyle555]

There's always another security product to sell you on top of what you have.

If you do it right, you don't need something on top.

If you got hacked, you'll never be able to sell your own company or your customer (if you're a partner) on doing it right so you'll buy this.

Either way, SBC R10 has auto-blacklisting of IPs after given thresholds if it's from a registration.

If you have internet facing trunks, the SBC just won't respond to IPs that don't match a flow.

There's plenty of misconfigured SBCs out there. It's not FUD if you can't prove you're using your SBC properly already.

Every SBC was made to be internet-facing already, but that doesn't mean they're configured correctly.

So, counter-points:
Do you want to go through the trouble of loopty-looping all your signaling through someone else to prove it's safe?
Do you want to test failover to bypass them if they're down?
Do you need to support/test complex call scenarios with refers and blind transfers and whatever else going through their loopty-loop machine?

It doesn't matter if it's an SBC or a PBX or an old school voicemail. You're supposed to lock it down properly. And if you didn't and got dinged, the solution is to lock it down properly.

Take your pick: outsource the config of your device or outsource the signaling processing and still need to configure your device.

You're probably going to have an internet facing firewall anyway, and that thing is probably smart enough - regardless of protocol - to notice that a bunch of TCP resets from you to some public IP is enough to shut 'em up.

Purely my opinion - if you want to run your own switch, you have the job of mitigating toll fraud. If you want to be in a public cloud and leave it up to a provider, that's ok too. I feel like it's a corner case where you need to run your own gear on the open internet and need someone else to protect it for you.

Your SBC doesn't need Cloudflare in front of it handling billions of HTTP requests. And even if you did, notice how their architecture puts the onus on your SBC to start the loopty loop to them. Their AI might be smart enough to reject everything, but you still had to front-end the internet traffic and send it to them. A DDoS is still going to make your SBC meltdown before they have a problem.

And I wonder how that loopty-loop affects licensing on your SBC sessions.
It used to be "Untrusted set/trunk-->SBC" and "SBC-->PBX"
Now it's "Untrusted set/trunk-->SBC" and "SBC-->Cloud" and "Cloud-->SBC" and "SBC-->PBX".

I'll bet you the guy at Avaya backbone support just can't wait for you to send him that SIP trace.

I'll get off my soapbox now