Link: Using IP tables to secure Linux server against common TCP hack attempts

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally published in November, 2010.

Iptables
Image by Jordan W via Flickr

I’m not entirely certain of the original source of this article — I found it on one site, but a quick search reveals that the original source is most likely this site, but I may be wrong. The author of that article says he took some of the info in that article (looks like more than “some” from where I sit) from this article: How to: Linux Iptables block common attacks

Related articles found on that site are Using iptables to secure a Linux based Asterisk installation against hack attempts and Securing Asterisk – Fail2Ban (and that latter article looks suspiciously similar to this one: Fail2Ban (with iptables) And Asterisk).

I don’t know how valid or useful any of this is, but if you are running iptables on your system (if you’re not sure enter iptables -V on the command line — it should show you the version of iptables that is installed, if it is installed) then you might want to check these articles out.  And if you find an earlier source for any of these, let me know and I’ll include the links.  I know that in the technical community sometimes information gets copied around, but would it kill you guys to give attribution and a link to the original source when you are lifting information (or even raw text) from someone else’s article?

Link: Using FreeSWITCH to add Google Voice to Asterisk

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

EDIT (2018): This article is extremely out-of-date and in no way useful today, and will probably be removed from this site at some point in the future. You might find this article more useful: How to use Google Voice with FreePBX and Asterisk without using XMPP or buying new hardware.

For those of you using Asterisk, Bill over at the PSU VoIP blog has come up with a way to interface Asterisk with Google Voice, by co-installing FreeSWITCH (which also supports Google Voice).  Turns out that Asterisk and FreeSWITCH can co-exist on the same server, though you do have to change the configuration a bit so they don’t compete for the same ports.  Anyway, Bill has come up with a how-to on adding Google Voice integration to current versions of Asterisk, so if that interests you, head on over and have a look:

Using FreeSWITCH to add Google Voice to Asterisk

The bonus is that once you get FreeSWITCH installed you can play around with it and look at some of its other features, if you are so inclined. Of course, the Asterisk folks could backport the Google Voice support to previous versions and make it unnecessary to do things like this, but I’m not holding my breath.

EDIT (January 26, 2012): The Google Voice channel drivers in Asterisk 1.8 have become unreliable enough (in my personal opinion, anyway) that I just used the technique shown in this article, and I must say that it works a LOT better than Asterisk 1.8’s Google Voice support.  I also added some comments to that article (probably too many!) that among other things show how I got it working for multiple Google Voice accounts.  So I would now recommend using this method to bridge Asterisk to Google Voice in preference to using Asterisk 1.8’s native channel drivers (unless you are very short on memory and/or storage space) — it just works, and calls connect faster.  Read the article AND the comments under it first, so you’ll know what to expect, and do be aware that it takes a relatively LONG time to compile and install FreeSWITCH (compared to Asterisk).  At points during the installation it may look like it’s stuck in an endless loop, but it really isn’t. Just go away and take a walk outside or something, and come back in a while and it should be done.

A Perl script to send Caller ID popups from Asterisk to computers running Growl under OS X on a Mac or Growl for Windows

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Notice
EDIT March, 2014 and August 2020: If you are running OS X Mavericks or later, or any version of MacOS we recommend that you do NOT use the script shown here, but instead send notifications to a XMPP/Jabber account and use either Apple’s Messages app (formerly iChat) or a third party messaging program such as Adium to receive them, since the message will then display in the Notifications Center and you do not need Growl. See How to send various types of notifications on an incoming call in FreePBX for more information. You may also find this thread on the RasPBX forum useful.

What follows will probably not work on ANY currently supported version of MacOS and is left here as a historical reference only.

Quite some time ago, I wrote a post explaining how you could poll a Linksys or Sipura VoIP adapter or phone once per second, and whenever there was an incoming call, generate a notification popup on your computer, if you have the Growl notification service installed.  However, that method doesn’t work if you’re not using a Linksys or Sipura phone or device.

If you are running Asterisk, there’s another way to do it, and that’s to get Asterisk to send the notifications directly. In order for this to work, the computer on which you want to receive the notifications has to be running Growl (under Mac OS X) or Growl for Windows. You must also configure Growl to receive network notifications. I will note here that if you are using a Mac and have never done that before, you may want to make sure that Growl network notifications work before proceeding, because it appears that under OS X, it’s pretty much a crap shoot whether Growl network notifications will work at all, and when they don’t the Growl folks apparently have no clue as to why they don’t. It seems to be a machine-specific thing – on some Macs they work fine, while on others they don’t work at all.

You must have the Perl language installed on your Asterisk server, and you must have the Net::Growl and Asterisk::AGI modules installed (I’m going to assume you know how to install a Perl module from the CPAN repository – if you have Webmin installed, it can be done from within Webmin). Chances are you already have Asterisk::AGI installed, unless you built your Asterisk server “from scratch” and never installed it, but if you’ve never installed Net::Growl you’ll need to do that first.

Next you want to copy and paste the following Perl script to the filename /var/lib/asterisk/agi-bin/growlsend.agi on your Asterisk server (to create a non-existent file, you can use the touch command, and after that you can edit it in Midnight Commander or by using the text editor of your choice). If this code looks somewhat familiar, it’s because it’s adapted from some code that originally appeared in a FreePBX How-To, which I modified.

#!/usr/bin/perl
use strict;
use warnings;
use Net::Growl;
use Asterisk::AGI;
my $agi = new Asterisk::AGI;
my %input = $agi->ReadParse();
my $num = $input{'callerid'};
my $name = $input{'calleridname'};
my $ext = $input{'extension'};
my $ip = $ARGV[0];

if ( $ip =~ /^([0-9a-f]{2}(:|$)){6}$/i ) {
    $ip = $agi->database_get('growlsend',uc($ip));
}

unless ( $ip =~ /^(d+).(d+).(d+).(d+)$/ ) {
    exit;
}

open STDOUT, '>/dev/null';
fork and exit;

if ( $ARGV[2] ne "" ) {
    $ext = $ARGV[2];
}

# Define months and weekdays in English

my @months = (
    "January", "February", "March", "April", "May", "June",
    "July", "August", "September", "October", "November", "December"
);
my @weekdays = (
    "Sunday", "Monday", "Tuesday", "Wednesday",
    "Thursday", "Friday", "Saturday"
);

# Construct date/time string

my (
    $sec, $min, $hour, $mday, $mon,
    $year, $wday, $yday, $isdst
) = localtime(time);
my $ampm = "AM";
if ( $hour > 12 ) {
    $ampm = "PM";
    $hour = ( $hour - 12 );
}
elsif ( $hour eq 12 ) { $ampm = "PM"; }
elsif ( $hour eq 0 ) { $hour = "12"; }
if ( $min < 10 ) { $min = "0" . $min; }
$year += 1900;

my $fulldate =
"$hour:$min $ampm on $weekdays[$wday], $months[$mon] $mday, $year";

# Next two lines normalize NANP numbers, probably not wanted outside of U.S.A./Canada/other NANP places
$num =~ s/^([2-9])(d{2})([2-9])(d{2})(d{4})$/$1$2-$3$4-$5/;
$num =~ s/^(1)([2-9])(d{2})([2-9])(d{2})(d{4})$/$1-$2$3-$4$5-$6/;

register(host => "$ip",
    application=>"Incoming Call",
    password=>"$ARGV[1]", );
notify(host => "$ip",
    application=>"Incoming Call",
    title=>"$name",
    description=>"$numnfor $extn$fulldate",
    priority=>1,
    sticky=>'True',
    password=>"$ARGV[1]",
    );

Also, if you want to be able to specify computers that you wish to send notifications to using MAC addresses rather than IP addresses (in case computers on your network get their addresses via DHCP, and therefore the IP address of the target computer can change from time to time), then you must in addition install the following Perl script. It requires a command-line utility caller arp-scan so install that if you need to – I used to use nmap for this but they changed the output format, making it harder to parse, and arp-scan is much faster anyway. Call it /var/lib/asterisk/agi-bin/gshelper.agi and note that there are two references to 192.168.0… within it that you may need to change to reflect the scope of your local network, if your network’s IP addresses don’t start with 192.168.0.:

#!/usr/bin/perl
use strict;
use warnings;
my @mac;
# Change the following lines to reflect the scope of your local network, if necessary
my @arp = `arp-scan --quiet --interface=eth0 192.168.0.0/24`;
foreach (@arp) {
        if (index($_, "192.168.0.") == 0) {
                @mac = split(" ");
                `/usr/sbin/asterisk -rx "database put growlsend \U$mac[1] $mac[0]"`;
        }
}

Make sure to modify the permissions on both scripts to make them the same as other scripts in that directory (owner and group should be asterisk, and the file should be executable), and also, if you use the gshelper script, make sure to set up a cron job to run it every so often (I would suggest once per hour, but it’s up to you).

Now go to this page and search for the paragraph starting with, “After you have created that file, check the ownership and permissions” (it’s right under a code block, just a bit more than halfway down the page) and if you are using FreePBX follow the instructions from there on out (if you are not using FreePBX then just read that section of the page so you understand how this works, and in any case ignore the top half of the page, it’s talking about a different notification system entirely).  But note that if you use the above code and have the gshelper.agi program running as a cron job, then after the first time it has run while the computer to receive the notifications is online you should be able to use a computer’s MAC address instead of the IP address.  This only works if you’ve used the modified script on this page, not the one shown in the FreePBX How-To.  As an example, instead of

exten => ****525,1,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)

as shown in the example there, you could use

exten => ****525,1,AGI(growlsend.agi,01:23:45:AB:CD:EF,GrowlPassWord,525)

(the above is all one line) where 01:23:45:AB:CD:EF is the MAC address of the computer you want to send the notification to.  Once again, just in case you missed it the first time I said it, this won’t work until the gshelper.agi script has been run at least once while the computer to receive the notifications was online.  If for some reason it still doesn’t appear to work, run the nmap command including everything between the two backticks (`) directly from a Linux command prompt and see if it’s finding the computer (depending on the size of your network, it might be several seconds before you see any output, which is why I don’t try to run this in real time while a call is coming in).

If you are NOT running FreePBX, but instead writing your Asterisk dial plans by hand, then you will have to insert a line similar to one of the above examples into your dial plan, except that you don’t need the four asterisks (****) in front of the extension number, and if it’s not the first line in the context, you’ll probably want to use n rather than 1 for the line designator (and, you won’t be putting the line into extensions_custom.conf because you probably don’t have such a file; instead you’ll just put it right in the appropriate section of your dial plan).  In other words, something like this (using extension 525 as an example):

exten => 525,n,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)

This line should go before the line that actually connects the call through to extension 525.  I do not write Asterisk dial plans by hand, so that’s about all the help I can give you. And if you don’t write your dial plans by hand, but you aren’t using FreePBX, then I’m afraid you’ll have to ask for help in whatever forum you use for advice on the particular software that you do use to generate dial plans, because I can’t tell you how to insert the above line (or something like it) into your dial plan.

Virtually everything in this article has already been published in one place or another, but I wanted to get it into an article with a relevant title and cut out some of the extraneous explanations and such.  There are links to all the original sources throughout the article, so feel free to follow those if you want more in-depth commentary.

Linksys and Sipura adapter users – check your RTP Packet Size and Network Jitter Level

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Edit: Reader Christopher Woods notes in a comment that the following is also applicable to at least some models of Linksys phones, e.g. SPA942 and SPA962.

Do you use a Linksys or Sipura VoIP adapter? Do the people you are talking to ever complain about your voice breaking up, or missing or dropped syllables, or unexplained clicks or noise?

There is an obscure setting in Linksys/Sipura VoIP adapters that is usually set incorrectly for most applications, at least on a factory-fresh adapter. Go to the SIP tab and check the RTP Packet Size – for most users, it should be set to 0.020 rather than the factory preset of 0.030. If you are running a connection where latency is critical (say you have a cable or satellite box that requires a phone connection to “phone home”, or you are trying to use a FAX machine) then you may even wish to set this to 0.010, which further reduces latency, at the expense of using a bit more bandwidth. In any case, the default 0.030 is not the correct setting when using the most commonly-used codecs. For more discussion of this issue, see this thread at DSLreports.com, which discusses how the RTP Packet Size and Network Jitter Level settings can be tweaked to achieve lower latency, along with the tradeoffs.

Be aware that the RTP Packet Size setting is found under the SIP tab, and that setting is applied to all lines served through that adapter. However, the Network Jitter Level can be set individually for each line, under the Line tabs. One interesting comment in the above-mentioned thread is that if a provider forces you to use a low-bandwidth codec, decreasing the RTP Packet Size may increase the quality of your calls, but again at the expense of increasing bandwidth used.

Changing the RTP Packet Size on one VoIP adapter resolved a few strange issues with audio quality. In this case the adapter was being used to connect to an Asterisk box on the same local network, so bandwidth usage wasn’t an issue. We set the RTP Packet Size to 0.020 and the Network Jitter Level to low, and it made a noticeable difference in the reduction of strange noises and breakups heard by the party on the other end of the conversation. However, changing the Network Jitter Level isn’t as critical as changing the RTP Packet Size, and in fact, changing the Network Jitter Level may be entirely the wrong thing to do on certain types of connections (probably not a good idea if your adapter is connected through a Wireless ISP, for example).

I must thank Paul Timmins for being the first to point out that the Linksys PAP2 has a default packet size of 0.030, which is incompatible with the uLaw (G711u) codec (or at least in violation of the standard). With that lead, I then discovered other articles (including the discussion thread linked above) that said essentially the same thing. So check those adapter settings, folks!

(And by the way, this advice probably does apply to some other makes of VoIP adapters, and even some IP telephones, but since I don’t have any readily available to look at, I can’t say for sure. If you know of any others that need to have a similar setting tweaked, please feel free to add a comment to this post).