Posts tagged: security

Amerika the Beautiful: An Insider’s View of What Went Wrong and How To Fix It

UPDATE: Following a week of almost daily new disclosures, we are republishing our original article with some additional observations from us and others who have been following what will almost certainly turn out to be one of the most shocking and important revelations in the history of our republic. Much of this story has unfolded on Twitter, one of the few companies that stood up to the government and refused to participate in the PRISM data collection enterprise. So it seemed only fitting to retell the events of the last few weeks through the tweets that have brought this story to life and fleshed out many of the details pertaining to Mr. Snowden’s original revelations. –Ward Mundy

As the cellphone and NSA scandals continue to unfold, we’ve wrestled with a number of emotions probably much as many of you have. This isn’t so much a liberal versus conservative controversy as it is a question about what type of society we all want for our families and for those that will come after us. Having grown up in a military family, I came in contact with individuals from literally all walks of life, commanding generals to sergeants and privates. Most did their jobs very well and took pride in their accomplishments and those of others. After high school, I attended Auburn University and then went on to law school at the University of Alabama, two schools known more for their football teams than their academic credentials. Even though the country was in the midst of the George Wallace era of states’ rights, I actually got a well-balanced legal education at Alabama. Much to the chagrin of the governor, many of my law professors were Yankees from the most liberal bastions in our country including Harvard and Yale. So it was probably not surprising that more than half of my law class of 130 became card-carrying liberals. In fact, I only remember one ultra-conservative classmate, and we never were sure whether he believed all the things he was saying or was just doing it for attention and to establish his pedigree for future political races.

We were up to our eyeballs in Vietnam when I graduated so my career path was chosen for me. Those with political connections and those from well to do families got to join the National Guard and stay home. The rest of us got drafted. If you were a lawyer, you had the choice of serving two years as an infantry officer or four years as a lawyer. That was an easy choice at least for me because I owed the military four years anyway because of a college scholarship. There was a great book at the time, Military Justice is to Justice as Military Music is to Music. You really didn’t have to read the book to figure out the message. As an appellate lawyer, I got to witness it up close and personal. Military courts have special rules. Military commanders decide who gets tried and then they hand-pick the military juries who also happen to be soldiers working for the same commander. If a criminal case went to trial, your odds of not being convicted were about the same as being struck by lightening or winning the lottery. The same held true for the criminal appeals. All of my clients were already serving time in Fort Leavenworth while I “represented” them in Washington. A handful saw their sentences reduced on appeal while one or two actually had their cases reversed. Despite the odds favoring the military, I actually worked for an appellate judge that would hide problematic cases in a bottom drawer until the soldier had served all his jail time. Then the case would magically reappear, and justice would be done by reversing the errors in the trial proceedings. Several of us finally filed a complaint against the judge, and he was “retired.” This was my first exposure to the “Rewards System.” Many folks are promoted into prestigious jobs in the government not to do future good work but as a reward for past service. In short, it’s treated more like a medal than a job. Suffice it to say, you don’t see a lot of boat rocking from the honorees.

At the time, I chalked this up as yet another military anomaly. It was reinforced by the decade I spent at all levels of the military justice system including a stint as the Court Executive of the U.S. Court of Military Appeals, the civilian court that oversaw the whole process. What was surprising to me were the extremes to which many individuals in the most important legal positions in the military were willing to go in order to rig the system in favor of what they perceived to be the desires of the military commanders. My dad had been a military commander. He and all of the commanding generals I have known would never have tolerated such a setup had they known about it. While the President technically appointed judges to the Court of Military Appeals, in actuality the judges were selected by members of the Senate Armed Services Committee. Because the Court had become too liberal for some of the senior people in Donald Rumsfeld’s Defense Department, they decided to change the name of the court to make it sound more like a real federal court. While they were at it, they expanded the number of judgeships in order to get rid of the “liberal problem.” Killing two birds with one stone wasn’t hard with the enthusiastic support of Strom Thurmond and the armed services committees. They “promoted” the most liberal judge to a district judgeship with life tenure to get him out of town.

When the court packing began, I left and joined the staff of the newly created U.S. Court of Appeals in Atlanta. There I served for more than 20 years as the technology guru. During my tenure, we introduced personal computers, networks, VPNs, video conferencing, cellphones, automated case management systems, and the 20th century to many judges and lawyers that still were deciding cases in much the same way they had been handled since the founding of our country.

Unlike the military system, the federal courts were different. These judges weren’t wearing medals. They took their jobs seriously. All were appointed for life by the President, and most had come from cream of the crop positions in the most prestigious law firms and law schools in the country. Many that I worked for had single-handedly desegregated the South: its schools, its lunch counters, its water fountains, and even its bathrooms. No small feat considering there were still Ku Klux Klan signs announcing evening meetings when I would drive back to school on Sunday afternoons.

I had almost daily contact with these judges because our courts in the southeastern United States were handling caseloads at least 10 times what other courts across the country were experiencing. And, without the very best technology, these courts would literally have been buried by the paperwork associated with these legal proceedings. It began with civil rights cases, then voting rights, then drugs, then bankruptcies, then death penalties, and on and on.

But something changed at about the time Ronald Reagan became president. Many of the new judges that were appointed had come from prior government jobs. Some had been magistrates. Others had been state court judges. Many had been former federal or state prosecutors or lawyers in the Department of Justice. Some were small town lawyers who happened to serve as a community campaign manager for the president or a staff assistant to a U.S. Senator. There was even a former nun. What was different was that many of them came with an agenda. And many of the selections were more about ideology than legal accomplishment. We’ve now seen that process play out for more than 30 years. With some notable exceptions, many “medalists” have crept into the federal judiciary at all levels. Free resort junkets for judges sponsored by organizations with their own agenda are all too common. As we saw in the military setting, the perks of the office and living the country club life style started mattering more than doing the job. Keep in mind that these judges serve for life with almost no outside scrutiny. When you then add secret tribunals to the mix, it makes for a dangerous concoction with no checks and balances.

There also was a metamorphosis underway in Congress. Southern Democrats became Republicans largely because of the civil rights statutes championed by Lyndon Johnson. Southern Democrats had always held their nose and gone along with the agenda of the Democratic Party as long as separate-but-equal was left in place. When “the deal” changed, they bolted. Big business was getting a very different foothold in Congress. A law school classmate of mine who became a very prominent lobbyist on Capitol Hill once told me that there was no bill he couldn’t get passed if his client had deep enough pockets.

The Oligopoly Revolution was also underway. Virtually every American industry now has less than a handful of players which has led to skyrocketing prices: Big Oil, Big Banks, Automobiles, Airplane Manufacturers, Airlines, Technology, Communications, Hospitals, Drug Manufacturers, Health Care Providers, Fast Food, Grocery Stores, Hardware Stores, and Drug Stores to name just a few. There really is no space left for the little guy and the entrepreneur. Price fixing by manufacturers now is perfectly legal. Software patents appeared out of thin air and have essentially killed off independent software development unless you work for the handful of leading technology companies that can afford a patent portfolio.

And then there was 9/11. In response to the threat of terrorism and under the convenient umbrella of national security, Congress has all but repealed the constitutional protections laid out in the Bill of Rights while establishing a National Security Agency that would have been the envy of Adolph Hitler and Joseph Stalin. The “new” federal courts have routinely rubber-stamped every piece of this legislation. And then came the secret FISA court with secret proceedings and secret decisions and secret court orders and no public appeals. If you read nothing else, read this article in The Verge. Here’s an excerpt:

The 9/11 terrorists should be proud. They have single-handedly changed our entire security apparatus (not to mention our judicial system) to one that looks frighteningly similar to what you would find in Pakistan, China, or North Korea. And the response from the President and Congress… “Gosh, we’re all so much more secure when we can identify the calling history of every single cellphone user and can intercept every email communication in the universe.” And the American Technology Oligopoly appears to have gone right along with it while lying their asses off about what has happened. Who needs the keys to your house? They’ve already got access to every piece of personal data you create!

We obviously hope some of this story turns out not to be true, but then there’s this:

The problem is that Congress and some within the judiciary have so tilted the playing field that it’s hard to have much faith in any of our public institutions any more. Just to reemphasize, this has nothing to do with Democrats or Republicans. It has to do with almost all of our national politicians who have sold themselves out to the highest bidder.

So how do we fix this mess? For the short term, stop using browsers to generate or read email. Encrypt your email and stop using Gmail, HotMail, and Yahoo. Use VPNs for communications whenever possible. And Silicon Valley needs to take a careful look in the mirror. They are a major part of the problem.

Then it’s time to take our country back. Those of us that continue to sit on the sidelines deserve what we get. What we really need is a new Constitution that actually has some meaning. Every person in the United States should get to vote on it, and it shouldn’t be based on gerrymandered political districts that favor a particular political party. As part of the process, throw all of these bums out. Every one of them regardless of political party! Then dismantle their retirement benefits and healthcare perks. Limit future elected officials to six years in office with no special benefits of any kind. It’s service to your country, not a career or mutual admiration society. Promulgate strict laws outlawing all lobbying of Congress by paid individuals. Force congressmen to write their own legislation rather than relying upon the work of corporate America. Pass laws that severely penalize companies that ship American jobs and corporate revenue overseas. Corporations are not people. Nor are they U.S. citizens. Stop pretending they are. Establish minimum tax rates for every person and every company doing business in the United States. Everybody who lives here should have to pay their fair share of the costs. Get rid of all the tax loopholes that have rigged the system in favor of special interest groups that literally have bought Congress. The rest of the problems will fix themselves hopefully in time for our kids to once again enjoy living and prospering in our great country.

We share the sentiments and recommendations of Hendrik Herzberg in The New Yorker:

Calling for a national commission can be the last refuge of the high-mindedly perplexed, but this is one instance when such a commission—independent, amply funded, possessing subpoena power, and with a membership and a staff deeply versed in both national security and civil liberties—may be precisely what is needed. The N.S.A. programs represent a troubling increase in state power, even if—so far, and so far as we know—they have not occasioned a troubling increase in state wrongdoing. Obama’s “difficult questions” have a new urgency. Are the programs truly efficacious? Do they truly provide an extra margin of safety sufficient to justify the resources poured into them, to say nothing of the domestic and international anxieties they inevitably provoke? Is it wise to entrust so many of their activities to the employees of private companies, which are ultimately answerable not to the United States and its Constitution but to corporate stockholders? Did it make sense to construct an intelligence behemoth that apparently cannot operate without giving an enormous number of people—more than a million—top-secret security clearances? And in what ways, exactly, might an ill-intentioned yet formally law-abiding Administration use its powers for nefarious purposes? From what we know so far—well, we know far too little, still.

Finally, let us close by pointing you to Steve Wozniak’s commentary on this mess. We couldn’t have said it better…

Originally published: Sunday, June 9, 2013

The Next Plateau: VoIP Communications with Asterisk in Amazon’s EC2 Cloud

We’ve spent considerable effort exploring and enhancing the VoIP cloud offerings for our followers, and today we’re delighted to introduce another terrific service: Amazon’s Elastic Compute Cloud (EC2). This is one of several Amazon Web Service (AWS) offerings that provides resizable compute capacity in the cloud and is designed to make web-scale computing easier for developers. That’s the Amazon pitch for their service. Ours is a bit different. For anyone with mission-critical operations or that has ever given a moment’s thought to business continuity planning (THINK: hurricanes, tornados, earthquakes, blizzards, fires, floods, bombs), you need an EC2 backup plan for VoIP communications. It really doesn’t matter whether your organization uses a proprietary phone system, or Asterisk®, or good ol’ black telephones, the point is simply this. When your lights go out and you still need a communications system for your employees and your customers, what’s your plan? Staying home in bed isn’t a choice for most folks. So our focus is not to persuade anybody to move their primary communications platform to Amazon EC2 although it’s certainly worth considering. For today, let’s tackle emergency planning and Disaster Recovery 101 for that dreadful day when you really don’t have a choice. And D-Day is a really bad day to start thinking about communications alternatives. You’ll have plenty of other things to do.

We’re going to make this fun today and provide all the tools you’ll need to set up shop in Amazon’s EC2 Cloud. The good news is that EC2 is almost free for your first year so getting started isn’t going to be a financial burden. Once you have everything built, you can turn it off and hope you never have to use it. On the other hand, it’s dirt cheap for an entire year so enjoy yourself and learn why VoIP communications can revolutionize your business at a fraction of the cost of a proprietary communications system. For our Asterisk aficionados that have already discovered the beauty of free VoIP communications, we’ve got some additional goodies today, Incredible Backup and Incredible Restore, that will let you quickly move your communications platform back and forth between EC2 and a local server or virtual machine effortlessly.

For those just getting started, the real beauty of VoIP communications is that, once your server platform is operational, you can bring up communications services for your employees without any hardware investment. A notebook computer and a free SIP softphone will let you make and receive calls through your EC2 communications system. By adding trunks from Google Voice or any SIP service provider, you complete the communications circle to connect to any phone in the world. We do this for a living so, if your business needs some hand-holding to get started, drop us a note. We like to travel.

The Choice is Yours: PIAF-Purple with Asterisk 1.8 or PIAF-Green with Asterisk 11

Getting Started. For your communications platform, we’ve built two new versions of PBX in a Flash™ for Amazon EC2: PIAF-Purple and PIAF-Green. You can’t beat the price. Both are free! These two builds are based upon the two long-term support (LTS) releases of Asterisk: 1.8 and 11. In our testing, both are rock solid and production-ready. If tried and true is your cup of tea, then PIAF-Purple with Asterisk 1.8 and FreePBX 2.10 is your baby. If you want to get a jump on the future, then PIAF-Green with Asterisk 11 and FreePBX 2.11 is worth a careful look. But, to use either one, you first need to get set up with an Amazon EC2 account. So head over to Amazon and click on Sign Up Now. A word to the wise here. You don’t want the bad guys breaking into your account unless you have an unlimited budget. There are lots of non-free Amazon EC2 services that could max out your credit card quickly. So, in addition to signing up for your Amazon account, also activate Multi-Factor Authentication. It’s your bank account!

Once your account is activated, sign in to the Amazon Management Console. After entering both your passwords, the AWS Management Console will appear. Click on EC2 to bring up the EC2 Dashboard (shown above). This is home base in EC2. The Launch Instance button is used to start a new virtual machine. We’ll walk you through that process in a minute. In the left margin are the functions you’ll be using most often. Instances displays your existing virtual machines, both running and stopped. Volumes are the virtual hard disks associated with your virtual machines or instances in Amazon-speak. A volume gets created as part of the VM launching process. When you delete instances, it’s important to also delete the associated volume, or you get billed for it separately. Elastic IPs lets you assign an IP address to an Instance using Amazon’s DHCP servers. You access your virtual machines using SSH and, without an IP address, you can’t gain access. For SSH security, EC2 uses Key Pairs. As part of launching a new virtual machine, we’ll walk you through creating one. Amazon EC2 also has its own firewalls called Security Groups. Basically, all services are blocked until you open them up. We’ll also walk you through that process as well. Once you’ve created your Key Pair and Security Group, you can use them with multiple instances. Now you’re an expert so let’s Launch a New Instance.

Creating a New Virtual Machine. Click on the blue Launch Instance button in the EC2 Dashboard to begin. Choose Classic Wizard. You build a new instance by starting with one that someone else has already built. Be careful here. There are literally thousands to choose from and, unless you know the creator, use Name Brand, trusted instances only. Anybody can hide anything in an instance that they’ve made publicly available. Think of your worst Trojan Horse horror story, and there’s probably a public Amazon instance to match it. For our purposes, the magic number you need to know is 399149154715. That’s our Amazon EC2 account number, and it means any instances prefixed with that number or our mugshot were created by us. So click on the Cloud Market and search for PIAF. In about a minute, both PIAF2 AMIs will appear. Pick your favorite but be sure the file name displays our smiling face. Then click Select. For the Instance Type, make sure T1 Micro is chosen. That’s the only free option during your first year. Leave the Availability Zone at No Preference and Number of Instances set to 1. Click Continue. In Advanced Instance Options, accept all of the defaults and click Continue. For Storage Device Configuration, accept the defaults by clicking Continue. Next, you’ll be prompted to add Tags to your Instance. This is a short-hand description to help you distinguish one instance from another. For the Name Value, enter something like PIAF-Purple-64 or PIAF-Green-64 and click Continue. Next, you’ll be prompted to create a Key Pair to use with the instance. If you don’t already have one, click Create New Key Pair and Continue. Once the key pair is created, the .pem file will be downloaded to your desktop computer. Change the permissions on the .pem file to what SSH requires: chmod 700 mykey.pem. You’ll need this key file to log into your instance with SSH so move it to a safe place. Next, you’ll create or use an existing Security Group. This sets up the firewall rules to use with your instance. For PBX in a Flash, you’ll need at least the following Inbound Rules in your Security Group: TCP 22 (SSH), TCP 80 (Web), TCP 1723 (for PPTP VPN only), and TCP 9001 (for WebMin access). For VoIP services, you’ll need UDP 5060 (SIP), UDP 10000-20000 (RTP), UDP 4569 (IAX), and UDP 69 (TFTP, if desired). EC2 lets you lock down Security Group entries to individual IP addresses. We strongly recommend this for SSH, Web, SIP, IAX, and TFTP services. If you need access from multiple IP addresses, just add additional Security Group rules for each address and service. Finally, you’ll be shown a summary of all your selections. If everything looks OK, click Launch to start the instance. While it’s starting up, click Elastic IPs from the left column of the EC2 Dashboard. Choose Allocate New Address and then Associate Address to connect it with the instance that just launched. Write down the IP address. You’ll need it for SSH access. Finally, click Instances and wait for your virtual machine to come on line with a green check mark.

Your First Login. Now you can log into your EC2 instance via SSH using your key file and the IP address associated with the instance: ssh -i mykey.pem -v ec2-user@ If you’re using a Windows machine with Putty, use PuttyGen.exe to convert your .pem key into something Putty can understand before attempting to log in. Once you’re logged in, you need to immediately change all the default passwords:

  • sudo passwd (to change your ec2-user password)
  • sudo passwd root (to change your root password)
  • su root (to switch to the root account with your new password)
  • passwd-master (to change your FreePBX and web passwords)
  • cd /root (to switch to the /root directory)

Keep in mind that PBX in a Flash is a little different than a standard Linux install. It has been designed for use as the root user only. So, whenever you log into a PIAF instance in EC2, always execute the following command: su root && cd /root. Most Linux and PBX in a Flash utilities will not work properly if you attempt to execute them as the ec2-user! For web access and management of your server, point your browser to the IP address of your EC2 instance. If you’re new to PBX in a Flash, stop here and read the PBX in a Flash Quick Start Guide. It’ll tell you everything you need to know to get started with PBX in a Flash.

Installing Incredible PBX. We’ve got a few more surprises for you today. First, there are new, GPL2-licensed releases of Incredible PBX: version 10 for FreePBX 2.10 and version 11 for FreePBX 2.11. If you’re new to all of this, Incredible PBX provides some additional layers of security for your server while also giving you dozens of turnkey Asterisk applications including text-to-speech, speech-to-text, SMS messaging, news, weather, stocks, and tide reports, and much more. You can read the Incredible PBX tutorial here. To install Incredible PBX while logged into your EC2 instance as root, issue the following commands and plug in your passwd-master password when prompted. If you’re using the PIAF-Green AMI, replace incrediblepbx10 with incrediblepbx11 below.

cd /root
gunzip incrediblepbx10.gz
chmod +x incrediblepbx10

Installing Incredible Fax. Yes, there’s more. Incredible Fax also works just fine on the EC2 platform. If you want the added convenience of having your Incredible PBX double as a free fax machine, run install-incredfax2 after the Incredible PBX 10 install completes. For Incredible PBX 11, run /root/ Plug in your email address for delivery of incoming faxes and enter your home area code when prompted. For every other prompt, just press the Enter key. If you’d like to also add the optional OCR utility, just choose it when prompted. For complete documentation, see this Nerd Vittles article. Don’t forget that a REBOOT OF YOUR SERVER is required when the install is finished, or faxing won’t work! Then log in to AvantFax through the PBX in a Flash GUI using maint:password. Be sure to change your password!

Also be sure to set up a second, dedicated Google Voice number if you want support for inbound faxing. Once the Google Voice credentials are configured in FreePBX for the additional Google Voice line, simply add an Inbound Route for this DID to point to the fax destination. Just plug in your 10-digit Google Voice number and other entries shown in the form below. Save your setup and reload FreePBX. Done!

Introducing Incredible Backup and Restore. Last, but not least, we have new GPL2-licensed backup and restore utilities to simplify the task of moving PBX in a Flash setups between Amazon EC2 and other standalone or virtual machine platforms. To complement these new utilities, we’ve also released a new 64-bit PIAF-Purple Virtual Machine image for VirtualBox. PIAF-Purple-64.ova is a free download from SourceForge and will run under VirtualBox on any Windows, Mac, Linux, or Solaris desktop computer. Our VirtualBox tutorial is available here. You also have the option of downloading the current 64-bit PIAF-20631 ISO from SourceForge and building your own server or virtual machine. All three platforms (Amazon EC2 AMI, VirtualBox OVA, or PIAF 64-bit ISO) are 100% compatible with Incredible PBX, Incredible Fax, and the new Incredible Backup. Once you have matching platforms, you can backup your PIAF or Incredible PBX setup on one platform and then restore it to a different platform by simply copying the backup image to the new platform and running Incredible Restore. The entire procedure takes only a couple of minutes.

To install the backup and restore utilities on either of the platforms, simply issue the following commands:

cd /usr/local/sbin
tar zxvf incrediblebackup10.tar.gz
rm incrediblebackup10.tar.gz

Because Incredible Backup shuts down Asterisk, MySQL, and Apache, do NOT run this when folks are using your PBX! To make a backup, log into your server as root and type: incrediblebackup.

The restore procedure essentially erases ALL of your existing FreePBX, Asterisk, TFTP, and web data. To restore a backup, copy the backup file to be restored to /tmp on the new server. Make sure the new server has Asterisk, FreePBX, and Incredible PBX versions that match what’s shown in the backup filename. There is NO error checking presently. To restore, log into your server as root, write down the filename of the backup file, and type: incrediblerestore /tmp/filename.tar.gz. If this is a new server and you’re still using your old one as well, then remove the DUNDI secret and secretexpiry entries from the Asterisk DB and restart Asterisk once the restore is completed:

asterisk -rx "database del dundi secret"
asterisk -rx "database del dundi secretexpiry"
amportal restart

For additional usage instructions and tips, see this thread on the PIAF Forum. Enjoy!

Originally published: Monday, February 11, 2013  Updated: Thursday, February 14, 2013

Support Issues. With any application as sophisticated as this one, you’re bound to have questions. Blog comments are a terrible place to handle support issues although we welcome general comments about our articles and software. If you have particular support issues, we encourage you to get actively involved in the PBX in a Flash Forum. It’s the best Asterisk tech support site in the business, and it’s all free! Unlike some forums, ours is extremely friendly and is supported by literally hundreds of Asterisk gurus and thousands of users just like you.

Need help with Asterisk? Visit the PBX in a Flash Forum. If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new 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…

Sleep Like a Baby: 20 Failsafe Tips to Enhance Asterisk PBX Security

We often tell the tale of the early Asterisk@Home days when almost every server was configured with no firewall, unlimited web access, and a 201 extension with a password of either 201 or 1234. What could possibly go wrong? Remember this Monday morning newspaper headline? “Small business gets $120,000 phone bill after hackers attack VoIP phone.” ran this story back in 2009: “Criminals hacked into an Internet phone system and used it to make 11,000 international calls in just 46 hours… 115,000 international mobile calls were made… over a six month period.”

Much has changed over the past ten years in Asterisk® Land. And, to get everyone in the football mood, today we want to do a little sofa quarterbacking and take a fresh look at security applying some 20-20 hindsight to everything we’ve all learned over the years. Whether you’re running PBX in a Flash or Incredible PBX in your basement or on a virtual machine in the cloud somewhere, security matters and the checklist that follows hopefully will assist everyone in tightening up your systems so that you or your company aren’t the next headline waiting to happen.

PBX in a Flash Security Alert: Run upgrade-programs then upgrade-fixes to secure your server today!

1. Review PIAF Security Alerts Daily. We devote a lot of time to making sure PBX in a Flash and Incredible PBX are secure. But stuff happens! For privacy and security reasons, we don’t push fixes to your server. You have to go get them. If you never see the alerts, our attention to security is for naught. Here are 3 Easy Ways to Keep Informed:

  1. Subscribe to the PBX in a Flash RSS Security Feed
  2. Follow @NerdUno on Twitter
  3. Review the RSS Feed in the PIAF Dashboard with a browser

Every security alert has a link to a solution. Finally, visit the PIAF Forums and click on the What’s New link. It only takes a minute to scan the list for security issues.

2. Hardware-Based Firewall Protection. Unless your PBX is operating on a shared server in the cloud, always run it on a private LAN behind a hardware-based firewall with no Internet port exposure. The one exception would be for those with remote telephone extensions, and we’ll get to that in a minute. The cheapest consumer grade router/firewall provides more security for your server than all of the other security mechanisms combined. Use it!

3. The Linux iptables Firewall. All PBX in a Flash and Incredible PBX servers have the iptables firewall in place. With PBX in a Flash, you have to configure it yourself unless you deploy Travelin’ Man 3. With Incredible PBX, iptables is preconfigured if you opt to install Travelin’ Man 3 as part of the installation process. It doesn’t do much good to have iptables if it’s not functioning. So check it regularly and especially after rebooting your server. On CentOS-based systems, issue the command: iptables -nL. On the Raspberry Pi, type: iptables-save. You should see a list with a lot of permitted IP addresses for preferred providers. If not, restart iptables and then check it again. To restart iptables on CentOS: service iptables restart. On the Raspberry Pi, issue the command: iptables-restore /etc/network/iptables. If you discover that your iptables firewall was not functioning and you’re running PBX in a Flash or Travelin’ Man 3, a security alert has been issued to address the problem. You can get the security fix here.

4. IP Address Filtering. Even with remote phones and dynamic IP addresses, it often is relatively easy to narrow down the range of permissible IP addresses that should have access to your server. With the Linux iptables firewall, you can implement dynamic DNS FQDNs for your remote users. With many hardware-based firewalls, you can’t. But often you can limit remote access to a range of IP addresses. A little protection is still better than none. With a hardware-based firewall, these IP address ranges usually can be changed via web access to your firewall. The minute it takes to make necessary changes is well worth the effort. Just make sure your hardware-based firewall has a long password with upper and lower case letters as well as numbers and non-alphanumeric characters if your firewall supports them.

5. Fail2Ban Access Monitoring. On PBX in a Flash and CentOS-based Incredible PBX servers, fail2ban is activated to limit access attempts to protected resources such as SIP extensions, SSH, and Apache. It is not infallible particularly in this age of megaservers such as Amazon’s S3 service. Because fail2ban reads your logs looking for failed login attempts, it can be defeated with powerful servers attempting thousands of access attempts simultaneously because fail2ban never gets sufficient Linux resources to read logs and block access. It’s better than nothing, but not by much.

6. Deploy WhiteLists for Remote Access. If your server is in the Cloud (meaning it is directly exposed to the Internet) or if you have remote extensions directly connected to your server, your primary line of defense against the bad guys is your iptables firewall. We’ve tried many designs with the objective of letting the good guys in while keeping the bad guys out. The one failsafe solution is IP address WhiteLists. What this means is, if an IP address is listed as safe in iptables, then connections to certain resources from that IP address are permitted. Otherwise, your server remains invisible to the outside world. We have a couple of tools to assist you in setting this up. Travelin’ Man 2 lets authorized users manage their remote IP addresses themselves through a simple browser interface to your server. Travelin’ Man 3 lets a system administrator manage remote IP addresses using both permitted IP addresses and fully-qualified domain names. In the case of remote users with dynamic IP addresses, DynDNS management tools can be deployed on Macs, Windows machines, and Android devices to automatically update FQDNs used in conjunction with Travelin’ Man 3. As noted previously, a security alert has been issued with Travelin’ Man 3. You can get the security fix here.

7. Remote Access with User Agent Knocking. A new approach to remote user access uses a derivative of the original Sunshine Networks port knock utility. With jeffmac’s new design, you define a customized “User Agent” string on your remote phones and then define iptables rules that permit access from SIP devices that attempt server connections using one of these obscure user agent strings. Here’s how to deploy it. To use this approach you’ll need remote phones that permit customization of the user agent string or that have sufficiently obscure, predefined user agent strings that wouldn’t lend themselves to dictionary-style, brute force hacking attempts by the bad guys.

8: Implement VPNs for PBX Systems. There are install scripts for PBX in a Flash to deploy a NeoRouter VPN or a PPTP VPN. Either or both of them can be installed and configured in minutes! VPNs provide an incredibly simple way to interconnect PBX systems worldwide and assure secure communications between these interconnected systems. Encourage remote users to deploy softphones on their Windows and Mac machines, and use secure, VPN access to connect to your server using these softphones.

9. Don’t Use ‘Normal Ports’ for Internet Access. Think of network and PBX security as a shell game. You want to do as many things differently as possible to make it as difficult as possible for the bad guys to figure out what you’ve done. Read that last sentence again. It’s important! With a hardware-based firewall, this is easy. dLink routers call them Virtual Servers. Other routers have similar functionality. Here is a typical entry:

HTTP TCP 22/2319 Allow All Always
This entry redirects a specified port to a different port for Internet access. Don’t do this for SIP and IAX ports, but it works great for HTTP, FTP, and SSH access. WE STRONGLY DISCOURAGE EVER OPENING HTTP ACCESS TO YOUR SERVER FROM THE INTERNET. But you may need SSH access from remote locations. For example, port 22 typically is the default SSH port on Asterisk aggregations, and this port normally can be used on your internal LAN assuming you know and trust your users. For external (aka Internet) SSH access, simply remap TCP port 22 to some obscure port and change it periodically. For example, you might redirect TCP port 22 to port 2319. Once the setting is saved, you access SSH like this from the Internet: ssh -p 2319 Then (and just as important!) next month, change the port to 4382, then 6109, and so on. Don’t use these numbers obviously! Make up your own.

The key here is that 2 minutes work every month will keep SSH access to your PBX much more secure than letting every Tom, Dick, and Ivan hammer away at port 22 every night while you’re sleeping. As previously mentioned, most of these routers also will let you block access to certain ports during certain hours of the day. If you’re sleeping, there’s really not much need to provide SSH access to your Asterisk server. At the risk of being labeled xenophobic, keep in mind that many of the world’s best crackers reside in countries where daytime happens to be nighttime in the U.S.

10. Really Secure Passwords Really Do Matter. While we have no hard evidence to back this up, our guess is that 90% of the security breaches in Asterisk systems have been the direct result of folks using passwords that matched the extension numbers on their phone systems. Since most Asterisk PBX systems are configured with extension numbers beginning in the 200, 700, or 800 range of numbers, it really wasn’t Rocket Science to remotely log into these servers and make unlimited SIP telephone calls. It may seem obvious but really secure passwords really do matter. And it’s more than having a secure root password. All of your passwords need to be secure including those on your phone extensions and voicemail accounts unless you are absolutely certain that you have blocked all access to your system from everyone except trusted users. If you use DISA, multiply this advice by 10. Part of having really secure passwords is regularly changing them. And our rule of thumb on Asterisk system passwords goes one step further. Never, ever use passwords on your PBX that you use for other important personal information (such as financial accounts). Remember, it’s your phone bill.

11: Minimize Web Access To Your PBX. Most of the Asterisk aggregations utilize FreePBX as the graphical user interface to configure your Asterisk PBX. Because FreePBX is web-based, it is extremely dangerous to leave it exposed on the Internet. As much as we love FreePBX, keep in mind that it was written by dozens and dozens of contributors of various skill levels over a very long period of time. Spaghetti code doesn’t begin to describe some of what lies under the FreePBX covers. While the FreePBX Dev Team is vigorously rewriting much of this old code, some of it still lingers. Our recommendation is to make absolutely certain that you have .htaccess password protection in place for all web directories in at least these directory trees: admin, maint, meetme, and panel.

Our rule of thumb on Internet web accessibility to any Asterisk PBX goes like this. Don’t! And, for FreePBX web access from the Internet. Never! If the bad guys ever get into FreePBX, the security of your PBX has been compromised… permanently! This means you need to start over with all-new passwords and install a fresh system. You can’t fix every possible hole that has been opened on a FreePBX-compromised system!

12. Choosing VoIP Providers. So long as you use reputable VoIP providers that support registration of your SIP and IAX accounts, NO INTERNET PORT EXPOSURE TO YOUR SERVER IS EVER REQUIRED! If a VoIP provider doesn’t support SIP/IAX account registration, don’t use them! Add your public and private IP addresses in FreePBX’s Asterisk SIP Settings module to eliminate one-way audio issues.

13. Never Activate Auto-Replenishment. If you’re using VoIP providers that you pay by the minute, do your wallet a favor. Never, ever activate auto-replenishment on your accounts. By manually controlling the money flow to your accounts, you automatically insulate yourself from a huge phone bill. If something does come unglued, your financial exposure is limited to the preauthorized amount in each of your VoIP provider accounts.

14. Tighten Up International Calling. Almost every VoIP provider gives you the option of restricting international calls. If you don’t make international calls, use it! If you do make international calls, implement Outbound Routes in your FreePBX® dial plan with designated country codes. If you never call Africa, China, or cruise ships in international waters, make sure your dialplan doesn’t allow these calls.

15. Time of Day Calling Restrictions. Whether your server is for business or home use, time of day restrictions can save you a bundle. If remote telephone extensions are a must have for your server, chances are that those extensions don’t place calls in the middle of the night. Almost every hardware-based router/firewall allows creation of time of day rules for access. Implement these restrictions to minimize exposure to those that are hacking while you’re sleeping.

16. Minimize Simultaneous Calls. Especially with pay-as-you-go VoIP providers, often there is no limit to the number of simultaneous calls that can be placed from a trunk on your server. If someone manages to gain access to your accounts or your server, that can be really bad news. Some providers offer tools to restrict the number of simultaneous calls that can be placed. Take advantage of it to limit your financial exposure. Similarly, FreePBX includes a Maximum Channels option when you configure a Trunk. Don’t leave it blank. Set it to what you need to meet your needs.

17. Outbound Route Passwords. For outbound routes to international numbers and 900 numbers, always take advantage of the FreePBX Outbound Route option to prompt for a password. Just enter a numeric Route Password when you configure these outbound routes, and FreePBX will handle the rest.

18. IP Address Filtering with Asterisk Extensions. With the number of Asterisk SIP vulnerabilities reported over the years, suffice it to say IP address filtering at the Asterisk extension level is not something you should rely upon exclusively to protect your server. But it’s better than nothing. And, when used in conjunction with the other security mechanisms we’ve outlined, it provides another layer of security for your server. The extension setup in FreePBX includes the permit field which can be used to limit connections to a particular extension based upon an IP address or range of IP addresses. In addition, Travelin’ Man 2 deploys additional permit tables using an include list in sip_custom_post.conf in conjunction with include files for specified extensions, e.g., to define additional authorized IP addresses.

To restrict an extension to a private LAN address with a FreePBX extension entry in permit like this: Then you can broaden this restricted access with specified WhiteList addresses using an include file in /etc/asterisk that looks like this:


You, of course, would also have to authorize the specified IP address in your iptables configuration as well. That’s essentially how Travelin’ Man 2 works.

19: Check Your Logs Every Day. We’re still dumbfounded by the following quote from the article we cited above: “115,000 international mobile calls were made using the small business’s VoIP system over a six month period.” Six months and they never checked their call logs? FreePBX provides an incredibly simple way to review your call logs. Click the CDR Reports link and look at your call log showing the number of calls each day and the combined length of those calls. Nothing could be easier. Do it every single day!

20: Do Some Reading… Regularly. No security implementation is complete without a little regular effort on your part: reading. If you’re going to manage your own network or PBX, then you need to keep abreast of what’s happening in the business. There are any number of ways to do this, none of which take much time. The simplest approach is just to scan the Open Discussion, Add-Ons, and Bug Reporting topics on the PBX in a Flash Forum, the FreePBX Forum, and Asterisk News. Aside from reviewing your call logs, it’s the best 15 minutes you could spend to safeguard your system.

Originally published: Monday, October 1, 2012

Astricon 2012. Astricon 2012 will be in Atlanta at the Sheraton beginning October 23 through October 25. We hope to see many of you there. We called Atlanta home for over 25 years so we’d love to show you around. Be sure to tug on my sleeve and mention you’d like a free PIAF Thumb Drive. We’ll have a bunch of them to pass out to our loyal supporters. Nerd Vittles readers also can save 20% on your registration by using coupon code: AC12VIT.

Need help with Asterisk? Visit the PBX in a Flash Forum. If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new 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…

Travelin’ Man 3: Securing a PBX in a Flash or VoIP in the Cloud Server

UPDATE: Be sure to read about the latest enhancement to Travelin' Man 3 here.

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™. :wink:

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. :roll: 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. :wink:

We're officially releasing this for RentPBX users running PBX in a Flash 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 PIAF™ or Incredible PBX system. We'll make a backup of /etc/sysconfig/iptables before replacing your IPtables setup with the PIAF 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 PIAF 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 in addition to the whole enchilada, 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.

0 - All Services
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.

IPtables also has a major shortcoming IMHO. We support FQDNs in IPtables to make it more flexible. However, a failed FQDN during an IPtables restart will cause IPtables not to load at all. We have worked around this by adding our own restart command which you should always use: iptables-restart. 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
tar zxvf travelinman3.tar.gz
yum -y install bind-utils

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.

NOTE: If you are running PBX in a Flash in a cloud environment, be sure to add an entry to Travelin' Man 3 with the IP address of your cloud server. ifconfig will tell you what the IP address is. To add the entry, issue the command: /root/add-ip cloud using your actual cloud IP address.

WARNING: If you use an FQDN for your Administrator PC and it points to a dynamic IP address, be sure to also add this same FQDN using add-fqdn. Otherwise, IP address changes will not be detected, and you may lock yourself out of your own server.

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, 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 ( and, Google Voice (, (, DIDforsale (, CallCentric (, and also ( plus, (, Future-Nine, AxVoice (, SIP2SIP (, VoIPMyWay (, Obivoice/Vestalink (, 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. and 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:

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:


# Insert the account filenames to be checked below
# Remember to increment the account[#] for new entries


# 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   Updated: April 19, 2014


Need help with Asterisk? Visit the NEW PBX in a Flash Forum. If you're wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new 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...

FreePBX Backdoor Passwords Pose Asterisk Security Threat

Whether it’s forgetting to change a default password or not removing an additional password that you didn’t even know existed, some new revelations this week about FreePBX security are worth a minute of your time. There’s more disappointing news. The bad guys are getting smarter and much more dangerous.

If you’re new to Asterisk®, FreePBX® is the terrific, web-based graphical user interface that turns Asterisk into a user-friendly PBX that even mere mortals can use. It is bundled as part of every Asterisk aggregation including PBX in a Flash, trixbox, Elastix, and Asterisk Now. With the exception of PBX in a Flash, you may not know it’s there, but it is.

Years ago when FreePBX was in its infancy, the developers set up a way that administrators could still get into their system even if they forgot their administrator password. Typing admin:admin as the username:password combination basically gave you the keys to the castle in the default FreePBX install. That worked great in the days before folks exposed their systems to direct Internet web access which is a really BAD IDEA by the way.

Some of the aggregations shipped with a default username and password combination of maint and password. And for visually-impaired users, an automatic installer was crafted which set a default password of passworm. While users were encouraged to change these default passwords, many unfortunately didn’t heed the advice. According to one unnamed provider that recently saw a spike in illegal calling activity, his attempt to log in to some of his customer’s systems using password as the administrator password yielded a list of 50 vulnerable systems in under an hour!

And then there was this week’s Elastix revelation that the developers had embedded an additional backdoor password in their distribution that very few knew about… except the bad guys unfortunately. According to Xorcom:

It recently came to our attention that it is possible to login to the Elastix server unembedded FreePBX Web interface (http://address/admin) with user name ‘asteriskuser’ and password ‘eLaStIx.asteriskuser.2oo7′. The user name and password are the same user name and password used by FreePBX to access the ‘asterisk’ MySQL database. They are defined in the parameters AMPDBUSER and AMPDBPASS in the /etc/amportal.conf file.

What could possibly go wrong? Well, everything! Over the past few years, what typically happened with these vulnerable systems was that the buy guys obtained an extension password and began making free calls on your nickel until you checked your FreePBX call log or received your phone bill. That was then.

Here’s the latest bad guy scenario. The intruder logs into your FreePBX GUI using the default administrator password using a very sophisticated script which extracts all of your extension numbers, all of your trunk credentials, and, of course, all of your passwords. The script then hides a BOT on your server that “phones home” whenever any change is made in your account names or passwords. Finally, rather than using your server to make calls, the bad guys now use their own servers with your provider credentials to make free calls. So the first notice you receive of the intrusion is when your credit card is maxed out because you stupidly chose credit card auto-replenishment when you set up your VoIP account with your favorite provider.

SO… how do you fix it? Well, first you need to check whether your system is vulnerable. Using a browser, attempt to log into FreePBX at http://yourIPaddress/admin and use the following username:password combinations:


Be aware that on some systems using Fail2Ban such as PBX in a Flash, three consecutive failed logins may lock you out of your system for a lengthy period of time. On these systems, we recommend you first stop Fail2Ban: service fail2ban stop. Don’t forget to restart it after your testing: service fail2ban start.

If you gain access to your system using any of the above credentials and the web interface your server is exposed to the Internet, then you’ve got a problem. Do NOT just change your password thinking all is well. As mentioned, your new credentials are likely being transmitted to the bad guys before you can say “I’m S-C-R-E-W-E-D.” Instead, you should reformat your drive, contact all of your trunk providers and change your credentials. Then reinstall a NEW system using your new credentials AND new extension passwords. DON’T FORGET TO CHANGE YOUR DEFAULT PASSWORD! On PBX in a Flash and Incredible PBX systems, it’s easy. Just log into your server as root, enter the command passwd-master, and answer the prompts. Think up a very secure password… as if your bank account depended on it. It does! Finally, read our Primer on Asterisk Security. Be safe!

Originally published: Friday, April 15, 2011

Changes in PBX in a Flash Distribution. In light of the events outlined in our recent Nerd Vittles article and the issues with Asterisk 1.8.4, the PIAF Dev Team has made some changes in our distribution methodology. As many of you know, PBX in a Flash is the only distribution that compiles Asterisk from source code during the install. This has provided us enormous flexibility to distribute new releases with the latest Asterisk code. Unfortunately, Asterisk 1.8 is still a work in progress to put it charitably. We also feel some responsibility to insulate our users from show-stopping Asterisk releases. Going forward, the plan is to reserve the PIAF-Purple default install for the most stable version of Asterisk 1.8. Currently, we think that dubious title belongs to Asterisk even though it has its own share of surprises. Other versions of Asterisk 1.8 (newer and older) will be available through a new configuration utility which now is incorporated into the PIAF ISO.

Here’s how it works. Begin the install of a new PIAF system in the usual way by booting from the CD and pressing Enter to load the most current version of CentOS 5.6. When the CentOS install finishes, your system will reboot. Remove the CD, accept the license agreement, and choose the PIAF-Purple option to load the default version of Asterisk 1.8. Or exit to the Linux CLI if you want a different version. Log into CentOS as root with your root password. Then issue a command like this: piafdl -p 184 (loads Asterisk 1.8.4), piafdl -p 1833 (loads Asterisk, or piafdl -p 1832 (loads Asterisk If there should ever be an outage on one of the PBX in a Flash mirrors, you can optionally choose a different mirror for the payload download by adding piafdl -c for the .com site, piafdl -d for the .org site, or piafdl -e for the .net site. Then add the payload switch of your choice, e.g. piafdl -c -p 184.

Bottom Line: If you use the piafdl utility to choose a particular version of Asterisk 1.8, you are making a conscious decision to accept the consequences of your particular choice. We would have preferred implementation of a testing methodology at Digium® before distribution of new Asterisk releases; however, that doesn’t appear to be in the cards. So, as new Asterisk 1.8 releases hit the street, they will be made available through the piafdl utility until such time as our PIAF Pioneers independently establish their reliability.

Need help with Asterisk? Visit the PBX in a Flash Forum or Wiki.
Or Try the New, Free PBX in a Flash Conference Bridge. If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new 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 and 60 free minutes 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 and you get a free hour of outbound calling to test out their call quality. 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! After the free hour of outbound calling, 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…

Avoiding a $100,000 Phone Bill: VoIP WhiteList for IPtables

It’s been almost a year since we last wrestled with VoIP security for Asterisk®. With Christmas just around the corner, it seemed like a fitting time for a report card. Suffice it to say, the bad guys have not stood still. Attacks have become much more frequent and more sophisticated as VoIP systems have proliferated. A year ago we saw brute force attacks with thousands of password attempts on VoIP servers. These attacks could easily be detected by Fail2Ban. What we are seeing today are one and two hit drive-bys that usually are initiated from Windows zombies or hosted accounts established with stolen credit cards. These VoIP attacks fly under the radar unless you review your logs every day. Have the creeps gotten more patient? No, just smarter. They now understand the VoIP security model that has been deployed on systems like PBX in a Flash, and they simply work around it. Two hits per server, and they’re off to the next IP address only to return in a few hours to try two more. Are these attempts successful? Well, here’s the latest recipient of a $100,000 phone bill so the answer would appear to be affirmative.

We continue to wrestle with new security approaches to better protect Asterisk VoIP systems, and we’ve stumbled upon another golden arrow for your security quiver. Our Incredible PBX platform continues to offer the very best security solution because it is designed to sit safely behind a hardware-based firewall with virtually no exposure to the Internet. But such deployments assume that both your server and your phones are all safely ensconced behind a hardware-based firewall. If it turns out that you want to deploy a SIP phone for use by grandma or you’ve decided you’d like to try hosted PBX service from a provider such as,1 then there either need to be holes opened in the firewall or there is no hardware firewall protection in the case of hosted service.

Over the past few weeks, we’ve explored a number of new security approaches to better protect your Asterisk server. These include The SunshineNetworks Knock as well as VoIP Black Lists and VoIP White Lists. If you’re technically savvy, you’ll want to carefully consider “The Knock” for all of your SIP phones exposed to the Internet.

We spent a good bit of time considering various VoIP BlackList solutions. As the name implies, a list of the bad guys’ IP addresses is fed into IPtables which then blocks access to your server from these addresses. Sounds good, right? One approach with a BlackList is to block all IP addresses from “problem countries.” The methodology to implement this solution can be found in this thread on the PIAF Forums. The problem, of course, is identifying the “problem countries.” Another option was to implement an IPtables Blacklist based upon the work of the VoIP Blacklist Project. Perhaps ironically, the VoIP Blacklist Project actually blocks the IP addresses of both Nerd Vittles and PBX in a Flash, and emails requesting removal of our IP address were ignored. To save time, the VoIP Blacklist Project employs CIDR Masks which can blacklist hundreds of thousands of IP addresses in one fell swoop. Problem is that a lot of innocent people get caught in the net, and there’s no easy way out without maintaining the blacklist yourself. The final dagger in the black list approach is zombies. Insecure Windows machines have been compromised by the droves worldwide and particularly in the United States. So identifying all of these now-malicious systems is not unlike playing Whack-a-Mole. When you block one of them, six more pop up. So, after giving it the good old college try, our view of VoIP Blacklists should be obvious. No, thanks. There are very real risks that the bad guys can and have poisoned existing blacklists with safe IP addresses, and the number of Windows zombies grows geometrically making it all but impossible to have or maintain a blacklist that affords any real protection.

These results with black lists led us to the conclusion that the only real security mechanism that could protect many VoIP servers today was a VoIP WhiteList for IPtables. As the name implies, we want to identify the IP addresses of every SIP and IAX trunk and extension on your server and then feed those addresses into IPtables so that the only access to VoIP resources on your server is from these addresses. Today’s VoIP WhiteList for IPtables consists of two bash scripts: one queries the MySQL database in which FreePBX stores all of the trunk and extension information for your server and the other populates IPtables with the results of the queries. We would hasten to add that a similar white list is equally important for SSH access to your server although we think it is better to implement an SSH WhiteList on your hardware-based firewall. In this way, you can adjust the SSH white list via web browser while traveling without locking yourself out of your Asterisk server.

Prerequisites. To use today’s VoIP WhiteList for IPtables, you’ll need either a current version of PBX in a Flash or Incredible PBX. Other aggregations will also work provided your system is FreePBX-based (version 2.6 or later), has IPtables already installed and functioning properly, and has an /etc/sysconfig/iptables configuration file that closely matches the stock PBX in a Flash design. We’ll leave it to you to make that call after reviewing the scripts.

VoIP WhiteList Design. We’ve designed the VoIP WhiteList for IPtables to be modular. There’s a script which extracts from MySQL the list of IP addresses used by your trunks and extensions. This text-based list is stored in /etc/firewall.whitelist. You can manually add and delete entries from the list once it is populated.You also can rerun the script at any time to generate a fresh catalog of WhiteList IP addresses based upon your current trunk and extension settings. This script also enables access to your server from the public IP address of your server as well as all non-routable IP addresses. Finally, it modifies /etc/sudoers slightly so that Travelin’ Man can be used to add dynamic IP addresses on the fly. We’ll cover that below.

The second script is, and it is used to actually implement your new VoIP WhiteList in IPtables. The changes take effect immediately. It also can be run again to update these entries if you manually add or delete IP addresses in /etc/firewall.whitelist. This script always creates a backup copy of your previous /etc/sysconfig/iptables file and names it iptables.timestamp where the timestamp is the date and time of your last update, e.g. iptables.12012010-083841 was created on Dec. 1, 2010 at 08:38:41. If you should ever shoot yourself in the foot, simply copy one of the iptables backup files to /etc/sysconfig/iptables and then restart IPtables: service iptables restart.

WARNINGS: In order to implement the WhiteList, the script removes the existing IPtables entries which permit SIP and IAX access from anywhere using UDP ports 4569 and 5000 to 5082. If you have edited these entries in any way, you’ll need to remove them and restart IPtables before running Otherwise, your more general firewall entries will leave your system vulnerable to access from IP addresses not in your VoIP WhiteList.

If your system is running on a hosted server, you’ll need to make a couple of additions to /etc/sysconfig/iptables and restart IPtables (service iptables restart) before running, or you may lock yourself out of your own server. Be sure to add the public IP address of your server, and also add the IP address from which you are making changes to your server. Each entry should look like the following example using your actual IP addresses. And the entries should be added above the COMMIT line in the same section of the iptables file as the existing UDP 10000:20000 ACCEPT entry:


Installing the VoIP WhiteList for IPtables. Installation is easy. Just log into your server as root and issue the following commands:

cd /root
tar zxvf firewall-whitelist.tar.gz

If you installed one of the beta versions of the VoIP WhiteList from the PIAF Forums, then you’ll need to do a little housecleaning before actually running either of the scripts. Just edit /etc/sysconfig/iptables and clean out all of the entries that contain 5000:5082 as well as any entries nearby that include the non-routable IP addresses, e.g. Finally, if there are entries beginning with -A WHITELIST, delete those as well. Then restart IPtables: service iptables restart. Thank you for your testing and feedback!

Deploying Remote SIP Phones. What remains is some method for connecting remote SIP phones with dynamic IP addresses. Our Travelin’ Man application was specifically designed to provide this support although the initial version only opened the necessary IP address for Asterisk access. The latest release also provides the necessary IPtables support. You have two options: either remove the old version and supporting directories under /var/www/travelman or edit the index.php file in each subdirectory you’ve created and make the change shown in this post on the PIAF Forums. Enjoy!

Need help with Asterisk? Visit the PBX in a Flash Forum.
Or Try the New, Free PBX in a Flash Conference Bridge. If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new 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 and 60 free minutes 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 and you get a free hour of outbound calling to test out their call quality. 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! After the free hour of outbound calling, 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…

  1. We gratefully acknowledge the contributions of to the PBX in a Flash Development Team. In addition to hosted accounts to test PBX in a Flash in the hosted environment, also has contributed technical assistance particularly as it relates to our Google Voice-Asterisk integration efforts. []

Ringbinder theme by Themocracy