Tag Archives: piaf

We hear some of you saying, "I love Asterisk. Why would I want to move to 3CX?" The short answer is don’t move, add a new 3CX server to supplement your existing Asterisk® infrastructure. Why? Because the 3CX Clients for Windows, Macs, iOS, and Android are incredibly compelling. You can make a connection from anywhere using WiFi or cellular infrastructure and make crystal clear calls with zero hassles. Better yet, folks can reach you on your mobile phone from anywhere in the world at zero cost by dialing your SIP URI using any SIP device including SIP softphones and other 3CX Clients. And the 3CX Client is literally plug-and-play. Send the welcome email for the extension you wish to activate on the 3CX Client, and in one-click your 3CX Client is automatically configured and on line. By interconnecting your 3CX server with your existing Asterisk infrastructure, you get the best of both worlds without the messy NAT and firewall problems that were daily fare using Asterisk alone. But we’re getting ahead of ourselves, let’s get your 3CX server in the Cloud properly secured before moving on to the fun stuff.

Five years ago, we first introduced our Failsafe PBX Security Tips to Sleep Like a Baby. That’s well worth a careful read before we begin. For today, we’ll be implementing most of the Travelin’ Man 3 Security Model with a few tweaks to take advantage of existing 3CX security features. We’ll walk you through (1) choosing a cloud platform, (2) deploying the IPtables Linux firewall, (3) implementing a WhiteList to hide your server from those that don’t need access, (4) installing PortKnocker to make it easy for end-users to give themselves access to your PBX, (5) configuring FQDNs and implementing dynamic DNS updates for remote users, (6) setting up a BlackList to complement 3CX’s existing Anti-Hacking mechanisms, (7) deploying IPset to facilitate blocking entire countries from accessing your server, and (8) protecting SSH by setting up Fail2Ban and changing ports.

Let’s spend a moment considering the best security methodology for your cloud-based server. The short answer is IT DEPENDS. If all of your users are situated in the same location and never travel and you don’t care to enable SIP URI calling from anywhere in the world to save on phone costs, then the solution is pretty easy. We can lock your server down to the public IP address of your private LAN, and nobody else will ever see your server. Once you add users outside your home office, things get more complicated. If they are all sitting behind local routers with public IP addresses that are static, things are still fairly straightforward. We can whitelist all of the static IP addresses, and again nobody else will see your 3CX server. If you have users that travel for a living or need 3CX Client connectivity from their smartphones or from PCs at various locations that only have dynamic IP addresses, then things get more complicated. You can take your chances and expose SIP communications ports while locking down other access, or you can lock down everything, assign FQDNs to each user, and use dynamic DNS clients running on Android or iOS devices or local PCs to regularly update IP addresses of users in the firewall whitelist.

Another option that we use when traveling is PortKnocker which will be installed as part of our Travelin’ Man 3 security suite. The way this works is you send a single packet to three different TCP ports on your server using a predefined sequence of 3 port numbers. When there is a match, the server will automatically whitelist your IP address. Then you can log into SSH or the Web portal or use a 3CX Client in the usual way. There are PortKnocker clients for smartphones (Android’s DroidKnocker and iOS PortKnock), or you can use the command line from a Linux server to immediately authorize remote access from any IP address. No firewall modification is required. By default, Travelin’ Man 3 temporarily authorizes IP address access until the next server reboot. But you can elect to permanently whitelist the IP addresses if desired. Again, all of this can be performed remotely by end-users without ever touching your server or calling upon assistance from an administrator.

Finally, we’ve provided utilities in /root to assist an administrator in whitelisting IP addresses (add-ip) or FQDNs (add-fqdn) as well as removing whitelisted entries (del-acct). In addition, if you prefer to leave your server exposed, we’ve included tools to blacklist IP addresses (add-blacklist), and our discussion below will provide some alternatives to secure SSH access. Whichever path you choose, just be aware that server security it totally your responsibility, not ours and not 3CX’s. We strongly recommend that you regularly monitor the Event Log in the 3CX Dashboard for security issues and attempted breaches. You then can make firewall adjustments to address the problems or to further lock down your server.

LEGAL DISCLAIMER: ALL OF THE SECURITY CODE WHICH FOLLOWS IS DISTRIBUTED AS IS AND PURSUANT TO THE GPL2 LICENSE. YOU AGREE TO ASSUME ALL RISKS BY USING THIS SOFTWARE. YOU ARE FREE TO MODIFY IT TO MEET YOUR REQUIREMENTS SO LONG AS YOU COMPLY WITH THE GPL LICENSE TERMS AVAILABLE HERE.

For today’s tutorial, we will cover both the WhiteList 3CX firewall methodology and the less secure BlackList alternative. We’ll walk you through exposing the necessary ports if you elect to use this relaxed security configuration for your server. Just be aware that it’s your phone bill at stake particularly if you have authorized calls to countries outside the location of your server as part of your 3CX setup.

Here are a few things to consider when choosing a cloud platform for your 3CX server. Keep in mind that the cloud giants like Amazon charge for data bandwidth usage AND data storage AND processing cycles. Even though Amazon uses what are traditionally considered non-routable IP addresses internally, be advised that Amazon internally routes these private LAN addresses. What that means is that, if you have whitelisted private LAN addresses in the 172.16.0.0/12 range, you will expose your server to hacking attempts from anyone with an Amazon S3 account. For that reason coupled with the pricing structure, we recommend against using Amazon as your 3CX cloud platform.

We also recommend you stick with VPS hosting plans using the KVM architecture and avoid OpenVZ unless it’s hosted with Virtuozzo 7. The traditional shared kernel architecture of OpenVZ means you will forfeit the ability to use powerful tools such as IPset to blacklist country-wide IP addresses from countries such as China and Russia. Over 90% of the attacks we see on our web sites originate from IP addresses in just those two countries. Fortunately, the new Virtuozzo 7 implementations of OpenVZ support ipset. SSDnodes in Montreal is the provider we use.

The rest of the cloud platform equation comes down to balancing the feature set and performance against the cost. At the bottom of the barrel is CloudAtCost which offers lifetime cloud services for a one-time charge PLUS an annual maintenance charge. Performance and reliability range from awful to tolerable. As an experimental platform, it’s worth considering. For anything beyond that, don’t waste your time or money.

Our preferences in low-cost, moderate performance cloud platforms include OVH virtual private servers ($3.49/mo. for 2GB RAM, 10GB SSD, 100Mbps unlimited bandwidth, and DDoS protection), Vultr VPS ($5/mo. for 1GB RAM, 25GB SSD, 1TB bandwidth), and Digital Ocean ($5/mo. for 512MB RAM, 20GB SSD, 1TB bandwidth plus $10 usage credit). For high performance, long-term use, nobody beats our corporate sponsor, RentPBX.com, at $15/mo. with referral code: NOGOTCHAS.¹

We’ve taken the pain out of deploying IPtables as a 3CX firewall. Our Travelin’ Man 3 script for 3CX does the heavy lifting for you by installing and preconfiguring IPtables and a collection of other security components. There are two alternatives when running the installer. You can completely lock down your server and use a firewall whitelist to enable access from specified IP addresses or FQDNs. There are utilities to allow administrators and end-users to add their own addresses to the whitelist. The other option is to run 3CX without the whitelist functionality and employ blacklisting to reduce the exposure of your server. This obviously increases the security risks but reduces the administrative burden on administrators and end-users. And, as you probably know, 3CX includes some security mechanisms to block or reduce attacks on your server. A third option using 3CX Clients or SBCs in networks that prevent VoIP calls is to deploy 3CX’s VPN-like Tunnel. This is well documented in this server tutorial and this client tutorial. It’s worth a careful look if you’re in a country that blocks VoIP calls, and it works with either TM3 firewall configuration. A fourth option which we will save for another day is to employ virtual private networks such as OpenVPN and NeoRouter. With VPNs, there’s more work on the front end but less day-to-day administration once properly configured.

If you don’t have widely scattered users and traveling users that need to employ 3CX Clients, the WhiteList option is far preferable. It sets up a WhiteList of devices that are authorized to access your PBX. Nobody else can even see the server on the Internet. To get started, log into your server as root using SSH or Putty. Be sure to login from a computer that will be used to manage your server so that this computer’s IP address gets whitelisted. You don’t want to lock yourself out of your own server! Then issue the following commands at the Linux prompt to run the TM3 installer, accept the license agreement, and choose either the WhiteList or BlackList option when prompted:

cd /
wget http://incrediblepbx.com/tm3-3cx.tar.gz
tar zxvf tm3-3cx.tar.gz
rm -f tm3-3cx.tar.gz
cd /root
./tm3-3cx.sh

When the installer finishes, press ENTER. You now have a functioning 3CX firewall with IPtables and Fail2Ban functionality to protect SSH logins from hacking attempts, IPset to block server access from certain countries, PortKnocker to facilitate remote user access to servers employing a WhiteList, and a collection of utilities in /root to facilitate WhiteListing and BlackListing of IP addresses and FQDNs by administrators.

For the more technical types, here’s an overview of how the IPtables firewall is configured and functions. Currently, only IPv4 is protected. The basic setup is handled in /etc/iptables/rules.v4 by making a copy of rules.v4.tm3 and whitelisting 3 IP addresses: your server, your user PC from which you logged into SSH, and your public IP address. Additional whitelist entries are added using add-ip or add-fqdn in /root. Or end users can whitelist themselves using the PortKnocker credentials stored in /root/knock.FAQ. IPtables ALWAYS must be restarted/reloaded using the command: iptables-restart. This assures that all necessary components are reloaded including the base rules.v4 IPtables config plus the custom config in /usr/local/sbin/iptables-custom plus Fail2Ban. An administrator can remove whitelisted entries using /root/del-acct using the *.iptables filename associated with the entry to be removed. PortKnocker whitelist entries are stored by creation date.

Two templates for the TM3 custom configuration are stored in /usr/local/sbin. The WhiteList is iptables-custom.secure. The BlackList is iptables-custom.insecure. As part of the install, one or the other is copied into iptables-custom for use with your IPtables firewall. The code is well documented so that administrators can easily make modifications to support your own requirements. Simply rerun the tm3-3cx.sh installer once you have made changes, and your server will be reconfigured. Be advised that any previously added whitelist entries should be removed (/root/*.iptables) BEFORE rerunning the installer as these entries will not be replicated.

There are two ways to use PortKnocker for end user management of the WhiteList. The default methodology is to temporarily WhiteList qualifying IP addresses whenever a successful port knock is performed from any remote site. This WhiteList addition to the firewall lasts only until the firewall is restarted with iptables-restart or the server is rebooted. For a mobile workforce, this is probably the preferable alternative with frequently updated remote IP addresses. The other alternative is to permanently add successful PortKnock IP addresses to the iptables-custom whitelist. The administrator can activate this by running the following command: iptables-knock activate. As with other WhiteList additions, these are stored in /root as *.iptables. To use PortKnocker, remote users will need the secret knock credentials stored in /root/knock.FAQ. Should you ever need to modify these codes when an employee is fired, simply edit /etc/knockd.conf and change the codes. Remember to revise /root/knock.FAQ with the new codes. Then restart PortKnocker: /root/knock-tester.sh.

Here’s an easier way to set up remote users whose IP addresses regularly change either because of an ISP’s dynamic IP addressing scheme or because the user travels or frequently uses 3CX Clients from a smartphone. The trick here is to assign a fully-qualified domain name (FQDN) to each remote user’s device and then deploy a dynamic DNS update application on their device to keep the user’s current IP address in sync with their FQDN. As part of the TM3 implementation on 3CX, we included the /root/ipchecker script which checks for IP address changes every 10 minutes and updates the firewall whitelist accordingly. All that is required from the administrator is running /root/add-fqdn once for each remote user. Everything else is automatic on the 3CX server and the end user device.

There are a number of Dynamic DNS providers. Some are free and others have a modest annual fee. When it comes to DNS service, you get what you pay for. And our favorite remains dyndns.com. There are hundreds of domain names from which to choose, and there are update clients for most client platforms: Windows, Mac, Linux, iOS, and Android.

The setup procedure is straight-forward. (1) Choose a FQDN for each of your users on the dynamic DNS provider site. (2) Install and configure the DNS updater on each client device. (3) Run /root/add-fqdn on your 3CX server to add the FQDNs of each user to the TM3 WhiteList. (4) Restart IPtables: iptables-restart.

If an administrator elects NOT to deploy the 3CX firewall with a WhiteList and opts for the open 3CX firewall, then there are some additional steps to assure that your server remains secure. First, you’ll want to carefully monitor the 3CX Event Log in the 3CX web dashboard. When you spot hacking attempts that are being temporarily blocked by your 3CX server, immediately add them to your IPtables BlackList: /root/add-blacklist ipaddress. Thereafter, those users will no longer be able to access your server. After adding less than a handful of entries, our exposed server has not seen any further hacking attempts. YMMV!

The primary reason individual blacklist entries are unnecessary is because the TM3 installer automatically configures IPset to block access from a number of problematic countries. You can review these in /etc/block-china.sh and make modifications based upon your own requirements. Keep in mind that, if you add or remove countries from the script, you will need to add/remove the same entries in /usr/local/sbin/iptables-custom to assure that all of the countries you intend to block are assimilated into your firewall’s blacklist. Then reload the IPset tables and restart IPtables with this command: /etc/block-china.sh. To begin, you’ll need to decipher the country code for additional countries you wish to block. The country listing with codes is available here. The IPset country zones are available here.

The syntax for a new country addition in /etc/block-china.sh looks like this with the country name inserted in lines 1 & 4 and the country code inserted in lines 2 & 3:

/sbin/ipset -N china hash:net
rm cn.zone
/usr/bin/wget -P . http://www.ipdeny.com/ipblocks/data/countries/cn.zone
for i in ; do /sbin/ipset -A china ; done

The blacklist entries in /usr/local/sbin/iptables-custom look like this using the country name from above:

/sbin/iptables -A INPUT -p tcp -m set --match-set china src -j DROP
/sbin/iptables -A INPUT -p udp -m set --match-set china src -j DROP

None of the country modifications take effect until you reload the IPset tables and restart IPtables. Both are accomplished by running /etc/block-china.sh.

If you chose to implement the TM3 WhiteList option, SSH on your 3CX server is insulated from SSH attacks because the bad guys can’t see or access port 22 on your server. However, if you’re using the non-WhiteList approach with IPtables, then some additional safeguards to secure SSH are appropriate. As part of the TM3 security suite, Fail2Ban was installed to block repeated attempts to login to SSH. While this offers some protection, be advised that Fail2Ban scans logs and, as such, requires a sufficient time slice of processing power to complete the task regularly. Some of the more vicious hacking attempts originate from extremely powerful server platforms that can monopolize processor resources thereby depriving Fail2Ban of the necessary horsepower to adequately protect your server from brute force SSH attacks. The most important thing you can do to protect SSH on your server is to regularly review /var/log/auth.log for hacking attempts and block those IP addresses using the add-blacklist script.

The most effective way to configure SSH access is to deploy key-based authentication using cryptographically secure keys. Once enabled and tested, be sure to remove the ability to login using your root password. But be aware that removing root password access will mean that you cannot login to your server from multiple devices without copying your private key to every device from which you wish to obtain access. An excellent tutorial that will walk you through the basic implementation procedure is available from Digital Ocean.

The other effective way to minimize SSH attacks is to change the default access port on your server from port 22 to some other TCP port above 1024. While there are arguments against this approach, if you have a dedicated IP address assigned to your server, the likelihood of a bad guy hijacking your IP address and setting up a script to fake SSH behavior and surreptitiously collect your passwords is extremely remote. Most of the bad guys use toolkits that target port 22 for brute force SSH attacks. By changing the port, you cut your vulnerability by about 99 per cent. Here’s how. First, edit /etc/ssh/sshd_config. Change the line near the top of the file from Port 22 to some port number above 1024. If the line is commented out with #, remove the #. Second, edit /etc/iptables/rules.v4. On or about line 27, change 22 to the port number you assigned in the first step. Third, edit /etc/fail2ban/jail.conf. Scroll down to the [ssh] section of the file and change the port entry to: port = ssh,1234 where 1234 is the port number you assigned in step one. Save the file. Fourth, restart SSH: /etc/init.d/ssh restart. Finally, restart IPtables: iptables-restart.

When using an SSH client to login to your server, the new syntax should look something like this: ssh -p 1234 root@ipaddress where 1234 is the port you assigned for SSH access to your server and ipaddress is the IP address or FQDN of your server. When using putty, be sure to change the port to match the SSH port you assigned for SSH access to your server.

Nerd Vittles Exclusive: Grab your new (free) 3CX perpetual license with unlimited SIP trunks, 10 extensions, 4 simultaneous calls, and 10-user conferencing here.

Originally published: Friday, June 23, 2017

Need help with 3CX or VoIP? Visit the PBX in a Flash Forum.

Special Thanks to Our Generous Sponsors

FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.

BOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.

The lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.

VitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
 

Special Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.
 

Some Recent Nerd Vittles Articles of Interest…

1. Some of our links refer users to providers that support Nerd Vittles through referral fees or advertising. These funds help cover the costs of our blog. We never recommend particular products solely to generate revenue. However, when pricing is comparable or particular features warrant our recommendation, we support these vendors and deeply appreciate their financial support of our software development efforts. [↩]