Category: Networking

Rolling Your Own: Creating a Custom Incredible PBX ISO for Asterisk

We promised to provide the Incredible PBX 13.2 ISO build environment for those of you that wanted to learn how to roll your own ISO. Why would you want to do such thing? Well, we can think of a number of reasons. First, you may just want to learn how sh*t works. Or you may want to impress your boss by building a custom ISO with the corporate logo splattered all over the place. Then there are those that want to add a feature or function that we haven’t included yet so you can share your creation with your friends. For us, the motivation was to provide an Asterisk® aggregation that others could build upon without legal hassles about copyrights and trademarks… you know, a real open source project based upon the GPL license.

Regardless of your motivation, today’s your lucky day. We’re providing an exact duplicate of the build environment that was used to create the Incredible PBX 13.2 ISO. It’s released under the same GPL license that applies to the ISO itself. Copy it, enhance it, give it to your friends, and share your additions so that all of us can learn from you. In addition to the code, we’re actually going to document how to modify it and use it… you know, real instructions.


The Schmoozers were back in full force last week with one accusing us of “stealing” their code and another with this gem:


For the record, we use GPL code of others with full credit to the authors. That’s what the GPL and Asterisk aggregations have always been about. Let’s compare that to our Sangoma® friends who rip the covers off RedHat’s GPL ISO, brand it as their own, and then have the balls to distribute it as closed source code. Repeating a lie over and over doesn’t make it come true!


Getting Started. Before you can use today’s code, you’ll need a suitable platform on which to play. You’ve got a couple of choices. First, you can actually install Incredible PBX 13.2 using last week’s ISO. A second option is to build yourself a virtual machine or a cloud-based server with Scientific Linux 6.7 or even CentOS 6.7 minimal. We recommend 32-bit architecture because the Incredible PBX 3.2 ISO build environment as configured is 32-bit to assure maximum hardware compatibility. The server hardware platform doesn’t really matter. Cheaper means it takes a little longer, but you’ll get the same results.

Installing the Incredible PBX 13.2 ISO Build Environment. Once you have your server up and running, log in as root. This usually isn’t a good idea for a build environment, by the way. We’re doing it because we’re assuming you have a machine dedicated to just building ISOs on which to experiment. Issue these commands to put the ISO build platform in place:

cd /root
setenforce 0
yum -y install wget nano
wget http://incrediblepbx.com/create-ISO-new.tar.gz
tar zxvf create-ISO-new.tar.gz
rm -f create-ISO-new.tar.gz

Creating Your First ISO. Why waste time? Let’s actually build an Incredible PBX ISO to show you how easy it is. Issue the following command to kick off the process: /root/create-ISO-new. Depending upon your server’s specs, the whole build procedure should take a minute or two to complete. When it’s finished, you’ll have a shiny new ISO that can be burned to a DVD or USB thumb drive following the steps documented in our previous tutorial:

ls -all /root/kickstart_build/*.iso

-rw-r--r-- 1 root root 890241024 Nov 24 12:45 /root/kickstart_build/IncrediblePBX13.2.iso

ISO Design Overview. There are lots of ways to design an ISO architecture. We’ve chosen a hybrid approach with a two-phase install. When you first boot from the ISO installer, you get the operating system platform. The server then reboots, and Phase II downloads and then runs the latest Incredible PBX installer. Our main reason for choosing this design is that you don’t have to create a new ISO every time you make changes in the Incredible PBX installer. For those of you that remember the Asterisk@Home and trixbox days, this was a major shortcoming. The ISOs were released about every three to six months, and invariably a major glitch was discovered about a week after the new ISO was introduced. With our two-phase installer, slipstream changes are easy to implement by simply adding a line to the Incredible PBX install script. The ISO itself never has to be updated until a major operating system refresh is necessary.

Adding Packages to Your ISO. With Incredible PBX, RHEL 6.7-compatible packages are added to new servers in a couple of ways. First, there are packages actually included within the ISO itself that are loaded during Phase I of the install, i.e. when Scientific Linux 6.7 platform is installed. These packages must include all necessary dependencies. The kickstart process actually resolves and loads package dependencies as part of the Phase I ISO install procedure. Once the base install is completed, the end-user’s server reboots and then the Phase II install kicks off by downloading and running the Incredible PBX 13-12R installer. Additional RPM packages and a number of other applications in tarball format are downloaded and installed during this Phase II process. Today, we’ll show you how to modify both pieces of the ISO install procedure.

To add RPMs to the ISO itself, keep in mind that the new RPMs must match the architecture of the default build environment. In the case of Incredible PBX, it’s a 32-bit architecture which means you’ll need 32-bit versions of RPMs you wish to add. Otherwise, you will need to replace all of the packages in the build environment with their 64-bit cousins.

There are 3 steps to adding new packages to the ISO build environment.

First, create a temporary directory (/tmp/packages) to use for gathering up the RPMs to be added. This is so you can check your work without screwing up your build environment. To add an RPM, you first need to download it from a repository to your temporary directory. The syntax looks like this where NetworkManager is the name of the RPM you wish to install:

yum -y install --downloadonly --downloaddir=/tmp/packages NetworkManager

Second, move the RPMs from /tmp/packages into your build environment. This must include RPM package dependencies (as was the case when adding NetworkManager):

mv /tmp/packages/*.rpm /root/kickstart_build/isolinux/Packages/.

Third, add the names of your new RPMs to the kickstart config files (ks*.cfg) in /root/kickstart_build/isolinux. The package names go in the section of each kickstart file labeled %packages.

NOTE: You do not have to add the names of RPMs being added because of dependencies in step 3. You DO have to add the actual RPMs and RPM dependencies in step 2. For example, with NetworkManager, only NetworkManager itself needed to be added to the %packages list in the ks*.cfg config files. But the collection of NetworkManager RPMs and its dependencies for step 2 looked like this:

avahi-autoipd-0.6.25-15.el6.i686.rpm
dnsmasq-2.48-14.el6.i686.rpm
libdaemon-0.14-1.el6.i686.rpm
mobile-broadband-provider-info-1.20100122-4.el6.noarch.rpm
ModemManager-0.4.0-5.git20100628.el6.i686.rpm
NetworkManager-0.8.1-99.el6.i686.rpm
NetworkManager-glib-0.8.1-99.el6.i686.rpm
ppp-2.4.5-10.el6.i686.rpm
rp-pppoe-3.10-11.el6.i686.rpm
wpa_supplicant-0.7.3-6.el6.i686.rpm

Changing the ISO Default Boot Menu. Once you have burned the ISO to a DVD-ROM or USB flash drive and booted your server-to-be, a default kickstart menu will be presented: /root/kickstart_build/isolinux/isolinux.cfg. Edit it to customize the splash screen and make any desired changes in the screen title and options displayed to those using your ISO. WARNING: If you modify the ks*.cfg options in the file, you also will need to make similar modifications in the create-ISO-new build script as well as adding new matching ks config files in /root/kickstart_build/isolinux.

Modifying the Phase II ISO Install Procedure. The Phase I install setup already provided in the Incredible PBX ISO will work for any number of ISO requirements you might have because it provides a robust Scientific Linux 6.7 base platform. Now for the fun part. You can modify the Phase II install in any way you like by simply adjusting the download script and hosting it on your own public server.

The Phase II magic is housed in the %post section of the kickstart config files (ks*.cfg). The initial setup in this section will work for almost any setup. It addresses the quirks of getting a working network connection functioning on most server platforms. This got much more complicated with the introduction of UEFI on newer Intel-based servers. But we’ve addressed all of that. To customize the install to run your own Phase II script, you need only modify the last few lines of the %post section:

/bin/echo "cd /root" >> /tmp/firstboot
/bin/echo "/usr/bin/wget http://incrediblepbx.com/incrediblepbx13-12.2-centos.tar.gz" >> /tmp/firstboot
/bin/echo "/bin/tar zxvf incrediblepbx13-12.2-centos.tar.gz" >> /tmp/firstboot
/bin/echo "/bin/rm -f incrediblepbx13-12.2-centos.tar.gz" >> /tmp/firstboot
/bin/echo "./Inc*" >> /tmp/firstboot
/bin/chmod +x /tmp/firstboot
eject
%end

These last few lines tell the ISO installer where to find your Phase II script and manage the procedure for downloading it, untarring it, and then running it. To deploy your own Phase II install script, simply modify lines 2, 3, 4, and 5 above. In line 2, provide the public server location of your script in .tar.gz format. In line 3, untar the script in the /root folder of the new server. In line 4, remove the .tar.gz file after it’s been decompressed. In line 5, run the shell script included in your tarball. The remaining lines shown above should be preserved as shown. Once you finish making changes in ks.cfg, copy the %post section to your other kickstart config files and then rerun /root/create-ISO-new to build your new ISO. Enjoy!

Originally published: Friday, December 11, 2015


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 Forums. It’s the best Asterisk tech support site in the business, and it’s all free! Please have a look and post your support questions there. Unlike some forums, ours is extremely friendly and is supported by literally hundreds of Asterisk gurus and thousands of users just like you. You won’t have to wait long for an answer to your question.



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


 
Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. 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. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts 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 our 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 and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up 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. Any balance is refundable if you decide to discontinue service with Vitelity.


Some Recent Nerd Vittles Articles of Interest…

The 30-Second PBX: Introducing Proxmox 4 for the Intel NUC and Asterisk 13

With the advent of cloud-based computing and desktop virtual machine platforms like VirtualBox, we haven’t played with dedicated hardware for Asterisk® in a couple of years. WOW! It’s just amazing the quantum leaps in miniaturization, price, and performance that have transpired during our absence. Last week, we introduced a dedicated server platform for under $200 that could serve as a small business PBX for almost any 20-30 person organization. Today, meet Big Brother. You’re looking at all the components that make up the $500 Intel® NUC D54250WYK with a Core i5 dual-core processor, a 250GB mSATA drive, and 16GB of RAM. While you install the RAM and disk drive yourself, if you can unscrew 5 screws and have 5 minutes to spare, you can handle this. With the addition of the just released (free) Proxmox 4 virtualization platform, it can run a half dozen powerful stand-alone applications without ever breaking a sweat. Little wonder that Digital Ocean and CloudAtCost are all but giving away server resources. They almost have to given the developments in stand-alone hardware.

Buying Your Hardware

So here’s how we started. Of course, you can adjust the components and the merchant to meet your own requirements. For us, Amazon1 works great, and the prices are competitive. Who else delivers on Sunday? Despite the notice that the computer would be here on Monday, we knew better. And sure enough it was in the box with the other Sunday goodies. Remove the four screws from the bottom feet of the computer, and the case opens easily. Next, unscrew the screw from the bottom of the motherboard that holds the SSD drive in place securely. Snap in the mSATA drive and the two memory sticks, replace the screws, and you’re in business.

Initial Setup of the Intel NUC Platform

Our unit actually came with the latest BIOS preinstalled, but you’ll want to always upgrade the BIOS on any Intel motherboard. Everything generally gets better with each new upgrade. The rest of the firmware is fine as is unless you plan to use the computer as a Windows machine. You’ll find all the downloads here. The firmware you want is version 0041, and the file you want is WY0041.BIO. Copy it to the top level directory of a DOS-formatted USB flash drive using any desktop computer. On the Intel NUC, plug in a USB keyboard and mouse as well as the USB flash drive and a USB CD/DVD drive. Then connect a network cable. Finally, connect a monitor using a microHDMI to HDMI cable, and you’re all set. Once we’re finished configuring the Intel NUC, you can stick it on a shelf that has power and a network connection. No other peripherals are necessary as everything can be managed through SSH or a web browser.

To upgrade the BIOS, boot the computer by plugging it in and pressing the power button on top. Press F7 during the initial POST, choose the USB flash drive, select the .BIO file, and press ENTER. Once the BIOS is loaded, the machine will reboot.

Introducing Proxmox 4.0 Virtual Environment

When it comes to virtualization, we’ve been big fans of Proxmox for a very long time. We introduced Proxmox for VoIP virtualization over six years ago. Things have come a long way since then. And Proxmox VE 4.0 is the culmination of years of hard work by a very talented development team. You can read all about the new feature set and support for KVM and Linux Containers here. Our own take on virtualization is that OpenVZ templates were appealing because they installed and loaded quickly. The downside was they shared a single (proprietary) kernel which often led to security issues and made firewall implementation at the virtual machine level difficult. Of course, any applications such as DAHDI that required kernel implementation were extremely complex to implement and use. Now that almost all of Intel’s and AMD’s processors support virtualization extensions (Intel VT or AMD-V), we were not one to shed tears when Proxmox dropped support for OpenVZ and replaced it with Linux Containers. In fact, for our purposes, they could have left out Linux Containers as well. They suffer from some of the same quirks that made OpenVZ implementations problematic. The platform we’ve chosen for VoIP implementation has full support for virtualization extensions which means you can load and run complex applications such as Windows and Incredible PBX just as if you were using standalone hardware. The only real difference is we’re going to provide a template for building KVM-based Incredible PBX virtual machines in under 30 seconds. So you’ll get the best of both worlds, standalone computer functionality coupled with jaw-dropping implementation speed. For those that train or support multiple independent organizations as well as those that love to tinker and experiment, our solution has no equal.

To begin, download the Proxmox VE 4.0 ISO and burn it to a CD or DVD.

As we mentioned last week, if you don’t happen to have one, LG’s tiny USB-powered DVD Writer is the best $25 you will ever spend. And they keep getting cheaper!

Installing Proxmox VE 4.0 on the Intel NUC

Now we’re ready to get started. Insert the Proxmox VE 4.0 CD into the drive connected to your Intel NUC and boot the machine. Press F10 during POST and choose the CD/DVD drive to start the Proxmox install. Accept the license agreement and fill in the blanks. The important piece is to give your server a hostname. Just be sure it starts with proxmox4, e.g. proxmox4.incrediblepbx.com or use your own domain: proxmox4.yourdomain.com. The actual domain becomes important only if your server will be directly connected to the Internet in which case the FQDN obviously matters. Otherwise, Proxmox needs the hostname to manage things internally. Assign a permanent IP address for your server or use DHCP to obtain an IP address and then reserve that IP address for use by Proxmox in your router’s settings. Either way works fine, but you don’t want the IP address changing down the road.

BIOS Adjustments to Support Proxmox VE 4.0

Once the Proxmox install completes, it’s time to reboot. During the POST, press F2 to access Intel’s Visual BIOS. If you followed along last week, you’ll recall that we made some changes to accommodate Legacy booting of the server in lieu of UEFI. This week we need a different approach because of some quirks in the Proxmox server implementation procedure. We pulled our hair out (what little is left) for a couple days wrestling with this because the server wouldn’t automatically boot in either Legacy boot mode OR UEFI mode. The reason is because Proxmox puts a GPT label on the drive signifying that it’s a UEFI-compatible device whether UEFI is disabled in the BIOS or not. This confuses the Intel NUC bootloader. So you end up with a boot failure and the cryptic message “No boot device found.” Proxmox blames Intel for a buggy BIOS even though Intel developed the GPT specification. If you enjoy food fights, break out the popcorn and enjoy the dialog on the Proxmox Forum. Suffice it to say, there’s a difference of opinion about who should fix this. Here’s the easy way to resolve the impasse.

In Visual BIOS, click Advanced tab. Click Boot tab. Click Boot Priority. Make it look like this:

If the BuiltIn EFI Shell option doesn’t appear, don’t worry about it. Just press F10 to save your changes anyway. When your server reboots, it will drop into the EFI shell. Type the following commands pressing ENTER after each entry:

fs0:
echo "fs0:\EFI\proxmox\grubx64.efi" > fs0:\startup.nsh
startup.nsh

At this point, your server should boot into Proxmox. On reboot, the EFI shell will appear momentarily followed by an automatic boot into Proxmox. Solved!

Using Incredible PBX with Proxmox 4.0

You now have a functioning Proxmox server. When you reboot and login as root, the server will tell you how to access the Proxmox GUI with your browser. Before we put the necessary pieces in place to support Incredible PBX, we want to provide a very brief technical overview of how best to use Proxmox virtualization based upon our testing. Using a methodology similar to that demonstrated by AVOXI using Docker at this year’s AstriCon meeting, we use a backup image to instantiate “KVM containers.” We hear some of you saying, “There’s no such animal.” And right you are. The nomenclature is different, but the concept is similar. In fact, our simulated KVM Containers work exactly like OpenVZ and Linux Containers with none of the drawbacks of a shared kernel. And the good news is Proxmox 4 implements this perfectly through its backup and restore mechanisms. New kernel-based virtual machines can be created in under 30 seconds. Following initial login to a new KVM as root from the console, we individualize the KVM by randomizing passwords, creating new SSH credentials, and setting up a custom whitelist for the Incredible PBX IPtables firewall. The initialization procedure takes less than a minute and is only run the first time you log into your new KVM as root. The bash init script is here: /etc/profile.d/helloworld.sh.

Preliminary Setup Steps with Proxmox 4.0

The most important setup step is to put your Proxmox server behind a hardware-based firewall or configure the built-in firewall to keep out the bad guys. Proxmox has had their share of security vulnerabilities over the years so this is really critical. It’s beyond the scope of this article to walk through the entire firewall setup process, but you’ll find plenty of literature on the Proxmox Wiki and Forum as well as on the Internet. Each of your KVMs will have its own preconfigured whitelist using the IPtables firewall, and any of the Incredible PBX tutorials can walk you through adding and changing entries in those whitelists.

To use the backup and restore functionality of Proxmox, you’ll need to create a backup storage directory in the Proxmox GUI. After logging in as root, click Datacenter in the Server View, click the Storage tab, click the Add button, and choose Directory from the pulldown list. Fill in the blanks like this using VZDump Backup File for the Content type:

If you have access to a Cloud-based or local NFS device, it’s just as easy to create an additional backup directory on your NFS server. Follow the same steps and choose NFS from the Storage pulldown. With NFS, you must first set up a storage directory with NFS permissions for the IP address of your Proxmox server.

Last, but not least, you need to learn your way around in the GUI. proxmox4 is the name of your server if you followed our recommended setup for your hostname. Under the server, you will find entries for each of your KVM, Linux Containers (LXC), and other drives, e.g. local, backup, and synology.

To add a new LXC image to your server, choose local -> Content -> Templates, pick the desired LXC image, and click Download.

To add new ISO images to your server for building KVMs, choose local -> Content -> Upload, pick ISO Image as the Content type, choose the ISO from your desktop by pressing Select File, then click Upload button.

To start up Virtual Machines once you have created them, click on the VM number under proxmox and click Start. To access the virtual machine once it has begun booting, click Console.

To shutdown a KVM, click on the VM number under proxmox and click Shutdown. Or you can type halt after logging into the KVM as root from the KVM’s Console.

For a list of all available content, choose proxmox4 -> local -> Content.

Loading the Incredible PBX 13 Components into Proxmox 4.0

We need to put two pieces into place to get things rolling with Incredible PBX 13. There are two ways to create Incredible PBX 13 KVMs. You can do it manually from the IncrediblePBX13.iso just as you would on a stand-alone machine. Or you can restore from the IncrediblePBX13 KVM backup image to create a new KVM. The first method takes about 30 minutes. The second method takes less than 30 seconds. The choice is all yours. The results are exactly the same.

Before you can create KVMs, we need to put the Incredible PBX 13 backup image and the Incredible PBX 13 ISO in their proper places. To save some time and steps, we’re going to load the backup image by logging into the Proxmox server as root. For the ISO image, we’ll use the GUI.

To install the Incredible PBX 13 backup image, log into your server as root using SSH and issue these commands:

cd /
wget 'http://downloads.sourceforge.net/project/pbxinaflash/IncrediblePBX13-12 with Incredible PBX GUI/IncrediblePBX13-KVM.tar.gz'
tar zxvf IncrediblePBX13-KVM.tar.gz
rm IncrediblePBX13-KVM.tar.gz

To install the Incredible PBX 13 ISO image, first use a web browser to download IncrediblePBX13.iso to your desktop from SourceForge. Next, login to your Proxmox GUI and choose proxmox4 -> local -> Content -> Upload, pick ISO Image as the Content type, choose IncrediblePBX13.iso from your desktop by pressing Select File, then click the Upload button.

Your Incredible PBX 13 backup image should now appear under proxmox4 -> backup -> Content.

Your Incredible PBX 13 ISO image should now appear under proxmox4 -> local -> Content.

Building Your First Incredible PBX 13 Virtual Machine

To create a new Incredible PBX Virtual Machine, click the options in the order shown on the image above. Use any VM number desired. In less than 30 seconds, you’ll have your first 10GB Incredible PBX 13 Virtual Machine in place:

Initializing KVM Network Device MAC Address. If you ever create more than one KVM from the same backup image, you must initialize the network device’s MAC address before starting the KVM. Otherwise, you will get a conflicting network connection and a mess. Best practice: ALWAYS initialize the network device MAC address when you first create a new KVM from a backup. Click on the VM number in the left column under proxmox4. Then click the Hardware tab, click Network Device, and Edit. Erase the existing MAC address and click OK. Now it’s safe to start the KVM. The telltale sign that you forgot to do this will be a flaky network connection on one or more of your KVMs. If it happens, just delete the offending KVM and create a new one. You won’t forget but once. 😉

To start your new Incredible PBX Virtual Machine, click on the VM number in the left column under proxmox4. Then click the Start button on the right side of the Proxmox GUI header. The Tasks list at the bottom of the GUI will show it loading. Now click on the Console button at the top of the GUI to open a QEMU console session with your virtual machine. At the login prompt, login in as root with the default password: password. The startup script will complete the customization of your server in less than a minute. Then you’re ready to go. Complete the same configuration steps that you would on any new Incredible PBX server:

Change your root password and make it very secure: passwd
Create admin PW to access Incredible GUI and FreePBX® GPL modules: /root/admin-pw-change
Set your correct time zone: /root/timezone-setup
Create admin PW for web apps: htpasswd /etc/pbx/wwwpasswd admin
Make a copy of your Knock codes: cat /root/knock.FAQ
Decipher IP address and other info about your server: status

Now it’s time to pick up the Incredible PBX 13 tutorial for CentOS and continue on with your adventure if you’ve never done this before. Then take a good look at the Incredible PBX Application User’s Guide to get the most out of your new server.

Building a second, third, and fourth KVM is just as easy as building the first one.

Backing Up Incredible PBX 13 Virtual Machines

The real beauty of virtualization and Proxmox in particular is that you can make instantaneous backups of your virtual machine at any time whether the virtual machine is running or not. Those backups can be copied to off-site storage for safe keeping. The critical component of any server is the reliability of and ease with which you can recover from a catastrophic failure. It doesn’t get any easier than this.

To make a backup of your virtual machine to your backup directory, click on the VM ID number in the left column. Then click Backup -> Backup Now. Fill in the blanks of the backup template.

To make a backup of your virtual machine to a local or off-site NFS device, it’s just as easy. Click on the VM ID number in the left column. Then click Backup -> Backup Now. Fill in the blanks of the backup template. Makes you want to run right out and buy a Synology NAS/NFS device, doesn’t it?

Restoring a virtual machine from a backup is just as easy as it was to create the virtual machine image from our backup above. Just choose your backup image instead of the one we provided.

Backing up your virtual machines is only half the story, of course. It also is important to get a backup of the whole enchilada, i.e. the entire Proxmox server. Luckily, the latest version of Clonezilla works perfectly after you have applied the UEFI BIOS patch as documented above. Enjoy!

Originally published: Monday, October 19, 2015






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


 
Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. 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. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts 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 our 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 and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up 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. Any balance is refundable if you decide to discontinue service with Vitelity.


Some Recent Nerd Vittles Articles of Interest…

  1. Some of our purchase links refer users to Amazon and other sites when we find their prices are competitive for the recommended products. Nerd Vittles receives a small referral fee from merchants to help cover the costs of our blog. We never recommend particular products solely to generate commissions. However, when pricing is comparable or availability is favorable, we support Amazon and other merchants because they support us. []

Firewalls 101: Why Every Asterisk Server Should Have a Functioning Firewall


Part of our fundamental disagreement with the FreePBX® design can be summed up in one word: FIREWALL or the lack of a functioning firewall in the FreePBX Distro and in the functionally identical Digium product, AsteriskNOW®.1 Most of the other design choices including the controversial, non-GPL compliant Module Signature Checking mechanism are touted as failsafe ways to detect altered systems even though changes in FreePBX MySQL tables and Asterisk config files can be modified easily without triggering alerts. In short, the Band-Aid® approach to module tampering does nothing to address the fundamental problem, prevention of unauthorized intrusions in the first place.

Some would contend that the included Fail2Ban product is specifically designed to prevent unauthorized intrusions by locking out the bad guys after a certain number of failed login attempts. Assuming Fail2Ban were functioning properly, which does not appear to be the case, putting all your eggs in the Fail2Ban basket also ignores several critical shortcomings in Fail2Ban. First, it has been documented that powerful servers such as Amazon EC2 and Twitter botnets give hackers almost unlimited intrusion attempts before Fail2Ban ever gets a time slice sufficient to scan logs for intrusion attempts. Second, Fail2Ban provides no protection against stealthy distributed bruteforcing activity. For example, if a botnet with 770,000 PCs attacked your server and each PC executed only two login attempts, Fail2Ban never gets triggered even assuming your server could handle the load and Fail2Ban got sufficient server resources to actually scan your logs. Finally, Fail2Ban provides no protection against Zero Day vulnerabilities where an intruder basically walks right into your server because of an unidentified vulnerability lurking in the existing code. Unfortunately, these are not hypothetical situations but regular occurrences over the past 10 years of Asterisk and FreePBX development. In a nutshell, that’s why you need a real firewall. It completely blocks all access to your server by unauthorized users all of the time.

Numerous companies have intentionally exposed Asterisk® servers to the public Internet in a continuing effort to identify problems before they affect “real servers.” We know of no similar efforts with a platform that includes FreePBX as an integral component of the server. Why? Because the potential for Zero Day Vulnerabilities in a platform of modular design is enormous. One vulnerable component in FreePBX and the entire house of cards collapses because of the blank check server access that a compromised FreePBX asterisk user account gives to an intruder. It’s the fundamental reason that services such as Apache were engineered to run with different user credentials than a root user in the real world. In essence, the current FreePBX design with Asterisk has elevated asterisk user credentials to allow root-like access to almost every server file and function with the exception of SSH access. And SSH access becomes all but unnecessary given the scope of the GUI functionality provided within FreePBX and the escalated privileges it enjoys.

On FreePBX-based Asterisk servers, the absence of any user account separation means Asterisk, Apache, and FreePBX services all operate under the single asterisk user account. If any piece collapses due to a vulnerability, the intruder gets the keys to the castle including read/write access to Asterisk and FreePBX manager credentials and config files as well as broad MySQL access. This, in turn, exposes your VoIP account credentials in addition to facilitating SQL injection into any and all FreePBX database tables. Because FreePBX “hides” numerous settings in over a hundred MySQL tables, the Asterisk DB, and dozens of Asterisk config files, once the asterisk user account access is compromised, many of the major components on your server could be cleverly reconfigured without leaving much of a hint that your server had been compromised. In fact, VoIP account credentials could be extracted and used elsewhere with no traceable footprint back to your server. For all you would know, your provider compromised your credentials rather than the other way around. Just another reminder that keeping a credit card on file for automatic replenishment with VoIP providers is a very bad idea!

Providing the asterisk user with these broad permissions was a (poor) design choice. Why was it done? To make it easy for the developers to alter virtually everything on your Asterisk server using FreePBX’s integrated Module Admin component. Root user permissions are never required to do much of anything other than server platform upgrades once the FreePBX Distro or AsteriskNOW product is installed. That’s exactly the design one would expect to find in a commercial, closed source software platform. But it’s unusual in the open source community to put it charitably. We trust we’ve made the case why a rock-solid firewall with any product that uses FreePBX modules is absolutely essential. FreePBX is a wonderful GUI, but use of the platform without a properly configured, fully functional firewall could be financially catastrophic not to mention the serious damage it could cause to others including the good reputation of Asterisk in the Internet community.

Our objective next week will be to help you implement a functioning Linux-based software firewall on the FreePBX Distro and AsteriskNOW platforms. It’s FREE! Not only will this improve the security of your server, but it will deny the bad guys a platform from which to launch mischievous acts against the rest of us. Unless you’re running Asterisk on a Cloud-based platform, do all of us a favor NOW! Run, don’t walk, to your nearest electronics store (including WalMart and BestBuy) and purchase one of the dozens of inexpensive NAT-based routers. Install it between the Internet and your server TODAY! This is the one we use, but there are plenty from which to choose including our refurbished one.2


NEWS FLASH:
Download the new FUD-Free Firewall for FreePBX Distro and AsteriskNOW.

Originally published: Monday, August 3, 2015




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


 
Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. 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. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts 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 our 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 and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up 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. Any balance is refundable if you decide to discontinue service with Vitelity.


Some Recent Nerd Vittles Articles of Interest…

  1. Technically, IPtables is running on the FreePBX Distro and AsteriskNOW platforms; however, it’s sole function is to act as the shutdown mechanism for Fail2Ban-detected breaches. It does not independently examine packets. There is no functioning iptables config file. From our vantage point, serving as the Fail2Ban traffic cop doesn’t qualify as a functioning firewall since it lacks any of the traditional IPtables rules that manage PREROUTING, INPUT, FORWARD, OUTPUT, and POSTROUTING of packets. []
  2. Where prices are competitive or availability is a factor, we often recommend Amazon because Amazon provides financial support to Nerd Vittles through our referral links. We encourage everyone to shop independently and purchase products from suppliers that best meet your own requirements. []

View from the Trenches: A Fresh Look at VoIP Project Development in the Cloud

The world of cloud-based computing has profoundly changed over the past year. And today we want to take a fresh look at the cloud landscape for those of you that spend considerable time experimenting or tweaking software applications either for customers or for your own organization.

First, a brief paragraph of history. We began our cloud experiments almost seven years ago when Amazon S3 was still in its infancy. At the time, Amazon S3 was a real bargain even with all its development quirks. The adventure continued when we moved some production level systems to Amazon’s EC2 cloud in early 2013. What we quickly learned was just how expensive cloud computing could be once you reached the end of your “free year” with Amazon. As the cloud options continued to bloom, RentPBX began providing technical and financial assistance to our projects while also offering inexpensive, production-quality VoIP services in the cloud at truly bargain basement prices: $15 a month. That barely covers the electric bill for many folks hosting their own local servers. And RentPBX servers are unique. They don’t commingle other processor-intensive applications on their servers. All of their servers are pure VoIP which makes for an incredibly reliable cloud-based platform. Our special pricing still is available for those using PBX in a Flash and Incredible PBX. Just sign up with the coupon code: NOGOTCHAS. So that’s a little background.

But there are many of us that develop systems and experiment with new offerings as part of our daily routine. We build systems. We tweak systems. We blow up systems. And we start over, sometimes dozens (hopefully not hundreds) of times. To give you an example, our typical Incredible PBX build to support a new platform goes through twenty to thirty iterations before all of the kinks are worked out of the code. And that’s before the software development teams for CentOS, Ubuntu, Asterisk, Apache, SendMail, MySQL, and the Raspberry Pi “improve” anything. A production-quality cloud service really isn’t flexible enough to support this type of activity, and an affordable local server lacks the horsepower to keep setup times reasonable. On occasion, we use a high performance iMac coupled with VirtualBox for development, but that introduces some quirks that typically aren’t found on real world servers.

The good news is that there are two relatively new cloud offerings that fit very well with the requirements needed for rapid application development. We use both of them in slightly different ways so let us share our experience in hopes that it will save many of you some time experimenting.

We can’t say enough good things about Digital Ocean. Despite a few growing pains from time to time, Digital Ocean provides a vast assortment of cloud-based servers scattered all around the world. There are servers in New York, San Francisco, Amsterdam, London, Frankfurt, and even Singapore. You can size your development platform to meet almost any requirement with prices starting at about 5¢ for a 7-hour day of development. That buys you a speedy 512MB/single-CPU platform with 20 gigs of storage and a terabyte of monthly bandwidth. Add a (free) 1GB cache to your build, and it’s the performance equivalent of our $3,000 standalone Dell servers. You can scale up from there to a platform with 64GB of RAM, 20 CPUs, 640GB SSD drive, and 9 terabytes of monthly data transfer for less than $1 an hour. The difference with this platform is you can create a CentOS, Ubuntu, Fedora, FreeBSD, or Debian server of any recent vintage in about one minute. There’s also a vast array of preconfigured applications for the specialists of the world:

Using our referral code, you get $10 of free service while we get a little spiff down the road to keep the Nerd Vittles lights on. Tear down of servers is almost instantaneous, and you simply pay for the time you used. Using the small platform for 90 minutes will set you back a whole penny. Some of our PBX in a Flash users are actually running production-level servers on this platform (which we don’t recommend), and the monthly cost is capped at $5. One of the best kept secrets at Digital Ocean is that you can take snapshots of your builds and store them at little to no cost. We have a dozen of them and have never paid a penny in storage fees. You also have the option of off-site backups for production platforms.

The new kid on the block is CloudAtCost.com. If you’re not into bleeding edge, this probably isn’t the offering for you. But it is dirt cheap. While you can pay by the month, CloudAtCost also has a revolutionary marketing strategy. You can pay for your virtual machine once (almost always at a substantial discount off the listed prices), and you get to use “your server” forever at no additional cost… at least as long as CloudAtCost stays in business. If this sounds like a pyramid scheme, you probably wouldn’t be the first to suggest that. Suffice it to say, their business has grown geometrically over the past year. And they recently announced CloudPRO which lets you pool resources from servers you previously have bought, and use them in much the same way as Digital Ocean but with no additional charges. So here’s today’s pricing:

To put things in perspective, the virtual machine equivalent of Digital Ocean’s smallest setup costs $17.50, ONE TIME! The Big Dog 3 platform with a one-time fee of $560 migrated to CloudPRO would provide you with the capability to create 8 smaller systems (1 CPU, 1GB RAM, and 10GB storage) as desired with no bandwidth limitations forever.1 Download and upload performance is fairly impressive using speedtest-cli:

So what’s the catch. Well, there are some. First, as you might imagine, these folks are much like the fella laying track in front of the steaming locomotive. Will that ever end? You’d better hope not because, when it does, the entire house of cards may come down. While Digital Ocean typically builds virtual machines in under a minute, CloudAtCost turnaround times are close to a day. Once your server is actually working, we’ve had a pretty good experience with the performance quality although there can be rough spots that usually are resolved within a day. The promise, of course, is to get build times down to a minute or two. But, frankly, we’re not holding our breath. As for platform support, there are plenty of options just like with Digital Ocean:

What is this platform good for? In our case, it’s almost perfect for off-site backups. You can judge the web performance for yourself by visiting the backup site for Nerd Vittles, or the PIAF Forum, or Incredible PBX, or PBX in a Flash. Would we use CloudAtCost for production? Not a chance. But for backups and demo servers, it’s AWESOME and CHEAP! If you’re a Nerd Vittles early bird, you can use our coupon code for an additional 20% off: Zu2eXYDYtU.

DEMO SERVER. We’ve actually set up an Incredible PBX server with Google Voice and an IVR of sample applications so you can judge the CloudAtCost performance for yourself. You can even try hacking the IP address if that’s your thing. We always love to test our firewall: nmap -sT -O 162.252.242.229. To try out Allison’s IVR, enter your 10-digit callback number below and then click the Click Here button once. Count to 10 and your phone should be ringing. After you answer the call and press 1, you’ll be connected to the IVR Demo in Canada. Don’t be shy.



Nerd Vittles IVR Demo Options
1 – Call by Name (say “Delta Airlines” or “American Airlines” to try it out)
2 – MeetMe Conference (password is 1234)
3 – Wolfram Alpha (say “What planes are overhead?”)
4 – Lenny (The Telemarketer’s Worst Nightmare)
5 – Today’s News Headlines
6 – Weather Forecast (say the city and state, province, or country)
7 – Today in History
8 – Speak to a Real Person (or maybe just Lenny if we’re out)

Originally published: Cinco de Mayo, 2015



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


 
Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. 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. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts 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 our 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 and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up 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. Any balance is refundable if you decide to discontinue service with Vitelity.


Some Recent Nerd Vittles Articles of Interest…

  1. forever: as long as CloudAtCost.com stays in business []

Firewalls and Internet Security: Separating FUD and Fiction in the VoIP World

Some of us have spent years developing secure VoIP solutions for Asterisk® that protect your phone bill while bringing Cloud-based solutions within reach of virtually anyone. So it’s particularly disappointing when a hardware manufacturer spreads fear, uncertainty, and doubt in order to peddle their hardware. In this case, it happens to be Session Border Controllers (SBCs). We want you to watch this latest “infomercial” for yourself:



To hear Sangoma tell it, every VoIP server protected by merely a firewall is vulnerable to endless SIP attacks unless, of course, you purchase an SBC. And since implementation of Cloud-based servers traditionally limits the ability to deploy an SBC, most Cloud-based VoIP solutions would become vulnerable to SIP attacks. In the words of Sangoma:

And with telecom fraud and PBX hacking on the rise, it’s important to keep your network secure. For most enterprises, it’s not a matter of if-but-when their [sic] network experiences an attack, potentially costing you valuable time and money.

Now Sangoma is touting an article in a blog from the U.K. that begins with the headline “Why Firewalls are not Enough.” The purported author is Jack Eagle, who is otherwise unidentified. Not surprisingly, the owner of the blog happens to be a reseller of Sangoma hardware. Here’s what Jack Eagle suggests:

In addition, the inherent function of firewalls is to deny all unsolicited traffic. Whereby, the act of making a phone call is an unsolicited event, thus, firewalls can be counterproductive to an effective VoIP deployment by denying VoIP traffic.

For the benefit of those of you considering a VoIP deployment either locally or in the Cloud using Asterisk, let’s cut to the chase and directly address some of the FUD that’s been thrown out there.

FUD #1: Internet SIP Access Exposes Asterisk to Attack

False. What is true is that unrestricted SIP access to your server from the Internet without a properly secured firewall may expose Asterisk to attack. Perhaps it’s mere coincidence but the only major Asterisk aggregation that still installs Asterisk with an unsecured firewall and no accompanying script, tutorial, or even recommendation to properly lock it down and protect against SIP attacks happens to be from the same company that now wants you to buy a session border controller.

FUD #2: Firewalls Aren’t Designed to Protect Asterisk from SIP Attacks

False. What is true is that the base firewall installation provided in the FreePBX® Distro does not protect against any attacks. In a Cloud-based environment or with local deployments directly exposed to the Internet, that could very well spell disaster. And it has on a number of occasions. The Linux IPtables firewall is perfectly capable of insulating your Asterisk server from SIP attacks when properly configured. With PBX in a Flash and its open source Travelin’ Man 3 script, anonymous SIP access is completely eliminated. The same is true using the tools provided in the latest Elastix servers. And, Incredible PBX servers have always included a secured firewall with simple tools to manage it. Of course, with local VoIP hardware and a hardware-based firewall, any Asterisk server can be totally insulated from SIP attacks whether IPtables is deployed or not. Just don’t open any ports in your firewall and register your trunks with your SIP providers. Simple as that.

FUD #3: SIP Provider Access to Asterisk Compromises Your Firewall

False. Registering a server with SIP or IAX trunk providers is all that is required to provide secure VoIP communications. Calls can flow in and out of your Asterisk PBX without compromising your server or communications in any way. Contrary to what is depicted in the infomercial, there is no need to poke a hole in your firewall to expose SIP traffic. In fact, we know of only one SIP provider that requires firewall changes in order to use their services. Simple answer: use a different provider. Consider how you access Internet sites with a browser from behind a firewall. The connection from your browser to web sites on the Internet can be totally secure without any port exposure in your firewall configuration. Registering a SIP trunk with a SIP provider accomplishes much the same thing. All modern firewalls and routers will automatically handle the opening and closing of ports to accommodate the SIP or IAX communications traffic.

FUD #4: Remote Users Can’t Access Asterisk Without SIP Exposure

False. Over the past several years, we have written about a number of methodologies which allow remote users to securely access an Asterisk server. That’s what Virtual Private Networks and Port Knocking and Remote Firewall Management are all about. All of these solutions provide access without exposing your server to any SIP vulnerabilities! We hope the authors of this infomercial will give these open source tools a careful look before tarnishing the VoIP brand by suggesting vulnerabilities which any prudent VoIP deployment can easily avoid without additional cost. Just use the right products!

Originally published: Thursday, April 23, 2015



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


 
Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. 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. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts 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 our 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 and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up 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. Any balance is refundable if you decide to discontinue service with Vitelity.


Some Recent Nerd Vittles Articles of Interest…

The Gotcha-Free PBX: Harnessing SIP URIs for Free Worldwide Calling

We continue the Incredible PBX for Asterisk-GUI adventure today with a close look at SIP URIs, those email-like addresses that are the fundamental building blocks for VoIP technology. Consider this. If everyone in the world had a SIP address instead of a phone number, every call to every person in the world via the Internet would be free. That pretty much sums up why SIP URIs are important. The syntax for SIP URIs depends a bit upon your platform. In the Asterisk® world, they look like this: SIP/somenameORnumber@FQDN.yourdomain.com. On many SIP phones, you enter SIP URIs in the following format: sip:somenameORnumber@FQDN.yourdomain.com. Others use somenameORnumber@FQDN.yourdomain.com. Assuming you have a reliable Internet connection, once you have “dialed” a SIP URI, the destination SIP device will ring just as if they had a POTS phone. And Asterisk processes SIP URIs in much the same way as other calls originating from trunks. As noted, SIP URI calls of any duration to anywhere are free. And, of course, Incredible PBX is also free with No Gotchas!

In our original articles on Incredible PBX for Asterisk-GUI, we covered outbound calls to SIP URIs, and we’ll briefly review that procedure today. Then we’ll move on to setting up one or more SIP URIs for your own server so that you can receive incoming SIP URI calls. We’ll show you how to route them to any destination you like, both internal and external. We’ll also address the security implications of enabling SIP URI calling on your server. You don’t want the whole world calling into your server to make outbound calls on your nickel. We’ll also walk you through a safer SIP methodology in which you use a service provider as a SIP intermediary to better protect the security of your server. And finally, we’ll show you how to interconnect your new SIP URIs to real telephone numbers at zero cost. Then your friends without a SIP URI still can call you from any POTS or cellphone in the world.

SIP URI Calling with Incredible PBX for Asterisk-GUI

With one line of dialplan code, you can add Speed Dials for free SIP URI calling worldwide. The dialplan code is stored in the [CallingRule_SIP_URI] context in extensions_custom.conf. Just clone one of the existing entries, designate a speed dial number to connect to the SIP URI, and enter the SIP URI for the destination. Numerous SIP providers support assignment of SIP URI’s to existing DIDs for unlimited free calling from anywhere in the world. Here’s a sample using a speed dial code of 53669 (L-E-N-N-Y). Use it for your telemarketers: exten = 53669,1,Dial(SIP/2233435945@sip2sip.info).

Choosing a SIP URI Strategy with Incredible PBX for Asterisk-GUI

Before we actually create SIP URIs on your own server to receive anonymous calls, let’s walk through the available implementation strategies so that you can make an informed choice on how best to proceed. Keeping in mind that SIP URIs consist of an identifier and a fully-qualified domain name (FQDN) or IP address, one option is to use the same domain that you use for your company. We don’t recommend this approach because it makes it easy to guess where your SIP resources reside. Another option is to use a really obscure FQDN with your SIP URIs. Something like k43X20.mycompany.com or, for dynamic addresses, something like k43X20.dyndns.org makes more sense. In the next section, we’re going to lock down SIP access to your server to this FQDN so the more obscure the FQDN the safer you will be. Security through obscurity still works wonders. A third option is to use the IP address of your server instead of an FQDN. That’s a bad choice because of programs like SIPVicious that the bad guys use to scan the Internet for potential SIP targets to be hacked.

An alternative approach worth considering is to use a provider such as VoIP.ms as a SIP intermediary. In this scenario, you create a sub-account and assign an obscure extension number to that account. This in turn generates a SIP URI that can be used to connect to that account from your server by simply registering a VoIP.ms trunk in Incredible PBX. Once the trunk is registered, incoming SIP URI calls to your VoIP.ms sub-account will be forwarded (without cost) to your server without exposing Asterisk to SIP guest access at all. The wrinkle with this option is that VoIP.ms has often indicated that they plan to charge a reduced fee for these connections at some point. However, to date, they’ve never done it. If VoIP.ms shifts gears down the road, you obviously can as well. For the time being, we would encourage you to take advantage of this free service option. It remains our first choice for SIP URI implementation because there is no need to expose SIP resources on your server at all. VoIP.ms takes care of all the SIP security headaches leaving you to enjoy free calling. In the screenshot we’ve shown above, assuming your VoIP.ms account number was 12345, the SIP URI to connect to this sub-account would be 123458005551212@houston.voip.ms assuming you registered your trunk with the houston.voip.ms server.

Creating Your Own SIP URIs with Incredible PBX for Asterisk-GUI

The procedure for creating one or more SIP URIs on your own Incredible PBX server is straight-forward:

  1. For servers behind a hardware-based firewall, map UDP 5060 (SIP) to your server
  2. Enable allowguest access in [general] context of sip.conf
  3. Create desired SIP URIs in [public] context of extensions.conf

1. Unless your server is sitting on the public Internet without a hardware-based firewall, you’ll need to map UDP port 5060 (SIP) from the firewall to the private LAN address of your server. Otherwise incoming SIP calls will never reach Incredible PBX. Most routers have a Port Forwarding tab in which you designate the port to be forwarded, the type of port, and the destination IP address. Consult the manual for your router/firewall for detailed instructions.

2. Changing the allowguest setting in the [general] context of sip.conf is mandatory since the purpose of SIP URI calling is to accept calls from unregistered users. The risk, of course, is that anyone in the world with an Internet connection can attempt to connect to your server. More on that later. For now, issue this command after logging into your server as root:

sed -i 's|allowguest=no|allowguest=yes|' /etc/asterisk/sip.conf

Once you issue this command and restart Asterisk, the setup of Incredible PBX for Asterisk-GUI is to route anonymous SIP calls to the [public] context in extensions.conf. Only extensions in this context will be exposed to anonymous callers. This is important. NEVER change the destination context for these calls to one that provides unrestricted access to the calling resources on your server. The reason should be obvious. But, in case it isn’t, this would permit anonymous callers to use all of your trunks to place outbound calls to anywhere… on your nickel. $100,000 phone bills are the usual result.

3. There are two important facets in creating your own SIP URIs for anonymous access to your server. As touched upon previously, the first is choosing an obscure FQDN for your server. This is a really important layer of security for a couple of reasons: (1) your anonymous caller has to know the actual FQDN of your server in order to reach you and (2) in the next step we’re going to lock down your server to only allow anonymous SIP access from this FQDN. So choose carefully. The second consideration is deciding which server resources you wish to expose for SIP URI access. Do you wish to permit SIP URI calls only to a specific extension or ring group, or perhaps a custom IVR just for SIP URI callers, or perhaps a conference or DISA access (very dangerous)?

You can deploy more than one SIP URI. For each one, you’ll need a destination for the incoming call and an identifier or extension. Identifiers could be numeric, alphanumeric, or pure alpha characters. For example, 8005551212, joe6001, and accounting are all perfectly acceptable. The resultant SIP URI would be something like joe6001@k43X20.mycompany.com.

As noted, for each destination on your server that you wish to enable for SIP URI access, you add a line of dialplan code to the [public] context in extensions.conf. The syntax is identical to what you’ve previously used in routing incoming trunk calls to a destination except we’ll restrict connections to those matching the identifier you’ve chosen for each SIP URI. Here are some examples to get you started.

To route SIP URI accounting@k43X20.mycompany.com to Ring Group #1:
exten = accounting,n,Goto(ringroups-custom-1,s,1)

To route SIP URI joe6001@k43X20.mycompany.com to Extension 6001:
exten = joe6001,n,Goto(default,6001,1)

To route SIP URI demo@k43X20.mycompany.com to the Nerd Vittles demo IVR:
exten = demo,n,Goto(voicemenu-custom-2,s,1)

To route SIP URI lenny@k43X20.mycompany.com to an outside SIP URI:
exten = lenny,1,Dial(SIP/2233435945@sip2sip.info)

To route SIP URI conference@k43X20.mycompany.com to the default conference at extension 2663:
exten = conference,1,Goto(conf_bridge,2663,1)

To route SIP URI weather@k43X20.mycompany.com to the Weather by ZIP Code application:
exten = weather,1,Goto(CallingRule_extensions_custom,947,1)

To route SIP URI 800directory@k43X20.mycompany.com to Directory Assistance using Google Voice trunk:
exten = 800directory,1,Dial(Motif/GoogleVoice/18005551212@voice.google.com)

Securing Your Server with SIP URI Implementations

There are two important security steps once you have enabled anonymous SIP URI calling to your server. The first line of defense is to harden the IPtables Firewall to only permit anonymous SIP access to the specific FQDN you plan to use for your SIP URI callers. The second is to harden Asterisk to disallow requests for domains not serviced by your server.

1. Edit the IPv4 rules for your operating system. On the CentOS-compatible platforms, it’s /etc/sysconfig/iptables. On the Debian/Ubuntu/Raspbian platforms, it’s /etc/iptables/rules.v4. Toward the end of the file and just above the final fail2ban entries, insert the following code using your actual FQDN in the first line:

-A INPUT -p udp --dport 5060 -m string --string "@k43X20.mycompany.com" --algo bm -j ACCEPT
-A INPUT -p udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -j DROP
-A INPUT -p udp --dport 5060 -m string --string "OPTIONS sip:" --algo bm -j DROP
-A INPUT -p udp -m udp --dport 5060 -j DROP

2. Run the following commands substituting your actual FQDN in the first line to lock down Asterisk to only your FQDN for anonymous SIP connections:

sed -i '/\[general\]/a ;domain=k43X20.mycompany.com' /etc/asterisk/sip.conf
sed -i '0,/;domain/s/;domain/domain/' /etc/asterisk/sip.conf
sed -i '0,/;allowtransfer=no/s/;allowtransfer=no/allowtransfer=no/' /etc/asterisk/sip.conf
sed -i '0,/; allowexternaldomains=no/s/; allowexternaldomains=no/allowexternaldomains=no/' /etc/asterisk/sip.conf

3. Restart your firewall: iptables-restart

4. Restart Asterisk: asterisk-restart

5. Done!

Interconnecting a SIP URI with a Free PSTN Phone Number

Wouldn’t it be nice if all your friends and business associates without SIP URI capability could still call you using a traditional PSTN number? Well, it’s your lucky day because www.ipkall.com provides just what you need, a free phone number in the Seattle area that you can connect to an existing SIP URI on your server.

When folks call the Seattle number, they will be connected to your server using whatever routing you chose for the SIP URI in the previous section. So sign up for a number, enter your email address and the SIP URI for the calls, and wait for the confirmation email identifying your new telephone number. The only catch is that you need to receive at least one call a month to keep the number. Aside from that, there are no restrictions on use of the PSTN numbers. Enjoy!


Don’t forget to List Yourself in Directory Assistance with your new IPkall PSTN number so everyone can find you by dialing 411. And be sure to add your new number to the Do Not Call Registry to block telemarketing calls.

Originally published: Wednesday, March 25, 2015


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 Forums. It’s the best Asterisk tech support site in the business, and it’s all free! Please have a look and post your support questions there. Unlike some forums, ours is extremely friendly and is supported by literally hundreds of Asterisk gurus and thousands of users just like you. You won’t have to wait long for an answer to your question.



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


 
Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. 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. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts 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 our 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 and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up 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. Any balance is refundable if you decide to discontinue service with Vitelity.


Some Recent Nerd Vittles Articles of Interest…