El Mon, 20 Feb 2023 20:08:50 +1000 Richard Edmands thesirdmz@gmail.com escribió:

Yeah, don’t trust that IP range blindly. It’s just Azure space. The only logical approach I’ve seen appears to be certificate validation and checking.

okok.

I can see that the client certificate is being validated. But that means the client certificate is valid. Doesn't mean that the certificate is microsoft.

Is there a way to check the certificate owner in the config script? Or to limit the certificate to a certain "Subject Alternative Name"?

Would it be nuts to limit the CA list allowed for that socket creating a custom ca list? It still would not filter just MS.

In the end I guess I'll get an IP list and filter because opening two /14 nets seems crazy to me.

...

On 20 Feb 2023, at 7:00 pm, Jon Bonilla (Manwe) manwe@sipdoc.net wrote:

Hi

Sorry for the OT but I think here's the place where I an find a lot of Ms teams integrations

I've been working on MS teams direct routing integration for PekePBX. It works. I guess I've done it as everybody else, using Henning's guide as base and extending it for multitenant setup (thanks Henning!)

What I've realized is that the source IP address of calls coming from MS are not always matching dispatcher hosts. Sometimes they come from another source IP and failover to the dispatcher hosts when they receive no response. That makes some of the calls to have an additional latency

Searching in the MS doc I see that they document these nets as source of their signaling:

52.112.0.0/14 52.120.0.0/14

But I've seen IP addresses outside of this range as source. In this blog https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/

The ranges are listed as

52.112.0.0/16 52.113.0.0/16 52.114.0.0/16 52.115.0.0/16 52.120.0.0/16 52.121.0.0/16 52.122.0.0/16 52.123.0.0/16

which looks better but scares me out. Having no auth is it secure to bind so many ranges to MS?

Do you use anything else than certificate verification for these calls?

cheers,

Jon

-- PekePBX, the multitenant PBX solution https://pekepbx.com __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

---

Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

El Thu, 23 Feb 2023 12:59:42 +0100 Daniel-Constantin Mierla miconda@gmail.com escribió:

You can also check the issuer of the certificate, there should be some variable in the config returning that when incoming traffic is over tls and the peer has presented a certificate.

Right

I was checking only in the tls module, not in the pseudovariables documentation.

I should know that there's always a pseudovariable for your needs.

Will check that.

Thanks Daniel.

El Mon, 20 Feb 2023 13:06:30 +0000 Henning Westerholt hw@gilawa.com escribió:

Hello,

correct me if I am wrong, but the second group of addresses ("/16") is included in the first group ("/14"), right?

Regarding the large IP scope, this is the way Microsoft designed it, unfortunately. There is not that much what you can do about.

Right. Didn't check the masks. they all were 16 in my mind :)

So, if I add those ranges in the permissions table my only way of avoiding spoofed calls is certificate validation? I'm already doing that and also checking the company domain and ms account email address. Just wanted to be sure that nothing "essential" was missing.