Cloud Deployment Security

Hello all,

Deploying FreePBX 14 on a VPS.

Will have roughly 200 Polycom VVX 201/310/410 phones registered. Some will be in our offices located throughout the state, some will be in employees home offices. We will be using the commercial EPM module for provisioning.

With a previous, smaller cloud deployment I set up the Sangoma Smart firewall and set the whitelist for ADMIN/UCP/SIP Registrations to either static IP’s or dynamic DNS hostnames. I’m unable to do that this time due to so many dynamic IP addresses registering. Can’t handout dynamic DNS hosts to everyone.

I figured if I set the Sangoma Smart Firewall up with strict rules, minimum password attempts and long fail2ban jail times, this should be sufficient.

Any further tips for locking the system down? Any special precautions for using the EPM in a cloud environment? I’ve only deployed it in on-premises situations.

Any guidance is greatly appreciated! Thanks!

I would suggest ensuring your provisioning services are secured, don’t leave tftp port open to the public.

I don’t use polycoms, so no clue if https provisioning is supported.

At the end f the day it’s all risk management, assigning ddns to the very one will suck, are you willing to accept the risk.


Thanks for the reply! Polycom phones do support https provisioning, unfortunately they are extremely picky with SSL certificates. I was thinking about securing the provisioning files with .htaccess over HTTP.

While I certainly don’t mind issuing DDNS to all remote employees, I just don’t know an easy way to manage the hostname updates of approximately 100 remote IPs.

Thanks for your recommendations!

You might be surprised by how few “networks” you might really need for 100 remote IP’s, even the dynamic ones they are usually within a quite small subnet, cable companies, providers etc. tend to be quite granular as to sub-nets used in any particular area. Add the Cell companies (only a small risk that the knuckle-draggers are using those networks)

We are not allowed to post full bash scripts here, but a simple wrapper around

and parsing the result with jq will return the network of each of your

rasterisk -x 'sip show peers'|grep OK|egrep "^[0-9]+"|awk '{print $2}'|uniq

should give you an idea

The System Firewall has a Responsive Firewall feature that allows minimal access to the SIP ports to allow devices to register while blacklisting/blocking attackers or bad attempts.

Running FreePBX in the “cloud” is like any other server you have connected to the Internet, you’re going to want to secure it regardless. Between your own security and the System Firewall you should be just fine. I run this all the time in the “cloud” and I don’t have issues.

In fact I’ve been providing services for over 10 years “remotely” to customers. All with different networks and setups from homes to offices. I have yet to be hacked because of just basic, simple, standard security logic that is applied.

You’re overthinking and complicating this issue.

@BlazeStudios can u please elaborate on some of these basic standard security logic you have implemented.

@frankb Mainly nothing more that SIP proxies facing everything and having proper iptables to allow/analyze the traffic that gets through.

1 Like

Would love some detailed info on this.

Can you share with us more?

Also, do you use the built in VPN server, or any other VPN Clients to improve security?

Thank you

I mean really that’s about it. I don’t provide services outside of North America generally so anything not ARIN IP space is automatically denied. The PBX systems are locked down to only accept traffic from the proxies and other servers in the network. The proxies do most of the work, tracking the SIP requests and User Agents. Everything has to go through the proxies which say what can be done and what can’t be done. The only thing that makes it to the PBX systems is what is allowed and sent by the proxies.

Having said that - there are lots of people that use “cloud” services and don’t sit behind firewalls or proxies. For these people, keeping their system’s safe and keeping their money in their checking accounts is a constant struggle.

Setting up the integrated and responsive firewalls correctly is the first line of defense, and many people simply don’t have the wherewithal to do much more than that. I’m with Tom - I’m responsible for the security on my systems, so I choose to always implement my systems with at least two layers of firewall defense. This, from having had one of my servers hacked and paying out hundreds of dollars for foreign phone access, is the minimum I will even consider any more.

@cynjut I am 100% in the “cloud”. Most of these places have firewall services to use with your servers on their network. They also offer, if all your servers are in the same DC, private networks.

Security isn’t magic, it’s compromise and logic.

Not sure how you came to the conclusion I thought it was magic, but that’s OK.

My point - which I’m apparently still trying to make, is that Security isn’t magic, it’s work. You can’t just throw a server on the Internet (anywhere, cloud or not) and expect other people to do the work for you. While many places do have the facilities for setting up security, some don’t - these providers are not helping their customers. We see it every day - how many posts a week do we see where someone is trying to figure out why they are seeing thousands of “wrong password” entries in their logs?

Even the providers that do make the firewall and security features “available” aren’t always helping. Without doing what needs to be done to secure the network, you are at risk. There is no one that’s going to ensure you are doing the right things. Not knowing what you need to do doesn’t make it so that you don’t need security - ignorance and lack of availability aren’t acceptable ways to prevent bad actors from stealing money and services from us.

The fact tat the original poster is ignorant of what needs to be done is only part of the problem. Setting up proxies and firewalls isn’t rocket science, but if people aren’t willing to do the work, there’s no amount of help we can provide them that will keep them from screwing this stuff up.

That was a general statement on the overall conversation.

The reason why this ignorant original poster asked for guidance is so that I can learn from those who have more experience than I do. Not trying to be “part of the problem”, I’m trying to prevent problems.

Also, at no point did I say I was unwilling to do anything.

At no point did you say anything like that - the discussion has become much larger than your original question.

Ignorance isn’t a trait - it’s a situation; stupid is a trait. We can fix ignorance through pointers and trying to help you understand the kinds of things that help and the kinds of things that don’t. We’re not always good at it, but that’s our goal.

So, back to your original question:

because your provider hasn’t set you up with any sort of reasonable firewall and you are unable to set one up on your own, you need to set up the Integrated Firewall and do your best to establish which networks are and are not trusted. Once you have those set up, you can turn on the Responsive Firewall to allow connections from your roaming connections. These should be limited to extensions only (no trunk configurations should require Responsive Firewall) and should be done to an “uncommon” inbound UDP port (try to avoid using the “standard” VOIP ports where you can.

Note that a few of the FreePBX ports are managed through the Responsive Firewall, so once you establish your connections with that (username and password are validated) the rest of the UCP, etc. ports should loght up and work.

An improved level of security can be added if you can get phone-level VPNs set up. If everyone can get on a VPN connection, you can (once again) do away with the Responsive Firewall.

Establishing a SIP Proxy can also help you by allowing you to point all of your connections at that and have it manage your traffic.

Dave, thank you for that reply. That really made sense and has me thinking about a few different possible routs to take.

My VPS provider is Vultr. I have their firewall set up to block all incoming request except for SIP (5060), HTTPS (443) and RTP. Everything else, including SSH, is blocked by Vultr’s firewall. Additionally, I’ve set up as much fraud prevention measures with my SIP trunking provider, Flowroute. I’ve enable outbound allowed IPs, disabled SIP credentials and restricted all outgoing calls to lower 48 states only.

Now, back to my PBX side of the equation… I’ve been looking into SIP proxies as well as session border controllers. Seems like I need a proxy more than a SBC. I’ve been reading up on Kamailio. Seems to have been around a while and has a large following. Also seems that it can be deployed with limited resources and still remain robust and scalable. I could always spin it up on a $5 Debian VPS with Vultr.

I also believe that Vultr supports private networks.

I think I understand the overall use of a SIP proxy server, any recommendations on where to begin or any words of wisdom before getting my hands wet?

Fortunately, we aren’t in a hurry to deploy so I have time to learn everything from the beginning, making sure it’s done right.

Yes you can enable private networks, best to statically assign them all in the same network.

we do this and have kamailio/(siremis for the cli allergic) proxying all the macines over eth1. if you do that then it is also an ideal canditatw machine for homer, saves bandwith costs and makes firewall/ids much simpler.

1 Like

First, go nuts and spend $10/month since Kamailio does make a lot of database queries and who knows what else you may need to make modifications for and how much you’ll want to store in memory before loading. I can tell you right now, using the LCR module properly will require more than a $5 VPS for the memory it will need to use.

Second, step back and ask “Do I really need a private network?”. Not saying there is nothing against having it that way but do you really need it? Because you have to take into consideration a few things. 1) On the Vultr side, your Ethernet configs are now all manual. 2) You still need public access 3) If using Kamailio and done properly all your end points will source from one IP, Kamailios. So you expose the PBX to only that one IP.

Third, using a private network will require 100% that you need RTPProxy or RTPEngine running on Kamailio because you are actively going to need to update the SDP details each time SDP passes through Kamailio so that it goes from the public IP to the private IP and vice versa. If this isn’t done or done properly, you will have No-Audio/One-Way Audio issues from the jump.

Fourth, Siremis is great but it is a database management and reporting GUI. It does allow you to issue some KAMCTL and other CLI commands from it but that’s ALL it does. It does not create routing, rules or do any pre-generated programming configuration for you. It lets you add users and it generates the two needed ha1 and ha1b hashes but outside of that, it’s just adding/editing/deleting stuff from the database.

You want Kamailio to process INVITEs from X IP/Domain differently than Y, you have to write the code yourself. You want to proxy one domain but do Location services for another domain, you have to write the code. Your routing selection, your failover handling, Presence, Subscribes, etc, etc, etc all of that has to be coded/written by you. There is nothing that is magically going to generate this stuff for you.

Oh this includes LOGS. You have to tell Kamailio what to log and when to log it. I actually spent hours on the logging process alone in my switches. But I also use cfg variables that can be adjusted realtime via the CLI to control that logging output. So I actually have a “SIP Debug” level that will show the SIP message in more depth. I have a “Firewall Debug” to show more of the SIP Firewall process.

Kamailio is something that can be setup quickly and very basically with little bells and whistles and work 100% but if you want real logging, routing logic, etc you’ll need to block out some serious time to put this together.

Not to mention, depending on your end goal, you’ll be making updates to FreePBX to make it work with the setup properly.