Posts tagged: iptables

Top 3 Asterisk Security Tips for 2014: WhiteLists, WhiteLists, and WhiteLists

We’ve devoted a lot of energy to Asterisk security over the years with our Primer on Avoiding the $100,000 Phone Bill and our 20 Failsafe Tips and our SIP Navigation Guide plus numerous tutorials on deployment of Virtual Private Networks to secure your servers and phones including NeoRouter, PPTP, and Easy OpenVPN among others. But, when it comes to ease of installation and use with rock-solid security, nothing comes close to deployment of WhiteLists with the IPtables Linux firewall that’s included at no cost with every major Linux distribution and with all of the Asterisk® aggregations including PBX in a Flash™ and Incredible PBX™. So we’re kicking off the summer with a careful look at the methodology behind IPtables and the Travelin’ Man™ tools developed to reduce the learning curve for new users.

Security, of course, is all about the “bundle of sticks.” As we learned from Aesop’s Fables, the more sticks you bundle together, the more difficult it is to break the stick. We are by no means advocating that you drop all of the other tools at your disposal to improve the security of your Asterisk security. So, before we dive into WhiteLists, let’s spend a little time covering some of the other tools that are available and why those tools should not be relied upon exclusively.

1. Hardware-based Firewall. The PBX in a Flash project has cautioned users for years not to run Asterisk-based servers connected to the Internet without a hardware-based firewall between your server and the public Internet. Is it failsafe? No. Some hardware-based firewalls have been compromised either by the bad guys or by the NSA. Pardon the redundancy. The other problem with hardware-based firewalls is that they’re generally not available with cloud-based solutions. As the price of cloud computing has dropped and the cost and headaches of maintaining your own hardware has increased, more and more folks are considering cloud-based alternatives. Yes. Hardware-based firewalls should be deployed whenever possible. No. They won’t resolve all security concerns.

2. Fail2Ban. Once upon a time, a number of us thought that Fail2Ban was the answer to all security issues with Asterisk-based servers. In a nutshell, Fail2Ban scans your logs searching for failed attempts to log in to either SSH, FTP, Apache, SIP, or an email account. After a small number of failed attempts, Fail2Ban blocks further access from the IP address initiating the requests. There are two problems with Fail2Ban. First, software developers of the affected services continue to “improve” things with new and different error messages when login failures occur. Since Fail2Ban is searching for specific word matches to identify unsuccessful logins, the whole security mechanism fails when the “magic words” change unless everyone is extremely vigilant in maintaining the “magic word” lists AND updating the Fail2Ban rules on all of your servers. Our experience suggests that the bad guys find the new “magic words” long before everyone else which means there are gaping holes in Fail2Ban regularly. The other problem is supercomputers such as Amazon EC2 which makes enormous computing resources available to every Tom, Dick, and Harry. We’re mostly worried about the Dick that can hammer your little server every second with hundreds of thousands of attempts to crack your SIP or SSH passwords. The problem this poses is that most Linux servers never allocate a sufficient time slice to Fail2Ban to scan your Asterisk, Apache, and SendMail logs. Instead of blocking a bad guy after 3 failed login attempts, a bad guy using EC2 may be able to perform several hundred thousand login attempts before Fail2Ban ever detects a problem. Yes. Fail2Ban helps against the bad guy manually keying in passwords. No. Fail2Ban is all but worthless against a sophisticated denial of service attack on your server.

3. Virtual Private Networks. The beauty of virtual private networks (VPNs) is that all of your Internet traffic is encrypted and tunneled through private IP addresses that others can’t intercept. That was the theory until Edward Snowden came along and spoiled the NSA’s party. Yes. We’ve known that PPTP VPNs were vulnerable for a good long while. No. We didn’t know that the NSA (and presumably others) may have had the keys to your castle much longer… regardless of the VPN topology you may be using. The other problem with VPNs is that you need VPN connections for every device connecting to your server. Unfortunately, VPN technology is only available on a small number of SIP telephones, and the supported OpenVPN topology is one of the more difficult VPNs to deploy on a Linux server. Are VPNs better than nothing? Absolutely. Does a VPN provide failsafe communications security over the open Internet? Probably not.

4. Nothing Beats Secure Passwords. Amen. There was a time when some Asterisk-based servers were routinely set up with extension passwords of 1234 or the extension number itself. And outbound SIP trunks were deployed with no dialing rules. And administrators opened accounts with SIP providers with automatic credit card replenishment whenever the accounts ran out of money to cover calls. And no safeguards were put in place to restrict international calling. Little did these folks know that registering to a SIP extension on an Asterisk server provided a blank check for making unlimited calls to anywhere on the planet. Thus was born the $100,000 phone bill. Yes. Nothing Beats Secure Passwords for root, for SIP accounts, and for SIP and IAX trunks connected to commercial providers. But you also need to implement dialing rules for outbound calls that allow your callers to reach only the destinations desired, not the world. And your accounts with providers should always include limits and restrictions on international calls and should never include automatic credit card replenishment.

5. BlackLists. There was a time when blacklisting IP addresses was believed to be the ultimate solution to Internet security problems. Sounds great, doesn’t it? Just set up a database with the IP addresses of all the bad guys in the world, and all our problems will be solved. Problem #1: A new bad guy is born every minute. Problem #2: The bad guys learned how to use VPNs and other random IP address masquerading sites to disguise their true identity. Problem #3: Security vulnerabilities in many Windows-based machines allowed the bad guys to take control of these computers and do their dirty work from there. Problem #4: There are actually some good guys that live in Russia and China. Problem #5: The bad guys learned to poison the “bad guy list” to block essential services such as DNS, Google, Amazon, Netflix, Pandora, and your favorite bank and credit card companies. Yes. The theory of blacklists sounded great. No. Blacklists not only don’t work. They’re downright dangerous.

WhiteLists with IPtables: The Knight in Shining Armor

For the past few years, our Internet security focus has turned toward defining a methodology that works with all PBX in a Flash and Incredible PBX servers, whether they’re dedicated servers behind a hardware-based firewall or public on a cloud-based shared host. And the conclusion we’ve reached is that nothing beats the IPtables Linux firewall for rock-solid Internet security. The reason is its deep integration into the Linux kernel itself through Netfilter, “a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack.” Wikipedia provides an excellent overview for those with an interest. For our purposes, suffice it to say that IPtables examines inbound and outbound packets before any further processing occurs on your server. With our default setup, we typically allow all outbound traffic from your server. For inbound traffic, if the iptables rules permit access, the packet comes in for processing. If not, the packet dies at the door with no acknowledgement that it was even received. In laymen’s terms, if someone attempts to scan your server to determine whether web or SIP services are available, there will be no response at all unless packets from the scanning server’s IP address are permitted in the iptables rules configured on your server. You can determine which rules are in force with this command: iptables -nL.

The basic configuration and syntax of iptables rules can be daunting to those unfamiliar with the territory. And thus was born Travelin’ Man 3, our open source tool to simplify configuration of IPtables by allowing administrators to define WhiteList entries describing the types of services that were allowed access to a server from specified external IP addresses. The basic rules of the Travelin’ Man 3 setup for iptables are these: (1) outbound packets are unrestricted, (2) forwarded, established, and related packets are permitted, (3) inbound packets from the private LAN are unrestricted, but (4) inbound packets from the public Internet are dropped unless permitted by a specific iptables rule. Those rules include certain basic services such as time synchronization (TCP 123) as well as WhiteListed IP address entries for specific or generic services.

Installation is easy. Log into your PBX in a Flash as root and issue the following commands. NOTE: Travelin’ Man 3 is optionally available as part of Incredible PBX installs on the CentOS, Scientific Linux, and PIAF OS platforms. It is preinstalled on the Raspberry Pi and BeagleBone Black platforms with RasPBX. You can determine if it’s already installed on your server with this command: ls /root/secure-iptables. If the script exists, you’ve already got Travelin’ Man installed, but it may not be running so keep reading…

cd /root
wget http://incrediblepbx.com/travelinman3.tar.gz
tar zxvf travelinman3.tar.gz
yum -y install bind-utils
./secure-iptables

Because PBX in a Flash and Incredible PBX servers are primarily designed to support telephony, Travelin’ Man 3 further simplifies the iptables setup by whitelisting the IP addresses of a number of the leading VoIP providers. These include 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. For the complete list: cat /etc/sysconfig/iptables (CentOS) or cat /etc/network/iptables (RasPBX).

The real beauty of Travelin’ Man 3 is you aren’t limited to our WhiteList. You can add your own entries easily using the TM3 scripts that are included in the /root directory. secure-iptables initializes your iptables setup and also lets you define a primary IP address or fully-qualified domain name (FQDN) that will always have access to your server. You must run this script at least once to activate IPtables on all platforms!

Once you have run secure-iptables, you can whitelist additional IP addresses by running add-ip. You can whitelist additional FQDNs by running add-fqdn. You can delete either IP addresses or FQDNs by running del-acct. As noted previously, you can check what’s authorized with the command: iptables -nL.

We’ve also included a custom script to restart IPtables gracefully: iptables-restart. The reason is because using the traditional restarting mechanism in IPtables will leave your server vulnerable (and IPtables inoperative) if a particular FQDN cannot be resolved. The iptables-restart script takes another approach and removes the offending rule from your whitelist, alerts you to the problem, and then restarts iptables without the offending entry. So all existing rules are put back in place and function as you would expect.

Finally, Travelin’ Man 3 includes a script that allows you to utilize FQDNs for users that may have ever-changing dynamic IP addresses. Steps #4, #5, and #6 in the original Travelin’ Man 3 tutorial will walk you through the Administrator set up which only takes a minute or two and never has to be touched again. Basically, a cron job script is employed to check for changes in the dynamic IP addresses you have identified with FQDNs. If changes are found, IPtables is restarted which updates the IP addresses accordingly.

Unfortunately, there was one group of end-users that weren’t covered by the Travelin’ Man 3 setup. This group included traveling salespeople or vacationing individuals that may land in a different city every night. Rather than relying upon an administrator to provide access to home base, these frequent travelers needed their own tool to manage their IP address as it changed. While this was supported through a web interface in Travelin’ Man 2, that setup exposed your web server to the public Internet and was burdensome for administrators to initially configure. Most importantly, it didn’t manage remote IP address access using IPtables which made coexistence with TM3 difficult. Thus was born Travelin’ Man 4.

Introducing Travelin’ Man 4: Managing WhiteList Access by Telephone

Travelin’ Man 4 is a new add-on for an existing Travelin’ Man 3 setup. It’s for those that wish to allow traveling individuals to manage their own whitelist access to PBX in a Flash or Incredible PBX using a telephone. An Administrator preconfigures accounts and passwords for the travelers together with the services to which they will have access on the server. Using any cellphone or hotel phone, the traveler simply dials a preconfigured number to access an IVR that will prompt the user for an account number and PIN. Unless you have a spare DID, you can grab a free one from IPkall.com to use with your Travelin’ Man 4 IVR. Once a user is successfully logged in, the IVR will prompt for the user’s IP address to be whitelisted on the server. Enter it using this format: 12*34*56*78.

Within a couple minutes, the new IP address will be properly formatted and then whitelisted in IPtables, and the traveler will be sent an email acknowledging that the account has been activated. Once the account is activated, the traveler can use a SIP softphone application such as Zoiper on any iPhone or Android phone or a softphone on any desktop computer to place and receive calls as well as to check voicemail on the remote PBX in a Flash server. For anyone that doesn’t know their current IP address, a quick visit to WhatIsMyIP.com will tell you. Travelin’ Man 4 is licensed under GPL2 so download a free copy. Then read the tutorial and give it a whirl. Enjoy!

Originally published: Wednesday, May 21, 2014




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


 
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…

Incredible PBX 1.8: New OpenVZ and Cloud Editions

Another exciting week in the Asterisk® community with the introduction of Asterisk 1.8.2 last Friday. It's now the official PIAF-Purple payload so you can simply download the current ISO to take it for a spin. Most of the pesky bugs in Asterisk 1.8.0 and 1.8.1 now have been addressed. Let us know if you find some new ones.

While the Asterisk Dev Team has been hard at work on Asterisk 1.8.2, we've turned our attention to the cloud and VoIP virtualization. We have three new products to introduce today. The first lets you install PIAF-Purple with Asterisk 1.8.2 using a new OpenVZ template. The second lets you run Incredible PBX 1.8 as a virtual machine using the new PIAF-Purple 1.8.2 OpenVZ template. Finally, we'll show you how to run Incredible PBX 1.8 in the cloud with hosted VoIP service from RentPBX.com for $15 a month with a free local phone number and free Google Voice calling in the U.S. and Canada. So let's get started.

Using the OpenVZ PIAF-Purple Template. If you haven't heard of OpenVZ templates before, you've missed one of the real technological breakthroughs of the last decade. Rather than wading through the usual 30-minute ISO installation drill, with an OpenVZ template, all of the work is done for you. And it's quick. You can build a dozen PIAF-Purple systems using an OpenVZ template in about 15 minutes with a per system cost of less than $50. See Comment #2 below for an extra special Dell half-price server deal this week. And it's incredibly easy to then tie all of these systems together using either SIP or IAX trunks. Just follow our previous tutorial. For resellers and developers that want to try various Asterisk configurations before implementation and for trainers and others that want to host dedicated Asterisk systems for customers, the OpenVZ platform is a perfect fit. Read our original two-part article to get up to speed on Proxmox, virtualization, and IPtables with OpenVZ. Then continue on here.

Thanks to Darrell Dillman (aka dad311 on the PIAF Forums), there already is a 64-bit OpenVZ template of PIAF-Purple with Asterisk 1.8.2. Just download the template to your Desktop and then, using the Proxmox console, choose Appliance Templates, Upload File to upload the OpenVZ template into your Proxmox server platform. Once installed, you can build Asterisk 1.8.2 virtual machines to your heart's content... in less than a minute apiece. Just choose Virtual Machine, Create to create a new virtual machine using the OpenVZ template you just uploaded. In the Configuration section, choose OpenVZ for the Type and pick your new OpenVZ template from the pulldown list. Fill in a Host Name, Disk Space maximum (in GB), and (root) Password. The other defaults should be fine. In the Network section of the form, change to the Bridged Ethernet (veth) option which means the VM will obtain its IP address from your DHCP server. Make sure your DNS settings are correct for your LAN. Here's how a typical OpenVZ creation form will look:

Once the image is created, start up the virtual machine, wait about 70 seconds for the system to load, and then click on Open VNC Console. Asterisk will be loaded and running. You can verify this on the status display. You can safely ignore the status messages pertaining to IPtables assuming iptables -nL shows that IPtables is functioning properly. With the exception of text-to-speech (TTS), you now have a PIAF-Purple base platform running Asterisk 1.8.2 and FreePBX 2.8. Be sure you always run it behind a hardware-based firewall with no port exposure to the Internet.

Before you do anything else, run passwd-master to secure the passwords for FreePBX GUI access to your system. Don't forget!

If you're planning to install Incredible PBX below or if you don't need text-to-speech on your system, you can skip this next step which gets 64-bit TTS installed. Otherwise, here are the commands to get it working:

cd /root
./install-flite

Note to Our Pioneers. To those that tested the new OpenVZ template this past week, THANK YOU! Be advised that we now have incorporated several of the recommended tweaks which were documented in the PIAF Forums. The install procedure outlined above explains the new behavior of the slightly improved OpenVZ template which now is available for download. We recommend you switch.

Asterisk CLI Change. Finally, just a heads up that (once again) the Asterisk Dev Team appears to have changed the default behavior of the Asterisk CLI. With Asterisk 1.8.2, if you make outbound calls after loading the CLI, you will notice that call progress no longer appears in the CLI. To restore the standard behavior (since Moses), issue the following command: core set verbose 3. :roll:

 


Installing Incredible PBX on OpenVZ Systems. We won't repeat the entire Incredible PBX article here. If you want the background on the product, read the latest article. To get everything working with an OpenVZ system, there are only three steps:

1. Set Up Your Google Voice Account
2. Run the Incredible PBX VM Installer
3. Configure a Softphone

Configuring Google Voice. You'll need a dedicated Google Voice account to support The Incredible PBX. The more obscure the username (with some embedded numbers), the better off you will be. This will keep folks from bombarding you with unsolicited Gtalk chat messages, and who knows what nefarious scheme will be discovered using Google messaging six months from now. So why take the chance. Keep this account a secret!

We've tested this extensively using an existing Gmail account, and inbound calling is just not reliable. The reason seems to be that Google always chooses Gmail chat as the inbound call destination if there are multiple registrations from the same IP address. So, be reasonable. Do it our way! Set up a dedicated Gmail and Google Voice account, and use it exclusively with The Incredible PBX. Google Voice no longer is by invitation only so, if you're in the U.S. or have a friend that is, head over to the Google Voice site and register. If you're living on another continent, see MisterQ's posting for some tips on getting set up.

You must choose a telephone number (aka DID) for your new account, or Google Voice calling will not work... in either direction. Google used to permit outbound Gtalk calls using a fake CallerID, but that obviously led to abuse so it's over! You also have to tie your Google Voice account to at least one working phone number as part of the initial setup process. Your cellphone number will work just fine. Don't skip this step either. Just enter the provided 2-digit confirmation code when you tell Google to place the test call to the phone number you entered. Once the number is registered, you can disable it if you'd like in Settings, Voice Setting, Phones. But...

IMPORTANT: Be sure to enable the Google Chat option as one of your phone destinations in Settings, Voice Setting, Phones. That's the destination we need for The Incredible PBX to work its magic! Otherwise, all inbound and outbound calls will fail. If you don't see this option, you may need to call up Gmail and enable Google Chat there first. Then go back to the Google Voice Settings.

While you're still in Google Voice Settings, click on the Calls tab. Make sure your settings match these:

  • Call Screening - OFF
  • Call Presentation - OFF
  • Caller ID (In) - Display Caller's Number
  • Caller ID (Out) - Don't Change Anything
  • Do Not Disturb - OFF

Click Save Changes once you adjust your settings. Under the Voicemail tab, plug in your email address so you get notified of new voicemails. Down the road, receipt of a Google Voice voicemail will be a big hint that something has come unglued on your PBX.

Running The Incredible PBX Installer. Log into your server as root and issue the following commands to set up The Incredible PBX:

cd /root
rm incrediblepbx18-vm.x
wget http://incrediblepbx.com/incrediblepbx18-vm.x
chmod +x incredible*
./incrediblepbx18-vm.x
passwd-master

When The Incredible PBX install begins, you'll be prompted for the following:

Google Voice Account Name
Google Voice Password
Google Voice 10-digit Phone Number
Gmail Notification Address
FreePBX maint Password

The Google Voice Account Name is the Gmail address for your new dedicated account, e.g. joeschmo@gmail.com. Don't forget @gmail.com! The Google Voice Password is the password for this dedicated account. The Google Voice Phone Number is the 10-digit DID for this dedicated account. We need this if we ever need to go back to the return call methodology for outbound calling. For now, it's not necessary. But who knows what the future holds. :roll: The Gmail Notification Address is the email address where you wish to receive alerts when incoming and outgoing Google Voice calls are placed using The Incredible PBX. And your FreePBX maint Password is the password you'll use to access FreePBX. You'll actually set it by running passwd-master after The Incredible PBX completes. We need this password to properly configure the CallerID Superfecta for you. By the way, none of this confidential information ever leaves your machine... just in case you were wondering.

Now have another 5-minute cup of coffee, and consider a modest donation to Nerd Vittles... for all of our hard work. :wink: You'll find a link at the top of the page. While you're waiting (and so you don't forget), go ahead and configure your hardware-based firewall to support Google Voice. See the next section for what's required. Without completing this firewall configuration step, no calls will work! When the installer finishes, READ THE SCREEN just for grins.

Here's a short video demonstration of the original Incredible PBX installer process. It still works just about the same way except there's no longer a second step to get things working.

One final word of caution is in order regardless of your choice of providers: Do NOT use special characters in any provider passwords, or nothing will work!

Before you do anything else, run passwd-master again to resecure the passwords for FreePBX GUI access to your system. Don't forget!

Firewall Configuration. We hope you've taken our advice and installed a hardware-based firewall in front of The Incredible PBX. It's your phone bill. You'll need to make one adjustment on the firewall. Map UDP 5222 traffic to the internal IP address of The Incredible PBX. This is the port that Google Voice uses for phone calls and Google chat. You can decipher the IP address of your server by logging into the server as root and typing status.

Extension Password Discovery. If you're too lazy to look up your extension 701 password using the FreePBX GUI, you can log into your server as root and issue the following command to obtain the password for extension 701 which we'll need to configure your softphone or color videophone in the next step:

mysql -uroot -ppassw0rd -e"select id,data from asterisk.sip where id='701' and keyword='secret'"

The result will look something like the following where 701 is the extension and 18016 is the randomly-generated extension password exclusively for your Incredible PBX:

+-----+-------+
id         data
+-----+-------+
701      18016
+-----+-------+

Configuring a SIP Phone. There are hundreds of terrific SIP telephones and softphones for Asterisk-based systems. Once you get things humming along, you'll want a real SIP telephone such as the $50 Nortel color videophone we've recommended above. You'll also find lots of additional recommendations on Nerd Vittles and in the PBX in a Flash Forum. If you're like us, we want to make damn sure this stuff works before you shell out any money. So, for today, let's download a terrific (free) softphone to get you started. We recommend X-Lite because there are versions for Windows, Mac, and Linux. So download your favorite from this link. Install and run X-Lite on your Desktop. At the top of the phone, click on the Down Arrow and choose SIP Account Settings, Add. Enter the following information using your actual password for extension 701 and the actual IP address of your Incredible PBX server instead of 192.168.0.251. Click OK when finished. Your softphone should now show: Available.

Incredible PBX Test Flight. The proof is in the pudding as they say. So let's try two simple tests. First, let's place an outbound call. Using the softphone, dial your 10-digit cellphone number. Google Voice should transparently connect you. Answer the call and make sure you can send and receive voice on both phones. Second, from another phone, call the Google Voice number that you've dedicated to The Incredible PBX. Your softphone should begin ringing shortly. If not, make certain you are not logged into Google Chat on a Gmail account with these same credentials. If everything is working, congratulations!

Here's a brief video demonstration showing how to set up a softphone to use with your Incredible PBX, and it also walks you through several of the dozens of Asterisk applications included in your system.

Solving One-Way Audio Problems. If you experience one-way audio on some of your phone calls, you may need to adjust the settings in /etc/asterisk/sip_custom.conf. Just uncomment the first two lines by removing the semicolons. Then replace 173.15.238.123 with your public IP address, and replace 192.168.0.0 with the subnet address of your private network. There are similar settings in gtalk.conf that can be activated although we've never had to use them. In fact, we've never had to use any of these settings. After making these changes, save the file(s) and restart Asterisk: amportal restart.

 


 

Running Incredible PBX in the Cloud. We've saved the best for last today. For many folks, you may want to experiment with VoIP technology without making a hardware investment and without having to master the intricacies of managing your own server and network. That's what Cloud Computing is all about. And we've searched far and wide to find you the perfect platform. As with many of you, one of our top priorities is always cost. While many providers were willing to provide Nerd Vittles with a few sheckles for pitching their product, only one stepped forward with a price point that we think is irresistible. And, for the record, we waived any compensation other than a few test accounts to get things working properly, so that all of the savings could be passed on to you! So here's the deal. $15 a month gets you your own PIAF-Purple server in the cloud at RentPBX.com. Just use this coupon code: BACK10, pick an east coast or west coast server to host your new system, choose the PIAF-Purple 1.7.5.5.4 install option, set up a username and very secure password, and you're off to the races. Once your account is established, here's the 5-minute procedure to install the special RentPBX-edition of Incredible PBX to begin making free calls in the U.S. and Canada through Google Voice.

Begin by Configuring Google Voice as outlined above. Then log into your RentPBX account using SSH and the port assigned to your account. For Windows users, download Putty from here. The SSH command will look something like this:

ssh -p 21422 root@209.249.149.108

Issue the following commands to download and run The Incredible PBX installer for RentPBX:

cd /root
wget http://incrediblepbx.com/incrediblepbx18-rentpbx.x
chmod +x incrediblepbx18-rentpbx.x
./incrediblepbx18-rentpbx.x
passwd-master

Now just follow along in the Incredible PBX virtual machine tutorial which we've included above. Remember that your new Incredible PBX is sitting directly on the Internet! So don't forget to run passwd-master when you finish the install, or your system is vulnerable. Ours was attacked within minutes!

Securing Your RentPBX Server. With the exception of our WhiteList application, everything is working on your RentPBX server. While we continue to work on the WhiteList component (reread this section of the article in a week or so to get the latest updates), you need to secure your system to avoid endless hack attempts on your SIP resources. Here's how. First, write down the IP addresses of your RentPBX server and your home network. Second, print out your existing IPtables configuration. The file to print is /etc/sysconfig/iptables. Third, make a backup copy of the file. While logged into your server with SSH, the easiest way is like this:

cd /etc/sysconfig
cp iptables iptables.bak

Now we need to edit the iptables file itself: nano -w iptables. Then search for the line that contains 5060: Ctrl-W, 5060, Enter. At the beginning of this line, add # to comment out the line. With the cursor still on this line, press Ctrl-K then Ctrl-U twice. This will duplicate the line. Move to the second commented line and remove #. Use the right cursor to move across the line to --dport. Then insert the following using the IP address of your RentPBX server, e.g.

-s 229.149.129.248

Be sure there's at least one space before and after the new text. Now duplicate that line with Ctrl-K and Ctrl-U twice. Change the IP address on the second line to the public IP address of your home or office network. Repeat this process for every IP address where you intend to use a SIP phone connected to your RentPBX server. Make additional entries for your SIP providers as well. If you want to sleep better, you can make similar changes to the SSH port entry to restrict it to your home/office IP address. It's the line immediately above the 5060 entry. Ditto for port 80 which is web access. Be very careful here. A typo will lock you out of your own server! When you're finished, save the changes: Ctrl-X, Y, Enter. Then restart IPtables: service iptables restart.

As always, we strongly recommend that you not put all of your VoIP eggs in one basket. Google Voice does go down from time to time. Vitelity is a perfect complement because the costs are low and you only pay for the service you use. A discount sign up link is below. And Vitelity has contributed generously to both the Nerd Vittles and PBX in a Flash projects. So please support them. Enjoy!

Originally published: Monday, January 17, 2011




Need help with Asterisk? Visit the PBX in a Flash Forum.
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...

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

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

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

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

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

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

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

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

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

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

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

-A INPUT -s 222.222.222.222 -j ACCEPT

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

cd /root
wget http://incrediblepbx.com/firewall-whitelist.tar.gz
tar zxvf firewall-whitelist.tar.gz
./firewall-whitelist-gen.sh
./firewall-whitelist.sh

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

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




Need help with Asterisk? Visit the PBX in a Flash Forum.
Or Try the New, Free PBX in a Flash Conference Bridge.


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…

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

Introducing Phone Genie for Asterisk (Email Edition)

From Our Disney Cruise Family Scrapbook Almost two years ago, we introduced Phone Genie for Asterisk®. It let you reconfigure your Asterisk system remotely using your favorite web browser. This included the ability to set and adjust call forwarding, call waiting, and Do Not Disturb for any Asterisk extension. In addition, you could enter Asterisk CLI commands and execute a number of Linux system commands, all from the convenience of your web browser. Phone Genie for Asterisk remains one of the all-time favorite downloads of our readers.

Unfortunately, you don't always have access to a web browser when you're away from your Asterisk server. So today we introduce the perfect complement to the original Phone Genie with our new Email Edition. By following this quick tutorial, you can configure your Asterisk server to respond to any Asterisk CLI command which can be sent from almost any email client on the planet. And we'll perform all this magic with less than a dozen lines of bash scripting. Asterisk CLI commands have almost limitless possibilities. Use Phone Genie to check the status or change the functionality of just about any component on your server.

How It Works. The best way to explain how all of this works is to use a simple example. Let's assume you've left home and forgot to transfer your inbound calls for extension 701 to your cellphone. What we'll do is send a simple email message to a special user account on your Asterisk server that we've set up specifically to handle email directives for your server. Unlike most email addresses, we want this one to be unintuitive so strangers aren't sending messages to your server all the time. Let's assume the address is kxt1498@myserver.dyndns.org for this example. Using any email client, just address a message to that account. For the subject of the message, we'll use the following:

Asterisk: database put CF 701 6781234567

It doesn't really matter whether you include a message with the email. As long as the subject of the email is in the proper form, that's all that matters. The command above activates call forwarding for extension 701 and sends the calls to 6781234567. The command uses standard Asterisk CLI syntax.

On your Asterisk server, we'll have a simple bash script that runs every minute or two to check for new emails in the kxt1498 user's mailbox. If it finds a new message, it will parse the subject line, make certain there is a password match, and then send the command (unaltered) to the Asterisk Command Line Interface for processing. Here's an overview of all the CLI commands. The results of executing the command will be emailed to the address you've configured in the script. This works as both confirmation that your command has been executed and a security alert that your Asterisk system has been accessed using the Email Edition of Phone Genie. In the above example, you would receive an email at the address you've configured in the script with a subject of PhoneGenie. The body of the email would look like this:

Updated database successfully...database put CF 701 6781234567

Prerequisites. This software assumes you are using one of the Asterisk aggregations built on CentOS 5. We've tested it with PBX in a Flash. You'll also need an SMTP server (SendMail or Postfix) that is configured to send and receive emails to and from destinations on the Internet. You do not need a POP3 or IMAP mail server! We've tested this with Asterisk 1.4, but it should work fine with Asterisk 1.6 as well. FreePBX 2.5 or later is required for some functions.

Security Warning. Before we begin, let's pause for a moment to review the enormity of your problems if you do this wrong and to remind you that YOU ARE PROCEEDING AT YOUR OWN RISK. PBX in a Flash in particular is shipped with all outside access to your SMTP server blocked. We've obviously got to remove that layer of security for this software to function properly. But you need to be especially careful with SMTP servers because they can be used to relay SPAM to the entire world if you fiddle with settings that you don't understand. So... DON'T MAKE IMPROVEMENTS THAT AREN'T COVERED HERE UNLESS YOU KNOW WHAT YOU'RE DOING!

This software also gives certain email messages elevated privileges on your Asterisk server so that Asterisk itself can be reconfigured. If you compromise the email account name and password for this application, anybody worldwide can pretty much destroy the functionality of your server. In addition, calls to a certain extension could be rerouted to a very expensive destination on a cruise ship sailing around the world. If your dialplan permitted these calls and you had an account with automatic replenishment from a credit card or bank account, you've got a very expensive problem on your hands. That's one reason that reliable email notification of every Phone Genie transaction is critically important. If you're not getting timely notifications of each Phone Genie transaction, DO NOT USE THIS SOFTWARE until that problem is resolved!

Should you detect that your system has been compromised by receiving an email that indicates a command has been executed on your Asterisk server that you did not initiate, you should immediately disable or remove the script so that no further Phone Genie emails are processed on your server. Be sure to preserve any unprocessed Phone Genie emails for authorities as these may contain important information regarding the source of the emails. These email messages usually are deleted once Phone Genie completes execution of the associated Asterisk commands.

Overview. Here's the drill for today. First, we'll adjust both your hardware- based and IPtables firewalls to allow inbound email delivery to your Asterisk server. Second, we'll remove SendMail from your system and install and configure Postfix to handle the SMTP email chores. This will greatly simplify the security issues in locking down your server from unwanted emails. Depending upon your Internet service provider, installation of Postfix may break outbound email delivery from your server if your provider happens to block outbound traffic on port 25. We'll show you how to fix it. Third, we'll add a new user account on your Asterisk server that will be used exclusively to handle Phone Genie messages. Fourth, you're going to need a fully-qualified domain name for your Asterisk server so that email can be delivered reliably to your server. We'll walk you through getting this set up. Fifth, we'll install and configure the Phone Genie software and run some simple tests to make certain everything is working as it should. Sixth, we'll add the Phone Genie script as a cron job which will be run every couple of minutes to check for incoming Phone Genie emails. Finally, we'll review some of the Asterisk commands that can be executed using the Email Edition of Phone Genie for Asterisk.

Security Design. We've obviously given a great deal of thought to the security issues surrounding this application. The security model we've adopted works like this. First, for an email to get through to your Asterisk server, one and only one email address will work from the Internet. All other inbound email from the Internet will be rejected by Postfix. We strongly suggest you leave it that way. Your email address consists of the special username that we will create on your server plus a (hopefully new) fully-qualified domain name that points to your server. You are well advised to use and keep secret both a non-intuitive and complicated username AND a non-intuitive and complicated, fully-qualified domain name. Only this combination will let the email message through the Postfix filter! Using the correct username and a different FQDN that may also point to your server's correct IP address will nevertheless be rejected by Postfix. The third piece in the security model is the password. If you examine the sample Subject above, you will note that it begins with the word "Asterisk" followed by a colon, a space, and then the Asterisk CLI command. The word "Asterisk" is actually the password, and it can be changed to any password you like. So, if you change your password to FooBaR, then the subject of your message should look like this. Note that the colon followed by a space are also required!

FooBaR: database put CF 701 6781234567

Finally, it should be obvious but... DON'T SEND THESE EMAILS FROM AN UNTRUSTED CLIENT OR A PC IN A PUBLIC PLACE because your email message may get stored in a place that someone else could decipher how to access your server. If you wouldn't leave a $1000 bill beside the computer from which you're sending the email, don't send it! Otherwise, you may lose a good bit more than $1,000. To give you some idea of what's at risk with a compromised system, try sending the following email using your correct email address and password:

FooBaR: help

</sermon>

Firewall Configuration. For purposes of our example today, we're assuming that your Asterisk server is sitting behind a hardware-based firewall/router on a private subnet and that your Asterisk server includes a functioning software-based IPtables Linux firewall. This is the default PBX in a Flash setup that we always recommend. On your hardware-based firewall, you will need to redirect incoming TCP port 25 traffic to TCP port 25 on the private IP address of your Asterisk server. This change often requires a reboot of your firewall/router. Once that change is complete, log into your Asterisk server as root and edit /etc/sysconfig/iptables on PBX in a Flash systems. We need to add a new rule to IPtables which allows incoming TCP port 25 traffic through the firewall. Scroll to the bottom of the file and insert the following lines just above the COMMIT line:

# Allow inbound SMTP traffic on TCP port 25
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

Save your additions to the file and then reload IPtables and your network:

service iptables stop
service iptables start
service network restart
service iptables status | grep "tcp dpt:25"

The last command should return an entry from IPtables showing TCP port 25 traffic is now being ACCEPTed into the server. If not, check your entries and repeat the process until this works.

Postfix Installation. Let's continue by removing SendMail from your server and installing Postfix. They both perform the same email functions, but the complexity of SendMail makes the likelihood of a configuration error too risky for us to sleep well. If you understand the intricacies of SendMail and feel comfortable implementing the security model we've described above, by all means, have at it. We'll be happy to share your results with the rest of our user community. In the meantime, here's the Postfix solution. While still logged into your server as root, issue the following commands to uninstall SendMail and install Postfix:

rpm -e --nodeps sendmail
yum -y install postfix

Choosing a Username and FQDN. Before we configure Postfix, you need to decide upon a user account name for your Asterisk server to manage Phone Genie messages. And you also need a fully-qualified domain name which points to the public IP address of your Asterisk server. As mentioned above, we strongly recommend that the username and FQDN be obscure and unguessable. For example, a combination of letters and numbers that don't spell words are good choices. Something like dlrpzh7b3@dhf34.nerdvittles.com will help you sleep well. If you don't have a static IP address and dedicated domain for your server that you can manage, then use an equally obscure FQDN from a provider such as dyndns.org. Something like dhf34.dyndns.org works. You then can configure your Asterisk server to automatically keep your dynamic IP address current. We're going to use these entries as examples below. Obviously, you should choose different entries!

To create the new user account on your server using whatever name you have chosen, here are the commands to issue while still logged into your server as root. Just substitute your chosen username for dlrpzh7b3 in both commands. Be sure to choose a secure password, too.

useradd dlrpzh7b3
passwd dlrpzh7b3

Configuring Postfix. Now let's get Postfix set up for maximum protection. First, move to postfix directory: cd /etc/postfix. Now edit main.cf: nano -w main.cf. Search for the inet_interfaces line in the file: Ctrl-W, inet_interfaces =. Add a hash mark to the beginning of each uncommented inet_interfaces line so that your entries look like this:

#inet_interfaces = $myhostname
#inet_interfaces = $myhostname, localhost
#inet_interfaces = localhost

Next, search for mydestination in the file: Ctrl-W,mydestination =. Comment out each of the lines except the one that looks like this:

mydestination = $myhostname, localhost.$mydomain, localhost

Now add the private IP address of your Asterisk server and your FQDN chosen above to the line so that it looks like this. Don't forget the commas and keep everything on one line.

mydestination = $myhostname, localhost.$mydomain, localhost, 192.168.0.118, dhf34.nerdvittles.com

Finally, move to the last line in the file and make it look like this, all on one line:

smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/access, permit_mynetworks, reject_unauth_destination

Save your changes to the file: Ctrl-X, Y, then Enter. Now edit /etc/postfix/access. Move to the very bottom of the file and add two new lines with the following entries using the actual email address and FQDN you chose above instead of the examples. The first line tells Postfix to allow emails addressed to the specified email recipient. The next line tells Postfix to reject all other emails addressed to anyone at this domain. Other domains and public IP addressing are blocked by our mydestination entry above.

dlrpzh7b3@dhf34.nerdvittles.com OK
dhf34.nerdvittles.com REJECT recipient rejected

Save your changes to the file: Ctrl-X, Y, then Enter. Now issue the following two commands:

postmap /etc/postfix/access
service postfix restart

Testing Postfix. Now comes the important part. We need to make sure that outbound emails from your Asterisk server are delivered. And we need to make sure that incoming emails ONLY to the one email address you've designated are received and that all other emails from the Internet are rejected. We can't stress enough how important all three of these tests are. If your Postfix implementation doesn't pass all three, DO NOT PROCEED!

Testing outbound email with Postfix is easy. While logged into your server as root, issue the following command using a destination email address (instead of yourname@gmail.com) where you regularly receive emails:

echo "Hi there" | mail -s Test yourname@gmail.com

Count to 20 and refresh your email's Inbox. If the message is there, you've passed Test #1. If not, check your junk mail folder. If it's still not there, try another email address if you have one. Still no cigar? Then your Internet Service Provider is probably blocking email generated from downstream email servers. For tips on remedying the problem, see this message thread on the PBX in a Flash forums. You might also want to review the Postfix tutorial on dyndns.com. Here's another good tutorial on setting up a Gmail relay using Postfix. And here's another excellent tutorial. Then run the test again until you achieve success.

Testing inbound email to your designated email address is Test #2. Use a web client and send an email message to dlrpzh7b3@dhf34.nerdvittles.com substituting the actual email address you have chosen for your server. Count to 20, log into your server as root and type the following command to retrieve email for user dlrpzh7b3: mail -u dlrpzh7b3. The server should report that you have one new message. Type "d 1" and then "q" to delete the message and quit the mail app. If no email arrives, check the Inbox on your sending client to see if the message bounced and, if so, why. Check your email entries in /etc/postfix/access and /etc/postfix/main.cf for typos and review the steps in Configuring Postfix above. Then repeat the test until you successfully send a message to your designated email address.

Testing inbound email to an unauthorized email address on your Asterisk server is Test #3. For this test, we want to make sure that an email sent to the root account on your server fails. What you'll need for this test is the FQDN that was chosen above. Then, using a mail client, send an email message to root@dhf34.nerdvittles.com using your actual FQDN. Count to 20, log into your server as root, and type: mail. The message you sent should NOT be in the Inbox. Repeat the test by sending a message to root and dlrpzh7b3 @the actual IP address of your Asterisk server. These, too, should both fail. Once you get a passing grade on all three tests, we can move on. The hard part is behind you!

Installing Phone Genie. While logged into your server as root, issue the following commands:

cd /root
wget http://pbxinaflash.net/source/nv/phonegenie.tgz
tar zxvf phonegenie.tgz
rm phonegenie.tgz

Configuring Phone Genie. While still logged into your server as root, edit phonegenie.sh. You will note that there are 3 fields that need to be configured at the top of the file: user, pw, and notify. The user field is the designated user account name that will be used for incoming emails (dlrpzh7b3 in our example). The pw field is the word in every email Subject that precedes the colon, space, and Asterisk CLI command (Asterisk in our example). The notify field is a reliable email address where you regularly receive emails promptly. This is where the results of your Phone Genie email commands will be sent. Choose this email address wisely, as if your bank account depended upon it. It does! Once you have filled in the 3 fields (preserving the quotation marks around each entry), save the file with your changes.

Testing Phone Genie. Now we're ready to try everything out. Using an email client, send an email message to dlrpzh7b3@dhf34.nerdvittles.com (using your actual Phone Genie email name and FQDN). For the Subject, enter the following (substituting the password you created above for Asterisk)... Asterisk: help

After counting to 20, log into your Asterisk server as root and issue the following command:

/root/phonegenie.sh

You should see a display of all of the Asterisk CLI commands and within a minute or so, you should receive an email with the same information at the email address you entered into the notify field in phonegenie.sh in the previous step.

Installing Phone Genie as a Cron Job. Once you have tested several Phone Genie emails manually and you're satisfied that everything is working reliably, you can set up the Phone Genie shell script as a cron job. It should be set to execute every minute or every couple of minutes throughout the day and night. Edit /etc/crontab and insert the command shown below to have the script execute every 2 minutes:

*/2 * * * * root /root/phonegenie.sh > /dev/null

Sample Phone Genie Commands. In addition to all of the traditional Asterisk CLI commands, Phone Genie also supports a number of commands that are specific to FreePBX. These additional commands let you configure call forwarding, call waiting, do not disturb, system speed dials, and blacklist entries on your Asterisk server. For Asterisk CLI command syntax, consult voip-info.org. For FreePBX command syntax, see the listing below. Enjoy!

database put CF 302 8338116666 * Call Forwarding Enable
database del CF 302 * Call Forwarding Disable

database put CFB 302 8238221234 * Call Forwarding on Busy Enable
database del CFB 302 * Call Forwarding on Busy Disable

database put CFU 302 8038445689 * Call Forwarding Unavailable Enable
database del CFU 302 * Call Forwarding Unavailable Disable

database put CW 302 ENABLED * Call Waiting Enable
database del CW 302 * Call Waiting Disable

database put DND 302 YES * Do Not Disturb Enable
database del DND 302 * Do Not Disturb Disable

database put blacklist 6781234567 1 * Blacklist a number
database del blacklist 6781234567 * Remove blacklisted number

database put sysspeeddials 99 6781234567 * Set up Speed Dial 99
database del sysspeeddials 99 * Remove Speed Dial 99
(NOTE: Be sure you enable Feature Code *0 prefix in FreePBX!)

We wish all of you a very Merry Christmas!




Need help with Asterisk? Visit the PBX in a Flash Forum.
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...

Welcome to IP Country: A New Layer of Asterisk Security

image courtesy of fail2ban.org One of the problems with writing a blog like Nerd Vittles is it's more than double the work of your typical blog where a writer pontificates about something and then moves on. What makes Nerd Vittles a little different is that, with help from a number of very gifted developers, we actually create useful applications and then write about how to use them. So you get a bonus for the same low price: free! This obviously imposes some time constraints in order to get fresh material into your hot little hands every week.

This week we turn our attention to Asterisk® Security again and unfortunately the Whole Enchilada is not yet ready. So today you get Chapter I of this topic with a comment that we're still mulling over some enhancements. When those pieces are finished or at least properly evaluated, we'll produce a sequel. Software houses spend years developing applications. And sometimes it takes us more than a week. :-)

Let's start with a few observations which should be quite obvious to those who have wrestled with VoIP or Asterisk for a while. Internet security is a bitch. And Asterisk security is much, much worse. When a few disgruntled people can bring Twitter to its knees because they're mad about some particular tweet or Twitter user, it tells you what we're all up against. Hate to say it but we can all thank Microsoft for years of security neglect that rendered the Windows operating system less than optimum in preventing the spread and deployment of BOTs. And the tools have gotten more dangerous as well. Strangers (our euphemism for these folks) write new software, too.

If you're using PBX in a Flash (and you really should be!), you know that we've devoted enormous resources to Asterisk security. Two years ago when PBX in a Flash was introduced, the majority of people using Asterisk still were using 1234 as the extension password on all or most of their extensions. A couple $100,000 phone bills and lots of public education, and that situation hopefully is behind us. Two years ago, no Asterisk aggregation included a firewall... except PBX in a Flash. Believe it or not, there were individuals running Asterisk servers on the public Internet with a default root password of password. That added more than a few more BOTs to the Internet kettle of fish. Then there were the brute force password hacks that hit Asterisk servers thousands of times per minute guessing passwords. Nothing stood in the way of these attacks until PBX in a Flash introduced Fail2Ban which automatically blacklisted IP addresses after a certain number of failed login attempts. We followed Fail2Ban with our Atomic Flash product which provided a turnkey Hamachi VPN implementation for rock-solid safe remote computing. And, of course, there was a one-minute Hamachi VPN install script for standard PBX in a Flash systems. No other aggregation has it to this day.

The purpose of the history lesson isn't to crow about PBX in a Flash although we're mighty proud of it. Rather we wanted to make you aware that precious little development effort is actually going into security while enormous resources are devoted to things such as Internet faxing, Skype, and Google Voice integration. We'll be the first to admit that we love the latest gee whiz gizmos as much as anybody. But come on. A handful of us who do this purely for fun somehow manage to turn out loads of security enhancements while huge, for-profit companies are devoting virtually zero resources to making Asterisk, SIP, and the VoIP community safer. SIP is about as secure as whispering at a movie theater. Google releases Google Voice with SIP access protected by a 4-digit password. :roll: That approach to security needs to change, or we're all going to wake up sorry one day soon. If this is preaching to the choir, then feel free to pass this article on to one of your brethren who has not yet seen the light! Start by reading our Primer on Asterisk Security.

If you have extremely secure passwords on your Asterisk extensions and trunks, and you have deployed a properly configured firewall with Fail2Ban to protect against brute force attacks, then you're ahead of the curve insofar as Asterisk security is concerned. But what we think is still missing is access restrictions based upon what the military calls a "need to know." Simply stated, it means folks shouldn't get access of any kind to your Asterisk server unless they have a need to be there. And, if we find someone there that doesn't belong, they should be kicked off and banned from further access.

So today we have a new security tool for your Asterisk toolbox: IP Country, country-based network filtering by IP address. In a nutshell, it means configuring your Asterisk server to dramatically reduce the number of IP addresses which can reach your server at all. If you receive anonymous SIP connections from all around the globe that you actually need or if you're attacked from a BOT running on grandma's Windows machine down the block, this may not work for you, but it's another tool in your quiver of arrows. For most servers, it has the potential to reduce the vulnerability from random outside threats substantially. It's taken a lot of research to come up with much of what follows, and we want to express our special thanks to Sandro Gauci and Joe Roper for their assistance. Some of this technology has been around for many years, but unfortunately it was expensive. So we also want to express our special appreciation to MaxMind for releasing their open source GeoLite Country database which is now free for downloading. That is the critical ingredient in much of what follows. So here's a word from our sponsor:

This product includes GeoLite data created by MaxMind, available from http://www.maxmind.com/.

Scope of Protection. An obvious question is just exactly what are we trying to protect. In our view, it's several things. First, we don't want strangers logging in to extensions on our server and making free calls around the globe using pilfered or hacked passwords. We also don't want strangers using our extensions to masquerade as us for any other purpose. Second, we don't want strangers randomly calling our server using SIP URI's that they've dreamed up. And third, we don't want strangers accessing any other applications on our server including SSH and FTP as well as web and email services.

IP Country Design. As with other security features in Asterisk, FreePBX, and IPtables, our implementation of IP Country uses permit and deny access tables that consist of authorized and unauthorized ranges of IP addresses. There's also a table with the latest GeoLite Country information which is used as the data source for your permit table. When a connection to the server is made, the IP address is checked against the permit table of authorized addresses. If there's no match, we'll consider the connection a stranger. If there is a match, then we'll check the deny table to make certain this particular IP address hasn't been banned. Unless you alter all of our scripts, your system must be using the default MySQL account name of root with a password of passw0rd. As configured in PBX in a Flash, this is NOT a security risk since MySQL access is limited to your server, and your server requires root credentials to log in.

Today's Objective. To get everyone started, we're going to tackle the first two objectives today. The solutions offered should work fine on any FreePBX-based Asterisk system... even those that hide the existence of FreePBX.

For outgoing calls, we'll introduce a new script which runs periodically to examine the IP addresses attached to every SIP and IAX extension and trunk on your Asterisk server. If a stranger's IP address is identified (as explained above), we'll add an IPtables firewall rule to permanently block access to your server from this IP address. These rules are stored in /etc/sysconfig/iptables should you ever need to remove an IP address that has been blocked. You can adjust the script execution frequency based upon the thickness of your wallet. After all, it's your phone bill. This functionality is mutually independent from the incoming call protection outlined below so you can use either or both of the functions to meet your own requirements. For systems that use enormous numbers of SIP URI's for communications around the globe, you might choose to implement just this piece for extension and trunk IP Country protection without altering your incoming dialplan at all. Keep in mind that FreePBX now supports permit and deny IP address filters on extensions, something you really should be using even if you decide against implementing the IP Country security protection layer.

For incoming calls, we're going to modify FreePBX's existing Blacklist functionality to also look up the calling IP address in our IP Country permit and deny tables. If the IP address is authorized, the call will go through. Otherwise, the call will be treated just as if the caller's number were blacklisted. Be aware that incoming calls to one of your commercial DIDs may reflect the IP address of your provider since the caller may be calling from a Plain Old Telephone rather than an IP address. The existing Blacklist functionality can be used to block these unwanted callers. If you live in the United States, you'll probably also want to call 888-382-1222 and place your DIDs in the Do Not Call database. Just call from a phone using the CallerID of the number you wish to block.

Installing GeoLite Country. To get started, log into your server as root and issue the following commands:

cd /
wget http://bestof.nerdvittles.com/applications/ipcountry/ipcountry.tgz
tar zxvf ipcountry.tgz
rm ipcountry.tgz
cd /root/ipcountry
./nv-ipcountry

Once the nv-ipcountry script begins to run, it will download and install the GeoLite Country database into MySQL. You then will be asked whether to add countries to your permit table. Since your permit table is empty at this point, the answer should be yes. You'll then get a list of country codes. Choose the two-character country code desired and type it in UPPERCASE, e.g. US. If you want to add one or more additional countries, just rerun ./nv-ipcountry and do NOT initialize the permit table (which erases all of its contents).

New GeoLite Country databases are released every month or two so get used to the procedure. You'll be using it periodically to keep your list of IP addresses current. We'll cover the update procedure after we get you up and running.

Remember: If no IP addresses for any country are added to the permit table, you will not be able to make calls or register trunks with your providers! The only default entries added to the permit table are the non-routable, private IP address ranges, e.g. 192.168.0, etc. The geolite table is merely a data repository of the latest GeoLite Country database and has no effect on the daily operation of your system! You use it only as a data source for populating your permit table.

Testing IP Country. Before we actually turn anything on, we need to be sure we're not going to blow your Asterisk system out of the water! In short, we want to make sure that every extension that's supposed to be able to make a connection to your PBX still can. And we need to make sure all of your trunk registrations still are working. While you're still in the /root/ipcountry directory, issue the following command: ./test.sh. This script will display all of your SIP and IAX connections and then will tell you whether each connection will pass muster with IP Country security in place. Each IP address should display ok. If any of them show ko, you have a problem. This means that you have an extension or trunk with an IP address that is not included in your permit table. You can scan through the show peers listings in the display to figure out which providers or extensions are associated with any problem IP addresses. Be sure it's not a bad guy first. Then you have a couple of options. You can either manually add the IP address to the permit table as outlined below. Or you can add additional countries which include the missing IP address(es). To decipher the country of any problem IP address, go to this link and plug in the IP address. Once you've made entries in your permit table to cover all of your needed IP addresses, run the test script again just to be sure everything shows ok. Do NOT proceed until you get all ok's, and don't write us if you do.

Manually Adding IP Addresses to IP Country. We've provided a command-line utility which makes it easy to add IP addresses and address ranges to either the permit or deny tables of IP Country. Be very careful using this tool! There's limited error-checking which means it's easy to create a mess. You'll find iputility.php in the /root/ipcountry folder. Since all IP addresses are stored as integers, you can use it to merely discover the integer value of an IP address, or you can actually insert IP addresses into either the permit or deny tables. Here are a few examples to show how the utility works:

./iputility.php 156.130.20.10
Returns the integer value for this IP address; no database update
./iputility.php 156.130.20.10 156.130.20.255
Returns integer values for this IP address range; no database update
./iputility.php 156.130.20.10 deny
Adds this IP address to IP Country deny table
./iputility.php 156.130.20.10 156.130.20.255 permit
Adds this address range to IP Country permit table)

A couple of points worth noting. First, all custom entries in your permit and deny tables using iputility will show a country code of AA. This makes them easy to find using phpMyAdmin if you make a mistake. Second, if you attempt to enter the same IP address range more than once, you'll get a database error since all entries in the tables must be unique. Third, remember that entries in the deny table take precedence over entries in the permit table. So, if the same IP address or address range is in both tables, access will be denied. The reason for this is to make it easy to exclude a few bad apples from a country that you might otherwise find unobjectionable. Finally, keep in mind that manual entries added to the permit table will have to be added again each time you initialize the table and insert new country IP codes after a GeoLite Country refresh. The deny table is unaffected by database refreshes. So make yourself a list of entries you manually insert into the permit table and keep it in a safe place for future reference.

Activating the IP Address Checker. In the /root/ipcountry directory, you'll find the script that we'll use to check your system periodically to be sure all of the extensions and trunks are registered at permitted IP addresses. To run the script manually, log into your server as root and type: /root/ipcountry/ip-checker.sh. When you run it, you shouldn't see any modifications to IPtables, just a string of ok's. So now we want to added the script as a cron job that will be run periodically to watch your system. Edit /etc/crontab and insert the following line at the bottom of the file:

*/1 * * * * /root/ipcountry/ip-checker.sh > /dev/null

*/1 means run the script once a minute, all day and night, every day. */5 means every 5 minutes. You make the call on how safe you'd like your system to be. If you'd like to receive an email or text message every time an IP address is blocked by ip-checker.sh, just edit the filecheck.php script, uncomment the two lines that begin with // and replace yourname@gmail.com with your email or text message address.

WARNING: For ip-checker.sh to work properly with IPtables, there are a couple of prerequisites. First, IPtables must be running on your system with the iptables file located in /etc/sysconfig. Second, your IPtables setup must include an SSH permit rule that looks like this:

-A INPUT -p tcp -m tcp --dport ssh -j ACCEPT

We use this rule as a place finder to determine where to insert new rules to block stranger's IP addresses. If you don't have the above rule, filecheck.php (used by ip-checker.sh) won't be able to insert new rules. So you'll need to manually edit filecheck.php to provide a "hook" that can be used to insert rules into your iptables file. PBX in a Flash systems come preconfigured to support this. With other aggregations, YMMV!

Activating the Incoming Call Checker. To screen incoming calls using your IP Country permit and deny tables, the setup is straight-forward assuming you are running the latest version of FreePBX 2.5. We're going to adjust the Blacklist context to also perform IP address lookups from IP Country when new calls arrive on your PBX. Just log into your server as root and add the following lines to the bottom of the extensions_override_freepbx.conf file in /etc/asterisk:

[app-blacklist-check]
include => app-blacklist-check-custom
exten => s,1,LookupBlacklist()
exten => s,n,GotoIf($["${LOOKUPBLSTATUS}"="FOUND"]?blacklisted)
exten => s,n,Set(TESTAT=${CUT(SIP_HEADER(From),@,2)})
exten => s,n,GotoIf($["${TESTAT}" != ""]?hasat)
exten => s,n,Set(FROM_IP=${CUT(CUT(SIP_HEADER(From),>,1),:,2)})
exten => s,n,Goto(gotip)
exten => s,n(hasat),Set(FROM_IP=${CUT(CUT(CUT(SIP_HEADER(From),@,2),>,1),:,1)})
exten => s,n(gotip),NoOp(Gateway IP is ${FROM_IP})
exten => s,n,NoOp(IP Country Lookup in Progress...)
; put authorized special calls like sipgate's Google Voice ringbacks below
exten => s,n,GotoIf($["${FROM_IP}"="sipgate.com"]?keepon)
exten => s,n,AGI(nv-ipcountry.php|${FROM_IP})
exten => s,n,GotoIf($["${STRANGER}"="true"]?blacklisted)
exten => s,n(keepon),NoOp(** AUTHORIZED CALLER **)
exten => s,n,Return()
exten => s,n(blacklisted),Answer
exten => s,n,Wait(1)
exten => s,n,Zapateller()
exten => s,n,Playback(ss-noservice)
exten => s,n,Hangup

Make sure you remove the line-wrap in the s,n(hasat) line and any others that may have wrapped in the display above! Then save the file and reload your Asterisk dialplan: asterisk -rx "dialplan reload". You're all set! If you'd like email notices when a stranger calls and is blacklisted, edit nv-ipcountry.php in /var/lib/asterisk/agi-bin. Plug in your actual email address in the $email variable and set $emailalerts = 1.

Housekeeping 101. As we mentioned above, the pool and location of IP addresses continues to change so periodic updates are necessary, or you'll end up blocking calls that otherwise should be permitted. MaxMind updates GeoLite Country on the first day of every month so add it to your TO-DO list. We strongly recommend that you perform these steps through an SSH connection from a remote PC. Why? Because, if you forget step 1 while logged directly into your server, you could inadvertently lock yourself out of your own system if the ip-checker script happens to run while your permit table is empty. If you do it from a remote machine, you can simply move to another machine and follow these instructions properly. Otherwise, you've got a serious problem on your main server. If this server provides phones to your business, do the update when the server is idle. So here's the drill:

  1. Comment out the ip-checker.sh /etc/crontab entry
  2. Download new GeoLite Country database from MaxMind
  3. Initialize the ipcountry.permit table
  4. Add authorized countries back into ipcountry.permit table
  5. Add back any custom entries to permit table
  6. Test your IP Country system to make sure you get all ok's
  7. Reactivate ip-checker.sh in /etc/crontab

1. Log into your server as root. To comment out the ip-checker.sh line in /etc/crontab, just add # as the first character on the line and save the file.

2. Change to the /root/ipcountry directory and run ./nv-GeoIPrefresh.

3. While still in the /root/ipcountry directory, run ./nv-ipcountry and choose 1-Yes to initialize your ipcountry.permit table.

4. Continue running or rerun ./nv-ipcountry to add each desired country to your ipcountry.permit table.

5. Run ./iputility.php to add custom IP address entries to your ipcountry.permit table. You do NOT need to reenter addresses in the deny table. It is unaffected by this update procedure.

6. Test your system again to make sure all extensions and trunks get an ok by running ./test.sh.

7. Edit /etc/crontab and remove the # at the beginning of the ip-checker.sh line and save the file.

What's Next. We're still exploring another possibility with IP Country, and that is integrating GeoLite Country directly into IPtables. This would validate every packet coming into your firewall using IP Country-like rules in IPtables. If you want to look at how it could be done, see this excellent writeup. Well, not so fast. Unfortunately, it won't compile under CentOS 5.2. Here's a link to the problem code if there are any Linux gurus in the house. Our reluctance in doing this has to do with performance. Keep in mind that, without stateful packet inspection, every single packet coming into your server would presumably trigger a database lookup. On a busy telephony system generating hundreds of thousands of packets per second, it would take a beast of a server with sufficient memory to cache the entire IP Country database in order to handle the processing load. So now we've got to either learn about or find an expert on the IPtables State Machine. If anyone wants to experiment, please share your expertise with the rest of us. There's a Google Voice invite in it for you, too.


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.



Need help with Asterisk? Visit the PBX in a Flash Forum.
Or Try the New, Free PBX in a Flash Conference Bridge.


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


Some Recent Nerd Vittles Articles of Interest...

Avoiding the $100,000 Phone Bill: A Primer on Asterisk Security

Here's a headline to wake up any CEO: "Small business gets $120,000 phone bill after hackers attack VoIP phone." News.com.au actually ran this story on January 20. "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 using the small business's VoIP system over a six month period."

News Flash: Be sure to read our latest article introducing 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.

For the latest Security Tips: See our most recent article.

Sad to say that folks install VoIP phone systems to save money and then completely ignore tried-and-true network security principles: hardening your system, regularly watching your logs, and periodically changing your passwords. If PBX in a Flash were a commercial offering, we'd probably keep much of what follows to ourselves and start touting our PBX systems as the only Asterisk® offering with Secure-Wrap™. That's not our world, of course, nor is it what open source is all about... which turns out to be both a blessing and a curse. We openly and jointly figure out ways to secure our Asterisk systems as well as those of our competitors. Then the bad guys get to read all about it and come up with new, more creative "solutions." The silver lining is there are millions of insecure Asterisk systems so the creeps typically move on to easier targets.

Today we'll walk you through our Top Ten Security Tips and Tricks. All of these can be implemented easily to harden your Asterisk PBX and lessen the chances of the bad guys transforming your VoIP system into a free, international payphone: you pay, they phone. In the process, we'll identify some common security blunders that accompany new system installs in hopes that you won't make the same mistakes. So let's start with the basics. If you plug your Asterisk PBX directly into the public Internet without carefully securing it, your chances of being hacked within the hour are pretty good.

Rule #1: Protect Your PBX With IPtables. PBX in a Flash systems are delivered with the IPtables firewall enabled. Leave it that way! If your Asterisk implementation doesn't have IPtables support, demand that it be added immediately or ask for assistance in adding it yourself. There is no reason not to use a freely available, open source firewall, period! And there are many good tools including WebMin (also included in PBX in a Flash distributions) to get it configured properly. With PBX in a Flash, all of the grunt work has been done for you.

Firewalls, of course, are only as good as the set of rules defined to secure your system. So only activate ports that are absolutely essential to run your PBX. For an excellent review of the ports that are opened by default in PBX in a Flash systems, see Joe Roper's summary. Think of an activated port as a hole in the dike. The more holes you add, the less secure your PBX will be. We'll leave it to you to count the holes in the dike if you choose to run your PBX without IPtables enabled. Our rule of thumb for PBX security goes something like this. If you don't need web access to your PBX, don't open ports 80 and 9080. If you don't need SSH, FTP, FOP, or WebMin access to your PBX, don't enable those ports. Better yet, don't even turn those services on unless there is a pressing need.

All of the IPtables rules are stored in /etc/sysconfig/iptables. Don't edit this file unless you know what you're doing. If you need help with the rules, post a question on the PBX in a Flash Forum. Typical response time on posted questions is under an hour on our forum. And don't forget to restart IPtables if you make changes to any of the rules: service iptables restart.

Rule #2: Protect Your PBX With A Hardware-Based Firewall. If one firewall is good protection, two firewalls are even better. As much as NAT-based firewall/routers get a bad rap, the extra layer of protection that a $50 hardware-based firewall/router delivers cannot be overstressed. Think of the software-based firewall as the tool of choice to secure your PBX on your internal LAN while the hardware-based firewall secures your system on the public Internet. We recommend the dLink WBR-2310 for home and SOHO use. It provides a reliable NAT-based router, a firewall, and excellent WiFi capability for under $50. If you've got some spare change, step up to one of dLink's Gaming Routers which we happen to use. They provide all the tools you'll need to prioritize your VoIP traffic. As with Rule #1, only open and redirect ports that are absolutely essential to use your PBX.

Rule #3: Safeguard Against Random Password Hacks. There is no better tool to protect your PBX from random password attacks than Fail2Ban 0.8.3. Fail2ban scans log files and bans IP addresses that make repeated, unsuccessful password attempts. It updates IPtables rules to reject those IP addresses for a period of time that you can set in /etc/fail2ban/jail.conf. Originally PBX in a Flash systems were shipped with an earlier version of Fail2Ban that provided only minimal protection. If your system doesn't include the jail.conf file above, you still have the older version. Simply run our update script to get the current release:

cd /root
mkdir fail2ban
cd fail2ban
wget http://pbxinaflash.net/source/fail2ban/fail2ban-update
chmod +x fail2ban-update
./fail2ban-update
service fail2ban restart

As was true with IPtables, Fail2Ban is only as good as the rules which are defined to identify failed password attempts on your system. On PBX in a Flash systems, we now protect against web, FTP, SSH, SIP, and IAX password attempts.

If your particular Asterisk implementation lacks Fail2Ban support, you're missing a critically important (free) tool to safeguard your system from random password attacks against SSH and your protected web sites as well as your SIP and IAX extension passwords. For tips on installation, review our script that is available on this thread in the PBX in a Flash Forum.

Rule #4: Narrow Access With IP Address Restrictions. Security privileges in the U.S. government are based upon a "need to know." It's pretty simple. If you don't have a need to know the information to perform your duties, you don't get the privilege. You can use a similar technique to secure your PBX by implementing IP address restrictions. For example, if all of your extensions are housed on a private subnet of your internal LAN, then there is no reason to allow Internet access to those extensions. Similarly, for extensions outside your local network, you now can hardcode the IP address into the extension to restrict access. To implement this with Asterisk and FreePBX-based systems, you'll first need to upgrade FreePBX to at least version 2.5.1.1. Once you've upgraded, go into each extension and enter either an IP address or an IP subnet for that extension in the permit field. For an IP address, the syntax is 192.168.0.44/255.255.255.255. For an IP subnet, the syntax would look like this: 192.168.0.0/255.255.255.0. This one tip would have been worth $120,000 to the Australian company referenced above. Yes, consultants can be worth their weight in gold. :-)

If you're as absent-minded as we are, you don't want to have to worry about remembering this each time you add a new extension to your system. So it's quite simple to change the default permit entry from 0.0.0.0/0.0.0.0 to the subnet mask of your LAN. Then you only have to adjust this entry whenever you add an extension which is not on your internal LAN. For example, if your LAN subnet is 192.168.0, then we want to replace the default entry with 192.168.0.0/255.255.255.0. The file to edit is /var/www/html/admin/modules/core/functions.inc.php. Just search for $tmparr['permit'] in BOTH the iax2 and sip sections of the file and make the value substitution preserving the single quotes on both sides of your new entries.

You also can implement both password and IP address restrictions to limit web access to your server. With Apache web servers, this is done through .htaccess files and directory restrictions in your Apache config files. On PBX in a Flash systems, htaccess password restrictions now are the default setup in all of our builds. Suffice it to say, if you can access the /admin directory on your web site from the Internet without being prompted for a password, your site probably has been compromised. Keep in mind that these passwords get cached so be sure you have cleaned out your browser cache before having a heart attack. Better yet, try this from a browser you don't ordinarily use (such as the one on your cellphone).

For additional security, you can further restrict access to your web directories by adding a list of authorized IP addresses to the .htaccess file in each subdirectory. Here's what an .htaccess file with IP address restrictions might look like. The first Allow entry is the private LAN subnet, the second is a remote site, and the third is the Hamachi VPN subnet mask:

Deny from All
Allow from 192.168.0
Allow from 68.218.222.70
Allow from 5.67

Rule #5: 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 such as the WBR-2310, this is incredibly easy. dLink calls them Virtual Servers. Here is a typical entry:

HTTP   192.168.0.150   TCP 80/2319   Allow All   Always

You can simply redirect common ports to different ports for Internet access. Don't do this for SIP and IAX ports, but it works great for HTTP, FTP, and SSH access. For example, port 80 typically is the default web server 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) web access, simply remap TCP port 80 to some obscure port and change it periodically. For example, you might redirect TCP port 80 to port 2319. Once the setting is saved, you access the web site with a browser entry like this: http://pbx.mydomain.com:2319/. Then (and just as important!) next month, change the port to 4382, then 6109, and so on. Don't use these numbers obviously! Make up your own. The key here is that 5 minutes work every month will keep web access to your PBX much more secure than letting every Tom, Dick, and Ivan hammer away at port 80 every night while you're sleeping. Incidentally, 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 and web 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 United States.

Rule #6: Really Secure Passwords Really Do Matter. While we have no hard evidence to back this up, our wild-assed guess (WAG) 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. The first five rules would have protected most Asterisk systems. But our WAG on the number of Asterisk PBX's that have implemented all five rules above would be less than one in a thousand. Part of that is because some of these tools weren't readily available until recently. But part of it is because most of us are just plain L-A-Z-Y.

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, make certain it has a really, really secure password. 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). You've been warned. It's your phone bill and bank account!
<end of sermon>

Rule #7: 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. 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 an Asterisk PBX goes like this. Don't! But, if you must, build as many layers of protection as possible to assure that your system is not compromised. If the bad guys get into FreePBX, the security of your PBX has been compromised... permanently! This means you need to start over with all-new passwords by installing a fresh system. You simply cannot fix every possible hole that has been opened on a FreePBX-compromised system!

Rule #8: Implement VPNs for PBX Systems. PBX in a Flash has provided simple install scripts to deploy Hamachi VPNs on all of our current systems. Hopefully, the other aggregations will do likewise. In addition, we offer turnkey VPN in a Flash systems which provide this functionality out of the box. VPNs provide an incredibly simple way to interconnect PBX systems worldwide and assure secure communications between these interconnected systems. We now are exploring other VPN solutions which would facilitate the use of VPN-enabled telephones such as the new offerings from SNOM.

Rule #9: Check Your Logs Every Day. We're still dumbfounded by the following quote from the article 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? Sounds like they earned this phone bill. FreePBX provides an incredibly simple way to review your call logs. Click the Reports tab at the top of the screen and look at the bar graph showing the number of calls each day and the combined length of those calls. Nothing could be easier. Do it every single day! It also should be noted that Ethan Schroeder has released a beta of some new monitoring software which will provide more granular monitoring of daily call volumes. For additional information or to participate in the beta, visit this link.

Rule #10: 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 trixbox Forum, and the FreePBX Forum. Aside from reviewing your call logs, it's the best 15 minutes you could spend to safeguard your system. We also have an RSS Feed which includes security alerts.

Update #1: Be sure to read this great new article. It has two fresh ideas for securing your system!

Update #2: Please also read this Nerd Vittles Alert about FreePBX backdoors and default passwords that was published on April 15, 2011.

Some Other Suggestions. A couple other suggestions come to mind that don't involve securing your PBX per se but nevertheless will lessen your exposure in the event of a security breach. First, if your usual calling patterns don't involve international calling or if they're limited to one or two countries, tighten up your outbound dialplan and restrict calling to countries that you actually need. It can always be changed when the need to call elsewhere arises. Second, if you use pay-as-you-go providers, never use credit card auto-replenishment. Instead, add funds periodically using the provider's web interface. The advantage of this is that, if someone does manage to break into your system, your loss will be limited to the current balance in your provider account. You'll not only save a lot of money, but you'll also get a notification that something has gone horribly wrong. Finally, a forum user mentioned one we had overlooked. If you have a mix of POTS and VoIP lines, don't put the POTS lines in the default outbound pool for toll calls. This could potentially save you lots of money.

Continue Reading Part II: The VoIP WhiteList for IPtables...

Got Some Other Ideas? 50,000 heads always are better than one when it comes to network security. If there are things we've missed, take a minute to post a comment. It'll help all of us keep our systems more secure. Good luck!

Digium® Weighs In. Since this article first appeared, Digium has released its own set of tips on SIP security. By all means, have a look!


Security Alert of the Week. A trixbox user yesterday reported that he had discovered a rootkit exploit on his server. You can could read all about it here. The 6:03 a.m. (California time) post mysteriously disappeared a few hours later... soon after the trixbox staff got to work. Another darn computer failure according to Fonality staff. :-? We've attempted to recreate the information from Google snippets. And here's a simple test to see if you have a similar rootkit problem:

ls -all /sbin/init.zk


Want a Bootable PBX in a Flash Drive? Our bootable USB flash installer for PBX in a Flash will provide all of the goodies in the VPN in a Flash system featured last month on Nerd Vittles. You can build a complete turnkey system using almost any current generation PC with a SATA drive and our flash installer in less than 15 minutes!

If you'd like to put your name in the hat for a chance to win a free one delivered to your door, just post a comment with your best PBX in a Flash story.1

Be sure to include your real email address which will not be posted. The winner will be chosen by drawing an email address out of a hat (the old fashioned way!) from all of the comments posted over the next couple weeks. All of the individuals whose comments were used in today's story will automatically be included in the drawing as well. Good luck to everyone and Happy New Year!!


New Fonica Special. If you want to communicate with the rest of the telephones in the world, then you'll need a way to route outbound calls (terminations) to their destination. For outbound calling, we recommend you establish accounts with several providers. We've included two of the very best! These include Joe Roper's new service for PBX in a Flash as well as our old favorite, Vitelity. To get started with the Fonica service, just visit the web site and register. You can choose penny a minute service in the U.S. Or premium service is available for a bit more. Try both. You've got nothing to lose! In addition, Fonica offers some of the best international calling rates in the world. And Joe Roper has almost a decade of experience configuring and managing these services. So we have little doubt that you'll love the service AND the support. To sign up in the USA and be charged in U.S. Dollars, sign up here. To sign up for the European Service and be charged in Euros, sign up here. See the Fonica image which tells you everything you need to know about this terrific new offering. In addition to being first rate service, Fonica is one of the least expensive and most reliable providers on the planet.
 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID and 60 free minutes from our special Vitelity sign-up link. If you're seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity's DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here's a deal you can't (and shouldn't) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month and you get a free hour of outbound calling to test out their call quality. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won't get the special pricing! After the free hour of outbound calling, Vitelity's rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity.
 


Some Recent Nerd Vittles Articles of Interest...

  1. This offer does not extend to those in jurisdictions in which our offer or your participation may be regulated or prohibited by statute or regulation. []

Ringbinder theme by Themocracy