We're big fans of playing with our own VoIP hardware. It has the advantage of allowing the installation of everything behind a secure, hardware-based firewall thereby eliminating almost all of the security issues associated with VoIP telephony. With PBX in a Flash™ and its Zero Internet Footprint™, you can run a secure VoIP server in your home or office with no port exposure to the Internet. This setup, of course, assumes that you have the necessary bandwidth to support Internet telephony and that you possess the necessary skill set to maintain your own Linux® server running Asterisk®, FreePBX®, Apache®, SendMail®, PHP®, and on and on. Not everyone does. And, of course, there are thousands of organizations in which employees and their phones are not colocated with the home office VoIP communications server. And, believe it or not, there are folks that run their VoIP server on the public Internet without any firewall protection. For all of you, today's your lucky day.
Lest you think that we've bitten off more than we can chew, we want to acknowledge the dozens of thought-provoking comments on the PIAF Forums that ultimately led to today's new release. That is the hidden beauty of open source development. So, thank you dad311, atsak, tbrummell, Hyksos, markieb, Ramblin, darmock, lowno, blanchae, bmore, vcallaway, jroper, mag, briankelly63, mbellot, phonebuff, The Deacon, Astrosmurfer, frontline, ou812, LostTrunk, lgaetz, kh40s, rossiv, and all of our other gurus that make the PIAF Forums a great place to learn something new every day.
Thanks to our good friends at RentPBX, who provide terrific technical and financial support to both Nerd Vittles and the PBX in a Flash project, you don't have to roll your own. And your phones can be anywhere because your communications server sits on the public Internet. If cost is a factor or for those outside the United States that need a U.S. presence to take advantage of services such as Google Voice, the $15 a month price point using the PIAF2012 coupon code makes RentPBX more than competitive with what it would cost you in electricity, Internet bandwidth, and hardware resources to do it yourself... minus the headaches. You get a stable PBX in a Flash or Incredible PBX platform from the git-go. In addition, issues of jitter and latency all but disappear from the VoIP equation because you can choose the site of your hosted PBX from a worldwide list of Internet POPs including five regions in the U.S. as well as Canada and Europe. Many sit within a few milliseconds of the Internet backbone.
What you don't have with a hosted PBX solution is a hardware-based firewall sitting between your server and the Big, Bad Internet. With PBX in a Flash, the risk is lessened because the IPtables Linux Firewall is baked into the fabric of PBX in a Flash. For a comprehensive overview of how IPtables works, read this article. It explains IPtables better than any book you could buy.
Today we're pleased to introduce Travelin' Man 3™, a completely new security methodology based upon FQDN Whitelists and DDNS. In a nutshell, you get set-it-and-forget-it convenience and rock-solid VoIP security for your Cloud-based PBX or any PBX in a Flash server that's lacking a hardware-based firewall and you get both transparent connectivity and security for your mobile or remote workforce. We'll quickly cover the mechanics of this new IPtables methodology that allows you to secure your hosted PBX without compromising flexibility. The nitty gritty details of IPtables and firewalls we'll leave for you to explore at your leisure.
And, speaking of leisure, we always get the question: "Have you tested it?" For frequent readers of Nerd Vittles, you already know the answer. We eat our own dog food! In the case of Travelin' Man 3, we gave it a healthy workout just last week from the deck of the Carnival Fantasy as we passed by Cape Canaveral and in Key West with 4G service, and finally in several ports with WiFi access in the Bahamas. The beauty of the new design is you'll know instantly if it's not working because you'll never get your VoIP SIP phone to connect back to your VoIP server. We had zero problems using nothing more than an Android phone for both DynDNS updates and Bria SIP phone service. Being a pioneer isn't always easy, but... Somebody's gotta do it™. 
Unlike previous iterations of Travelin' Man, version 3 lets you configure remote phone access from the server and keep one or hundreds of phones in sync even with changing IP addresses using dynamic DNS update software at the sites of the remote phones. Whether the site is a remote office or a floating hotel room, any PC or Mac whether it's a desktop or netbook can automatically manage the dynamic DNS updates while keeping all of the local phones securely connected to the VoIP Cloud. And any jail-broken iPhone can manage the updates as well. With Android phones, it's even better. You have your pick of several great apps: DynDNS Client, Dynamic DNS Client, or Dynamic DNS Updater. We've found the DynDNS Client to be nearly perfect. As we'll explain in a minute, this version of Travelin' Man is not compatible with prior versions so you'll need to choose either the manual methodology of previous iterations or version 3 which does it automagically.
A New Approach to WhiteLists. Our new approach to IPtables is to lock down your server using a WhiteList of safe IP addresses and fully-qualified domain names (FQDNs) that should be given access to your hosted VoIP server. Then we'll periodically check to see if the IP addresses associated with the FQDNs have changed and make the necessary adjustments automatically. If any intruder attempts to access any port on your PBX, their packets are simply discarded by IPtables so the bad guys never know your server exists.
We've experimented with BlackLists for VoIP security, and the bottom line is they just don't work because of inherent problems with reliability and completeness. You spend your entire day updating lists of the bad guys only to discover that they've morphed to thousands of new IP addresses. Think Whack-A-Mole. IP addresses can easily be changed, and zombies have made attacks from third-party PCs a daily occurrence. Earlier this month, Nerd Vittles was hit with a denial of service attack from 30,000+ zombie PCs. This was in spite of the fact that we already block well over 100,000 IP addresses with the world's finest blacklists. Now it's 130,000. 
Of course, none of the owners of these PCs had any idea how their computers were being used. I'm reminded of a famous judge's secretary who received a knock at her door one Sunday morning from the FBI. They informed her that she was using her computer to host porno movie downloads. I won't offend your tender sensibilities by repeating what she actually told those "young men."
There's also the problem of dynamic IP addresses which means an address that was used by a bad guy yesterday may be handed out by the same ISP to your grandma tomorrow. And it didn't take the bad guys long to poison blacklists with IP addresses that you actually need for services such as DNS or network time services. If you've ever had an IP address that ended up on one of the major blacklists, you know what a hassle it is to get your IP address unBlacklisted. The Soup Nazi has nothing on these folks.
Bottom Line: Public web sites are pretty much forced to use BlackLists because they want their sites to be generally accessible. With a VoIP server, we have the luxury of choice, and WhiteLists are much more effective for server security.
Overview. Our recommended design works like this. Block everything. Then permit packets from known hosts and non-routable IP addresses only, and limit known hosts to only the services they actually need. For example, a VoIP provider such as Vitelity that is providing a DID for your inbound calls doesn't need web access to your server. They need SIP and RTP access. Nothing more. The same goes for a remote user: SIP and RTP access so their SIP phone works. Nothing more. You, as Administrator, need complete access to the server but only from a specific, defined IP address. We, of course, don't want IPtables to have to inspect and filter every single packet flowing into and out of your server because that would bog things down. And we don't want users on your private LAN and remote users with dynamic IP addresses to have to wrestle with updating their phones just to stay connected. So, we've opened up all non-routable IP addresses and, once we've verified that a remote site is authorized access, then subsequent packets flowing into and out of the server for that IP address will be passed along without additional packet inspection. And once we set up the FQDN for a remote user, local dynamic DNS update clients can be used to automate the process of keeping IP addresses current. Then, every few minutes, we'll let your server check whether there's been a change in any users' dynamic IP addresses. If so, we'll simply refresh the IP addresses of all FQDNs using an IPtables restart to bring the phones back to life. To end users, The Phones Just Work™.
Finally, a word about security for VoIP in the Cloud servers. If you run a virtual machine from any hosting provider with wide open access to SIP, IAX, and web services, it's just a matter of time before your server is going to be compromised, period! If you foolishly use credit card auto-replenishment for one or more of your hosting providers then you might as well mail a blank check to the bad guys and wait for them to cash it. Today's tools will take you less than a minute to permanently lock down your server. So... JUST DO IT™.
To give you some idea of how far the Android platform has come, here are a couple screenshots of our Samsung 4G Skyrocket smartphone running three simultaneous VoIP apps all day, every day: Bria SIP extension to our PIAF2 server in Charleston, CSipSimple extension to our RentPBX VM in California, and GrooveIP session with Google Voice. Try that on your 3G iPhone 4S.
We're officially releasing this for RentPBX users running PBX in a Flash 2™ or Incredible PBX 3™. These folks have been our pioneers for a very long time, and we like to take care of them first. Properly installed, Travelin' Man 3 should work fine on any PIAF2™ or Incredible PBX 3 system. We'll make a backup of /etc/sysconfig/iptables before replacing your IPtables setup with the PIAF2 default setup. It assumes ALL of your traffic is flowing on eth0. If that's not the case, don't use it without major modifications! We would hasten to add that Travelin' Man 3 is licensed as GPL2 open source software. So it's available NOW to everyone to use or to embellish as they see fit. We hope every provider of VoIP services offering virtual machines in the cloud as well as those without a hardware-based firewall to protect your Asterisk server will take advantage of the opportunity to customize and deploy this code for their particular IPtables environment. To paraphrase Bill Clinton: "It's your phone bill, stupid!"
Deploying Travelin' Man 3. Here's how to deploy Travelin' Man 3 on your server. In Step #1, we run secure-iptables. This locks down virtually all IP ports and services in the original IPtables configuration for PBX in a Flash to either the IP address or the FQDN of the administrator. Be advised that this setup uses the default ports for all PIAF2 services, e.g. SSH, WebMin, HTTP, etc. If you use custom ports, you'll need to modify the script accordingly. If the administrator is on the move or has a dynamic IP address on his or her desktop or notebook PC/Mac that will be used to administer the cloud server, then use an FQDN, not a static IP address, when you run secure-iptables.
Step #2 is automatic and is part of secure-iptables. It opens SIP and IAX port access for "trusted providers" such as Google, Vitelity, etc. This is covered in detail below. We also open accessibility from non-routable IP addresses. You obviously can close or limit private LAN access, if desired. We included it for the benefit of those running and administering PBX in a Flash on private LANs where internal security is not a concern.
In Step #3, we'll let you set up additional access for other providers, users, and phones. You get your choice of up to 9 separate services to enable, and each account gets a name and a file to keep track of the latest IP address entry: somename.iptables. These are stored in /root. Don't delete them! New accounts can be added using either a static IP address (add-ip) or an FQDN (add-fqdn). These accounts also can be deleted whenever necessary (del-acct). You can rerun secure-iptables whenever you like, but it automatically deletes all custom user accounts. Here's the list of services from which to choose. Mix and match as desired to meet your own requirements.
1 - SIP (UDP)
2 - SIP (TCP)
3 - IAX
4 - Web
5 - WebMin
6 - FTP
7 - TFTP
8 - SSH
9 - FOP
Just a word of caution. IPtables stores its setup in /etc/sysconfig/iptables, but it actually runs from an image in memory on your Linux server. As part of the load process, IPtables converts all FQDNs stored on disk to static IP addresses. This speeds up firewall processing enormously. While it's possible to add IPtables rules in memory without writing them to disk (as in the original Travelin' Man design), don't do it with Travelin' Man 3! You will lose these settings whenever IPtables is restarted by running any of the above scripts or whenever a refresh of FQDN IP addresses becomes necessary. Whatever you do, never ever run the command: service iptables save. This command is used to write the IPtables entries in memory to disk. In doing so it writes only static IP addresses to disk. This will erase (a.k.a. ruin) your Travelin' Man 3 FQDN setup and force you to start over with Step #1. Otherwise, none of your FQDN's would ever get refreshed because they've all disappeared and become static IP addresses. You've been warned.
Locking Down Your Server. While there's still time, let's spend a minute and lock down your server to the public IP address of the PC that you use to administer the system. If you don't know the public IP address of the desktop machine you use to manage your server, then click on this link using a browser on that machine, and our web site will tell you the IP address.
Now log into your virtual machine as root using SSH and issue the following commands:
cd /root
wget http://incrediblepbx.com/travelinman3.tar.gz
tar zxvf travelinman3.tar.gz
./secure-iptables
When prompted for the FQDN or IP address of your Administrator PC, use the FQDN if you have one. Otherwise, type in the IP address and press the Enter key. Agree to the terms of service and license agreement by pressing Enter. When the iptables file displays, verify that you have typed your FQDN or IP address correctly, or you will lock yourself out of your own server. Press Ctrl-X to exit the editor, and then press Enter to update IPtables and save your new configuration. Done! Nobody can access your server except someone seated at your PC or on your private LAN with your login credentials. You can repeat this process as often as you like because each time the script is run, it automatically restores your original IPtables configuration. Now let's grant access to your SIP providers and those using remote SIP or IAX phones.
Using DynDNS to Manage FQDNs. The key ingredient with Travelin' Man 3 is automatic management of dynamic IP addresses. When a user or even the administrator moves to a different location or IP address, we don't want to have to manually adjust anything. So what you'll first need is a DynDNS account. For $20 a year, you can set up 30 FQDNs and keep the IP addresses for these hostnames current 24-7. For $30 a year, you can manage 75 hostnames using your own domain and execute up to 600,000 queries a month. That's more than ample for almost any small business but, if you need more horsepower, DynDNS.com can handle it. What we recommend is setting up a separate FQDN for each phone on your system that uses a dynamic IP address. This can include the administrator account if desired because it works in exactly the same way. When the administrator extension drops off the radar, a refresh of IPtables will bring all FQDNs back to life including the administrator's account. Sounds simple? It is.
Preparation. Before we make further modifications to IPtables in Step #3, let's make a list of all the folks that will need access to your VoIP Server in the Cloud. For each entry, write down the name of the person, server, or phone as well as the type of entity which needs server access. Then provide either the static IP address or FQDN for each entry. If one or more of your IP addresses are dynamic (meaning the ISP changes them from time to time), we'll cover managing dynamic IP addresses in a minute. For now, just make up a fully-qualified domain name (FQDN) for each dynamic IP address using one of the available DynDNS domains. For static IP addresses, use the FQDN or the IP address. HINT: FQDNs make it easy to remember which entry goes with which provider.
Make a list of your providers NOT in this list: Vitelity (outbound1.vitelity.net and inbound1.vitelity.net), Google Voice (talk.google.com), VoIP.ms (city.voip.ms), DIDforsale (209.216.2.211), CallCentric (callcentric.com), and also SIPgate.com (sipgate.com), VoIPStreet.com (chi-out.voipstreet.com plus chi-in.voipstreet.com), Les.net (did.voip.les.net), Future-Nine, AxVoice (magnum.axvoice.com), SIP2SIP (proxy.sipthor.net), VoIPMyWay (sip.voipwelcome.com), Teliax, and IPkall. The providers listed above are already enabled in the secure-iptables setup script. We call them Trusted Providers only because we trust them and have personally used all of them. We consider them reliable folks with whom to do business. It doesn't mean others aren't. It simply means these are ones we have tested with good results over the years. The only providers you'll need to add are ones we haven't provided. Also be sure to check whether the FQDNs of the providers above cover the server for your account. If not, you'll need to manually add those FQDNs as well. Keep in mind that trusted providers will have full SIP and IAX access to your server so stick with tried-and-true providers for your own safety. The PBX in a Flash Forum and DSL Reports are good sources of information on The Good, The Bad, and The Ugly.
Finally, list with a name each phone that will be connected to an extension on your server. If you have 10 traveling salesmen, then you might want to name them all by last name and also provide FQDNs with their last names, e.g. smith.dyndns.org and jones.dyndns.org. No spaces or punctuation in names or FQDNs! We strongly recommend using FQDNs wherever you can because it means zero work for you when a provider changes an IP address. Here's the table we use:
Name
Type: Person, Provider, Server, Phone
IP Address Type: Static or Dynamic
FQDN or IP Address
Services Desired: SIP, IAX, Web, FTP, SSH, etc.
Step #3: Adding Authorized Users. Now take your list and add each account to your server while logged in as root and positioned in the /root directory. For static IP addresses, use add-ip. For dynamic IP addresses and FQDNs, run add-fqdn and plug in the FQDN for each account. When one of your accounts needs to be removed, just run del-acct from the /root folder on your server and plug in the name of the account to delete. If a user changes from a static IP address to a dynamic IP address or vice versa, just delete the user and then add them again with the new IP address or FQDN. All of the accounts are stored in /root and have names like this: name.iptables.
Step #4: Setting Up DynDNS Client Updates. There are actually two pieces in the Dynamic DNS update puzzle. At the end-user side, you need to deploy a DynDNS update client on the same subnet as the phone of your user. See the links above to download the update software you prefer. In the case of cellphones with SIP phone capability, this could be as simple as installing the DynDNS update client directly on the phone itself. Plug in your DynDNS credentials as well as the FQDN associated with the particular phone, and the rest is automatic.
Step #5: Setting Up IPtables Auto-Refresh. Finally, we need a way for your server to discover when a refresh of FQDNs becomes necessary because someone's IP address has changed. The simplest way to do this is to automatically run a simple script (ipchecker) that polls the DNS authoritative server to determine whether the dynamic IP address associated with an FQDN has changed. If so, we'll update the account.iptables file to reflect the new IP address and then restart IPtables. This will refresh all IP addresses associated with FQDNs. If all or most of your users spend time sleeping each day, you may wish to run the script only during certain (waking) hours of the day so your server has less of a load. The other consideration is how often to check. The guideline here is how long can any user live without their SIP phone being connected to your server. 10 minutes may be reasonable for some. 60 minutes may suffice for others. For us, it's 3 minutes. It's your choice. The way Travelin' Man 3 works is, whenever at least one account has an IP address change, it will trigger a restart of IPtables to do an IP address refresh for all of the FQDNs.
The top of the ipchecker script in /root looks like this:
#!/bin/bash
# Insert the account filenames to be checked below
# Remember to increment the account[#] for new entries
account[0]=larry.iptables
account[1]=curly.iptables
account[2]=moe.iptables
# ipchecker (c) Copyright 2012, Ward Mundy & Associates LLC.
You'll need to edit the script (nano -w /root/ipchecker) and modify the section in bold to reflect the actual FQDN account names you've created on your server that are associated with dynamic IP addresses only. You don't want to monitor accounts with static IP addresses or FQDNs that never get updated. When those extensions are off-line, it's not because their IP address changed, and restarting IPtables won't really help to improve the situation. Be sure to increment the account[n] array for each new account that you want to monitor and use the exact format shown in the example above. Before you enter an account in the script, display the contents of the file using cat /root/accountname.iptables. Make certain that the file includes BOTH an FQDN, then a space, and then an IP address. If not, delete the account (del-acct) and add it again using add-fqdn.
Once you've entered all of your accounts with dynamic IP addresses, save the script: Ctl-X, Y, then Enter. Run the script manually now to be sure it works as you intended: /root/ipchecker. Be advised that typos that list accounts that don't exist will cause problems. Error checking consumes processing cycles by requiring additional queries so we've left it out. That means it's solely up to you to check your account names for accuracy. And, remember, only include accounts that have dynamic IP addresses with FQDNs.
Step #6: Automating FQDN Refreshes with Cron. Finally, you'll need to add an entry to the bottom of /etc/crontab using nano. If you wanted the script to run 24 hours a day at 10 minute intervals, here's the command:
*/10 * * * * root /root/ipchecker > /dev/null
If you wanted the script to only run between the hours of 8 a.m. and 9 p.m. (server time zone) at 10 minute intervals, then you'd use something like this:
*/10 8-21 * * * root /root/ipchecker > /dev/null
On our RentPBX complimentary account which we use while traveling, we actually set the interval to 3 minutes. Since the DNS lookups use dig, changes on Android phones using the DynDNS client are almost instantaneous even with automatic switching between WiFi and cellular service. Finally, be sure to type date on your server and verify which time zone your cloud server thinks it's in! Adjust the times in /etc/crontab accordingly.
Be sure to check back here periodically for updates and follow the latest happenings about Travelin' Man 3 in this thread on the PIAF Forums. Enjoy!
Originally published: Thursday, March 29, 2012
March 30 Update: We've released a 1.1 version based on some excellent recommendations from those that already have tried Travelin' Man 3. This new version lets you choose from 9 different web services to activate for each new user. Read all about it including how to update if you installed the original version yesterday. New downloads will get the updated 1.1 release.
December 3, 2012 Update: We've been alerted to a pretty serious security issue with the methodology that CentOS uses to start and restart iptables. In a nutshell, if you have an FQDN in your iptables file or in your Travelin' Man 3 FQDN rules that cannot be resolved to an IP address, iptables will not load properly when your system is booted. This basically would leave your server with no iptables firewall protection. The matter has been reported to the iptables Dev Team, and we are awaiting a response. In the meantime, you should regularly monitor your server to make certain that iptables is functioning properly. iptables -nL will tell you which rules are active. If you don't see any of your VoIP-specific rules, then restart IPtables: service iptables restart. Watch the display for the location of the offending rule. Then edit /etc/sysconfig/iptables and either fix or remove the rule and restart IPtables again. Once iptables is actually working, you can avoid the problem with a failed FQDN by using the following command instead of service iptables restart: iptables-restore /etc/sysconfig/iptables. Unfortunately, this will not catch or fix an issue which occurs during the boot process. You also should edit line 64 of /root/ipchecker and replace the service iptables restart command with: iptables-restore /etc/sysconfig/iptables. New downloads already have the patch.
UNLESS YOU DISCONTINUE USING FQDN'S WITH IPTABLES, IT IS ABSOLUTELY ESSENTIAL THAT YOU MONITOR YOUR SERVER DAILY IF YOU ARE RELYING EXCLUSIVELY UPON IPTABLES AS YOUR FIREWALL PROTECTION MECHANISM AND YOU ARE USING FQDN'S AS PART OF YOUR CENTOS SECURITY METHODOLOGY!
Need help with Asterisk? Visit the NEW PBX in a Flash Forum.
whos.amung.us If you're wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new
whos.amung.us statistical web site and check out what's happening. It's a terrific resource both for us and for you.
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special
Vitelity sign-up link. If you're seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use
our special link to sign up, the Nerd Vittles and
PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity's DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For
PBX in a Flash users, here's a deal you can't (and shouldn't) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click
here.
Do not use this link to order your DIDs, or you won't get the special pricing! Vitelity's rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity.
Some Recent Nerd Vittles Articles of Interest...
[↩]
Configuring Google Voice. As we mentioned, you’ll need a dedicated Google Voice account for this. The more obscure the username (with some embedded numbers), the better off you will be. This will keep folks from bombarding you with unsolicited Gtalk chat messages, and who knows what nefarious scheme will be discovered using Google messaging six months from now. 
Calendar
Kindle
iMovie
CoPilot HD
Game Center
Twitter
