Tag: asterisk

Monitoring Asterisk via SNMP (with OSS_SNMP)

Over on the company blog, we just announced that we committed a complete Asterisk MIB implementation to OSS_SNMP in addition to a proof of concept Asterisk wallboard to NOCtools which includes active channels, uptime, version information and more.

Full details are on the company post but here’s a snippet of how easy it is to query Asterisk over SNMP:

 $host = new \OSS_SNMP\SNMP( $asteriskIP, $community );
 echo "Asterisk version: " . $host->useAsterisk()->version();
 echo "Active calls: " . $host->useAsterisk()->callsActive();
 echo "Calls processed: " . $host->useAsterisk()->callsProcessed();

And here’s a screenshot of the proof of concept Asterisk wallboard:

[NOCtools Asterisk Wallboard]
NOCtools – Asterisk Wallboard

Asterisk with SS7 via Wanpipe, Dahdi and libss7 – with ISUP SAM support

A howto on installing Asterisk with SS7 supported via libss7 on Sangoma hardware along with support for ISUP SAM messages.

After much head banging in bringing up an SS7 link with SAM support, I am documented what worked here.

Firstly, what is SAM support? One end of an SS7 link initialises a new call by sending an Initial Address Message (IAM). All SS7 software stacks support this and usually it’s enough. One case where it’s not enough is when one wants to address a phone number with more than the E.164 standard max length of 16  (usually to pass additional information tacked on the start, end of or even replacing an A or B number). In this scenario, SS7 uses a Subsequent Address Message (SAM) to send the additional digits. Most / all mainstream Asterisk SS7 software stacks do not support this.

The platform and software used is as follows:

  • Ubuntu 10.04 LTS standard CLI install;
  • dahdi-linux-complete-2.4.0 from the archives (direct link);
  • a patched version of libss7 supporting SAM via SVN (see below);
  • a patched version of chan-dahdi via SVN (see below);
  • Asterisk 1.6.0.28 from the archives (direct link);
  • Asterisk Addons 1.6.0.6 from the archives (direct link);
  • Sangoma Wanpipe 3.5.24 (direct link).

Yes, I know some of the above are obsolete. Unfortunately it’s what’s required for everything to play nicely together. And, guess what, it works!

Before You Start

Ensure you have all the necessary packages for building the packages:

apt-get install build-essential libnewt-dev subversion    \
   libsqlite3-dev libsnmp-dev bison libtool flex          \
   autoconf2.13 libmysqlclient-dev

You can assume the working directory is /usr/local/src in the following.

Installing dahdi-linux-complete

Download and extract dahdi-linux-complete into /usr/local/src. Then, in the same directory, create some symbolic links:

ln -s dahdi-linux-complete-2.4.0+2.4.0/linux dahdi-linux
ln -s dahdi-linux-complete-2.4.0+2.4.0/tools dahdi-tools

Now build dahdi-linux:

cd dahdi-linux
make
make install

Now move onto dahdi-tools:

cd dahdi-tools
./configure
make menuconfig # (and select tools or accept defaults)
make
make install
make config

Installing libss7

There is a patched version of Digium’s libss7 referred to as Attila’s libss7 available via SVN. Download and install it:

svn co https://observer.router.hu/repos_pub/libss7/trunk alibss7
cd alibss7
make
make install

Installing Asterisk

Download and extract the Asterisk 1.6.0.28 package reference above.

cd asterisk-1.6.0.28

Now this next bit is very important and easy to miss – you also need a patched version of chan_dahdi.c that is compatible with the patched version of libss7. This is also available from SVN:

svn co https://observer.router.hu/repos_pub/chan_dahdi/trunk achan_dahdi

Then copy it to your Asterisk source:

cp achan_dahdi/chan_dahdi.c asterisk-1.6.0.28/channels/chan_dahdi.c

Now continue with the Asterisk installation:

./configure
make menuconfig
make
make install
make samples
make config

Install Asterisk Addons (optional)

Download and unpack the above referenced add ons package and build and install:

cd asterisk-addons-1.6.0.6
./configure
make menuconfig
make
make install
make samples

Sangoma Wanpipe

I’m using one of Sangoma’s E1 / T1 interface cards and so I need Wanpipe also. I’m using version 3.5.24 and preceed as follows after unpacking:

cd wanpipe-3.5.24./Setup install

During the install, follow these prompts:

  • select option 2 => Asterisk/Dahdi Support;
  • enter path /usr/local/src/dahdi-linux (for Zaptel path prompt);
  • select defaults for everything else;
  • you DO want to install start-up scripts;
  • you DO to configure wanpipe devices for DAHDI;
  • you DO want to generate /etc/asterisk/chan_dahdi.conf and:
    • select E1 / T1 as appropriate;
    • select line framing and encoding;
    • choose clock source;
    • select Zaptel/Dahdi – PRI CPE as signalling;
    • select National ISDN 2 as switch type;
    • do not enable hardware DTMF detection;
    • use all channels;
    • select dial plan context as appropriate;
  • and continue for other ports as necessary;
  • finally, choose Save cfg: Stop Asterisk & Wanpipe now
  • you would like wanrouter to start on system boot;
  • and you would like to execute ‘dahdi_cfg’ each time wanrouter starts.

Configuration Steps

We now need to set various options in Wanpipe, Dahdi and Asterisk for SS7 as it’s PRI/ISDN by default.

Edit all /etc/wanpipe/wanpipeX.conf files as necessary and change:

 TDMV_DCHAN              = 16

to

TDMV_DCHAN              = 0

Now edit /etc/dahdi/system.conf and change (for example):

span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-31
echocanceller=mg2,1-15,17-31
hardhdlc=16

to

span=1,1,0,ccs,hdb3,crc4
bchan=2-31
echocanceller=mg2,2-31
mtp2=1

which of course assumes signalling is on channel 1. If you have voice only links, you might need something like:

span=1,0,0,ccs,hdb3,crc4bchan=1-31
echocanceller=mg2,2-31

Lastly, we need to configure Asterisk. Replace lines such as:

;Sangoma A102 port 1 [slot:4 bus:5 span:1]
switchtype=national
context=from-pstn
group=0
echocancel=yes
signalling=pri_cpe
channel =>1-15,17-31

with an appropriate configuration. Mine follows below with some edits and some important notes at the end:

;Sangoma A102 port 1 [slot:4 bus:5 span:1]
switchtype=national
context=from-pstn
group=0
echocancel=yes

signaling=ss7
ss7type=itu
ss7_called_nai=dynamic
ss7_calling_nai=dynamic
ss7_internationalprefix=00
ss7_nationalprefix=0
ss7_subscriberprefix=
ss7_unknownprefix=
linkset=1
pointcode=1
adjpointcode=2
defaultdpc=3
networkindicator=national_spare
cicbeginswith=2
channel=2-31
sigchan=1
  • Set pointcode, adjpointcode and defaultdpc as appropriate;
  • set networkindicator as appropriate and ensure it matches the other end (you can see what you’re being sent and what you’re sending via ss7 debug;
  • cicsbeginwith is normally 1 but the telco on my end are starting at 2 – this was groping in the dark diagnostics and issues such as no audio, CICs not in service when both sides claim they are, etc may point to misaligned CICs;
  • make sure you have configured from-pstn or the appropriate context in yourextensions.conf.

Confirming Your Link Is Up

Now start wanrouter (/etc/init.d/wanrouter start); dahdi (/etc/init.d/dahdi start); and Asterisk (/etc/init.d/asterisk start). You should see your link come up via logs available with the dmesg command. Launch the Asterisk console and check the status of your links:

ast-deg1-1*CLI> ss7 show cics 1
  CIC   DPC  DAHDI        STATE   BLOCKING
    2    3      2         Idle
    3    3      3         Idle
    4    3      4         Idle
    5    3      5         Idle
    6    3      6         Idle
    7    3      7         Idle
    8    3      8         Idle
    9    3      9         Idle
   10    3     10         Idle
   11    3     11         Idle
   12    3     12         Idle
   13    3     13         Idle
   14    3     14         Idle
   15    3     15         Idle
   16    3     16         Idle
   17    3     17         Idle
   18    3     18         Idle
   19    3     19         Idle
   20    3     20         Idle
   21    3     21         Idle
   22    3     22         Idle
   23    3     23         Idle
   24    3     24         Idle
   25    3     25         Idle
   26    3     26         Idle
   27    3     27         Idle
   28    3     28         Idle
   29    3     29         Idle
   30    3     30         Idle
   31    3     31         Idle

You should now be okay to make test calls.

Do You Need Professional Support / Consultancy?

While I will try to respond to comments and questions on this blog, I don’t have the time to provide one on one assistance pro-bono. Professional consultancy on Asterisk and SS7 is available worldwide through my company, Open Solutions with contact details here.

References

For posterity, I have added Domjan Attila patched libss7 and chan_dahdi to GitHub:

Asterisk SIP Brute Force Attacks on the Rise

See my article on the company blog for a discussion on this, and a how to on using Fail2ban to help stop these attacks.

SIP Brute Force Attacks on the Increase

On our own Asterisk PBX server for our office and on some customer boxes with open SIP ports, we have seen a dramatic rise in brute force SIP attacks.

They all follow a very common pattern – just over 41,000 login attempts on common extensions such as 200, 201, 202, etc. We were even asked to provide some consultancy about two weeks ago for a company using an Asterisk PBX who saw strange (irregular) calls to African countries.

They were one example of such a brute force attack succeeding because of a common mistake:

  1. an open SIP port with:
  2. common extensions with:
  3. a bad password.

(1) is often unavoidable. (2) can be mitigated by not using the predictable three of four digit extension as the username. (3) is inexcusable. We’ve even seen entries such as extension 201, username 201, password 201. The password should always be a random string mixing alphanumeric characters. A good recipe for generating these passwords is to use openssl as follows:

openssl rand -base64 12

Users should never be allowed to choose their own and dictionary words should not be chosen. The brute force attack tried >41k common passwords.

Preventing or Mitigating These Attacks

You can mitigate against these attacks by putting external SIP users into dedicated contexts which limit the kinds of calls they can make (internal only, local and national, etc); ask for a PIN for international calls; limit time and cost; etc.

However, the above might be a lot of work when simply blocking users after a number of failed attempts can be much easier and more effective. Fail2ban is a tool which can scan log files like /var/log/asterisk/full and firewall IP addresses that makes too many failed authentication attempts.

See VoIP-Info.org for generic instructions or below for a quick recipe to get it running on Debian Lenny.

Quick Install for Fail2ban with Asterisk SIP on Debian Lenny

  1. apt-get install fail2ban
  2. Create a file called /etc/fail2ban/filter.d/asterisk.conf with the following (thanks to this page):
  3. Put the following in /etc/fail2ban/jail.local:
  4. Edit /etc/asterisk/logger.conf such that the date format under [general]reads: 
    dateformat=%F %T
  5. Also in /etc/asterisk/logger.conf, ensure full logging is enable with a line such as the following under [logfiles]: 
    full => notice,warning,error,debug,verbose
  6. Resart / reload Asterisk
  7. Start Fail2ban: /etc/init.d/fail2ban startand check:
    • Fail2ban’s log at /etc/log/fail2ban.logfor: 
      INFO   Jail 'asterisk-iptables' started
    • The output of iptables --list -vfor something like: 
      Chain fail2ban-ASTERISK (1 references)
 pkts bytes target     prot opt in     out     source               destination
  227 28683 RETURN     all  --  any    any     anywhere             anywhere

You should now receive emails (assuming you replaced the example addresses above with your own and your MTA is correctly configured) when Fail2ban starts or stops and when a host is blocked.