I got a message from my trunk provider saying there was suspicious activity, for several hours there was successive less than 30 second phone calls made from extensions that are not in use. I cannot tell from the logs how this has happened.
The call trace shows local extension 207 dialing a 605 area code number which the provider does not terminate. The 605 South Dakota destination is very common for traffic pumping, so itâs highly likely that your extension SIP secrets have leaked (or are insecure) allowing spurious registrations.
For confirmation, look thru your asterisk logs for registrations from IP addresses you donât recognize:
It really is that simple. Now how has the secret been compromised?
Must mean PBX access (the phones are in secure location) though SSH and the GUI are password protected. Guess I am changing passwords. Any other thoughts?
And thanks for taking the time.
Is the secret a good pw for extension 207? If it is, there could be another area of ingress. If the secret for 207 is weak, changing it could be enough to stop the problem.
Did you create 207? Or do you think someone else created 207?
The most common way that SIP secrets leak is your provisioning services are not protected either by firewall and/or passwords. There was also an exploit fixed last fall that could be an issue if youâre admin GUI framework is out of date and also exposed to untrusted traffic.
I guess I have trouble with the words. Provisioning server is my freepbx and it is current. All modules are current. Excuse me missing this, but what is âmethod for provisioningâ in this context?
I have a phone. I can login to the phone GUI and manually configure it with everything it needs to register and make calls.
OR i can configure my phone with a provisioning URI. The phone then connects to the provisioning server (the pbx) using the protocol specified in the URI (i.e the provisioning service) and downloads a text file containing the entire configuration required for setup. This is the process of âprovisioningâ and it is critically important if you are generating provisioning files that you secure the provisioning services. Provisioning protocols include tftp, ftp, http(s) etc.
We use tftp for provisioning. Each extension has a secret password. I am not aware of additional security beyond that for provisioning. I understand I can provision the phone in front of me by auto-provision or through the phoneâs menu. In either case, I need to know the secret for that extension. The simple and straight answer seems to be that the secret password was compromised. Ive changed system password.
This was setup with all the extension having the same secret. Outside of this problem, that appears to be a bad idea.
Think about NOT using tftp (the first T stands for Trivial, i.e. zero checks on anything) anyone allowed through your firewall can indefinitely troll your presented directory ( /tftboot or whatever) until they chance on a file that âleaksâ your family jewels)
Seeing a bunch of flags scattered thru this thread. Hosted PBX, tftp provisioning, 8 character secrets, shared SIP secrets, signalling ports open to untrusted traffic, possible untrusted access to tftp as well.
How is the system secured? Itâs time for a thorough review of whatever youâre using to lock this system down. Changing passwords is necessary, but just mole whacking at this stage.
Very much agreed. Can you recommend a primer on setting this up correctly? Is there a Theory Of Operations âmanualâ for security? Iâm showing my age.
Is there any reason NOT to use the default offered secret when creating an extension?
Is it acceptable to use extension numbers as user names?
Maybe. But not without a hint about your setup. How was the system installed, is it a FreePBX Distro? What version? Are you using a local firewall? Are you using an external Firewall? Both? Neither?
FreePBX 14.0.13.33
It is NAT through a router straight to the PBX which is running fail2ban. I understand that the same way my remote site phones connect, a bad guy connected. That implies the secret got compromised. It has been suggested that promiscuous sending of the provisioning file may have lead to the compromise.