I am trying to understand, how someone could dial out to foreign numbers from our FreePBX.
The logfile has entries of kind of:
pbx.c: Executing [0037052871640@from-internal:1] Macro("Local/0037052871640@from-internal-00000052;2", "user-callerid,LIMIT,EXTERNAL,") in new stack
Dialing out from legit extensions normally would state the extension number in kind of pbx.c: Executing [legit-number@from-internal:1] Macro("PJSIP/2098-00000000", "user-callerid,LIMIT,EXTERNAL,") in new stack
How may I find out, from where the attack came? Our PBX is externally reachable via UDP 5060 and nothing else.
Edit: The PBX is as well externally reachable on port 80 http because of letsencrypt.
You need to look back i the logs to find out what created the Local channel. It could be:
a Dial() issued by the real culprit channel;
a Queue() issued by the real culprit channel;
a (blind) transfer initiated by the real culprit;
an AGI script run from the real culprit channel;
AMI, through compromised port 5038 access;
a call file, from a completely compromised server.
In some of these cases the local channel will optimise out when the call is answered, leaving the culprit channel exposed.
Also, note that the current advice is to never expose port 5060, or any other commonly used SIP port, but rather change that to one you have chosen randomly, unless your ITSP doesn’t allow this, in which case you first change the ITSP.
[C-00000026] pbx.c: Executing [s@macro-dialout-trunk:24] AGI("Local/0015442037694207@from-internal-00000025;2", "agi://127.0.0.1/sangomacrm.agi") in new stack
Seems like I have to work through documentation whether our PBX need those AGI functions or not. Is it possible to block that external requests via firewall rules?
I have updated our PBX this morning. The restapps version was 15.0.19.88. I think there is no further research necessary. I have secured outbound calls to foreign numbers with a PIN as well and will reconsider if it is actually necessary that our PBX is publicly reachable.
Had exactly the same issue. Luckily our provider blocked the calls so no costs incurred
Nuke & restore from latest Backup was also our course of action. Then we upgraded all Modules to the latest version before allowing Access from the Internet again. Also enabled the Responsive Firewall to only allow HTTP Access after SIP is connected