(Or, “Oh no, The Aussie is Blogging Again!”)
It’s a rare day that someone doesn’t come into our IRC channel or forums asking for help with their firewall settings. Usually it’s because they twiddled a knob, or pushed a button on their firewall that they shouldn’t, or even worse, they didn’t twiddle a knob that they should have! After a day of me continuously moaning on IRC about how people just don’t understand firewalls, how there isn’t a good one, and how people just throw things together and go “that’ll do”, my complaints were picked up and echoed around other various forums, by Bloggers who watch our IRC. This made me realize that it wasn’t just me who was irritated by this, and that’s when the idea of a proper FreePBX Firewall was born.
Credit to XKCD, https://xkcd.com/1583/
Firewall was, at first, a quiet “Skunkworks” project, but after we sat down and figured out how much this would help the whole community, it was blessed as an official FreePBX project, and has since been released as a module for FreePBX 13!
Historically, we’ve seen a huge number of people who have either had some half broken default firewall installed by their distro, or, have installed one themselves after a random google search returns (often terrible) advice. This almost always causes many more problems than it solves. These firewalls usually default to being massively over enthusiastic and block large chunks of needed traffic, or, they require constant hand-holding and fiddling to keep them working. This tends to cause people to give up and turn them off, or open them far too wide — either because it was TOO configurable, or, not configurable at all without understanding raw iptables rules and memorizing the periodic table backwards!
Credit to XKCD, https://xkcd.com/1014/
I saw this as a pretty fundamental problem with third party firewalls and resolved to fix it. Additionally, since FreePBX is an Open Source project, I wanted to make sure everyone else had the opportunity to make suggestions and recommendations, too. I realise that not everyone is as deeply involved in security as I am (and where my background has been for years) but you’ll be happy to know that I also realise that I am quite often not the best person to write user interfaces. I tend to make them nerd friendly, with lots of knobs and buttons to twiddle and push, not human friendly with a simple On and Off setting. So I started a couple of threads in our forums, which sparked a lot of great discussions and ideas.
As a starting point of the design, when thinking about this, I took a step back and pondered the basic, and important question “What is a firewall meant to do?” The answer is, of course, “Keep bad guys out, and let good guys in.” Unfortunately, a lot of the current crop of firewalls have changed the answer to be more along the lines of “Keep everyone out until they cast some magic incantation.” That magic incantation could be something like “Enter your current IP address after dialing some phone number” (How are you meant to dial a number, if you don’t have a working phone?) or “Connect to some random ports on a remote machine in a specific order”, or other overly complex and unneeded things (that, sadly, usually result in the firewall being abandoned). This is something we see in our paid support department on a weekly basis, as the users often turn these default firewalls off because they can’t get their SIP trunk provider or remote phones working.
That is unacceptable! A firewall should not make your life harder. A firewall should make your life easier! (Much easier, in fact, by ensuring you don’t have bad guys attacking your server!). You, as a user, should also never need to do a pile of configuration just to get it to a sensible starting point.
Firewalls can (and often do!) have a large number of nerd-friendly knobs and buttons to twiddle. But I wanted to make this as simple and easy for our users as possible, so I worked hard to constrain my ‘Add a button!’ desires. This means that there’s probably not as much configuration as you expect to see in a firewall — EXACTLY what I wanted to achieve!
I’m also lucky in that I was able to build the firewall around the concept of “This firewall is going to secure a FreePBX Server and that’s it”. I know exactly what FreePBX wants, and FreePBX can tell the Firewall module which firewall rules to care about. This removes most of the complexity that people have to deal with in standard firewalls, and lets me get it to the “Zen-like” On and Off settings that I wanted.
Screenshot of the main screen of the Firewall module, when it’s enabled.
With this goal in mind — of it being secure, extremely intuitive, and easy to use so that people actually use it instead of turning it off — I then asked myself “What do FreePBX installations need?” and came up with this short list:
- By default block everything that shouldn’t be coming in.
- Examine the PBX configuration and open up specific IPs and Services for everything the user has indirectly configured in their PBX.
- Find a secure but usable way to automatically detect legitimate remote users who don’t have static IP addresses but need access, and make it easy for them to get to the services and phone access they need while safely blocking everything else out there (I’ve coined this the Responsive Firewall, more on this below!).
- Provide GUI access for common advanced firewall settings so knowledgeable users who need to do more can do so within the Firewall, and aren’t forced to turn it off so they can do their own thing.
Since I was able to tightly define what the firewall needs to secure, I was then able to put in a lot of VoIP specific intelligence that normal firewalls can’t do. For example, you can expose your SIP ports to the global internet, if you have the need. Normally that’s a terrible idea (and I can hear people lining up to tell me how wrong that is, and how they’re going to punch me in the nose for even suggesting that), and normally I would agree.
However, because this firewall is deeply integrated at a very low level of your system, it can be far more intelligent than a normal firewall. If you’re familiar with firewall concepts, you’ll, of course, see the standard things you expect from a modern firewall, such as zones, network interface configurations, and lists of services (such as SIP, SSH, HTTPS and so on….) Those are all important capabilities in a firewall and are there to allow more advanced configuration by advanced users.
But, where it really shines is the tight integration with FreePBX. The first and most useful integration is to constantly scan your FreePBX configuration and automatically configure the firewall to match it! For example, we’ll detect trunks you’ve configured with your VoIP providers, or other branch offices, and automatically allow those in. We’ll even update the IP addresses on a regular basis, if you’re using dynamically changing hostnames (DDNS) or domains.
At this point you’d think I would have stopped, but where things get REALLY handy is the second integration, the Responsive Firewall.
Screenshot of the Responsive Firewall, when it’s enabled.
Of course, it would be wonderful if everyone always used a VPN when away from the office — and, in fact, we’ve put a lot of work into enabling that capability with the new VPN module (more on that to come, but that topic will be left for a future blog). For the rest of us, there’s the Responsive Firewall. If you enable Responsive Firewall and expose the selected protocols (SIP or IAX), the firewall will actively validate clients that are trying to connect to the machine on the selected port(s). This is somewhat similar to what fail2ban does, but fail2ban is passive, banning an ip by looking at logs only after too many failed attempts.
FreePBX Responsive Firewall, on the other hand, detects the fingerprints and patterns of known attack tools at the Operating System level, and blocks them quickly, BEFORE they have a chance to try more than a few attempts! However, to make sure a legitimate error doesn’t lock you out, Responsive Firewall is designed to tolerate common errors (such as the misconfiguration of a phone with the wrong password) by detecting the pattern of such issues and not immediately locking that out, while still being able to block illegitimate break in attempts. (Too much fumbling can still result in getting locked out, but a lot of thought has been put into minimizing this while maintaining high security levels.)
This is, to put it simply, an incredible leap forward in VoIP security. There’s a new Sheriff in town ready to stand up to those brute force attacks of known extensions! Where needed, you can simply put your FreePBX server on the internet, or in the DMZ of your office network, and allow the System Firewall to correctly and securely manage your machine, blocking attacks as they’re detected, but still permitting approved clients through, all without you needing to raise a finger.
But, after all of this, Firewall is still not finished. This is an Open Source project. Everyone has access to it, everyone can read it, everyone can change it! If you think it’s missing something, tell us! If you think it’s doing something wrong, YELL at us (nicely)! If you think you can do it better, do it! Then make sure you click the ‘Pull Request’ button in Github so we can make it better for everyone!
I still have a couple of pending things on my todo list. The highest priority is to allow you, via User Manager, to assign firewall rules per user.
For example, you should be able to specify that Extension 300 only has access to UCP, but Extension 301 has access to the UCP, as well as WebRTC access to make calls from their browser. However, Extension 333 is the admin, so they have access to the main FreePBX Admin interface, as well as SSH access. All of these rules will be automatically applied and removed as their phone connects and disconnects.
Today there are some simple defaults (it opens up access to UCP when a phone has successfully navigated the Responsive Firewall and registered). We’ll also add additional integration to the VPN module, so once you’ve made a secure VPN connection from your computer, we’ll open up the external IP address and proper port that you’re coming from so that the phone itself can register, if the phone is not capable of making it’s own VPN connection.
To ensure the utmost security, the FreePBX Firewall module depends on an RPM package provided by the FreePBX Distro. This means you need to be running the FreePBX Distro (or another distro that is derived from FreePBX Distro) in order to run the module.
I’ll be reviewing what’s involved in making these bits of supporting technology available for other Linux distributions once I get back from Astricon and my other jet setting plans around the US over the next few weeks. In the meantime I’d love to see you try the new Firewall, and keep that feedback and those ideas coming, in the Forum thread!
Thanks for reading and I hope you like what I did!
