News items for tag asterisk - Koos van den Hout

I guess some kind of bug in the sipscanner at 193.55.30.2 got triggered by my firewalling the IP so asterisk does not 'see' the traffic. The incoming traffic is now up to 70 kilobyte/second. It is all ignored, but that is still a fair chunk of incoming bandwidth being eaten.
Update 2010-05-24 I let asterisk answer the requests for a few packets which slowed down the incoming traffic again to something reasonable. And this morning the traffic was gone which suggests somebody read my report to the security contact.

Just got in and noticed that the adsl link was particularly s-l-o-w. A tcpdump showed that there was a SIP brute-force attack going on, and with the wondershaper settings this was filling the ADSL upstream to the maximum. In the asterisk logs:

[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"607589258"<sip:607589258@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"2737039014"<sip:2737039014@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"hello"<sip:hello@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"ranger"<sip:ranger@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"shadow"<sip:shadow@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"baseball"<sip:baseball@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"donald"<sip:donald@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"harley"<sip:harley@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"hockey"<sip:hockey@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 14:49:08] NOTICE[11238] chan_sip.c: Registration from '"letmein"<sip:letmein@82.95.196.202>' failed for '193.55.30.2' - No matching peer found

[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found
[May 22 17:46:24] NOTICE[11238] chan_sip.c: Registration from '"active" <sip:active@82.95.196.202>' failed for '193.55.30.2' - No matching peer found

For a total of 284970 attempts. Then I updated the firewall to block this. And send out an abuse report to the ISP.

With tshark the attacks look like:

Session Initiation Protocol
    Request-Line: REGISTER sip:82.95.196.202 SIP/2.0
        Method: REGISTER
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 127.0.0.1:5091;branch=z9hG4bK-1064873464;rport
            Transport: UDP
            Sent-by Address: 127.0.0.1
            Sent-by port: 5091
            Branch: z9hG4bK-1064873464
            RPort: rport
        Content-Length: 0
        From: "instruct" <sip:instruct@82.95.196.202>
            SIP Display info: "instruct" 
            SIP from address: sip:instruct@82.95.196.202
        Accept: application/sdp
        User-Agent: friendly-scanner
        To: "instruct" <sip:instruct@82.95.196.202>
            SIP Display info: "instruct" 
            SIP to address: sip:instruct@82.95.196.202
        Contact: sip:123@1.1.1.1
            Contact Binding: sip:123@1.1.1.1
                URI: sip:123@1.1.1.1\r
                    SIP contact address: sip:123@1.1.1.1\r
        CSeq: 1 REGISTER
            Sequence Number: 1
            Method: REGISTER
        Call-ID: 3859238695
        Max-Forwards: 70

Lots of SIP attacks lately (stuff which goes on even when I'm more interested in IPv6). First near-standard SIP registration attacks from Amazon EC2, also seen by one of my asterisk installs:

[Apr 10 16:40:30] NOTICE[6890] chan_sip.c: Registration from '"02"<sip:02@xxx.xxx.xxx.xxx>' failed for '184.73.12.46' - No matching peer found
[Apr 10 16:40:30] NOTICE[6890] chan_sip.c: Registration from '"03"<sip:03@xxx.xxx.xxx.xxx>' failed for '184.73.12.46' - No matching peer found

My system wasn't the only one attacked, I saw reports everywhere, including: Amazon EC2 SIP Brute Force Attacks on Rise - VoIP Tech Chat , Amazon EC2 Flood Attacks from the Cloud - VoIP Users Conference, SIP Attacks From Amazon EC2 Going Unaddressed - SlashDot IT and SIP Brute Force Attack Originating From Amazon EC2 Hosts - Stuart Sheldon.
I changed /etc/asterisk/sip.conf to include alwaysauthreject = yes which makes SIP account enumeration impossible: the attacker can't see the difference between 'account does not exist' or 'password not valid'. This violates the SIP rfc but makes attacks a lot harder.
A lot of the articles above give one answer: Amazon EC2 network abuse does not care. Which immediately degrades the 'standing' of their network. You don't care about attacks originating from your network means lots of people won't care about anything originating from your network.

SIP scanning is active again. Sandro Gauci came with a link to And the scanning just keeps on coming I checked the logs on 2 asterisk servers for recent break-in attempts and presto... from different IPs, but the pattern I saw before in trying to find insecure SIP servers:

[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"3776548202"<sip:3776548202@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"100"<sip:100@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"101"<sip:101@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:20] NOTICE[6890] chan_sip.c: Registration from '"102"<sip:102@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found


[Feb 21 10:09:28] NOTICE[6890] chan_sip.c: Registration from '"952"<sip:952@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:28] NOTICE[6890] chan_sip.c: Registration from '"953"<sip:953@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found
[Feb 21 10:09:28] NOTICE[6890] chan_sip.c: Registration from '"954"<sip:954@xxx.yyy.zzz.xxx>' failed for '96.57.107.3' - No matching peer found

No damage and no costs. The other server shows attempts to use the sip guest environment again:

[Feb 13 05:27:08] NOTICE[5710] chan_sip.c: Call from '' to extension '90442075821233' rejected because extension not found.
[Feb 13 05:27:27] NOTICE[5710] chan_sip.c: Call from '' to extension '9442078493108' rejected because extension not found.
[Feb 13 05:27:38] NOTICE[5710] chan_sip.c: Call from '' to extension '0442076311117' rejected because extension not found.
[Feb 13 05:27:40] NOTICE[5710] chan_sip.c: Call from '' to extension '0011447850019298' rejected because extension not found.
[Feb 13 05:27:42] NOTICE[5710] chan_sip.c: Call from '' to extension '00011441628481177' rejected because extension not found.
[Feb 13 05:27:44] NOTICE[5710] chan_sip.c: Call from '' to extension '0001441383417547' rejected because extension not found.
[Feb 13 05:27:56] NOTICE[5710] chan_sip.c: Call from '' to extension '0000447956581268' rejected because extension not found.
[Feb 13 05:27:57] NOTICE[5710] chan_sip.c: Call from '' to extension '00011441628481177' rejected because extension not found.
[Feb 13 05:28:08] NOTICE[5710] chan_sip.c: Call from '' to extension '900442075964032' rejected because extension not found.
[Feb 13 05:28:08] NOTICE[5710] chan_sip.c: Call from '' to extension '9011441252625280' rejected because extension not found.
[Feb 13 05:28:09] NOTICE[5710] chan_sip.c: Call from '' to extension '1442074370973' rejected because extension not found.
[Feb 13 05:28:10] NOTICE[5710] chan_sip.c: Call from '' to extension '9442078493108' rejected because extension not found.
[Feb 13 05:28:10] NOTICE[5710] chan_sip.c: Call from '' to extension '00000447889904142' rejected because extension not found.
[Feb 13 05:28:10] NOTICE[5710] chan_sip.c: Call from '' to extension '0001441383417547' rejected because extension not found.

This time with somewhat random looking phone numbers in the UK which aren't well-known to google.

My very own security incident involving China (in a way):

[Jan 28 09:55:45] NOTICE[7593] chan_sip.c: Call from '' to extension '00442078420960' rejected because extension not found.

An attempt (within the public sip context) to call a number in England. The Chinese embassy in London. All attempts failed since the asterisk which logged that has no idea how to call the big phone network. Information from a lecture on SIP security suggests that this kind of attempts is a sort of ddos attack on a phone number.

The asterisk setup with bristuff-patched zap and the qozap driver failed bigtime: a call to the internal phone failed and diverted to voicemail within 2 seconds. Back to a working mISDN version. But I can't unload the mISDN drivers correctly so it took a few reboots to get things right again.

Outgoing calls without echo are nice, but I also need incoming calls to work. According to the kernel messages I should have working echo cancellation:

[  132.157748] mISDN_dsp: Audio DSP  Rev. 1.29 (debug=0x0) EchoCancellor MG2 dtmfthreshold(100)
[  132.157753] mISDN_dsp: DSP clocks every 80 samples. This equals 1 jiffies.

Time to start testing stuff on a testserver so I don't have to reboot the home server greenblatt so often.

One good effect from the change in isdn driver: telephony sounds a lot better. This is probably because zaptel automatically enables echo cancelling:

Sep 11 20:34:38 greenblatt kernel: [ 2954.439478] Zapata Telephony Interface Registered on major 196
Sep 11 20:34:38 greenblatt kernel: [ 2954.439483] Zaptel Version: 1.4.10
Sep 11 20:34:38 greenblatt kernel: [ 2954.439484] Zaptel Echo Canceller: MG2

Today I decided to put some time in trying to use a different driver for using the openvox B200P card in the ubuntu installed asterisk in home server greenblatt. mISDN has a few stability issues in this setup (ubuntu 8.04 LTS amd64, asterisk 1.4.17 from ubuntu source recompiled for misdn support) where I can't unload the driver (instant kernel warning message and module system wedged) and sometimes after a long while the internal channel got confused and rejected calls, needing a restart of Asterisk.
So I tried the other route: the qozap driver with bristuff patches which comes with ubuntu as package zaptel-source. Configuring this driver was a bit of a puzzle. Step one: don't load ztdummy because that will confuse the channel ordering. TE / NT choice is done by the module parameter ports for the module, the bitmapped value of the TE / NT configuration. In my case I created /etc/modprobe.d/zaptel with:

 
options qozap ports=2

So the second port is switched to NT mode, which matches the jumper setup. The working samples are documented at ZaptelBRI - voip-info.org.
The qozap driver sort of works on the TE side (the side facing the phone company). Diving deeper into docs from openvox showed that the openvox cards need a slightly changed qozap driver source from http://downloads.openvox.cn/pub/drivers/bristuff/patches/. It helps to find that the version of bristuffed in Ubuntu 8.04 is probably 0.4.0.
The current state is working up to a level: I can dial numbers from the internal isdn phone to the external isdn line and I can accept calls, but trying to get dialtone from asterisk results in:

    -- Extension 's' in context 'internte' from 'xxxxxxx' does not exist.  Rejecting call on channel 0/2, span 2

which looks like the problem mentioned in Re: [Asterisk-Users] zaphfc problem: overlapdial don't work after update bristuff but that change (and a complete recompile of my asterisk package) did not do the work. Browsing the source of chan_zap shows a lot of places where it can decide to switch to 's'.

Some websearching suggests my headaches with mISDN could be solved by using the qozap driver which I get when I compile zaptel-sources. Just a bit of configuring asterisk differently... time to find some time for that somewhere.

Yesterday evening I installed a 6-tape DDS-3 changer in the homeserver greenblatt and activated the latest ubuntu kernel updates. The tape changer works great but the mISDN drivers got confused because the 'loading drivers' stage at boot loads them without the right parameters which results in confused drivers (hardware not found) which I can't unload because that causes a kernel panic. Workaround: remove the mISDN drivers, reboot the system, reinstall the mISDN drivers and let /etc/init.d/mISDN load the drivers in the correct way.

Met de correcte frequenties voor de eerste en tweede kiestoon heb ik nu een Asterisk simulator Nederlandse telefooncentrale (voor 1995) geschreven. Dat heeft me wat over de beperkingen van Asterisk en vooral de functie WaitExten geleerd. Maar hij doet het!

After finding out the hopefully correct frequency for the old Dutch first and second dialtone in the Netherlands I tried to implement a simulator for making calls in the style of an old Dutch phone exchange (although I can't simulate the clicks and background noises.. yet). This made some downsides of the Asterisk extensions.conf 'programming' language show. But, after some grumbling and testing and testing I think I found the right way.

De tweede kiestoon is gevonden! Dankzij het museum voor communicatie en een vrijwilliger daar.

De eerste kiestoon bestond vroeger uit een combinatie van 150 Hz en 450 Hz.
De 2e kiestoon was 450 Hz bij electromechanische systemen en 425 Hz bij computerbestuurde centrales.
Bij het vervallen van de tweede kiestoon op 10-10-1995 bestonden geen electromechanische centrales meer en is de frequentie van de tweede kiestoon gebruikt voor de kiestoon.

Dus als ik dat wil nabouwen in Asterisk krijg ik iets in indications.conf als:

[nl-old]
description = Netherlands before 10-10-1995
ringcadence = 1000,4000
dial = 150+450
; second dial tone after area code
seconddial = 450
busy = 450/500,0/500
ring = 450/1000,0/4000
congestion = 450/250,0/250
info = 950/330,1400/330,1800/330,0/1000
stutter = 450/500,0/50

en moet ik Playtones(seconddial) gebruiken.
Update : En nu heb ik 2 andere meningen dat de eerste kiestoon alleen 150 Hz was.

I did it: we now use Asterisk as home 'pbx'. I bought an OpenVox dual ISDN card via Novavox. Great company, Novavox: when it would take about a week to deliver the card they got in touch to make sure I could wait that long.

The choice for dual ISDN was because I still want to keep the outside line via KPN isdn: we are also using budgetphone but it was quite easy to find a phone number that was unreachable via budgetphone but reachable via KPN. And I want to keep using an ISDN set. So one port of the isdn card is configured as 'TE' card (terminal equipment) connected to KPN and one is configured as 'NT' card (network terminator) connected to the ISDN set. Asterisk does all the heavy lifting: outgoing call routing depending on number called and time of day. Incoming call routing, reacting to callerid and advanced answering machine.

After the attack I saw on an asterisk server which was most likely scanning for valid user accounts to use in international dialing I am wondering if I can 'play' with users who try to abuse an asterisk setup.

For the hcc!pc gg netwerkgroep demo asterisk I scripted a sort of teaser for users trying to dial abroad:

[internationaltrick]
; not really dial an international number: play an interesting 'wrong number'

exten => _00XXXXXXXXXX.,1,Wait(5)
exten => _00XXXXXXXXXX.,n,Goto(wrongnumber,s,1)

The delay is to add confusion to how many digits it accepts (although someone using 'early dialing' could see when asterisk reports back it has seen enough digits). What the wrongnumber routine does is play a random 'wrong number' recording taken from Telephone world - International sounds & recordings so someone who tries this who is actually listening to call progress might think he is on to something and spend hours trying to find the right way.

Ok, the imap storage for asterisk voicemail works like the proverbial charm. I needed some work on the home dialplan and setup before I could test it, but I was able to leave a message to the home mailbox, seeing it stored in the voicemail imap box and retrieve and delete it using a telephone connected to the ISDN port accessing the VoicemailMain application. The access number for voicemail is now set to 0140-1233 to (sort of) stay in line with the Dutch numbering plan. There is no customer-service at 0140-1200 planned...

Ok, got that bit fixed too: asterisk uses imap as storage backend for voicemail. In modules.conf:

noload => app_voicemail_odbc.so
noload => app_voicemail.so
load => app_voicemail_imap.so

This is with the ubuntu package recompiled to use misdn, so the selection of voicemail storage is a question of which .so to load. In voicemail.conf :

[general]
imapserver=koos.idefix.net
imapfolder=INBOX.calls

[default]
9911 => 19999,House mailbox,,,Tz=european|imapuser=housemail|imappassword=S3cr1t

Now voicemail is saved only on the imap-server, so I can view it with Thunderbird. Or use the asterisk voicemail application to retrieve and delete it. That bit is not tested yet. After all the testing of drivers including heavy torture it's now time to set up a dialplan for the home pbx. Rule 1 of playing with the phones at home is that normal dialing still has to work so my wife can call the numbers without having to dial '0' for an outside line or other tricks, and that the phone in the living room rings when a call comes in. So I have to set up a 'number plan' which allows for special things but also makes all normal numbers work as they should. Solution: I use the 0140 area code, which is reserved (in the Netherlands) for test-numbers for the telecom provider. I am my own telecom provider so I can divert 0140 and do stuff with it, like provide voicemail or internal dialing.

IMAP can do great things, but more advanced things always seem half-documented and lots of searching. I tried to set up shared mailboxes. At home I want a shared mailbox for the voicemails from Asterisk so Mirjam and I can both check the imap inbox, listen to messages and delete them when they are not interesting anymore. Ideally I'd like asterisk to use IMAP as backend storage so we can still access the voicemail over the phone and deleting the voicemail via the phone menu is the same as deleting it from the imap server with a mail client (that's almost something like unified communications!). The next nicest option is to have the voicemails mailed to the shared voicemail mailbox. Still working on getting that fixed. Anyway, setting up the shared mailbox in courier is a bit vague. Not all documentation agrees, but finally the right answer is in /usr/share/doc/courier-base/README.sharedfolders.txt.gz how to set up a server shared mailbox via the shared mailbox index file set as IMAP_SHAREDINDEXFILE in /etc/courier/imapd. A lot of fiddling with rights was needed: by default shared mailbox users can't do anything with it. A light sprinkling of chmod 770 and chgrp voicemail fixed that. The last bit is that the imap server needs to know which other users have full access, using maildiracl to set this up. All now works and we can both read and delete mails. The shared box shows up as #shared.voicemail.calls next to the normal Inbox and Inbox.Sent.

Next needed was shared mailboxes at work so all members of the system group can see the mailboxes where cronjobs from all systems dump their stuff. I never got the same 'system shared mailbox' to work as at home so I decided to go for the 'filesystem shared mailbox' which is set up by creating a file shared-maildirs in your imap directory. That file just lists an alias and a base directory for the mailboxes to access. Rights on the shared boxes still need to be very open which is not my idea of a safe system. But that works, so everybody can see the 'postmaster', 'ups' and other boxes where system mail ends up and delete it when it is not an error message. Those shared boxes show up as shared.systeemgroep.ups and shared.systeemgroep.postmaster in Thunderbird and mutt (haven't checked other clients yet).

Met al het testen van ISDN opties zou het wel handig zijn om een ISDN toestel met display te hebben. Iemand toevallig eentje in de aanbieding voor niet al te veel? Of ruilen voor een Sun Sparcstation 20 of Ultra-1.

Sunday evening I finally had time to look at the new home server greenblatt and I tried to get the sitecom dc-105 isdn card in NT (network termination) mode connected to the fixed line (outside) isdn port of the fritz!box 7170. It took a bit of work as a lot of documentation about the mISDN drivers mentions NT mode but the needed cable isn't very well documented. I finally found it, chapter 2.2 of the PBX4Linux manual. By itself the crossed cable did not work (and the fritz!box is good at diagnosing problems with SIP dialing, but just goes 'meh' when ISDN dialing fails). I didn't need the fancy solution with power, but I had to look for a while for termination resistors. I remembered the sitecom dc-105 isdn card had some jumpers near the ISDN port. Those are indeed 100 ohm ISDN termination resistors. Nowhere to be found in any of the manuals of the dc-105 online.

After setting those jumpers it all started working. At first the dialtone sounded weird but that was caused by

[general]
country=us

in indications.conf. Changing this to

[general]
country=nl

made it suddenly sound a lot more familiar: KPN style. Now the test calls are running again via the modem connected to the fritz!box.
Conclusion: the jumpers on the sitecom dc-105 are isdn termination jumpers and can help to make an NT mode cross cable work.