Incredible PBX remains one of the most secure VoIP server platforms on the planet for one simple reason. We always deploy a preconfigured Linux IPtables firewall with a whitelist that hides your server from everyone except you and trusted VoIP providers. IPtables is automatically configured and deployed as part of every initial install of Incredible PBX regardless of your platform. This includes XiVO with Debian 8 as well as CentOS 6 and 7, Ubuntu 14.04, Raspbian 7 and 8, and even SHMZ OS (not recommended). If your server happens to be housed behind a hardware-based firewall as well, then so much the better. That obviously isn’t possible with most Cloud-based servers so IPtables firewall security is a must.

Unlike most other VoIP server platforms, we don’t leave firewall configuration to chance. Nor do we assume you’re a firewall expert. It really doesn’t matter whether you are or not, you still need a server platform that is secure and protected. So we do it for you initially and, if you are a firewall expert or study to become one, you then can modify the default settings to meet your own requirements down the road. In the meantime, you and your server are protected.

As you probably have surmised, we conduct periodic security audits of our servers testing for vulnerabilities. And we perform these audits locally as well as remotely using servers we’ve deployed throughout the world. We also deploy honeypot servers from time to time in order to gather important information about what the bad guys are up to. With as many platforms as Incredible PBX now supports, just conducting local and remote security audits is no small feat.

Today we want to share some of the methodology we use in conducting our audits, and we’ll provide the results of our most recent remote security audit. We encourage everyone with a VoIP server, whether it’s Incredible PBX or some other platform, to periodically test your server(s) for vulnerabilities AND access. It not only could save you thousands of dollars, but it also protects the rest of us by assuring that you haven’t inadvertently provided malicious individuals with a zombie platform from which to launch denial of service and spam attacks against the Internet community. So let’s get started.

The first step in testing your server is to log into your server as root using SSH or Putty from multiple IP addresses. These sites should include logins from the home base of your server if it’s a dedicated machine, from your home PC, from a neighbor’s PC, from a public WiFi hotspot, and from your smartphone as well as someone else’s. If you gain access from all of these sites, you’ve got a problem. It means SSH access is not protected in any way on your server. While SSH is relatively secure, it has had its share of problems. And zero day vulnerabilities are regularly discovered in various Linux utilities so exposing all of your server’s important resources to the Internet is a very bad idea.

The second test deciphers the existing firewall rules that have been activated on your server: iptables -nL. If the results look like the following, you’ve got a major problem. It means there are no firewall rules blocking any access to your server:

root@incrediblepbx:~ $ iptables -nL

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Next, reboot your server and repeat the first two tests to make certain that your firewall still is activated properly whenever your server experiences a power outage and comes back on line.

If your firewall is not running, try issuing the command, iptables-restart, and then retest: iptables -nL. If you get the same results shown above, then something has come unglued. Here’s how to easily fix things up. First, move to the directory where the iptables rules are stored on your server. For CentOS/SL/RHEL, it’s /etc/sysconfig. For Debian/Ubuntu/Raspbian, it’s /etc/iptables.

Next, copy the default Incredible PBX firewall settings to the proper file location.

For CentOS/SL/RHEL platforms:

cp -p /etc/sysconfig/rules.v4.ubuntu14 /etc/sysconfig/iptables
cp -p /etc/sysconfig/rules.v6.ubuntu14 /etc/sysconfig/ip6tables

For Debian/Ubuntu/Raspbian platforms:

cp -p /etc/iptables/rules.v4.ubuntu14 /etc/iptables/rules.v4
cp -p /etc/iptables/rules.v6.ubuntu14 /etc/iptables/rules.v6

Next, edit iptables (CentOS/SL/RHEL) or rules.v4 (Debian/Ubuntu/Raspbian) and move to the bottom of the file where you’ll find a section that looks like this:

# The IP addresses are your server, user, and public addresses respectively
-A INPUT -s 8.8.4.4 -j ACCEPT
-A INPUT -s 8.8.8.8 -j ACCEPT
-A INPUT -s 74.86.213.25 -j ACCEPT

Replace the existing IP addresses with the actual IP addresses of your server, user workstation, and public IP address. Be very careful here. If you don’t whitelist the IP address of the machine on which you are performing these tasks, you will lock yourself out when you restart your firewall. Once you’ve made the changes, save the file.

Finally, restart IPtables using the following command: iptables-restart. Then retest: iptables -nL.

We’re not going to spend a lot of time addressing what the proper firewall rules for your VoIP server should be. If you’re interested, you can take a look at the IPtables firewall setup that is deployed with Incredible PBX. On RHEL/CentOS/SL servers, you’ll find the firewall rules in /etc/sysconfig/iptables. On Debian/Ubuntu/Raspbian servers, the rules are in /etc/iptables/rules.v4. Suffice it to say that, if the only remote access required with your server is to connect to VoIP service providers, there is no reason to expose your web server or your SIP ports to the Internet, period. And this is true whether your server is sitting behind a hardware-based firewall or not.

The Incredible PBX security design uses a whitelist to provide access to most network services other than those that are absolutely essential to the operation of your server. The reason we use a whitelist is because blacklists don’t work. Those interested in doing harm to your server are perfectly capable of altering their IP addresses until they find one that isn’t blacklisted. And they also are adept at poisoning blacklists with IP addresses that are absolutely essential to the operation of your server, e.g. DNS servers and NTP servers.

As part of every Incredible PBX firewall install, we provide SIP and IAX access to many of the major VoIP providers around the globe. You may be wondering why we use IP addresses for providers rather than fully-qualified domain names. The reason is that IPtables doesn’t directly support FQDNs. Instead, when IPtables starts up, it looks up every FQDN and converts it into an IP address. If a server matching the FQDN happens to be off line, IPtables crashes and burns. The same is true if the lookup is attempted before DNS services are running on your server. So, the short answer to why we use IP addresses is because it is safer. The downside, of course, is you can’t eyeball the IP address and decipher to whom it belongs. If you ever have any doubt about the identity of the provider associated with any specific IP address, there’s a simple utility you can run to identify its owner: nslookup 178.63.143.236.

Here is a list of the providers included in the default Incredible PBX whitelist. Others can be added using the add-ip and add-fqdn utilities in /root. If you use FQDNs, be sure to add the entries to /root/ipchecker so that your IP addresses are periodically checked and updated when necessary. This is especially important for dynamic IP addresses at remote locations.

outbound1.vitelity.net
inbound1.vitelity.net
atlanta.voip.ms
chicago.voip.ms
dallas.voip.ms
houston.voip.ms
losangeles.voip.ms
newyork.voip.ms
seattle.voip.ms
tampa.voip.ms
montreal.voip.ms
montreal2.voip.ms
toronto.voip.ms
toronto2.voip.ms
london.voip.ms
didforsale.com
callcentric.com
sipgate.com
chi-in.voipstreet.com
did.voip.les.net
magnum.axvoice.com
proxy.sipthor.net
sip.voipwelcome.com
incoming.future-nine.com
outgoing.future-nine.com
DEN.teliax.net
LAX.teliax.net
NYC.teliax.net
ATL.teliax.net
IPkall (defunct) used two IP addresses: 66.54.140.46 and 66.54.140.47
gvgw1.simonics.com
sip2sip.info
googlelabs.com
talk.google.com
gmail.com

The major drawbacks to firewall whitelists are (1) you can inadvertently lock yourself out of your own server and (2) someone that needs access to your server from remote locations may have more difficulty connecting without intervention by a network administrator to authorize remote access. With Incredible PBX, we’ve provided some tools to ease the pain. First, Incredible PBX is deployed with both the PPTP and NeoRouter VPN platforms already in place. With a VPN IP address, remote logins are minimized because they work from almost anywhere. Second, Incredible PBX includes the PortKnocker utility which lets a remote user “knock” on the server using three randomly assigned port numbers to gain temporary access. Many Incredible PBX platforms also support Travelin’ Man 4 which lets you authorize remote access by telephone. You also need to test remote VPN, PortKnocker, and Travelin’ Man 4 access as part of your security audits.

Testing for vulnerabilities is only half of the puzzle. Also make certain that your server has the proper Linux tools in place to allow you to whitelist additional IP addresses so that remote users can deploy phones or gain access to your server when necessary. Try to run the nslookup and dig utilities to verify that they are installed on your server. If not, install them with yum install bind-utils (CentOS/SL/RHEL) or apt-get install dnsutils (Debian/Ubuntu/Raspbian).

Security Audit Results. We’re pleased to report that no vulnerabilities were identified in any of the Incredible PBX platforms; however, good security practices dictate that the IPkall IP addresses should probably be removed from the whitelist now that the company has ceased providing VoIP services.

For CentOS/SL/RHEL platforms:

sed -i '/66.54.140.46/d' /etc/sysconfig/iptables
sed -i '/66.54.140.47/d' /etc/sysconfig/iptables
sed -i '/66.54.140.46/d' /etc/sysconfig/rules.v4.ubuntu14
sed -i '/66.54.140.47/d' /etc/sysconfig/rules.v4.ubuntu14
iptables-restart

For Debian/Ubuntu/Raspbian platforms:

sed -i '/66.54.140.46/d' /etc/iptables/rules.v4
sed -i '/66.54.140.47/d' /etc/iptables/rules.v4
sed -i '/66.54.140.46/d' /etc/iptables/rules.v4.ubuntu14
sed -i '/66.54.140.47/d' /etc/iptables/rules.v4.ubuntu14
iptables-restart

We did identify a couple of access anomalies that kept the add-ip and add-fqdn utilities in /root from functioning properly. These glitches meant that a few administrators could not easily add remote IP addresses to their whitelists. Three fixes are recommended. First, be sure the utilities documented in the previous paragraph are installed on your server. Second, on CentOS/SL/RHEL platforms or servers installed using the Incredible PBX ISO, issue the following commands after logging into your server as root:

sed -i 's|/etc/iptables/rules.v4|/etc/sysconfig/iptables|' /root/add-ip
sed -i 's|/etc/iptables/rules.v4|/etc/sysconfig/iptables|' /root/add-fqdn

Third, for Incredible PBX deployments on the CentOS 7 platform, issue these commands while logged in as root:

 chattr -i /root/add-ip
 sed -i 's|iptables-persistent|iptables|' /root/add-ip
 chattr +i /root/add-ip

Be safe!

Originally published: Tuesday, August 9, 2016





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


 

Special Thanks to Our Generous Sponsors

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


​​3CX is a software PBX that’s easy to install & manage. It includes integrated softphones, WebRTC conferencing and essential add-ons out of the box, at no additional cost. Try the free edition at www.3cx.com. Better yet, download the PIAF5 ISO powered by 3CX. Free version includes support for 8 simultaneous calls with a SIP trunk.

  • Run on Premise or in the Cloud, on Windows and now on Linux
  • Softphones for iOS, Android, Win & Mac
  • Easy install, backup & restore, version upgrades
  • Automatically configures IP Phones, SIP Trunks & Gateways

  • RentPBX, a long-time partner and supporter of PIAF project, is offering generous discounts for Nerd Vittles readers. For all of your Incredible PBX hosting needs, sign up at www.RentPBX.com and use code NOGOTCHAS to get the special pricing. The code will lower the price to $14.99/month, originally $24.99/month. It’s less than 50¢/day.


    Some Recent Nerd Vittles Articles of Interest…

    Be Sociable, Share!