In the cloud-enabled, highly networked world of VoIP, security is one of, if not THE, most important facets of proper software engineering. The FreePBX Development team takes security seriously, and when vulnerabilities are discovered or reported, we have a fantastic history of responding and mitigating issues quickly. We aim not to just resolve issues as they are discovered but have a goal of continually developing with security in mind – this is paramount in today’s world with many Big Bad Wolves constantly trying to get into your PBX.

Security is not just another bullet point item. You cannot just bolt it on at the end of the development process, or at the time of installation. You must consciously design security into your application or service from the very beginning, and make it a continuous part of the entire process from design through implementation to testing and release. To keep on top of this — and so that we implement the best security practices and methodologies as they evolve — we are continually revising and revisiting FreePBX code, from something that was written yesterday, to code that goes back more than 10 years!

Sadly, in today’s world of Internet telephony you are just as likely (if not more so!) to have a system attacked and compromised from within your local LAN as you are from an external connection, so implementing a firewall and other perimeter protections, while vital in themselves, are no longer enough.

There are some integrators that recommend you just do the equivalent of building your security out of a bundle of various different security packages – just like building your house out of sticks. Sure it might be quick and easy to do that, and yes – It’s true that the more obstacles you put in the way of a drive-by attacker, the more likely it is they will move on to other lower hanging fruit. But this often has the unexpected and unwanted consequence (we have seen in far too many instances) that when this ‘House of Sticks’ – because it hasn’t been planned and designed from the ground up – makes their platforms too restrictive to the end users, or even removes functionality inadvertently!

If user panels and other Unified Communications aspects of a system are too laborious to utilize then one of two things will happen – either people will not use them, or system administrators will start pulling sticks out! This has the potential to significantly weaken the security of the overall system in the process, as quite often there’s no obvious and documented reason WHY a random security policy was put in place.

So, instead of building your security policies with a bundle of sticks methodology, we focus on building and improving the core of the FreePBX platform, brick by brick. We ensure that everything from the OS, Asterisk, and FreePBX, is maintained and monitored as one. In several cases we have released patches for the FreePBX Distro before the upstream maintainers have! This is why we believe that a strong foundation is central to a strong and secure house, or phone system.

Security and system updates are built holistically, and are much more likely to survive attacks from the Big Bad Wolf, than systems built with straw and bundles of sticks. Even if the Big Bad Wolf huffs and puffs and blows away your bundle of sticks, we do our best to ensure that the core, made of bricks, is still going to be there, standing strong.

One recent example of our engineering in security is the Signature Checking, or Module Signing, that we implemented in FreePBX 12 and onward.

If you purchase a proprietary PBX platform, it’s shipped from the manufacturer pre-loaded with its own software and firmware. Not that you can typically interact with the code on those appliances, however since the return address on the package is from the manufacturer, you can reasonably trust that the software installed is authentic and unmodified. Even then, there have been well publicized cases of this not being true! We wanted a way to allow users to independently confirm that the FreePBX software on their server hadn’t been changed by an additional, unexpected third party.

Module Signing takes a two-pronged approach. The first avoids the most common issues on an insecure Internet – it validates that the packages you’re downloading and installing are the ones that you’re EXPECTING to download and install, by cryptographically signing the module packages (exactly the same, in fact, as Debian and Redhat do with DPKG and RPMS!)

The second is a constant monitoring of the FreePBX files on your system. If a file is changed, the FreePBX machine sends you an email, and displays a warning on every page, as soon as it detects that something wrong is happening.

Module Signing uses the standard, proven and well known, Web of Trust, as implemented by GPG. This is a decentralized trust model where there are many independent webs of trust, which any user (through their identity certificate or key) can be a part of.

Module Signing also assists in ensuring integrity and authenticity, by anyone being able to answer the two important questions “Who published this module?” and “Was this module changed since it was published?” Both of these questions are able to be easily answered, by even an unskilled user, by simply looking at the publisher of the module and making sure that no security alerts are being displayed.

We looked at what other Open Source projects were doing, and implemented Module Signing using the same methods that Redhat and Debian/Ubuntu are using, as these methods have been successfully proven to be secure. Coincidentally, almost immediately after we implemented and published Module Signing, we were alerted by the community to an active and in the wild vulnerability that was then quickly patched.

Next week we will discuss utilizing the FreePBX Distro, which not only gives you a quick method of installation of a FreePBX System, but also the OS and other dependencies while at the same time allowing you to keep the entire PBX platform updated.