[OpenSIPS-Users] Strange username registration

Brett Nemeroff brett at nemeroff.com
Wed Apr 7 20:38:10 CEST 2010 

Well something is up...
look at the trace, the auth username in the REGISTER is *right*..

that $Au is being set from the FROM I suspect (which is WRONG).

Almost as if authentication is not being performed on the INVITE at
all. Can you send a trace of the INVITE?

If you arn't authenticating the INVITEs I'd expect this behavior with
an improperly set client.
-Brett




On Wed, Apr 7, 2010 at 1:34 PM, Douglas Lane <doug at wd.co.za> wrote:
> Hi Brett,
>
> For billing , I use an AVP which is then sent to FreeRADIUS for
> normalization by CDRTool.
>
> The billing_party avp is constructed like so:
>
> $avp(s:billing_party)=$Au;
>
> And now I've just read the following:
>
> $Au - username for accounting purposes. It's a selective pseudo variable
> (inherited from acc module). It returns $au if exits or From username
> otherwise.
>
> Hmmm I'm wondering if its using the From header?
>
> As for authorization, I'm sure it should be failing - I actually thought
> I had stuffed up my multi-domain support, or done something wrong, but
> definitely domains are working correctly. As far as I'm aware, the
> username section in the digest should only hold the username and not the
> realm / domain name in it.
>
> In any case, the fact that the auth id contains the username and the
> realm is something I need to reject as its not a truly legal
> registration / authorization. I'm assuming auth_db module problem does a
> sanity check on the username section of the digest when authorizing, and
> if it has a @ portion in it, probably strips it out so that it can
> register successfully. Hmmm thats actually something I should test - see
> if I change the auth id to something like username [at] bob [dot] com
> and then have domain [dot] com in the domain part and see if that registers.
>
> Thanks
> Doug
>
>
> Brett Nemeroff wrote:
>> Ok, well something is wrong there..
>>
>> I suspect that you are probably using different headers for billing
>> and authentication..
>>
>> The auth should really be failing...
>>
>> Actually, relooking at your REGISTER message, the auth id is fine,
>> which is why the REGISTER succeeds.. However, I bet you arn't logging
>> the auth id for billing.. I can't remember how CDRTool logs that bit
>> of the top of my head.
>>
>> On Wed, Apr 7, 2010 at 1:15 PM, Douglas Lane <doug at wd.co.za> wrote:
>>
>>> Hi Brett,
>>>
>>> I agree to the rejecting part, as then client can phone support. The
>>> problem is, if I don't make a plan to do some fancy searches to reject
>>> the message, OpenSIPS happily auths the request correctly, and the user
>>> can make and receive calls.
>>>
>>> Thats what has had me a panic as www_authorize returns success on this,
>>> so does proxy_authorize. The issue is when the billing server (CDRTool)
>>> does its rating, it sees username [at] domain [dot] com [at] domain
>>> [dot] com as the billing party, instead of username [at] domain [dot]
>>> com and hey presto - FREE calls. (well default rated anyway)
>>>
>>> Anyway, was looking through the textopt functions, and search() seems
>>> the right tool to use, but I don't see it has any options to narrow down
>>> to like the WWW header as well as the To header of the message - any
>>> suggestions?
>>>
>>> Thanks
>>> Doug
>>>
>>>
>>> Brett Nemeroff wrote:
>>>
>>>> There's only so much you can do for user error... either correct it
>>>> silently, allowing them to work, even though they did it wrong (you
>>>> could automatically remove the extra domain param), or reject it.
>>>>
>>>> I suppose a third method would be to redirect them to a feature server
>>>> that could actually announce to them what they did wrong "I'm sorry,
>>>> but you seem to have configured your SIP client improperly".
>>>>
>>>> I personally would reject this kind of failure.. which I think would
>>>> be the default behavior if you didn't do anything since the username
>>>> param wouldn't match anything valid.
>>>>
>>>> -Brett
>>>>
>>>>
>>>>
>>>> On Wed, Apr 7, 2010 at 1:02 PM, Douglas Lane <doug at wd.co.za> wrote:
>>>>
>>>>
>>>>> Hi Brett,
>>>>>
>>>>> I know the problem is with the auth id, and I was using Xlite as an
>>>>> example. Unfortunately when we hand the SIP accounts out, we don't have
>>>>> control over the client setting up the end device (such as an
>>>>> audiocodes, siemens, linksys or alike). So I was looking for a way I
>>>>> could reject it due to invalid characters.
>>>>>
>>>>> I'll look into textopts and move forward from there - thanks for all the
>>>>> assistance.
>>>>>
>>>>> Thanks
>>>>> Doug
>>>>>
>>>>>
>>>>> Brett Nemeroff wrote:
>>>>>
>>>>>
>>>>>> You could probably use textops to search the auth username for the "@"
>>>>>> character and simply reject with a code like "401","Invalid Characters
>>>>>> in Auth Id"
>>>>>>
>>>>>> With clients like xlite, it'll probably display in the screen when
>>>>>> attempting to register.
>>>>>>
>>>>>> However, this really seems like the auth id on the client is just
>>>>>> setup improperly and should be an easy fix:
>>>>>>
>>>>>> Seems like in XLite you have:
>>>>>> Auth Id: username at domain.com
>>>>>>
>>>>>> when it should be
>>>>>> Auth Id: username
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 7, 2010 at 12:33 AM, Douglas Lane <doug at wd.co.za> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Iñaki Baz Castillo wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 2010/4/6 Douglas Lane <doug at wd.co.za>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> My clients register as username [at] domain [dot] com, which works
>>>>>>>>> perfectly. CDRTool then checks the billing party portion, and bills
>>>>>>>>> accordingly.
>>>>>>>>>
>>>>>>>>> Recently, I've noticed the odd client registering as username [at]
>>>>>>>>> domain [dot] com [at] domain [dot] com. This causes a problem in the
>>>>>>>>> billing server, as it tries to find subscriber username [at] domain
>>>>>>>>> [dot] com [at] domain [dot] com instead of username [at] domain [dot] com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Which exact REGISTER field you mean? From URI? To URI? Contact URI?
>>>>>>>> credentials username? credentials realm?
>>>>>>>>
>>>>>>>> Could you please paste an example of such REGISTER?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Hi Inaki,
>>>>>>>
>>>>>>> As requested, please find below REGISTER request:
>>>>>>>
>>>>>>> IP 1.2.3.4 is the client
>>>>>>> IP 5.6.7.8 is the server
>>>>>>> domain.com is the domain/realm used to register
>>>>>>>
>>>>>>> T 1.2.3.4:58889 -> 5.6.7.8:5060 [AP]
>>>>>>> REGISTER sip:domain.com SIP/2.0.
>>>>>>> Via: SIP/2.0/TCP
>>>>>>> 192.168.0.236:10990;branch=z9hG4bK-d8754z-375adf06ebab9063-1---d8754z-;rport.
>>>>>>> Max-Forwards: 70.
>>>>>>> Contact:
>>>>>>> <sip:doug%40domain.com at 1.2.3.4;rinstance=0051b76a880b6325;transport=TCP>.
>>>>>>> To: <sip:doug%40domain.com at domain.com>.
>>>>>>> From: <sip:doug%40domain.com at domain.com>;tag=7adae37b.
>>>>>>> Call-ID: ZDlmN2JmMmY4ZjdmYTU2MmI5YzAyYjZmMTE4ODBjY2Q..
>>>>>>> CSeq: 2 REGISTER.
>>>>>>> Expires: 3600.
>>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>>>> SUBSCRIBE, INFO.
>>>>>>> User-Agent: X-Lite Beta release 4.0 v3 stamp 55153.
>>>>>>> Authorization: Digest
>>>>>>> username="doug at domain.com",realm="domain.com",nonce="4bbc186000007a99f8b3ca45e77563c7b19f6ea461817c3e",uri="sip:domain.com",response="96bf9f599ddf3057c5bc48faf9a1d923",algorithm=MD5.
>>>>>>> Content-Length: 0.
>>>>>>> .
>>>>>>>
>>>>>>> #
>>>>>>> T 5.6.7.8:5060 -> 1.2.3.4:58889 [AP]
>>>>>>> SIP/2.0 100 Trying.
>>>>>>> Via: SIP/2.0/TCP
>>>>>>> 192.168.0.236:10990;branch=z9hG4bK-d8754z-375adf06ebab9063-1---d8754z-;rport=58889;received=1.2.3.4.
>>>>>>> To: <sip:doug%40domain.com at domain.com>.
>>>>>>> From: <sip:doug%40domain.com at domain.com>;tag=7adae37b.
>>>>>>> Call-ID: ZDlmN2JmMmY4ZjdmYTU2MmI5YzAyYjZmMTE4ODBjY2Q..
>>>>>>> CSeq: 2 REGISTER.
>>>>>>> Server: OpenSIPS (1.6.1-tls (x86_64/linux)).
>>>>>>> Content-Length: 0.
>>>>>>> .
>>>>>>>
>>>>>>> #
>>>>>>> T 5.6.7.8:5060 -> 1.2.3.4:58889 [AP]
>>>>>>> SIP/2.0 200 OK.
>>>>>>> Via: SIP/2.0/TCP
>>>>>>> 192.168.0.236:10990;branch=z9hG4bK-d8754z-375adf06ebab9063-1---d8754z-;rport=58889;received=1.2.3.4.
>>>>>>> To:
>>>>>>> <sip:doug%40domain.com at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.5bf0.
>>>>>>> From: <sip:doug%40domain.com at domain.com>;tag=7adae37b.
>>>>>>> Call-ID: ZDlmN2JmMmY4ZjdmYTU2MmI5YzAyYjZmMTE4ODBjY2Q..
>>>>>>> CSeq: 2 REGISTER.
>>>>>>> Contact:
>>>>>>> <sip:doug%40domain.com at 1.2.3.4;rinstance=0051b76a880b6325;transport=TCP>;expires=3600;received="sip:1.2.3.4:58889;transport=TCP".
>>>>>>> Server: OpenSIPS (1.6.1-tls (x86_64/linux)).
>>>>>>> Content-Length: 0.
>>>>>>>
>>>>>>>
>>>>>>> Invites are also similar just with the From header being set - so I
>>>>>>> assume if we can fix this, then I can apply the same type of fix to
>>>>>>> register requests.
>>>>>>>
>>>>>>> Either I need to be able to reject the above messages with invalid
>>>>>>> formatted headers, or I need t rewrite things (which I'm not always
>>>>>>> comfortable doing within opensips)
>>>>>>>
>>>>>>> I appreciate the assistance.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Doug
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at lists.opensips.org
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

More information about the Users mailing list