Just wondering if anyone has any suggestions for a reputable service provider that can help us find vulnerabilities in our FreePBX deployment.
Our self hosted FreePBX 13.0.190.5 (Firmware 10.13.66-12) is located in Toronto, Canada. We’ve connected about 50 phones on our local network and 3 phones outside our local network through the FreePBX Responsive Firewall. We’ve been compromised a few times since we set it up despite my best efforts and I want to put an end to it.
I know FreePBX provides support in the form of time blocks. Would this be an effective way to tackle this?
You say you have been compromised 3 times. Are you sure there are no files leftover? If you have a backdoor on your system it’s impossible to get rid of the hackers.
Since you only have 3 external phones, turn off the responsive firewall and allow the 3 IPs in the network settings. Even if the IPs are dynamic you can allow the range and it almost never changes in my experience. Close port 80, 443 in the firewall (and everything else you don’t need) and only allow internal admin access to the GUI.
Always update your modules. They just issued a fix again today.
Thanks for the recommendations and heads up regarding the update. I just noticed the security update issued today and applied it. I’ve been generally good at staying on top of the updates.
We’ve blocked port 80 but allow 443 for HTTPS access via a valid certificate for those who want to check their voicemail through the web GUI when they are out of the office. Not sure how I could allow the User Control Panel while blocking admin access.
I like your idea of disabling the responsive firewall and only allowing the IP’s for the few phones we have outside the network although none are static so I’ll have to allow the range.
We’ve been compromised more than 3 times but only once since I rebuilt the PBX from scratch about 5 months ago. I wanted a fresh start to negate corrupt or compromised files. The second time around I made sure to beef up the passwords.
“Allow SIP Guests” has always been set to “No” however I just noticed that “Allow Anonymous Inbound SIP Calls” was set to Yes! Perhaps that was responsible for our last attack? I just changed that to No.
Both http and https access from external should be closed (no matter which port you assign) as it allows access to the FreePBX admin control panel.
If I was you (compromised system) I would close everything, incl SSH, ftp, tftp, xmp, etc… Nothing should be accessible from outside the LAN except UCP (port 81) if you must.
port 81 has its own virtual host reserved for UCP in the firewall so why would you use anything else?
@dcitelecom Agreed, any access to the admin console has been removed. Thankfully we’ve got nothing else (like ftp phone provisioning) that requires outside access with the exception of UCP. Since UCP now has secure access by default via 4443 with it’s own virtual host why not use it… unless you don’t have a certificate.
Since you only have a few remote users, it may be practical to have them run a dynamic DNS client at each location, then use the fqdn to white list in firewall.
I’ve made changes based on some suggestions here and everything is running along smoothly but I’m not sure how to redirect HTTP to HTTPS from outside our network. The RewriteRule I’ve added to .htaccess seems to work great inside our local network.
However from outside HTTP requests aren’t received at all even when exposing port 80. If it did work by exposing port 80 in this scenario would it be a bad thing?
nothing shows up in the logs at /etc/httpd/logs. It’s acting like it’s not even listening while port 80 does listen from inside our network. so weird.
Where are your attacks coming from? A single country? A cluster of countries? A continent? You should have a decent enough router that you can add blocks of IPs for countries or entire continents.
If none of your remote users venture beyond the US or Canada for example then there is no reason to allow access beyond those IP blocks. At least if the attacks originate in the US then you have a reasonable chance of recourse.
I wish I could tell you where the attacks were from. I have the full log file and CDR report from the last attack a few days ago if anyone is interested in having a look. The logs include only the 3 minute window they had with us which cost us about $200 USD.
We use pfSense which should easily do the job you are suggesting. I suppose blacklisting everything by default and allowing only the countries we approve is likely to reduce the number attacks by a lot.
Blacklisting everything outside of where you expect your remote workers makes sense for a PBX.
For a mail server, that would be a terrible idea as you would not know when someone legitimate is having issues sending you email, unless they gave you a ring in the old telephone
pfSense has a package called DNSblock that works really well for this purpose. The subnets are updated daily for countries and common offenders.
Also, make sure you have in call transfer star * codes turned off. Someone calling you and getting a hold of even just your IVR can press *2 or *22 (double check those numbers) and transfer the call where lever they want. Call transfers will still work for your extensions because the transfer message is send out of band.
you could ‘insert’ the “ipset drop” rule at the top of your iptables INPUT rules after they are set by other means (a local firewall script and/or fail2ban for example) so don’t follow this install procedure blindly. . .
If you use firewalld then you can do that also, perhaps @xrobau will share how to add ipsets elegantly to his firewall
