Attacker IP is not available and can't be blocked

Configuring detection parameters, and optimizations
Post Reply
User avatar
CRM User
Posts: 172
Joined: Sun Nov 27, 2016 3:41 pm

Attacker IP is not available and can't be blocked

Post by CRM User » Sun Nov 27, 2016 6:06 pm

I see an attack report in my /var/log/asterisk/message file which mistakenly shows my server’s own IP address as the source of the attack. For example:

[2013-07-06 05:11:06] NOTICE[4106][C-0000001f] chan_sip.c: Failed to authenticate device 555<sip:555@a.b.c.d>;tag=e9a98a3

where a.b.c.d is the IP of my own Asterisk server. What is wrong?
Account for questions transferred from CRM system
User avatar
Telium Support
Posts: 227
Joined: Sun Nov 27, 2016 3:27 pm

Re: Attacker IP is not available and can't be blocked

Post by Telium Support » Sun Nov 27, 2016 6:55 pm

The attacker is providing a fake IP address (your server) as the source IP address in the SIP header, and this confuses Asterisk and results in the above error. SecAst is able to detect this type of attack and block the attacker at the network edge.

Digium is aware of the underlying issue and has resolved it in Asterisk version 10 and later, but older Asterisk versions will not receive updated code. (Some users have posted changes to the Asterisk C code but this is beyond most users to apply). In versions of Asterisk 10 through 12, you can enable the Asterisk security log as described here: https://wiki.asterisk.org/wiki/display/ ... ent+Logger) to view more accurate error messages; and you can tell SecAst to use the security log you specified (as described in the detailed installation guide).

However, there are still dangers remaining from this type of attack. In version 13 and later of Asterisk you should not be using a security log file, and instead set SecAst to use the AMI for notification of events. Setting SecAst to use the AMI not only increases the speed and accuracy of blocking attackers, it allows SecAst access to detailed caller behavior which can be used to identify fraud and hacking before any damage has been done.

If SecAst communicates with Asterisk through the AMI then numerous other protective measures are also enabled, including detection of stolen credentials, suspicious dialing patterns, etc.
Post Reply