Il problema iniziale

Il trunk in questione era configurato su chan_sip (il canale SIP «legacy» di Asterisk), con un peer dedicato che specificava:

type=peer
insecure=port,invite
host=<IP del provider>
context=from-trunk

Sulla carta, questa configurazione dovrebbe già permettere ad Asterisk di riconoscere il provider tramite il suo IP sorgente, senza bisogno di autenticazione né di aprire il centralino ad anonymous/guest. Eppure, disattivando quelle due opzioni, le chiamate in entrata smettevano di funzionare.

Perché questo è un problema di sicurezza, non solo di funzionalità. Tenere Allow Anonymous Inbound SIP Calls e Allow SIP Guests su «Yes» significa accettare INVITE SIP da qualsiasi IP su Internet, senza autenticazione. È il vettore d’attacco più comune per il toll fraud: bot che scansionano range IP alla ricerca di centralini esposti e instradano chiamate verso numerazioni a pagamento a spese del titolare del trunk.

Il processo di diagnosi

1. Verifica della configurazione del trunk

Il primo passo è stato escludere un errore banale nella configurazione del peer: host IP corretto, insecure=port,invite presente, context corretto. Tutto sembrava a posto.

2. Analisi del firewall di FreePBX

Il modulo Firewall di FreePBX lavora a zone (Trusted, Internal, Other, Internet) e può interferire con il traffico SIP indipendentemente da chan_sip. Abbiamo verificato che l’IP del provider fosse effettivamente assegnato alla zona Trusted nella sezione Networks. Lo era — quindi anche questa pista è stata esclusa.

3. Controllo di Fail2ban

Un IP può risultare bloccato da Fail2ban (Intrusion Detection) a causa di tentativi precedenti falliti, indipendentemente dalla configurazione del trunk. Abbiamo controllato lo stato del jail dedicato ad Asterisk:

fail2ban-client status asterisk-iptables

L’IP del provider non risultava tra quelli bannati. Anche questa ipotesi è stata scartata.

4. Cattura del traffico di rete con tcpdump

A questo punto abbiamo verificato, a livello di rete, se il traffico del provider arrivasse fisicamente alla macchina:

tcpdump -i any udp port 5060 -n

Qui è emerso il primo indizio utile: il traffico SIP in arrivo dal provider esisteva, ma andava analizzato con attenzione, perché nella stessa cattura comparivano anche tentativi di scansione automatizzata da IP sconosciuti — un promemoria pratico di quanto sia reale il rischio descritto sopra.

5. La svolta: log applicativo di Asterisk in tempo reale

Il passaggio decisivo è stato riattivare temporaneamente le opzioni «Yes» e osservare il log verbose di Asterisk mentre arrivava una chiamata reale:

asterisk -rvvvvvvvvvvvvvv
sip set debug on

Il log ha rivelato un dettaglio chiave: la chiamata in arrivo dall’IP del provider veniva gestita da un canale PJSIP/anonymous-xxxxxxxx — non dal peer chan_sip configurato per quel trunk. In altre parole: il traffico arrivava, ma finiva sul canale PJSIP generico «anonimo», non sul trunk legacy dedicato.

La causa reale: due canali SIP, due porte diverse

FreePBX supporta contemporaneamente due implementazioni del protocollo SIP: il canale legacy chan_sip e il canale moderno PJSIP. Quando entrambi sono attivi, per evitare conflitti, chan_sip viene tipicamente spostato su una porta diversa dalla 5060 standard (nel nostro caso, la 5160), lasciando PJSIP sulla porta standard.

Verifica diretta da Asterisk:

asterisk -rx "sip show settings" | grep -i bind
> UDP Bindaddress: 0.0.0.0:5160

asterisk -rx "pjsip show transports"
> 0.0.0.0-udp   udp   0.0.0.0:5060

Il provider VoIP inviava le chiamate sulla porta 5060 — la porta di PJSIP, non quella di chan_sip. Il peer chan_sip configurato per quel trunk, per quanto corretto, semplicemente non poteva mai ricevere quel traffico, perché era in ascolto su una porta diversa (5160). Le chiamate arrivavano dunque solo a PJSIP, dove non esisteva nessun endpoint dedicato per quell’IP — e per questo venivano gestite dal canale «anonymous», l’unico modo per farle passare senza un match esplicito.

La scoperta chiave: non era un problema di configurazione del trunk né di sicurezza mal impostata. Era un mismatch tra la porta su cui il provider inviava effettivamente le chiamate e la porta su cui il canale SIP configurato per quel trunk era realmente in ascolto. Un dettaglio invisibile finché non si osserva il traffico a runtime.

Il ruolo (mancato) della comunicazione del provider

Un aspetto rilevante di questo caso: il provider VoIP, in un momento non specificato, aveva probabilmente cambiato o standardizzato l’invio delle chiamate sulla porta 5060 senza comunicarlo. Per un provider, «SIP standard sulla 5060» è un dettaglio implementativo trascurabile; per un centralino configurato in precedenza su un peer chan_sip legacy (storicamente spostato su porte alternative), lo stesso dettaglio diventa la causa di un blocco totale delle chiamate in entrata.

Questo caso evidenzia un punto spesso sottovalutato nella gestione di trunk VoIP: la configurazione lato centralino deve restare sincronizzata con eventuali cambiamenti silenziosi lato provider, e l’assenza di comunicazione da parte del fornitore non elimina la necessità di verificarlo periodicamente.

La soluzione applicata

Anziché continuare ad affidarsi al meccanismo anonimo (che richiede di tenere il centralino aperto a chiunque su Internet), abbiamo creato un trunk PJSIP dedicato, allineato alla porta realmente utilizzata dal provider:

• Nuovo trunk PJSIP con match IP esplicito sull’indirizzo del provider
• Porta di ascolto coerente con quella effettivamente usata (5060)
• Context di instradamento identico a quello del vecchio trunk chan_sip

Risultato: il traffico del provider viene ora riconosciuto correttamente come proveniente da un endpoint noto, sia in entrata che in uscita, senza più bisogno di tenere attive le opzioni Allow Anonymous Inbound SIP Calls e Allow SIP Guests, che sono state riportate su «No» ripristinando la postura di sicurezza corretta del centralino.

Lezioni per chi gestisce centralini FreePBX

1. Non lasciare mai anonymous/guest attivi come soluzione permanente. Se un trunk sembra «richiederlo», è quasi sempre il sintomo di un problema di matching sottostante, non una reale necessità.
2. Verificare sempre su quale porta ascoltano chan_sip e PJSIP quando entrambi i canali sono attivi sullo stesso sistema — è una causa di malfunzionamento facile da trascurare.
3. La configurazione statica di un peer non basta: senza osservare il traffico reale (tcpdump, log Asterisk in tempo reale), un mismatch di porta può restare invisibile per mesi, «risolto» solo aprendo pericolosamente il sistema.
4. Documentare e monitorare i trunk provider nel tempo, perché cambi di infrastruttura lato fornitore (nuove porte, nuovi IP, nuovi SBC) spesso non vengono comunicati in modo proattivo.