Today we’re pleased to introduce a new state-of-the-art Travelin’ Man 3 firewall implementation for 2017. Five years ago, we developed a new security model for Asterisk® servers that whitelisted those needing access while blocking everyone else. The design was simple. You can’t attack what you can’t see. Three years ago, we made Travelin’ Man 3 more flexible for remote users with the addition of PortKnocker, a terrific tool providing temporary remote server access using a random three-number code. Today’s release further streamlines the firewall management process. Trusted users can permanently whitelist new IP addresses from anywhere using any PC or smartphone.
Travelin’ Man 3 Overview
If you’re new to Travelin’ Man 3 and the Linux IPtables firewall, here’s a quick overview. IPtables is a software-based firewall that is integrated into the Linux kernel. It consists of rules that define which IP packets hitting your server are allowed through the gate. The whitelist methodology behind Travelin’ Man 3 works like this. We predefine a list of trusted VoIP providers that get SIP and IAX access to your server so that you can easily set up trunks for incoming and outgoing calls. Then, as part of the Incredible PBX installation procedure, we whitelist all non-routable IP addresses as well as the public IP addresses of your server and the PC from which you installed Incredible PBX. Nobody else can even see your server on the Internet.
New Travelin’ Man 3 Design
With today’s new Travelin’ Man 3 design, you can whitelist additional IP addresses in several ways. First, as the administrator, you can log into your server as root and whitelist any IP address using the add-ip script in the /root folder. If a fully-qualified domain name (FQDN) is associated with the IP address to be whitelisted, the administrator can use the add-fqdn script to add the FQDN. If the FQDN points to a dynamic IP address that is refreshed using a dynamic IP update service, then Travelin’ Man 3 will refresh the firewall at 10-minute intervals to assure that remote users always have access to the server. This differs from previous releases of Travelin’ Man 3 that required a manual entry in /root/ipchecker to enable automatic refreshes.
A third method for permanently adding whitelist entries to your firewall is now provided using PortKnocker which is an integral component of Incredible PBX. By providing your PortKnocker credentials (/root/knock.FAQ) to any user, that user can easily gain one-click permanent access to the server using either the NMAP utility from a remote computer or the iOS PortKnock or Android DroidKnocker apps available for smartphones. As in previous releases of Travelin’ Man 3, an administrator can remove whitelist entries using del-acct utility in the /root folder. All admin and user-generated whitelist entries are stored in /root with a file extension of .iptables. Those generated using PortKnocker are automatically assigned a filename consisting of the timestamp associated with the time at which the whitelist entry was created. IMPORTANT: To authorize PortKnocker to permanently add IP addresses to your firewall, there is an activation step. Log into your server as root and issue the following command: iptables-knock activate
As part of the new implementation of Travelin’ Man 3 for the Incredible PBX for Wazo platform (only!), we’ve also reworked the firewall design a bit. There were several serious limitations in the original IPtables implementation of TM3. First, while IPtables allowed FQDN entries in its main configuration file, if one or more of those domains was off-line when IPtables was started or restarted, the entire firewall came crashing down leaving your server unprotected. In prior implementations, we avoided catastrophe by always using our iptables-restart utility to start and restart IPtables. This utility automatically tested for firewall failures and removed FQDN entries that caused the problems. A second limitation in the original Travelin’ Man 3 design involved an administrator who inadvertently used the iptables save command to modify an existing IPtables setup. Whenever this command is executed, IPtables immediately rewrites all FQDN entries in its configuration by converting them to IP addresses thereby eliminating the ability of the firewall to account for dynamic IP address changes occurring thereafter. Perhaps the most dangerous limitation occurred where your server’s network connection was not yet active when IPtables was started. If your configuration included FQDN entries, this would always cause IPtables startup to fail since FQDNs are all tested for availability as part of the initialization process. With Incredible PBX implementations, we have designed some safeguards into the network startup process to minimize this risk, but it would still be a problem if an administrator happened to notice that a network cable was unplugged and chose to plug it in after the server had already booted. Yes, the network would come on line. No, the IPtables firewall would not if there were FQDN entries in the config causing an IPtables startup failure.
Here’s a quick summary of the new IPtables design. First, there are never FQDN entries in the main IPtables config file, /etc/iptables/rules.v4. Instead, all custom whitelist entries now are generated in /usr/local/sbin/iptables-custom. The startup and restart procedure with iptables-restart now works like this. First, IPtables is started with the rules.v4 rules. Next, Fail2Ban is restarted as a second layer of protection for your server. Finally, the custom rules including all of your whitelisted IP addresses and FQDNs are started by running iptables-custom. If individual custom rules fail, they simply fail. They won’t bring down the firewall or Fail2Ban. Custom rules in iptables-custom look like this:
/sbin/iptables -A INPUT -s yourFQDN.dyndns.org -j ACCEPT
It should be noted that, if an administrator, inadvertently restarts the firewall without using the iptables-restart script, the consequences will be that the custom whitelist rules will not be loaded and Fail2Ban may not function properly. This shouldn’t be a problem because those with whitelisted remote phones will soon be calling with complaints that their phones are off-line. 🙂
As with all servers, your Incredible PBX server is only secure as long as you have no rotten apples in the employee pool. So, yes, there may come a time when it becomes necessary to modify your 3-number PortKnocker credentials to block an employee who has been terminated. The three steps to do this would be the following. First, edit /etc/knockd.conf and change the 3 port addresses in the sequence entry. Second, restart PortKnocker on your server: /etc/init.d/knockd restart. Third, modify /root/knock.FAQ to reflect your newly assigned ports and redistribute the file to remote employees.
Ready to get started? Hop over to the latest Incredible PBX for Wazo tutorial and fire up a new server. If you have an existing XiVO or Wazo server and you’d like to implement the new Travelin’ Man 3 design, here’s a tutorial to get you started. Enjoy!
Published: Monday, February 20, 2017
Need help with Asterisk? Visit the PBX in a Flash Forum.
Special Thanks to Our Generous Sponsors
FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.
BOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.
The lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.
VitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
Special Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.
Some Recent Nerd Vittles Articles of Interest…
Ward and XiVO/Wazo Teams,
Please keep up the great work!
What if you dialed into the server and gave it the 3 port knocking numbers e.g. 233*245*478 as a string for your credentials. Then give it your Internet IP address of your remote location e.g. 999*888*777*666 to open the door.
You could also add a PASSCODE for security.
Then have the script repeat the external IP address of the VoIP server using text-to-speech for the remote user to use.
I have an agi-bin script that you enter an IP address and the system PINGs the IP and returns the results to you.
I also have an agi-bin script that gives you the external IP of the VoIP server.
Just thinking out loud!
[WM: Great minds think alike. Take a look at Travelin’ Man 4. 🙂 ]