The attac:k

This week it happened to me, too. Somebody (with an IP address from Belize) managed to bruteforce the password of a SIP account on one of our internal Asterisk servers. I noticed it purely by accident. Usually i never look at the CLI of that machine (except when things fail, which is pretty rare). Fortunately, luck is with the stupid, so i noticed it just two hours after the first calls were made.

Calls were made to a single number in the British Indian Ocean Territory. The same number seems to be used by a few malicious Android applications, too. I have learned that the username “droid” and password “android” are not secure enough for a SIP account.

Immediately i redirected all calls from that account to one of my SIP phones, which started ringing very soon. Unfortunately there was no one at the other end when i answered the call. The other side (which claimed to be an Asterisk) was only sending silence (in g.711 RTP). So, our BRI lines were not abused for call termination but probably for a premium number scam. I can’t wait to get the invoice next month.

Things I have learned:

• Do not use a dialplan pattern like “_X.” in your context for external calls. Set up an extension for every country you need to call, e.g. “_0049.”. I had this on all of our ITSP machines, but of course not on our internal box (“The shoemaker got the worst shoes.”).
• Use good usernames and passwords. Try to avoid numeric usernames.
• Protect you accounts from being bruteforced by using something like fail2ban.
• When possible use a SIP domain instead of IP addresses. Make sure the domain cannot be guessed from the IP address!

The new setup:

Instead of setting up fail2ban on our Asterisk box, I decided to use kamailio in front of Asterisk. All authentication is done by kamailio and all calls are forwarded to Asterisk (even calls between local subscribers). The “antiflood” feature of kamailio keeps our fellow bruteforces outside.

The authentication between Asterisk and kamailio is done on a trusted IP basis. There are no SIP accounts on the Asterisk box. An very nice side effect is that you can now register the same SIP account on multiple SIP phones without any effort! Before I had to have one SIP account for each of my phones.

Kamailio’s multi-domain support is enabled. All automatic aliases have been removed. It is only listening to requests for the domains configured in the database. The SIP domain we use cannot be guessed from the IP address of the box. This feature alone would probably be sufficient to protect the accounts against bruteforcing!

Update:

I have just made some tests with the metasploit SIP options scanner and SIP enumerator. With kamailio’s multidomain support configured to a non-guessable domain it does not even respond to the SIP options message from the scanner. That way our fellow bruteforcers dont even recognize the kamailio server as a SIP server. And leave it alone.

It was about time to re-test up to date Asterisk versions for memory leakage. As these tests take a rather long time, i will update this post when the 1.4 and 1.6 versions have gone through the test.
The test procedure is the same as in my previous test, incoming SIP calls that send a ringing, wait a little and hang up (no call is ever connected, no RTP is flowing).

Asterisk 1.8.4-rc2

Since my last test, things have improved a lot! Asterisk does not consume 200m+ right from the start and it does not leak that much any more. However it still leaks a bit. After 32M+ calls i stopped the test.

Memory consumption before the test: virt 513m  16m 5940 S

Memory consumption after the test: virt 712m res 192m 6432 S

Asterisk 1.6.2.18-rc1

After pushing 37M+ calls Asterisk stopped processing calls because it ran out of RTP ports (it was using the default RTP port range from 10000 to 20000). “netstat -l -n -p  | grep asterisk -c” shows that 10009 ports are in use by asterisk. Calls fail with:

Memory consumption before the test: 476m  14m 5412 S

Memory consumption after the test: 742m 197m 5868 S

Asterisk 1.4.41-rc1

After pushing 10M+ calls Asterisk is processing calls very slowly. The machine has a high load because it is constantly swapping pages to and from disk. Retransmissions start to fail:

[Mar 30 10:58:50] WARNING[10667]: chan_sip.c:2070 retrans_pkt: Maximum retries exceeded on transmission a3621613-d54e-122e-43b7-001aa0314ced for seqno 10401673 (Critical Response) — See doc/sip-retransmit.txt.

Memory consumption after the test: 1472m 358m 1324 S

Asterisk 1.2.40

During the test Asterisk was complaining about “avoiding initial deadlocks” and “avoiding deadlocks” a lot, but it did not deadlock or go into the famous 100% cpu loop. It just works.

After processing 65M+ calls,  I decided to stop the test as i could not see an increasing memory consumption. The 1.2 branch of Asterisk keeps its place as my favourite branch (when it comes to stability).

Memory consumption before the test:  276m  11m 3464 S

Memory consumption after the test:  460m  79m 3768 S S