The Michigan Telephone blog

This article has been moved. Please click here to read it.

Today the Nerd Vittles folks released a new web app called Travelin’ Man, which is described as follows:

Ever wrestled with one of those thorny problems for weeks only to wake up in the middle of the night with the answer? Thus was born Travelin’ Man, a web- based, one-click Asterisk application that automatically reconfigures your Asterisk PBX to enable remote SIP phone access from your cellphone, iPad, remote PC, NetBook, or desktop telephone.

This is a great step in security of those who have remote users that travel from place to place, and that use a phone or device with web access, and that are running the so-called “Incredible PBX” (the current “all-in-one” package from Nerd Vittles, that includes CentOS, FreePBX, Asterisk, and a few extras).  Unfortunately, it’s not real helpful for those of us that may be using a different distribution (EDIT: but, see the comment by NerdUno following this article, where he says “We’d be happy to consider sharing the source code with anyone that would like to write an equivalent system for other aggregations or even generic Asterisk systems”), or who have users with endpoints that do not necessarily have web access (for example, someone who carries a VoIP adapter with them), or for remote users at fixed locations that may not even be aware that their IP address has changed.

It appears at first glance that the Nerd Vittles solution locks each extension to one and only one IP address (which is also possible from within the FreePBX extension configuration screen, in all versions from 2.5 on).  The Travelin’ Man solution appears to use a web app that detects the user’s current IP address, then resets the extension configuration to allow connections from that extension at that IP address only.  However, even with that, there may be a security issue.  As the article notes:

The installer has been encrypted for your/our own protection. In source form, the script would allow anyone to defeat the Incredible PBX requirement. Doing so would mean the required IPtables security component would not be in place and properly configured to protect the underlying system from attack. So we’ve opted to play Big Brother to avoid potential security problems for all of us down the road.

From the above, it sounds to me like perhaps they are hoping that no one will be able to reverse-engineer what they are doing.  Unfortunately, given that Asterisk and FreePBX both use unencrypted configuration files, I’m not certain how successful they will be in keeping their method obscure, so I really hope they are not counting on “security through obscurity.”  I wish them the best, and congratulate them on coming up with a solution that will work for many users, but personally I might have preferred a slightly different approach.

On any FreePBX system, you basically have two categories of extensions – those that are on your local network, and those that aren’t.  It’s very easy to secure the ones on your local network using the permit and deny fields in the extension configuration. For example, if your router assigns addresses in the 192.168.0.x range, then you would use deny 0.0.0.0/0.0.0.0 and permit 192.168.0.0/255.255.255.0 to make sure that no one could connect using that extension’s credentials from outside your local network.  Even if they could somehow guess the correct password, they would not be allowed in. If you have also set up fail2ban on your system, and use good passwords, the chances that anyone will be able to get into your system fall significantly.

Still, if you have remote extension (such as family members or friends that connect from elsewhere on the Internet), you might want to be able to qualify them, or at least take notice if an IP address change looks suspicious.

Asterisk provides a way to find out where are your remote extensions are connecting from. From the Asterisk CLI, you can enter sip show peers to see all your sip-connected extensions, and iax2 show peers to see all your iax2 connected extensions. One of the pieces of information available is the IP address that the extension is connecting from (or (Unspecified) if the extension is not currently connecting). I’m guessing that this same information is available in the Asterisk database (where it could perhaps be accessed using an AGI or similar script?), or if all else fails, in the Asterisk log file. The trick would be to have a script, or maybe even a FreeBX module, that determines the current address that each off-site extension is connecting from, and then checks a local database to see if it matches the address that extension connected from on the previous check (ignoring (Unspecified) extensions).  You could run this check once each minute, or even every few seconds if it doesn’t put a load on your system.

If you do find that the address a particular extension is connecting from suddenly changes, then you could go to a site that will give you some information about where the new IP address is geographically located.  You program or module could allow you to set up rules that would determine whether you want to allow connections from the new IP address.

Let me give you an example.  Let’s say that you had a user whose IP address suddenly changed to 173.194.33.104 (this is just an example, that’s actually Google’s IP address).  Now, since you know that’s not the same as the last address that user connected from, you might do something like this (Warning: don’t click on this link unless you are willing to use one of your daily lookup credits – see below):

http://www.ip2location.com/173.194.33.104

Note that the ip2location service only allows you 20 lookups per IP address per day (200 if you open a free account), so you only would want to query it when a user’s address changes, which hopefully would be a rare event.  So, continuing with the example, you go to that address and get this:

IP2Location demo page (partial page)

Now, as you can see, there is plenty of information there that might help you determine whether this is actually your user. Maybe you know that your user’s ISP is not google.com, or maybe they are always connecting from Michigan, not California. With a properly written script or module, you could say something like “If they are not in time zone -05:00 don’t allow a connection” or “If they are not in Minnesota don’t allow a connection”, or you could get even more specific and narrow it down to a particular zip code. The advantage of this would be that it requires no effort or knowledge by your users, as long as they stay in the area they’re “supposed” to be in, or connect from the ISP they are “supposed” to be using. ISP identification would be particularly useful for external users at fixed locations, where the ISP may randomly assign them some new IP address.

I am not really what you call a programmer, and I definitely don’t have the ability to write a FreePBX module. The best I can do is, on occasion, hack together a small script, but in this case there are two things I don’t know. One is how to get a list of extensions and associated IP addresses out of Asterisk and into an external program or script, into a form that program or script can utilize (basically, the information in sip show peers and/or iax2 show peers, but just the extensions and associated IP addresses). EDIT: Okay, I have figured this much out.  The secret command is  asterisk -rx “sip show peers” (or asterisk -rx “iax2 show peers”) which can then be filtered or piped as necessary.  Just as an example:

asterisk -rx “sip show peers” | grep -v 192\.168\.[12]\. | grep ^1[01] | grep / | sort -n > /tmp/peers.txt

Breaking the above line down:

asterisk -rx “sip show peers” — dump the list of SIP peers
grep -v 192\.168\.[12]\. — filter out the ones on the local network (starting with 192.168.1 or 192.168.2 in this example)
grep ^1[01] — filter out the entries that don’t begin with 10 or 11 (our extension range) (those are probably trunks)
grep / — filter out the ones not currently connected (only keep those with a / character on the line)
sort -n — sort in numeric order
> /tmp/peers.txt — redirect output to the file /tmp/peers.txt

Here’s another example, this one for iax2:

asterisk -rx “iax2 show peers” | grep -v 192\.168\.[0-9]\. | grep ^[1-9] | grep -v “(Unspecified)” | grep -v “iax2 peers” | sort -n

Breaking this line down:

asterisk -rx “iax2 show peers” — dump the list of IAX2 peers
grep -v 192\.168\.[0-9]\. — filter out the ones on the local network (starting with 192.168.0 through 192.168.9 in this example)
grep ^[1-9] — filter out the entries that don’t begin with a digit 1 through 9
grep -v “(Unspecified)” — filter out the ones not currently connected (iax2 doesn’t use the / character on the line)
grep -v “iax2 peers” — filter out the status line
sort -n — sort in numeric order

Point is, you may have to play around with this line a bit to see what works on your system to show connected remote extensions only. NOTE: WordPress changes regular double quotes to “fancy” quotes; in all examples here, if you cut and paste you’ll have to change the quotes back to regular double quotes. Sorry about that.

I also found out that there is a Perl module called Geo::IP, which calls the GeoIP C API.  If you install that API (when downloading, I’d go into the test/ directory and get the latest beta) using the directions on the linked page, and then install the Perl module (you must do it in that order, or installation of the Perl module will fail), you could run a Perl script that shows the location that your off-site extensions are coming in from.  If you don’t want to install the API, or can’t figure out how (not difficult if you follow the directions), you can use the Geo::IP::PurePerl Module which is slower, but does not require the additional C library. Just so you know, GeoIP puts its data file at /usr/local/share/GeoIP/GeoIPCity.dat and they suggest that you go to http://www.maxmind.com/download/geoip/database/ every month or so to grab the latest database (the full link for the country database is currently http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz or you can get a much larger city-level database at http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz — just make sure you don’t grab a CSV version by mistake!). If you need them, there are installation instructions for the database, although they are primarily for the city-level database. If you buy an account, they’ll give you automatic updates, though I can’t imagine it would be that hard to write a script to do that (or maybe Google could help you find one, or see this message thread).

Here’s a really rough first cut at a Perl script which may or may not work as intended, which in theory looks at each of your SIP extensions and if they are connecting from outside the US, then the IP address they are connecting from is banned, and a notice is posted to the syslog and e-mailed to whomever you like — of course this could be modified to check for a different country, or even to add exceptions for various extensions that might have reason to connect from other countries (I warn you, I am NOT a Perl expert – suggestions for improvement are welcome, as are reports of it working or not working):

#!/usr/bin/perl
use strict;
use warnings;
use Geo::IP;
use Sys::Syslog;
my $gi = Geo::IP->new(GEOIP_STANDARD);
my ($ext, @peerline, @extension, $ipaddress, $country, $shellcmd);
my $flag = 0;
# change grep statements in next line to match your local IP range (1st grep) and first digits of extensions (2nd grep)
my @sippeers = `asterisk -rx “sip show peers” | grep -v 192\.168\.1\. | grep ^[1-9] | grep / | sort -n`;
foreach (@sippeers) {
@peerline = split(” “);
$ipaddress = $peerline[1];
$country = $gi->country_code_by_name($ipaddress);
@extension = split(“/”,$peerline[0]);
$ext = $extension[0];
# The next line is a diagnostic you can uncomment if things aren’t working as expected
# print “Extension $ext has IP address $ipaddress which is in country $country\n”;
# In next line change US to your country’s code if necessary
if ($country && $country ne ‘US’) {
$shellcmd = `iptables -D INPUT -p ALL -s $ipaddress -j DROP 2>&1`;
system(“iptables -A INPUT -p ALL -s $ipaddress -j DROP”);
openlog($0,’pid’,'user’);
syslog(‘notice’, “Banning IP address $ipaddress in $country because Asterisk Extension $ext is connecting from there”);
closelog;
if (index($shellcmd, “Bad rule”) >= 0) {
# Change you@yourisp.com to your actual e-mail address in next line
$shellcmd = ‘echo “This is an automated message – please do not reply. IP address ‘ . $ipaddress . ‘ in country ‘ . $country . ‘ was banned in iptables because Asterisk SIP extension ‘ . $ext . ‘ was connecting from there.” | mail -s “IP address banned on Asterisk box” you@yourisp.com’;
system($shellcmd);
$flag = 1;
}
}
}
# If an IP address was banned, the next line totally restarts Asterisk (interrupting all in-progress calls) – you may want to do something different.
if ($flag == 1) {
`asterisk -rx “restart now”`;
}
else {
openlog($0,’pid’,'user’);
syslog(‘info’, “Completed normally”);
closelog;
}

EDIT: After working on this some more, I think I have come up with a better script than the above — see my follow-up article, Geolock — a Perl script for Asterisk or FreePBX users to enhance security for details.

Note there’s a few lines up there that may wrap on your screen but are really all one line — I suggest using cut-and-paste to get the lines in their entirety. In case you are wondering, the reason I try to delete the iptables rule before creating it is because I don’t want to create the same rule multiple times (iptables happily accepts duplicates, unfortunately).  If I get an error when trying to delete the rule, then I know that what follows will be the first attempt to create it, and I should send an e-mail and restart Asterisk when we’re all finished.  Basically, it’s supposed to be a safety mechanism to keep from repeatedly sending the same e-mail, or restarting Asterisk once a minute if for some reason the iptables rule doesn’t “take” at first.  Should you actually try to use this as it sits, read the comments in the source code carefully (they’re important), don’t forget to make the Perl script executable, and run it manually a few times to watch the output (uncomment the “print” line during initial testing).  After you have run it a few times, do an iptables –list and make sure everything looks okay there.  Remember that I am NOT a programmer, so check my code carefully! Only then should you even think about setting up a cron job to run it every minute.

I don’t know of any way to block access to a specific extension in Asterisk “on the fly” from an external script, but I would think that blocking the offending address using iptables would suffice.

So here’s the challenge for you programmers:  Write a FreePBX “Extension Geolocation” module, or a much better and more configurable script that accomplishes what I’ve envisioned here. Something that would run, say, once each minute and check for changes in the IP addresses of all extensions, ignoring those on the local network and those marked as (Unspecified).  When it finds a changed IP address, query a geolocation service (could be ip2location.com, but maybe you know of a better one that permits more free accesses or gives better information?) or run a geolocation api, as shown in the example above, and then check whatever criteria you have established for that extension (any of Country, Region, City, Zip Code, Time Zone, ISP, Domain, IDD Code, Area Code, or Zip Code might be good “trigger” criteria).  If anything doesn’t match, either ban the specific IP address (using iptables) or turn off access to that extension in some manner. And if you need to do that, it would be a good idea to automatically email the user and the system administrator to let them know that something is amiss!

I will note that there’s probably nothing FreePBX-specific about this idea, so while it would be nice to have a FreePBX module that manages this, a script or a program in a high-level language (maybe in any of those languages that starts with a “P” ) would be more universal, in that it could be utilized by Asterisk users that don’t use FreePBX.  Either way, it would be a great addition to the available security tools.