Nope. Close 5060, reset secrets, move on. Been bashed too many times when filing bug reports.
Perhaps at least post a sample line so it could be checked against the Fail2Ban regexes ?
Dont use 5060 as Dicko would say, and “Permit” at the extension level wouldnt hurt either.
1 Like
I think I’ve sorted out my original problems. I think maybe that Vitelity (sip provider) was compromised.
So… turns out Freepbx was ok this time.
However, the depth of this thread still proves my point. I am grateful for the hard work done behind the scenes. However, how is it that this degree of knowledge and tweaking is NOT necessary for your average home router???
Apples and oranges, including the fact that the home router is at least three devices missing many of the rich enterprise features (flexibility at the cost of complexity). Home routers target a broader, and often less knowledgeable (generally) demographic, thus it tends to be more locked down and simplified. This simplification can make getting setup easier/quicker, but does not necessarily mean you are safer (vs. enterprise).
How did you come to the conclusion it was Vitelity that was hacked and not your PBX?
Did Vitelity confirm this?
2 Likes
Great question.
I use Openwrt for my small business. After going through the initial complexities of flashing it, and the initial set-up, its been pretty much hassle free from a security standpoint.
The CDRs for Vitelity did not match that of my server. Therefore, my sub-account was being used. I am not sure how it was initially compromised. Vitelity sent out an email (maybe to all their customers) that they recommended changing passwords (their web portal and trunk passwords)
This thread just caught my interest. Having managed many FreePBXs since late 2010, I experienced my first security issue two days ago.
Vitelity SIP credentials were compromised and hundreds of calls were made using the two sub-accounts. All to the same number 1-701-717-xxxx None of the calls appear in the PBX CDRs, there are no login attempts to the box, responsive firewall was on. All the calls directed to my sub-account originated from a 52.162.x.x ip that has nothing to do with my organization. I can’t figure how the credentials were exposed but I have no indication it was the box as other providers were not affected. It seems there may be more of us and leaves me wondering if this a new attack vector? Anyone else?
How could you not figure that as ‘You’ having been compromised, not Vitelity/Voyant?
1 Like
Can confirm. Vitelity sub accounts are / were being compromised. Best to use IP based authentication as I was told it is not impacted. The number 1-701-717-xxxx is associated with the attacker. Viteity has been sending notifications to customers to update portal and sub_account passwords.
Hmm, that is a cautionary reminder from Voyant/Vitelity to you to use ‘best practices’ to help you not getting your accounts compromised.
I don’t see any acceptance of liability or an offer of recompense for any of their own lack of due care.
Reading between the lines, they acknowledge that more than a few folks using sub-accounts have been compromised. That is not their liability though, it is “you” as a client.
Perhaps more widely a possible FreePBX compromise as it seems you are not unique. . . .
If you can use IP authentication, I strongly advise you to do so.
1 Like
Thus far it appears they are forgiving the charges… so there is that.
kerensen were your fees waived??
^^Bump^^
We are also a Vitelity customer but have not received an email like this.
Reading it I don’t see that Vitelity admits any wrongdoing one their part saying that it was on their side where customer’s subaccount credentials were stolen.
What makes you think it was on their side rather than on your end?
1 Like
This might be a left-turn in terms of a question I’m adding to this thread. Apologies in advance. 
In terms of securing the FreePBX environment, if I have my FreePBX VM sitting on my private LAN, there’s no port-forwarding/server publishing taking place, and I have SIP trunks registered with my external provider…the primary Internet-facing exploit that I could be exposed to would be if a malicious party was able to authenticate with the SIP trunk creds and hijack those trunks by registering them to one of the malicious party’s own resources…correct?
It’s not like I have Chan or PJ SIP ports exposed on the Internet, not like anyone can pull up the web admin GUI, etc. since that’s all on the private LAN. Just thinking out loud. Unless someone goes old school with a phreaking blue box…lol.
Correct. And that is why the suggestion to use “IP Authentication” is advanced. Instead of relying on SIP credentials that would be vulnerable if leaked, calls are sent from the provider directly to a specific set IP address that you control (your PBX). Of course, a consequence of IP authentication is firewall config to allow inbound IP traffic from the provider’s SIP and media hosts, so trading one potential security issue for another.
2 Likes
I am sorry to read the issue you have had. I know about 5 years ago I had 3-5 PBX hacked due to a vulnerability in FreepBX and unfortunately when they released the information, and from the time we became aware of the vulnerability, the PBX’s were already compromised.
Since then, I do 3 important things… 1. enable the responsive firewall and only allow UCP from the internet. 2. Ensure FailToBan is enabled and change the values so the reset time is longer. 3. set PBX to auto update security updates (and modules if you like). I also run nightly Backups to FTP.
I use to configure our UTM to block all port access except for the essential PBX ports however I find the Responsive firewall and FailToBan does a great job. I see a lot less of hack attempts by changing the FailToBan reset times to be 1-3 days.
My company provides Cloud PBX based on FreePBX Distro and in the last 5 years we have had no issue following the steps I mentioned.
I should also mention we set the SIP Auth password for devices and these are generally not available to clients however if the client wants to set their own password we make sure it is strong and we can check that for weak password detection as found under the Reports Menu.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.