Suspicious activity

(United States) #1

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.

PBX is not behind a NAT.

(Lorne Gaetz) #2

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:

grep "Registered SIP" /var/log/asterisk/full*

grep "Added contact" /var/log/asterisk/full*

(United States) #3

So this line means they have the secret password for that extension? We have a random 14 char password on the extensions.

/var/log/asterisk/full-20200528:[2020-05-27 17:31:04] VERBOSE[17473] res_pjsip_registrar.c: Added contact 'sip:207@' to AOR '207' with expiration of 3600 seconds

(Lorne Gaetz) #4

The log line shows a device behind IP successfully registered to ext 207, and they can only do that with the SIP secret.

(United States) #5

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.

(Communication Technologies) #6

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?

(Lorne Gaetz) #7

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.

(United States) #8

Please explain what you mean by “your provisioning services are not protected either by firewall and/or passwords.” Thanks.

(United States) #9

I created it long ago. The secret is 8 chars mixed. Guessing that is not enough.

(Communication Technologies) #10

That’s not I would consider secure. See @lgaetz’s post and confirm you are patched, and your method for provisioning is secure.

(United States) #11

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?

(Lorne Gaetz) #12

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.

(United States) #13

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)

(United States) #15

What is preferable?


https if the phones support it.

(Lorne Gaetz) #17

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.

(United States) #18

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?

(Lorne Gaetz) #19

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?

(United States) #20

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.

Thanks for the help.