Posts tagged: security

Introducing the Grandstream UCM6100 Asterisk PBX: So Close But So Far Away

Grandstream has done with Asterisk what Samsung and others did with Android. You basically take a freely available, open source toolkit and transform it into a terrific piece of turnkey hardware with tremendous savings in development costs. While it’s great for consumers, to us it highlights what is wrong with the GPL2 license which lets companies do this in the first place. These for-profit companies give almost nothing back to the open source community. Remember, it’s not their toolkit which took talented (and uncompensated) developers hundreds of man-years to construct. In Samsung’s case, they built closed source smartphones and tablets. With the Grandstream UCM6100 series, you get closed source PBXs. What’s wrong with this picture? Lots! You’re taking someone else’s work product, embellishing it to make a profit, and returning nothing to the open source community that made your open source product possible in the first place. Don’t get us wrong! We love Samsung’s smartphones and tablets. We’ve owned at least a half dozen of them. And Grandstream’s UCM6100 is an incredibly useful appliance for home offices as well as small and large organizations. We can think of a thousand use cases for the UCM6100 in the corporate and government workplace. If done right, it could easily have replaced the $200,000 PBX that supported 100+ employees in one of my former organizations. We also should note that Grandstream isn’t the first company to attempt this feat with Asterisk. Read Tom Keating’s excellent article for the history. And don’t forget the AA50 for a few cents more. :-)

What is disappointing is that all of these products would be so much better and so much safer if the companies would open source their code and encourage community development to finish the job they started.1 No individual and few companies could match the hardware development platform that Samsung and Grandstream have managed to put together. In Grandstream’s case, you can buy the UCM6102 at retail for $264! It includes two FXS ports for devices such as fax machines and two FXO ports for interconnecting your Ma Bell PSTN trunks to a one-pound SIP powerhouse. That $264 buys you an incredibly attractive piece of hardware with an LCD that tells you everything about your PBX at the click of a button. And there are small LEDs to display the status of the LAN, WAN, USB, SD card, Phone, Fax, and both Telco lines. The device can sit under your phone on your desk in a SOHO office, or it can be wall-mounted in the closet of a bank’s branch office. Models are also available with 4 FXO ports (pictured above) as well as 8 and 16 FXO ports. One of these could meet the needs of almost any organization, regardless of size. Amazing hardware technology, really!

The web-based software user interface (UI) is no less impressive. FreePBX® has been our development partner on open source Asterisk® projects for the better part of a decade. To say they’ve made Asterisk what it is today is an understatement. Asterisk is a toolkit. FreePBX makes it a useful PBX for millions of users around the globe. Having said all of that, competition makes the world go ’round. And Grandstream has built an impressive UI for the UCM6100 devices. What is more amazing is to compare the performance of the Grandstream device to our own Incredible PBX for the Raspberry Pi which runs with Asterisk and FreePBX on a virtually identical processor with the same memory constraints as the UCM6100 devices. Night and day is the only way to sum it up. The Grandstream PBX literally runs circles around the Raspberry Pi in hardware and UI performance. In fact, you would never know the Grandstream PBX wasn’t running on a quad-core processor with several gigs of RAM if you were judging by performance. And there’s even a little fan that comes on about once an hour as if to remind you that there’s a real computer under the covers.

After receiving our UCM6102 late last week, we put it through its paces. We set up extensions and trunks and ring groups and outbound routes and inbound routes. We tested voicemail. We configured an IVR. We uploaded custom voice prompts. We tried out the Parking Lot and Call Forwarding and Conferencing. It all worked swimmingly, and configuration took only minutes with the web-based UI which was quite intuitive given its similarity to older releases of FreePBX such as 2.8 and 2.9.

But, in the words of Geoffrey Chaucer, “All good things must come to an end.” Our next mission was to interconnect the UCM PBX with one of our existing PBX in a Flash servers. After all, the real utility of a turnkey PBX appliance like this would be to support a branch office with no technical staff in residence. This would allow a bank or a hospital or a real estate company to interconnect sites with extensions at each site that could transparently connect to each other. For example, dialing 5000-5099 would ring phones in the main headquarters while dialing 5300-5399 would ring phones in branch office #3. For this to work in the Asterisk environment, we need password-protected trunks on each Asterisk server that interconnect the PBXs to each other to form a meshed network. It’s not difficult, and we’ve explained how to do it in previous Nerd Vittles articles using PBX in a Flash as well as Incredible PBX for the Raspberry Pi.

Trunk to Trunk Server Connections. As the screenshot above shows, connecting a trunk from the Grandstream PBX to our Asterisk server was a breeze using both SIP and IAX trunks. But attempts to connect a trunk from the Asterisk server to the Grandstream PBX using both SIP and IAX failed with password errors. When we alerted the Grandstream development team, suffice it to say they were confused. Did we mean we wanted to connect a remote Asterisk server to an extension on the UCM6100? That was the first hint that all was not well in Asterisk Land. It became readily apparent that the developers were quite adept at mimicking the functionality of FreePBX to create a powerful PBX. But they lacked an in depth understanding of some of the Asterisk fundamentals. While the Grandstream development team was incredibly responsive, it reinforces why open sourcing their code would provide huge benefits not only to others but also to their own project. It gets worse, unfortunately, much worse.

To make a long story short, it doesn’t appear that safely interconnecting trunks between Asterisk servers and the Grandstream devices is available at least at this juncture. What is possible and what the Grandstream developers documented is the ability to create a trunk on a remote Asterisk server that registers to an extension on the Grandstream PBX. But this still did not enable users on remote Asterisk servers to call extensions on the Grandstream PBX unless the Allow Guest Calls option was enabled in the device’s SIP settings. That didn’t make a lot of sense to us if, in fact, the remote Asterisk server was actually registered to the Grandstream PBX. So we changed the password on the extension to make sure the registration would fail. And, yes, you still could make calls to the Grandstream PBX extensions so long as Allow Guest Calls was enabled. Did we mention? It gets worse, much worse.

IVR Vulnerability. Remember that IVR setup we mentioned? By default, it sits on extension 7000 on the Grandstream PBX. We called it from an extension on the remote Asterisk server, and it worked as expected even without a valid SIP registration so long as Allow Guest Calls was enabled. You probably can guess what our next test was. We disabled Allow Guest calls and attempted to call an extension on the Grandstream PBX. It rang busy as it should. We then dialed extension 7000, and guess what? The call went through. Whoa! Remember, SIP guest calls had been disabled, and there was no SIP registration because of a password mismatch. In short, anybody from anywhere that knew the public IP address of our Grandstream PBX could now connect to any IVR on the device just by knowing that the IVRs begin with extension 7000. It’s a classic dial plan mistake of letting external calls bleed into privileges which should be reserved for internal users. For security and other reasons, it’s also why FreePBX does not assign extension numbers to IVRs. But there’s more.

Stealth AutoAttendant Gone Bad. As you can see from the IVR Setup screen shown above, two of the options available when setting up an IVR are to enable calls to Extensions and to Trunks. Many administrators as well as casual users that barely understand what they’re doing probably would enable these features believing the options would be restricted to local use by the default guest call restriction. Wrong! What it means in terms of this security lapse is that now any anonymous caller with your IP address can dial into your Grandstream PBX and, while the IVR announcement on the default IVR extension (7000) is playing, the anonymous caller can dial any Extension or any long distance call supported by the Grandstream PBX trunk configuration so long as these options were enabled in the IVR. In Nerd Vittles parlance, think of it as a remake of our Stealth AutoAttendant with Public DISA Connectivity… for the world!

FXO/PSTN Warning. In discussing this with Tony Lewis of Schmooze and FreePBX fame, he reminded me that we’re talking about a PBX that’s been designed for business use with FXO ports and PSTN trunks. So, while the SIP vulnerability at least required that someone know the IP address of your PBX, once you connect PSTN lines to the Grandstream PBX and answer incoming calls with an IVR on the system, all bets are off. Anonymous bad guys now can place PSTN calls to any published phone number for your server that happens to connect to an IVR. These calls then can be used as the springboard to place outbound calls to anywhere the PBX trunk setup permits. Get out your checkbook!


Syslog Configuration. We have another concern with the device as well. The default syslog setup sends information to log.ipvideotalk.com which is a server registered to Grandstream Networks in Los Angeles. With a closed platform, you have no way to decipher what is actually being sent without putting Wireshark on the line and monitoring it. While we are not suggesting that Grandstream has anything but the best of intentions, we think it’s a better practice to allow folks to opt in to monitoring systems, particularly ones that provide as much confidential information as the Asterisk syslog setup.

Other Security Issues. Having owned the device for only a few days, we obviously have not tested all of the potential attack vectors. There are other anomalies in the dial plan code which we really can’t quite figure out without seeing the actual code. We were going to try to document an equally serious issue with the trunk peering, but your head would probably explode just trying to wrap your head around the problem. Ours did! Suffice it to say, with a single outbound route to a registered trunk that has failed to register, all outbound calls initiated by internal and external callers should always fail. They don’t! We’re also unclear whether the appliance provides SSH access for the root user. In any case, you aren’t provided the password. That could potentially be a problem if, in fact, a root account is enabled on the appliance. Finally, we should note that, according to the GPL materials published by Grandstream, this appliance is running Asterisk 1.8.9.3. Twenty-five versions of Asterisk 1.8 have been released since that offering appeared eight months ago. Some of those updates patched serious security vulnerabilities in the Asterisk 1.8 code.

Until Grandstream addresses some of these security issues, you are well advised to only operate a Grandstream PBX behind a secure, hardware-based firewall with no Internet port exposure. We would caution against connecting PSTN trunks to the device at this juncture. If you’re feeling lucky, a possible option for the time being would be to disable IVRs and especially the extension and trunk dialing options. That alternative unfortunately defeats the real purpose of buying these devices.

I Have A Dream. Not to beat a dead horse, but discoveries like this reinforce the need for companies such as Grandstream to revisit their design strategy and give serious consideration to open sourcing their code. After all, Grandstream is primarily a hardware company, and they could sell a gazillion of these appliances if the platform were open. We’ve hurriedly compiled a list of features that currently are missing which could be added almost overnight if this were an open source project. The PBX in a Flash development team would be at the front of the line to assist!

  1. No text-to-speech functionality
  2. No speech-to-text functionality
  3. No (intended) DISA functionality (but data is collected in syslog??)
  4. No ability to load custom dialplan code
  5. No AGI/PHP script support
  6. No Google Voice support for free calling in U.S. and Canada (add it for $30 like this)
  7. No SIP/IAX trunk registrations from remote Asterisk servers
  8. No incoming calls except via anonymous SIP or PSTN (nixes interoffice setups for extensions)
  9. No traditional fax support except using fax machine on FXS port (T.38 is supported)
  10. No access to Asterisk CLI for debugging or otherwise
  11. Crippled SSH access (basic config info, set/get variable, upgrade, reboot, reformat)
  12. No VPN support
  13. No SIP security with Internet exposure
  14. No Fail2Ban support
  15. No WhiteList security to lock down the server

Recommendations. In closing, we don’t mean to suggest that security vulnerabilities never occur in open source code, but open source does guarantee that hundreds if not thousands of developers would be reviewing the code rather than a handful of people that may not fully appreciate all of the nuances of Asterisk. And each time a discovery like this occurs that has the potential of costing unsuspecting companies thousands of dollars in unanticipated phone bills, it gives Asterisk an undeserved black eye. Issuing a patch unfortunately won’t cure this problem for most purchasers because most purchasers never upgrade firmware on appliances.

We hope Grandstream will either pull the devices from the marketplace until the default firmware is fixed or place a big orange warning sticker on the boxes warning purchasers to upgrade the firmware and explaining the consequences of not doing so. Better yet, do the right thing and open source the platform and the code so that others can benefit from Grandstream’s development work on what still could be an incredibly useful and amazing device.


July 31 Update: After an exchange of emails with Grandstream, we have a better understanding of their call routing methodology that we want to pass along. It should be noted that the security holes we documented still exist, but there are mechanisms in place to stop the bleeding… if you know how to use them. Grandstream relies upon a set of Privilege Levels for extensions and IVRs as well as inbound and outbound routes. These include Internal, Local, National, and International. Only Extensions and IVRs with matching or higher privileges can use Inbound and Outbound Routes of a matching or lower privilege level. Read that again! It’s important. For example, if an extension has Internal privileges (the default), then that Extension can only access Outbound Routes designated as Internal. Calls to other numbers will fail. Unfortunately, all routes default to Internal, and this security mechanism is barely documented in the User Manual. Unlike FreePBX which uses Outbound Routes to connote calls leaving your server, Outbound Routes in Grandstream parlance are a set of dialplan rules for every call. Stated differently, to have a secure system, you need to create an Outbound Route for every possible type of external AND internal call. The same holds for Inbound Routes. Here’s an example of how to safely configure Trunks and Extensions between the Grandstream PBX and a remote Asterisk server so that extension-to-extension calls can be made between the two offices while insulating your IVRs from the long distance free for all that we documented in the original article.

Unfortunately, the IVR setup is still buggy and hence vulnerable. As the chart at the end of this article makes clear, there presently is no way to configure an IVR in such a way that remote callers cannot make long distance trunk calls while local extensions can. The only options presently available are either to disable the Dial Trunk option or to set the IVR Privileges lower than the Privileges setting for your outbound trunks. Do NOT rely upon a separate IVR for local users with the Dial Trunk option enabled thinking you’re safe. You’re not! Our original article above explains the possible consequences.

Remote Asterisk Server Setup Using FreePBX. On our remote server, we want to create two Trunks and an Outbound Route. One trunk will be used to set up an outbound registration to an Extension on the Grandstream PBX. We’ll use this trunk to place calls to Grandstream PBX extensions, IVRs, and conference rooms. The other trunk will be used to authenticate an inbound registration from the Grandstream PBX. The Grandstream PBX extensions will use this trunk (with registration from the Grandstream PBX) to initiate calls to extensions registered on our remote server. The outbound route will be used to route calls using the outbound registration trunk to Grandstream PBX extensions, IVRs, and conference rooms.

Here is the outbound registration trunk to extension 5001 on the Grandstream PBX (192.168.0.120 in our example):

Here is the inbound registration trunk to authenticate the Grandstream PBX matching trunk:

Here is the outbound route that allows extensions on the remote server to call Grandstream extensions, IVRs, and Conference Rooms:

You would also want to create an Inbound Route for 5001 that sends incoming calls from dialing 5001 on a Grandstream PBX extension to a particular destination on your remote server. Otherwise, the calls would be processed using the FreePBX default inbound route if you happen to have one. In our setups, we typically point the default inbound route to an IVR or a receptionist’s extension.

Grandstream PBX Setup to Connect to Remote Asterisk Server. To make all of this work securely, we need to create an Extension to handle the inbound registration from the remote Asterisk server so that users on the remote server can call extensions, IVRs, and conference rooms on the Grandstream PBX. And we need a SIP trunk that will register to the remote Asterisk server so that Grandstream PBX users can call extensions on the remote Asterisk server. Then we need Inbound and Outbound Routes to lock things down. We’re using 192.168.0.181 as the IP address of the remote Asterisk server in this example. The key point in securing the Grandstream PBX is to assign the proper permissions to the Grandstream Extension and IVRs that will be used with remote server connections. Then elevate permissions where necessary on the Inbound and Outbound Routes to make sure only our truly local extensions can make calls using Grandstream long distance and PSTN trunks. Don’t confuse local extensions with Local permissions. A local extension is an extension that registers to the Grandstream PBX. Local permissions is a security level that means a particular resource can only do things with other matching Internal or Local resources and with no resources that have been assigned a higher permission level. Internal permissions means a resource can only do things with other Internal resources. Clear as mud? We know. Hang in there until we’re finished.

First, create extension 5001 that will be used by the remote Asterisk server to register with the Grandstream PBX:

Next, create a SIP Trunk that will register to the remote Asterisk server at 192.168.0.181. We’ve used 1234 as the password in our examples so plug that in for the time being. You obviously would want something more secure than that! You’ll note that you don’t assign a Permission level to a Trunk. That is handled in the Inbound and Outbound Routes which tie particular routes to designated trunks. So Trunks inherit their permissions based upon a matching route. We suspect this may be the root cause of the security holes that we’ve documented. If there is no specified route for a particular type of call, Grandstream is doing something internally to make a determination on whether to allow the call or not. In some cases, that determination just happened to be wrong.

For truly local users, i.e. extensions directly connected to the Grandstream PBX, you need to elevate the Permissions for those extensions to reflect the types of calls you want them to be able to make. Typical permission for these extensions would be National or International. The same holds true for IVRs. Elevate IVR permissions to restrict usage to your intended audience. Keep in mind that we’re treating calls to extension 5001 on the remote Asterisk server as Internal. That’s the bottom rung in the security ladder which means every local extension and IVR will be able to place calls to that extension. If this isn’t what you want, then you’ll need to elevate the 5001 extension permissions accordingly. For example, you may only want Grandstream PBX extensions with Local call permissions to be able to call extensions on the remote PBX. In this case, you would want to change the 5001 extension permission level to Local.

Let’s tackle the Inbound Routes next since this was the cause of the inability to connect to local Grandstream extensions from the remote server. If you’re using the default Grandstream setup, then you’ll need Inbound Routes for both _50XX extensions and _70XX IVRs to permit remote callers to connect with Grandstream PBX extensions and IVRs with Local permissions only. This means that even if they connect to the 7000 IVR, they will not be able to make long distance calls on your nickel even if Trunk dialing is enabled.

The Inbound Route rule for Extensions should look like this:

The Inbound Route rule for your IVRs should look like this:

The key point to keep in mind with Inbound Route IVR permissions is to keep the permission level LOWER than whatever permission level you assign to the Outbound Route for placing calls that cost you money, typically National and International.

Now let’s set up the Outbound Route to restrict outbound calls to 10-digit numbers for extensions, IVRs, and Inbound Routes to those with at least National permissions. Keep in mind you may need additional outbound routes with Local permissions for certain 10-digit numbers if your local calling area happens to include free calling to multiple area codes, e.g. Atlanta.

Depending upon your setup, you may need additional dialplan rules and outbound routes to handle 11-digit numbers which should be routed out through a PSTN trunk, e.g. 1NXXNXXXXXX. And because of the security hole, be sure to add a catch-all for international calls that requires International permissions. The dial string XXXXXXXXXXX. will catch everything not included in the NXXNXXXXXX and 1NXXNXXXXXX outbound rules.

Finally, you’ll need an Outbound Route that allows local callers on the Grandstream PBX to connect to extensions on the remote PBX. You typically would assign Internal or Local permissions to this route which would look something like the following depending upon the extension configuration on your remote PBX:

A Word of Caution on IVRs: In the Grandstream security model, IVRs have their own Privilege levels. At least at this juncture, that Privilege level can “promote” the permissions of a call that began at a lesser privilege level. For example, if your Inbound Route for 7XXX calls is assigned Local privileges and the 7000 IVR is assigned National privileges, an incoming call to 7000 from a remote PBX will “inherit” the National privileges of the IVR. This obviously should never be possible. Either the 7000 IVR should generate Congestion and not answer the call at all where the Inbound Route has lesser privileges than the IVR. Or, at the very least, those options in the IVR (including stealth extension and trunk dialing) that require National or International privileges should generate Congestion and disconnect the call. For the time being, ALWAYS set the Privilege level of an IVR to the lowest permission threshold to protect your server and wallet from the consequences of placing unintended toll calls. Here’s a little chart we put together to document the impact of merely changing the Privilege setting for the 7000 IVR:

Other Tips and Tricks. Here are a few other suggestions to expand the functionality of your Grandstream PBX:

Add Google Voice Support with an OBi Device

Add Bluetooth Cellphone Trunk with an OBi202

Add Free iNum Calling Worldwide with a VoIP.ms Account using an OBi202

Continue reading Part 2


Deals of the Week. There are a couple of amazing deals still on the street, but you’d better hurry. First, for new customers, Sangoma is offering a board of your choice from a very impressive list at 75% off. For details, see this thread on the PIAF Forum. Second, a new company called Copy.com is offering 20GB of free cloud storage with no restrictions on file size uploads (which are all too common with other free offers). Copy.com has free sync apps for Windows, Macs, and Linux systems. To take advantage of the offer, just click on our referral link here. We get 5GB of extra storage, too, which will help avoid another PIAF Forum disaster.

Originally published: Tuesday, July 30, 2013




Need help with Asterisk? Visit the PBX in a Flash Forum.


 

Don’t miss the first-ever FreePBX World on August 27-28 at the Mandalay Bay in Las Vegas. For complete details, see this post on the FreePBX blog.


 

We are pleased to once again be able to offer Nerd Vittles’ readers a 20% discount on registration to attend this year’s 10th Anniversary AstriCon in Atlanta. Here’s the Nerd Vittles Discount Code: AC13NERD.


 
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…

  1. It turns out Grandstream may not have much of a choice but to open source their code. It now appears their PBX and User Interface are both based upon open source GPL2 software owned by Digium. []

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@54.235.12.34. 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 2.0.6.3 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
wget http://incrediblepbx.com/incrediblepbx10.gz
gunzip incrediblepbx10.gz
chmod +x incrediblepbx10
./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/incrediblefax11.sh. 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
wget http://incrediblepbx.com/incrediblebackup10.tar.gz
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.


whos.amung.us If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what’s happening. It’s a terrific resource both for us and for you.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity.
 


Some Recent Nerd Vittles Articles of Interest…

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.” News.com.au 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 192.168.0.150 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 root@pbx.mydomain.com. 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. 701.inc, to define additional authorized IP addresses.

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

[701](+)
permit=150.155.90.143/255.255.255.255

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.


whos.amung.us If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what’s happening. It’s a terrific resource both for us and for you.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity.
 


Some Recent Nerd Vittles Articles of Interest…

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
wget http://incrediblepbx.com/travelinman3.tar.gz
tar zxvf travelinman3.tar.gz
yum -y install bind-utils
./secure-iptables

When prompted for the FQDN or IP address of your Administrator PC, use the FQDN if you have one. Otherwise, type in the IP address and press the Enter key. Agree to the terms of service and license agreement by pressing Enter. When the IPtables file displays, verify that you have typed your FQDN or IP address correctly, or you will lock yourself out of your own server. Press Ctrl-X to exit the editor, and then press Enter to update IPtables and save your new configuration.

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 12.34.56.78 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, DynDNS.com can handle it. What we recommend is setting up a separate FQDN for each phone on your system that uses a dynamic IP address. This can include the administrator account if desired because it works in exactly the same way. When the administrator extension drops off the radar, a refresh of IPtables will bring all FQDNs back to life including the administrator's account. Sounds simple? It is.

Preparation. Before we make further modifications to IPtables in Step #3, let's make a list of all the folks that will need access to your VoIP Server in the Cloud. For each entry, write down the name of the person, server, or phone as well as the type of entity which needs server access. Then provide either the static IP address or FQDN for each entry. If one or more of your IP addresses are dynamic (meaning the ISP changes them from time to time), we'll cover managing dynamic IP addresses in a minute. For now, just make up a fully-qualified domain name (FQDN) for each dynamic IP address using one of the available DynDNS domains. For static IP addresses, use the FQDN or the IP address. HINT: FQDNs make it easy to remember which entry goes with which provider.

Make a list of your providers NOT in this list: Vitelity (outbound1.vitelity.net and inbound1.vitelity.net), Google Voice (talk.google.com), VoIP.ms (city.voip.ms), DIDforsale (209.216.2.211), CallCentric (callcentric.com), and also VoIPStreet.com (chi-out.voipstreet.com plus chi-in.voipstreet.com), Les.net (did.voip.les.net), Future-Nine, AxVoice (magnum.axvoice.com), SIP2SIP (proxy.sipthor.net), VoIPMyWay (sip.voipwelcome.com), Obivoice/Vestalink (sms.intelafone.com), Teliax, and IPkall. The providers listed above are already enabled in the secure-iptables setup script. We call them Trusted Providers only because we trust them and have personally used all of them. We consider them reliable folks with whom to do business. It doesn't mean others aren't. It simply means these are ones we have tested with good results over the years. The only providers you'll need to add are ones we haven't provided. Also be sure to check whether the FQDNs of the providers above cover the server for your account. If not, you'll need to manually add those FQDNs as well. Keep in mind that trusted providers will have full SIP and IAX access to your server so stick with tried-and-true providers for your own safety. The PBX in a Flash Forum and DSL Reports are good sources of information on The Good, The Bad, and The Ugly.

Finally, list with a name each phone that will be connected to an extension on your server. If you have 10 traveling salesmen, then you might want to name them all by last name and also provide FQDNs with their last names, e.g. smith.dyndns.org and jones.dyndns.org. No spaces or punctuation in names or FQDNs! We strongly recommend using FQDNs wherever you can because it means zero work for you when a provider changes an IP address. Here's the table we use:

Name
Type: Person, Provider, Server, Phone
IP Address Type: Static or Dynamic
FQDN or IP Address
Services Desired: SIP, IAX, Web, FTP, SSH, etc.

Step #3: Adding Authorized Users. Now take your list and add each account to your server while logged in as root and positioned in the /root directory. For static IP addresses, use add-ip. For dynamic IP addresses and FQDNs, run add-fqdn and plug in the FQDN for each account. When one of your accounts needs to be removed, just run del-acct from the /root folder on your server and plug in the name of the account to delete. If a user changes from a static IP address to a dynamic IP address or vice versa, just delete the user and then add them again with the new IP address or FQDN. All of the accounts are stored in /root and have names like this: name.iptables.

Step #4: Setting Up DynDNS Client Updates. There are actually two pieces in the Dynamic DNS update puzzle. At the end-user side, you need to deploy a DynDNS update client on the same subnet as the phone of your user. See the links above to download the update software you prefer. In the case of cellphones with SIP phone capability, this could be as simple as installing the DynDNS update client directly on the phone itself. Plug in your DynDNS credentials as well as the FQDN associated with the particular phone, and the rest is automatic.

Step #5: Setting Up IPtables Auto-Refresh. Finally, we need a way for your server to discover when a refresh of FQDNs becomes necessary because someone's IP address has changed. The simplest way to do this is to automatically run a simple script (ipchecker) that polls the DNS authoritative server to determine whether the dynamic IP address associated with an FQDN has changed. If so, we'll update the account.iptables file to reflect the new IP address and then restart IPtables. This will refresh all IP addresses associated with FQDNs. If all or most of your users spend time sleeping each day, you may wish to run the script only during certain (waking) hours of the day so your server has less of a load. The other consideration is how often to check. The guideline here is how long can any user live without their SIP phone being connected to your server. 10 minutes may be reasonable for some. 60 minutes may suffice for others. For us, it's 3 minutes. It's your choice. The way Travelin' Man 3 works is, whenever at least one account has an IP address change, it will trigger a restart of IPtables to do an IP address refresh for all of the FQDNs.

The top of the ipchecker script in /root looks like this:

#!/bin/bash

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

account[0]=larry.iptables
account[1]=curly.iptables
account[2]=moe.iptables

# ipchecker (c) Copyright 2012, Ward Mundy & Associates LLC.

You'll need to edit the script (nano -w /root/ipchecker) and modify the section in bold to reflect the actual FQDN account names you've created on your server that are associated with dynamic IP addresses only. You don't want to monitor accounts with static IP addresses or FQDNs that never get updated. When those extensions are off-line, it's not because their IP address changed, and restarting IPtables won't really help to improve the situation. Be sure to increment the account[n] array for each new account that you want to monitor and use the exact format shown in the example above. Before you enter an account in the script, display the contents of the file using cat /root/accountname.iptables. Make certain that the file includes BOTH an FQDN, then a space, and then an IP address. If not, delete the account (del-acct) and add it again using add-fqdn.

Once you've entered all of your accounts with dynamic IP addresses, save the script: Ctl-X, Y, then Enter. Run the script manually now to be sure it works as you intended: /root/ipchecker. Be advised that typos that list accounts that don't exist will cause problems. Error checking consumes processing cycles by requiring additional queries so we've left it out. That means it's solely up to you to check your account names for accuracy. And, remember, only include accounts that have dynamic IP addresses with FQDNs.

Step #6: Automating FQDN Refreshes with Cron. Finally, you'll need to add an entry to the bottom of /etc/crontab using nano. If you wanted the script to run 24 hours a day at 10 minute intervals, here's the command:

*/10 * * * * root /root/ipchecker > /dev/null

If you wanted the script to only run between the hours of 8 a.m. and 9 p.m. (server time zone) at 10 minute intervals, then you'd use something like this:

*/10 8-21 * * * root /root/ipchecker > /dev/null

On our RentPBX complimentary account which we use while traveling, we actually set the interval to 3 minutes. Since the DNS lookups use dig, changes on Android phones using the DynDNS client are almost instantaneous even with automatic switching between WiFi and cellular service. Finally, be sure to type date on your server and verify which time zone your cloud server thinks it's in! Adjust the times in /etc/crontab accordingly.

Be sure to check back here periodically for updates and follow the latest happenings about Travelin' Man 3 in this thread on the PIAF Forums. Enjoy!

Originally published: Thursday, March 29, 2012   Updated: April 19, 2014

UNLESS YOU DISCONTINUE USING FQDN'S WITH IPTABLES, IT IS ABSOLUTELY ESSENTIAL THAT YOU MONITOR YOUR SERVER DAILY IF YOU ARE RELYING EXCLUSIVELY UPON IPTABLES AS YOUR FIREWALL PROTECTION MECHANISM AND YOU ARE USING FQDN'S AS PART OF YOUR CENTOS SECURITY METHODOLOGY!




Need help with Asterisk? Visit the NEW PBX in a Flash Forum.


whos.amung.us If you're wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what's happening. It's a terrific resource both for us and for you.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you're seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity's DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here's a deal you can't (and shouldn't) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won't get the special pricing! Vitelity's rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity.
 


Some Recent Nerd Vittles Articles of Interest...

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:

admin:admin
admin:password
admin:passworm
maint:admin
maint:maint
maint:password
maint:passworm
wwwadmin:password
wwwadmin:wwwadmin
wwwadmin:admin
asteriskuser:eLaStIx.asteriskuser.2oo7

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 1.8.3.3 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 1.7.5.6.2 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 1.8.3.3), or piafdl -p 1832 (loads Asterisk 1.8.3.2). 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.


whos.amung.us If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what’s happening. It’s a terrific resource both for us and for you.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID 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…

Ringbinder theme by Themocracy