Hacking Asterisk


Over several years I discover succesfull hacking-attemps on my Asterisk. The machine, provider, IP, Debian and Asterisk-Version has been changed, the working hacking-attemps are keeping.

I´ts every time the same process.


[2012-06-14 09:05:27] NOTICE[27426] chan_sip.c: Registration from ‘"378749064"sip:378749064@’ failed for ‘’ - No matching peer found
[2012-06-14 09:05:30] NOTICE[27426] chan_sip.c: Registration from '"2038492213"sip:2038492213@
failed for ‘’ - No matching peer found

Until here a non-working hack.

Yesterday this works:
[2012-06-13 13:14:26] NOTICE[6631] chan_sip.c: Registration from ‘"3390288695"sip:3390288695@’ failed for ‘’ - No matching peer found

Today this works:
[2012-06-14 10:39:41] NOTICE[27426] chan_sip.c: Registration from ‘"502715279"sip:502715279@’ failed for ‘’ - No matching peer found

There is only this one single line in the log, verbosity is set to 6.

After this I cannot reach my phone-numbers, because the provider has registered it to the IP

They don´t try to make any phone calls, they do nothing. Since about 5 years with dozen of IPs.

There isn´t much to do after this, just adding the IP to denyhosts, after 10 Minutes I can reach my phone numbers again and the registration of the hacker drops. Then, after same months, or a few hours later, the same thing repeats with a different IP. It´s not necessary to change any passwort. Itself I change all Passworts (SIP, Account, machine) it doesn´t change anything or prevents the next attack.

Does anybody know how this works and how I can prevent this?

I´m using currently this Asterisk:

Connected to Asterisk 1.4.42 currently running on server1 (pid = 27398) (The problem is version independent)

In my sip.conf is alwaysauthreject = yes

Because I´m using changing IPs to register I can´t block too much IPs.


(Sorry for my bad english, I hope you understand what i wrote)

Not sure if your version supports this but you should look into using dynamic_exclude_static option. There are also some other options which might be useful - viewtopic.php?t=80281 .You could also stop using the default port 5060 and switch to something less revealing. Finally think about using nat=yes as the default, this way asterisk will disregard the Contact: header from attackers.

I don’t think that you’ve addressed the real issue, which is that he is claiming that a REGISTER is being honoured even though it has failed authentication.

I’m not comfortable about using an already poorly understood option in a non-standard way. The sort of attack for which this applies should be rare, as most people will only take REGISTER from their local network, and they should already have firewall rules to suppress spoofing of local addresses as the source of incoming packet.

I think they spoof the Register, so my provider use their IP and no long mine. There might be something wrong with the register.

NAT is alredy set to yes, changing Ports does not help because the do a portscan if 5060 not work.


The trace shows attempts to register on your Asterisk, not to register on the provider. If they are replacing your registration on the provide, it is the provider that is getting hacked, even if you pick up the tab.

I assume the reason for suggesting nat=yes was that some hackers may register from a spoofed IP address but with their real address in the contact address. That shouldn’t work for your internal phones, as you should be restricting them to you internal network and blocking attempts to spoof your internal addresses the firewall.

The reason you probably already have nat=yes, is that a lot of service providers seem to think that applies when Asterisk is inside the NAT, whereas it is actually intended to be used in the rarer case, when Asterisk is outside the NAT, but the SIP device is inside and the Contact headers are neither being pre-translated (which is what Asterisk prefers to do) nor being translated by the router.


I couldn´t understand why I don´t need to change any passwort, the register on my provider will be gone away about 10 Minuten later than I enter the IP in my deny.hosts. It´s not necessary to change the SIP or Login-Passworts at my provider.

There must be a problem at the register-function.