FreePBX on FreePBXHosting.com Best Practices & VPN

Is there a “Best Practices” for FreePBX running on cloud servers?

We have a fresh new FreePBX running on FreePBXHosting.com. It’s version 12.7.6-1904-1.sng7 according to /etc/schmooze/pbx-version.

The Admin Dashboard shows everything green (with the exception of an annoying message about LetsEncrypt).

The firewall is configured, and we don’t allow anonymous SIP connections. (Was quite surprised that wasn’t the default configuration.)

We have 2 main sites, one in AZ and another in AR with about 20 endpoints. In addition we have about 10 other locations across 5 states with an endpoint at each location.

I kind of naively assumed that the default FreePBX image provided by Sangoma/FreePBXHosting would be secure. (I already mentioned the anonymous connection default that I have changed.)

We have also changed the Apache Rewrite rules to redirect http requests to use the https scheme. (I think that’s what’s messing with LetsEncrypt, btw. It’s on my ToDo list to run that down.)

As I have been becoming more familiar with the FreePBX system, I can see that a number of non-TLS protected channels are enabled, and I am unsure whether our calls are in the clear over the internet. I sure hope not. :open_mouth:

A lot of the FreePBX documentation speaks about the PBX server being “on the same network”. I’m assuming that means on the LAN segments that will receive broadcast packets during discovery. Could be wrong.

Either way, since the FreePBX is cloud hosted is should be obvious that none of the endpoibts are local to it.

We are currently auto configuring Yealink handsets using the commercial EndPoint Manager. To get this to work, we’ve selected the External Address for Destination and Provision, and we require HTTPS for provisioning and for Phone Apps Protocol.

I suspect a better configuration would be to have each of the two main sites VPN/L2TP to the FreePBX server and then change back to HTTP and Internal Addresses.

But, it doesn’t seem right to have the 10 satelite locations VPN to the PBX server, especially since they already VPN to our AR site gateway.

So…

Who out there has real-world experience with FreePBX on a virtual private server, and what is the recommended configuration to deploy a solid, stable, and secure FreePBX solution on a VPS (e.g. Sangoma/FreePBXHosting)??

Thanks in advance for constructive input. And, I’m happy to provide any details or answer questions.

-Mark

You’ll get different opinions on this but mine is that Allow Anonymous SIP is not inherently insecure. It basically toggles where incoming calls go that aren’t associated with one of your trunks. If it’s allowed, incoming calls go to your Inbound Routes, and it would be wise of you to set up a catch-all route that hangs up or something similar. If it’s disallowed, anonymous incoming calls go to another part of the dialplan that just plays a message and hangs up. Either way, those incoming calls ARE entering the dialplan.

A more interesting setting is Allow SIP Guest which denies SIP traffic not defined as being from a trunk or extension (device).

It sounds like you have a pretty good plan for a cloud server by using exclusively SIP-TLS and HTTPS-based administration and provisioning.

I, personally, never agree with turning on Allow SIP Guests or Anonymous Callers. While they may not be overtly insecure because they trap the call it does require the call to be accepted and that takes up resources. Just had someone in the IRC channel that limited their RTP ports because there were only three users on the PBX. Had these two settings on and guess what happened? They ran out of RTP ports because they were getting hammered so hard that the PBX was answering and playing back the “Service not allowed” recordings to them.

Right there that means all those calls are being answered and now if you’re being blasted the PBX is actually processing all those calls (as short as it may be) and taking up RTP and other resources.

So again, I personally am a fan of turning them off because I’m a fan of my systems no doing more work than they really need to and not taking away resources for valid users because I’m letting random requests in to blackhole them.

2 Likes

I have my FreePBX in the cloud. I also manage an OpenVPN server in the cloud. I am using pfsense (on site) to connect to OpenVPN and from there to FreePBX. I only allow the OpenVPN IP address and the SIP providers IPs and port ranges to access the FreePBX on the cloud Firewall. Pfsense (and all the endpoint) can connect directly to the FreePBX using the VPN.

Additionally, I wrote a script to send me an email (within minute) if the system was accessed from any unapproved IP.

I do not use LetsEncrypt, they keep changing their IP addresses. I used Certificate Management to upload third party (cheap) SSL certificate for UCP users to send faxes (we use the FreePBX as fax system as well).

On smartphone, I have OpenVPN app connected to the OpenVPN server (to get an approved IP).

1 Like

@BlazeStudios thx! I already had those both turned off. I’m really sursrised that FreePBXHosting had those turned on by default. Definitely best practices to turn those options off.

@moussa854 can you post who you use for your ssl certificate?

Also, who do you use to host your 2 VPS instances? It sounds like you are not using FreePBXHosting/Sangoma.

If anyone out there is using FreePBXHosting to host their business phone system, I would really like to hear. Thx!

Those settings have nothing to do with FreePBXHosting.

My aim is to provide encryption for UCP/admin GUI users (just in case), so I got my certificate from gogetssl.com ($7.75 for 2 yrs). My FreePBX is installed at GCP, see [How-to] Install Freepbx distro (with commercial modules) on Google (cloud) Compute Engine. GCP provides $300 for one year, so essentially your FreePBX is hosted for free the first year. I was able to manage my OpenVPN community edition on f1-micro machine (I do not have much traffic) https://cloud.google.com/free/

If you decide to give it a try I suggest using https://downloads.freepbxdistro.org/ISO/SNG7-FPBX-64bit-1805-2.iso to avoid error in installing the cloudendure agent. Then you can update the system through SSH. The modules can be updated through the admin GUI.

1 Like

@moussa854, that is exactly what I needed. Thx!

I’m still holding out (hoping) someone in the community is actually using the FreePBXHosting/Sangoma cloud since that’s the strongly recommended solution at freepbx.org.

Anyone out there willing to share their Best Practices & VPN configurations??

I am, but not using VPN. I have iptables setup to pretty much only allow http/https/ssh/etc access from my two IP addresses.

Anonymous connections off. Fail2ban running. I don’t recall what else… found a document a long while back about hardening FreePBX.

1 Like

@brk Thank you very much for responding! I’ll look to see if I can find that hardening FreePBX doc and post a link.

It makes me feel a little better that there are installations out there that are not using VPN and are not having issues.

Are you using FreePBX to provision your phones (vs manual config)? If so, do you force then to provision off https only or do you allow http as well?

Lastly, I’m assuming your http/https/ssh/etc services are all on the standard port numbers. If not, can you say which ones you recommend moving?

I prefer to use the standard ports because a) it’s less headache, and b) security through obscurity is not robust, imho. If the system can’t withstand a brute force attack on the standard ports, it’s not going to do any better on the “hidden” ports once they are discovered by the attackers out there.

FWIW… Here are the open ports on our FreePBX instance. These are the ones allowed by the default configuration provided from FreePBXHosting.com as of August 2019:

PORT     STATE SERVICE
22/tcp   open  ssh
53/tcp   open  domain
80/tcp   open  http
81/tcp   open  hosts2-ns
82/tcp   open  xfer
83/tcp   open  mit-ml-dev
84/tcp   open  ctf
111/tcp  open  rpcbind
443/tcp  open  https
1443/tcp open  ies-lm
3306/tcp open  mysql
4443/tcp open  pharos
5000/tcp open  upnp
5060/tcp open  sip
5061/tcp open  sip-tls
5222/tcp open  xmpp-client
8001/tcp open  vcom-tunnel
8080/tcp open  http-proxy
8088/tcp open  radan-http
8089/tcp open  unknown

I’d love to see a list of what you have open @brk. If anyone has an opinion about Best Practices for an extern, cloud-based FreePBX server, this would be the place to reply. :wink:

Let’s keep in mind one thing here, FreePBXHosting is a company that sells VPS systems that have FreePBX pre-installed and with some commercial modules installed. That’s it.

It’s your PBX they can’t decide what you are going to do with it or not. They don’t know your IPs or security concerns. Just like with any other VPS hosting company, you need to do this stuff.

1 Like

@BlazeStudios, I am 100% clear on that. And, I am actively “doing that stuff.”

In fact, that’s what I’m doing right now, right here. :sunglasses:

What I’m asking the community is what they have done and what they have found to be Best Practices so that other n00bs like me will have some general guidance to gleen when they are working on their “Stuff To Do” list.

It sounds like you might have some valuable experiances with just exactly this configuration. I’d love to hear what you have found to be effective. I hope you’re willng to share.

-Mark

Do your remote sites have static IPs? Will your users use UCP from the office? From home?

@billsimon, we have two main sites which have static IPs. We have 16 additional sites scattered over 5 states that have dynamic IPs assigned by the local internet service provider. If it’s not considered a security risk, I’d love to allow our field reps and executives to install softphones on their cellphones as well. Those would have very dynamic IPs that would change throughout the day depending on their geographic location.

No one is using UCP yet. I suspect most UCP users will be offsite.

Most of the people with phones on their desks will probably not use UCP, and a small number might try it out from their office PC.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.