La configurazione sicura di un SBC (Session Border Controller) è ciò che separa un perimetro voce protetto da un bersaglio esposto su internet. L’SBC è per definizione l’apparato di confine della telefonia: se è configurato male, diventa la porta d’ingresso per frodi telefoniche e attacchi. In questa guida vediamo la messa in opera sicura di un SBC, con il caso concreto del Microsoft Teams Direct Routing: dalla segregazione di rete alle access list interne dell’apparato, fino alle regole sul firewall perimetrale aziendale.

Perché il perimetro voce è un bersaglio

Un SBC esposto senza protezioni subisce entro poche ore scansioni SIP automatiche che cercano di registrare interni, indovinare credenziali e generare traffico verso numerazioni internazionali a tariffa elevata: è il toll fraud, la frode telefonica che si traduce in bollette da migliaia di euro. A questo si aggiungono i tentativi di intercettazione del traffico non cifrato e gli attacchi di esaurimento risorse. La buona notizia è che l’SBC nasce esattamente per difendere questo confine: va solo configurato con metodo.

L’architettura di rete: DMZ e interfacce separate

La messa in opera parte dalla topologia. Nel modello enterprise l’SBC lavora con due interfacce logiche su VLAN distinte: una verso la LAN, dove vivono il centralino IP e la stazione di gestione, e una verso la DMZ, da cui attraversa il firewall perimetrale per raggiungere internet, cioè l’interfaccia Direct Routing di Microsoft e, a seconda della topologia, l’operatore SIP. Due dettagli spesso trascurati: l’interfaccia di gestione (OAMP) non deve mai essere esposta sul lato internet, e l’apparato deve avere un server NTP configurato, perché senza un orologio corretto la validazione dei certificati TLS delle controparti fallisce.

Il firewall interno dell’SBC: la access list

Gli SBC professionali integrano un firewall proprio, una access list valutata dall’alto verso il basso: la prima regola che corrisponde decide, e ciò che non corrisponde a nessuna regola di permesso deve essere bloccato da una regola finale di chiusura totale. Per un deployment Teams Direct Routing su un SBC AudioCodes, lo schema di riferimento sull’interfaccia WAN è questo:

Sorgente	Protocollo	Azione
DNS server utilizzati	UDP/TCP 53	Consenti
52.112.0.0/14 (Microsoft)	TCP/TLS (segnalazione) e UDP/SRTP (media)	Consenti
52.120.0.0/14 (Microsoft)	TCP/TLS (segnalazione) e UDP/SRTP (media)	Consenti
IP dell’operatore SIP (se su questa interfaccia)	UDP/TCP	Consenti
0.0.0.0/0 (tutto il resto)	Any	Blocca

Le due subnet 52.112.0.0/14 e 52.120.0.0/14 sono quelle che Microsoft documenta per il Direct Routing, e servono sia la segnalazione sia i media. Sul fronte segnalazione i punti di connessione sono tre FQDN con logica di failover: sip.pstnhub.microsoft.com (primario, da tentare per primo), sip2.pstnhub.microsoft.com (regione di seconda priorità) e sip3.pstnhub.microsoft.com (terziario, usato nel caso raro in cui i datacenter di due regioni non siano disponibili); nei Proxy Set vanno configurati tutti e tre. Attenzione però a non restringere la lista agli indirizzi a cui risolvono quegli FQDN: Microsoft avverte che il traffico SIP in ingresso verso l’SBC può originare da qualunque IP delle due subnet, quindi si consente l’intero /14, non i singoli /32 usciti da una risoluzione DNS. È l’errore tipico che produce chiamate in ingresso perse a intermittenza per mesi. Per lo stesso motivo il vecchio FQDN cumulativo sip-all.pstnhub.microsoft.com, che circola ancora in molte configurazioni, non è più supportato da Microsoft dal 2022: se compare in una access list va sostituito con le due subnet.

Sul fronte media, il traffico arriva da un servizio distinto del cloud Microsoft, i Media Processor, che lavorano dalle stesse due subnet in UDP/SRTP: le porte esatte sono nella sezione sul firewall perimetrale, più avanti. La regola finale di blocco resta la più importante della tabella: senza di essa, l’elenco è solo un suggerimento. Alla access list si affianca la classificazione del traffico SIP: le chiamate provenienti da Teams si riconoscono verificando che l’header Contact contenga il dominio pstnhub.microsoft.com, e tutto ciò che non viene classificato non deve mai raggiungere una rotta verso la rete pubblica. È la difesa strutturale contro il toll fraud: nessuna rotta aperta per sorgenti sconosciute.

Cifratura: TLS, MTLS e SRTP

L’interfaccia Direct Routing accetta esclusivamente connessioni TLS con certificato firmato da una Certification Authority pubblica riconosciuta da Microsoft: il certificato va emesso sul nome FQDN dell’SBC (Common Name e Subject Alternative Name coerenti con il dominio dichiarato nel tenant) e sull’apparato vanno caricati anche i certificati root e intermedi. Per la connessione MTLS con la rete Teams è obbligatorio installare nel Trusted Root Store dell’SBC le root CA con cui Microsoft firma i certificati dei propri servizi: non una sola, ma tutte quelle elencate nella sezione Root Certificate Authorities della pagina Azure Certificate Authority details di Microsoft. La catena è già cambiata in passato, con la dismissione della storica Baltimore CyberTrust Root, e va ricontrollata a ogni deployment e a ogni rinnovo. Il contesto TLS va limitato alle versioni 1.2 e successive. Sul piano dei media, verso Teams si usa SRTP: l’audio viaggia cifrato, e l’SBC fa da punto di conversione verso i tratti in RTP dove necessario. Il risultato è che segnale e voce attraversano internet protetti, mentre le eventuali tratte in chiaro restano confinate nella rete interna.

Il firewall perimetrale: le regole lato FortiGate

Il firewall interno dell’SBC non sostituisce il perimetrale aziendale: sono due strati che si sommano. Sul firewall di frontiera, ad esempio un NGFW FortiGate, le policy per il perimetro voce seguono cinque principi. Primo: il traffico in ingresso dalla rete pubblica è ammesso esclusivamente verso l’indirizzo dell’SBC in DMZ, mai verso la LAN. Secondo: le sorgenti consentite si limitano alle subnet Microsoft del Direct Routing e agli indirizzi dell’operatore SIP, sulle sole porte necessarie. Attenzione, perché qui si commette l’errore più frequente: i gruppi di porte sono due, non uno. Per la segnalazione serve la porta TLS: verso il SIP Proxy Microsoft è sempre la 5061, mentre la porta di ascolto lato SBC è configurabile sui tenant commerciali. Per i media servono, in entrambe le direzioni, le porte UDP 3478-3481 e 49152-53247 verso i Media Processor di Microsoft, più il range UDP definito nei Media Realm dell’SBC, dimensionato con la regola di Microsoft di almeno due porte per chiamata concorrente: cento chiamate contemporanee vogliono un range di duecento porte. Se si apre solo la segnalazione, la chiamata si stabilisce e l’audio non arriva: è il sintomo classico di un perimetro configurato a metà. Queste regole valgono per il Direct Routing senza media bypass; con il media bypass entrano in gioco i Teams Transport Relay, con requisiti di porte diversi documentati da Microsoft in una pagina dedicata. Terzo: gli helper e le funzioni di SIP ALG del firewall vanno verificati e in genere disattivati per il traffico che attraversa l’SBC, perché la manipolazione dei pacchetti SIP da parte del firewall confligge con il lavoro dell’SBC stesso. Quarto: i profili IPS e la protezione DoS del NGFW si applicano anche alle policy voce, con il geo-blocking come filtro aggiuntivo sulle sorgenti che non hanno motivo di raggiungere il perimetro. Quinto: logging attivo su tutte le policy voce, perché in caso di anomalia i log del perimetrale e i CDR dell’SBC insieme raccontano l’intera storia.

Messa in servizio e monitoraggio

A configurazione completata, la verifica del pairing con Direct Routing si fa osservando lo scambio dei messaggi OPTIONS: lo stato dei Proxy Set verso i nodi Microsoft deve risultare online su tutti gli indirizzi. Da lì in avanti la sicurezza diventa esercizio continuo: aggiornamenti firmware pianificati, revisione periodica delle access list, controllo delle scadenze dei certificati e monitoraggio dei volumi di traffico, perché un picco anomalo di chiamate uscenti fuori orario è quasi sempre il primo sintomo di una frode in corso. Un security assessment periodico dell’infrastruttura chiude il cerchio.

Netframe progetta e mette in opera SBC AudioCodes e Patton certificati per il Microsoft Teams Direct Routing, con configurazione sicura di apparato e perimetro. Il contesto architetturale completo è nella guida all’integrazione della telefonia aziendale; per il percorso di coesistenza tra Teams e centralino esistente, leggi come integrare Teams con il centralino tramite SBC.

Domande frequenti

Perché serve il firewall interno dell’SBC se c’è già il firewall aziendale?

Perché lavorano a livelli diversi: il perimetrale filtra rete e porte, l’SBC classifica e filtra il traffico SIP che quelle porte attraversano legittimamente. La difesa in profondità richiede entrambi: se uno strato viene aggirato o configurato male, l’altro contiene il danno.

Quali indirizzi vanno consentiti per il Teams Direct Routing?

Le subnet Microsoft 52.112.0.0/14 e 52.120.0.0/14, sia per la segnalazione (TCP/TLS verso i tre FQDN sip, sip2 e sip3.pstnhub.microsoft.com, ricordando che il SIP in ingresso può originare da qualunque IP delle subnet) sia per i media (UDP/SRTP da e verso i Media Processor, porte 3478-3481 e 49152-53247 in entrambe le direzioni), oltre ai DNS utilizzati e agli indirizzi dell’operatore SIP. Tutto il resto va chiuso con una regola finale di blocco.

Serve un certificato pubblico per l’SBC?

Sì. L’interfaccia Direct Routing accetta solo connessioni TLS con certificato emesso da una Certification Authority pubblica riconosciuta da Microsoft, intestato al nome FQDN dell’SBC. I certificati autofirmati non sono accettati, e per la connessione MTLS vanno installate nel Trusted Store dell’apparato le root CA elencate da Microsoft nella pagina Azure Certificate Authority details: la catena è cambiata in passato e va verificata a ogni deployment.

Cos’è il toll fraud e come si previene?

È la frode telefonica: un attaccante sfrutta un perimetro voce mal configurato per generare chiamate verso numerazioni internazionali a tariffa elevata, a spese dell’azienda. Si previene con access list restrittive, classificazione del traffico SIP, nessuna rotta verso la rete pubblica per sorgenti non riconosciute, credenziali robuste e monitoraggio dei volumi di chiamata.

Il SIP ALG del firewall va disattivato?

In presenza di un SBC, in genere sì. Le funzioni ALG riscrivono i pacchetti SIP per gestire il NAT, ma quando c’è un SBC questa manipolazione è già compito suo: la doppia riscrittura produce chiamate senza audio e registrazioni instabili. La gestione degli helper SIP va verificata sul firewall secondo la documentazione del vendor.

Un SBC ben configurato è un confine, uno configurato male è un ponte. La differenza non sta nell’apparato ma nel metodo: segregazione, liste chiuse, cifratura e due firewall che lavorano insieme. Vuoi una verifica del tuo perimetro voce? Scrivici a info@netframe.it o chiamaci allo 059 7134794.

Netframe è un system integrator indipendente. AudioCodes, Patton e Fortinet, citati in questa guida, sono produttori di cui Netframe è partner certificato; Microsoft è technology partner di Netframe. Le indicazioni di configurazione derivano dalla documentazione ufficiale elencata nelle fonti.

Fonti

• Microsoft Learn, Plan Direct Routing: FQDN e failover, subnet, porte di segnalazione e media, nota sul SIP in ingresso, regola delle due porte per chiamata (learn.microsoft.com)
• Microsoft Learn, Plan for media bypass with Direct Routing (learn.microsoft.com)
• Microsoft Learn, Azure Certificate Authority details, sezione Root Certificate Authorities (learn.microsoft.com)
• Microsoft Learn, Office TLS Certificate Changes (learn.microsoft.com)
• Documentazione AudioCodes per il deployment Microsoft Teams Direct Routing: Media Realm, Proxy Set e classificazione del traffico
• Documentazione Fortinet sulla gestione di SIP ALG e session helper

Fonti verificate il 10 agosto 2026. Gli intervalli IP e le porte del Microsoft Teams Direct Routing sono soggetti a modifica: prima di applicare qualunque regola in produzione, riverificare i valori correnti sulla documentazione Microsoft.