asterisk users - Mar 2012 - how to show used "wrong password"

hi all,

have asterisk set up in combination with fail2ban.
all works as expected only there is 1 extension that is trying to 
register with a wrong password causing fail2ban to block the IP address, 
normally that is ok behaviour but i have several extensions on that IP 
address.

someone has once setup this extension as a test, but it seems to be 
impossible to find where it was installed (probably a softphone) and its 
a bit far away for me to go check it out.

since there is no way to stop the troubling extension i figured i might 
as well let it connect by setting the wrongly used password as correct, 
at least in that case the other extensions won't be blocked and i can 
try to call that extension myself.


anyway to see which "wrong password" is being used?


much obliged,

Randall

On Tuesday 13 March 2012, Randall wrote:
> hi all,
> 
> have asterisk set up in combination with fail2ban.
> all works as expected only there is 1 extension that is trying to
> register with a wrong password causing fail2ban to block the IP address,
> normally that is ok behaviour but i have several extensions on that IP
> address.
> ..... snip .....
> anyway to see which "wrong password" is being used?
tcpflow.

(And don't underestimate the power of simply disconnecting things until it 
works .....  last thing you disconnected was the faulty one.)


-- 
AJS

Answers come *after* questions.

> Ouch.  That isn't going to be so easy to spot, then!  You would have to
guess
> a bunch of likely passwords, fake up a challenge with some known nonce, and
> compare the response against those you would expect with each of the
various
> possible passwords.  (You've already got the Source Code to do all
this, of
> course.)
> 
> You'll have to try the selective unplugging method instead .....
There may be a way to do this, even in the face of the nonce-and-hash
security system.

As I understand it:  when a system (re)registers with a good
password, what you'll typically see is:

-  A registration request from the client (with the client's ID
   in the SIP parameters)

-  A response from Asterisk, saying something on the order of
   "Stale authentication.  Try again.  Here's a new nonce for
you."

-  Another registration request from the same client, specifying
   the newly-issued nonce, and having a hash based on that nonce and
   the shared secret.

-  An "OK" response from Asterisk.

When a system (re)registers, and has the wrong password/secret,
the exchange will be different.

-  A registration request from the client (with the client's ID
   in the SIP parameters)

-  A response from Asterisk, saying something on the order of
   "Stale authentication.  Try again.  Here's a new nonce for
you."

-  Another registration request from the same client, specifying
   the newly-issued nonce, and having a hash based on that nonce and
   the shared secret.

-  A response from Asterisk, rejecting the second registration request
   with something like a "bad digest" error.

So, if you examine all of the SIP protocol exchanges taking place,
you should see a whole bunch of successful four-way handshakes (from
clients that have the correct secrets), and an occasional four-way
handshake failure (from the one client that has the wrong password in
its configuration).

You won't be able to tell what password the client is actually trying
to use - that's the whole point of the nonce-and-hash approach -
but you'll be able to identify its client name, and (unless the
far end is using a NAT or proxy) its IP address.

To pin down the actual location of the client, you'll either have
to go there, or have someone at the remote site do some investigation
and (possibly) packet tracing on the LAN.

Or, I suppose one could simply use Asterisk to try to phone the
device or softphone in question, at whatever address it called in
from, and ask whoever answers the phone to disable it!