[asterisk-dev] Non-universalized log messages render security tools useless in Asterisk SVN-branch-1.8-r354348 or maybe other versions as well !!!

Pavel Troller patrol at sinus.cz
Sat Feb 11 12:46:35 CST 2012


Hi!

> Hello,
> 
> I could be wrong but I think there are two different log NOTICE messages
> displayed when there is a similar attack on Asterisk server. I am running
> version Asterisk SVN-branch-1.8-r354348 right now:
> 
> This line is logged in /var/log/asterisk/full when I am using *Eyebeam
> softphone* to make a peer-to-peer call to the Asterisk server:
> *NOTICE[10331] chan_sip.c: Sending fake auth rejection for device
> Eyebeam-Softphone<sip:99998 at 192.168.0.170>;tag=ac0d8c42*
> 
> This line is logged when I use another Asterisk server to send a calls
> using originate command: *originate sip/192.168.0.170/99998 extension
> s at test-context *
> *NOTICE[10331] chan_sip.c: Sending fake auth rejection for device
> "Anonymous" <sip:Anonymous at anonymous.invalid>;tag=as4a1b8317*

Why do you think that these are two different messages ? Both are the same,
but they display a different caller, because it was different in every call.
I think they are putting contents of the From: header to the message.
Eyebeam puts there the obvious Display name (probably not changed from the
default "Eyebeam-Softphone") and the SIP URI of the calling party (and 
because it's common that the caller is sending a proxy IP address in the
headers to indicate that it's its subscriber, it's logical that there is
the Asterisk address, not the device one). The second case uses a standard
 From: header format for anonymous calls.

> 
> There are two problems above:
>  1- Why are the NOTICE[10331] outputs different with calls coming from two
> different sources? Shouldn't this be the same? They are both
> un-authenticated attacks. This must be universalized for tools like
> Fail2ban to work.

They are not attacks. They are just call attempts. It's depending on your
site policy, whether you treat them as attacks or not.

> 2- Calling from Eyebeam, the log shows the IP of the Asterisk server itself
> (192.168.0.170 - what the heck) rather than the originating source IP
> address. So, this is really useless for Fail2ban. And it's even worse in
> the second line logged as you can see it's only *
> <sip:Anonymous at anonymous.invalid>. *I mean, where is the source IP address?

It's not intended to put the source IP address in this message. It's intended
to put the calling party ID there, and it has been explained, why it is, as
it is.

> 
> First, there shouldn't be two different types of log messages and secondly
> there MUST be a mention of the source (caller) IP address so it can be used
> for security purposes (banning, logging, etc...).

I'm still afraid that this message is not intended to indicate any security
alerts or attacks.

> 
> In both cases, allowguest=no, alwaysauthrej=yes, and nat=yes was set in
> sip.conf.
> 
> Unless these log messages are universalized and unless the source IP
> address is always logged, there is NO WAY to use Fail2ban or any other
> security tool effectively.

You can look into the CDRs. There should be an originator's IP address there.
And if you will find many failed call attempts from the same source IP, you
can activate Fail2ban or similar tool.

> 
> ***What I have quoted above is based on just Eyebeam, and another Asterisk
> server making calls and not SIPvicious or other hacking tools which I am
> afraid might generate even many more different log messages. Shouldn't all
> these messages be universalized for once and for good across all versions
> of Asterisk for security sake?

I understand your position, but I think there is still possible to use some
(maybe a bit more complicated) heuristic to detect attacks. Please remember
that VoIP/SIP is not as simple as for example ssh or telnet. SIP attacks may
use relatively rich set of techniques, which will never cause generation of
just one unified message in the "Hey! There's an attack!" style.

> 
> Cheers,
> Bruce

Regards,
  Pavel

> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-dev mailing list