[OpenSIPS-Users] Strange username registration
Brett Nemeroff
brett at nemeroff.com
Wed Apr 7 21:18:18 CEST 2010
Bah....
I think I spoke to quick the auth id does have the domain in it..
I think something is buggy here really It shouldn't be authenticating
like that. For a temp fix I'd just use the textopts mod to reject auth
ids with invalid characters. I'm interested in how this gets
resolved..
Maybe you can do something like
$avp(s:authname) = $(Au{uri.user}) + $ar
or this would be userful too:
$avp(s:username) = $(Au{uri.user})
Or something similar.. BTW, there seems to be some discrepancy in the
docs over "$ar"
Let us know what works. :)
-Brett
On Wed, Apr 7, 2010 at 2:04 PM, Douglas Lane <doug at wd.co.za> wrote:
> Hi Brett,
>
> Auth is definately being done on the INVITE as well, but once again,
> this succeeds even though it has another @domain part.
>
> I know it all looks right, the problem is, OpenSIPS is even storing the
> location data as username [at] domain [dot] com [at] domain [dot] com.
> And I can't rely on using the Auth ID for billing as a lot of other
> correctly configured clients are using
>
> Digest username="doug",realm="domain.com".
>
> I guess I'd have to put the two vars together, $au and $ar (or $ad) and
> then if $au contains a domain name, just to strip it off or something?
>
> As requested, trace follows:
>
> IP: 1.2.3.4 is the client
> IP: 5.6.7.8 is the OpenSIPS proxy
>
> T 1.2.3.4:62689 -> 5.6.7.8:5060 [AP]
> INVITE sip:18005556667 at domain.com SIP/2.0.
> Via: SIP/2.0/TCP
> 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport.
> Max-Forwards: 70.
> Contact: <sip:doug%40domain.com at 1.2.3.4:62689;transport=TCP>.
> To: <sip:18005556667 at domain.com>.
> From: <sip:doug%40domain.com at domain.com>;tag=1b164627.
> Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU..
> CSeq: 1 INVITE.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO.
> Content-Type: application/sdp.
> User-Agent: X-Lite Beta release 4.0 v3 stamp 55153.
> Content-Length: 188.
> .
> v=0.
> o=- 7 2 IN IP4 192.168.0.113.
> s=CounterPath X-Lite 4.0.
> c=IN IP4 1.2.3.4.
> t=0 0.
> m=audio 58262 RTP/AVP 0 8 3 101.
> a=sendrecv.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
>
> #
> T 5.6.7.8:5060 -> 1.2.3.4:62689 [AP]
> SIP/2.0 100 Trying.
> Via: SIP/2.0/TCP
> 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport=62689.
> To: <sip:18005556667 at domain.com>.
> From: <sip:doug%40domain.com at domain.com>;tag=1b164627.
> Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU..
> CSeq: 1 INVITE.
> Server: OpenSIPS (1.6.1-tls (x86_64/linux)).
> Content-Length: 0.
> .
>
> #
> T 5.6.7.8:5060 -> 1.2.3.4:62689 [AP]
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/TCP
> 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport=62689.
> To: <sip:18005556667 at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
> From: <sip:doug%40domain.com at domain.com>;tag=1b164627.
> Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU..
> CSeq: 1 INVITE.
> Proxy-Authenticate: Digest realm="domain.com",
> nonce="4bbcd61d00000a1268c6ccae9b032af3204121ac0623b648".
> Server: OpenSIPS (1.6.1-tls (x86_64/linux)).
> Content-Length: 0.
> .
>
> ###
> T 1.2.3.4:62689 -> 5.6.7.8:5060 [AP]
> ACK sip:18005556667 at domain.com SIP/2.0.
> Via: SIP/2.0/TCP
> 1.2.3.4:24022;branch=z9hG4bK-d8754z-552d4b70ed34a43e-1---d8754z-;rport.
> Max-Forwards: 70.
> To: <sip:18005556667 at domain.com>;tag=cdff758d742c799b04c91123cd1608d5.fdd1.
> From: <sip:doug%40domain.com at domain.com>;tag=1b164627.
> Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU..
> CSeq: 1 ACK.
> Content-Length: 0.
> .
>
> ##
> T 1.2.3.4:62689 -> 5.6.7.8:5060 [AP]
> INVITE sip:18005556667 at domain.com SIP/2.0.
> Via: SIP/2.0/TCP
> 1.2.3.4:24022;branch=z9hG4bK-d8754z-a5ba7a6914ca1e45-1---d8754z-;rport.
> Max-Forwards: 70.
> Contact: <sip:doug%40domain.com at 1.2.3.4:62689;transport=TCP>.
> To: <sip:18005556667 at domain.com>.
> From: <sip:doug%40domain.com at domain.com>;tag=1b164627.
> Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU..
> CSeq: 2 INVITE.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO.
> Content-Type: application/sdp.
> Proxy-Authorization: Digest
> username="doug at domain.com",realm="domain.com",nonce="4bbcd61d00000a1268c6ccae9b032af3204121ac0623b648",uri="sip:18005556667 at domain.com",response="2a7d0482c71d07180af31548fc344904",algorithm=MD5.
> User-Agent: X-Lite Beta release 4.0 v3 stamp 55153.
> Content-Length: 188.
> .
> v=0.
> o=- 7 2 IN IP4 192.168.0.113.
> s=CounterPath X-Lite 4.0.
> c=IN IP4 1.2.3.4.
> t=0 0.
> m=audio 58262 RTP/AVP 0 8 3 101.
> a=sendrecv.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
>
> ##
> T 5.6.7.8:5060 -> 1.2.3.4:62689 [AP]
> SIP/2.0 100 Trying.
> Via: SIP/2.0/TCP
> 1.2.3.4:24022;branch=z9hG4bK-d8754z-a5ba7a6914ca1e45-1---d8754z-;rport=62689.
> To: <sip:18005556667 at domain.com>.
> From: <sip:doug%40domain.com at domain.com>;tag=1b164627.
> Call-ID: YzdjMGRjNDNhODNiMWE1MTMzYjY0ZDJkMDNmNWE5MGU..
> CSeq: 2 INVITE.
> Server: OpenSIPS (1.6.1-tls (x86_64/linux)).
> Content-Length: 0.
>
> Brett Nemeroff wrote:
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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