[Serusers] Avoiding caller ID spoofing....

[Greger V. Teigre]

Oh, I see :-) Sorry, I misunderstood. Well, I think many providers handle 
this by turning off the web server in the UA and only allow config updates 
through remote download of the config file.
If you want to do it server side, the uac module would definitely be the 
right place to start.
g-)
----- Original Message ----- 
From: "sip" <sip at arcdiv.com>
To: "Greger V. Teigre" <greger at teigre.com>; <serusers at lists.iptel.org>
Sent: Monday, October 24, 2005 02:15 PM
Subject: Re: [Serusers] Avoiding caller ID spoofing....


> The problem with check_to and check_from are that they don't quite do what 
> I
> want.
>
> For instance, if Bob Smith with the number 1-101-991-9298
> (11019919298 at my.server.com) puts, in his display name section "Steve 
> Geldorf"
> then when he calls someone, they're liable to see the name "Steve Geldorf" 
> and
> say "Oh... Steve... he's a great guy... I'll answer the phone!" only to be
> greeted by the grating and unpleasant voice of Bob Smith whom they've been
> trying to avoid for weeks.
>
> Alternatively, if they enter in to their display name
> "16612121115 at another.server.com" then THAT name will show up on the 
> 'caller
> ID' incoming call, yet again fooling a good number of people (it's 
> generally
> pretty easy to fool people) into thinking that they're receiving a call 
> from
> someone else -- perhaps someone they trust.
>
> The trick would be to either remove the display name field altogether from 
> the
> From: message and just put the number... or to replace it with a 
> "last_name,
> first_name" lookup from the database to ensure that, at least for local 
> users,
> there's accountability... and for remote users dialing in (yes, we allow
> that), that their valid information is displayed (by valid, I mean that 
> their
> basic username at domain is displayed).
>
> I've seen this done in many a provider, and I was just wondering if 
> they're
> simply using Asterisk to get around this security hole, or if they've 
> written
> their own modules to handle it, or if there's a logical, elegant solution 
> I've
> yet to see.
>
> N.
>
>
>
> On Mon, 24 Oct 2005 07:40:16 +0200, Greger V. Teigre wrote
>> You use check_to and check_from.
>>
>> As for From modification: Some UAs use From and To for matching
>> messages in the same dialog. These are primarily older ones and
>> allthough the general recommendation is "don't do it", I'm not sure
>> how many of these there are out there now. Anyone?
>>
>> UAC solves this by changing back and forth.
>> g-)
>>
>> ----- Original Message ----- 
>> From: "sip" <sip at arcdiv.com>
>> To: <serusers at lists.iptel.org>
>> Sent: Friday, October 21, 2005 03:43 PM
>> Subject: [Serusers] Avoiding caller ID spoofing....
>>
>> >I think I asked this question before, but I honestly can't remember 
>> >(been
>> >one
>> > of those weeks).
>> >
>> > How can I avoid someone spoofing caller ID by just putting in fake info
>> > into
>> > their Display Name field in their UA client?  I'd like to be able to
>> > replace
>> > the display name with one of my choosing (preferably based on some 
>> > rules
>> > about
>> > the caller's ID... i.e. if the caller is a user on our system, replace
>> > his/her
>> > display name with the last name, first name from the DB subscriber 
>> > info.
>> > If
>> > the caller is from a different system, remove the display name 
>> > completely
>> > and
>> > just pass the sip info so that at least a valid identification is 
>> > seen).
>> >
>> > This involves the dreaded modification of the From: header (although it
>> > shouldn't break RFC because it doesn't actually involve modifying the 
>> > URI.
>> >
>> > Is there a reasonable way to do this or does this call for some more
>> > module
>> > hacking (maybe taking bits from the UAC module and rewriting it to 
>> > accept
>> > an
>> > avp or some such) ?
>> >
>> >
>> > N.
>> >
>> > _______________________________________________
>> > Serusers mailing list
>> > serusers at lists.iptel.org
>> > http://lists.iptel.org/mailman/listinfo/serusers
>> >
>
>