[asterisk-dev] Security Request for discussion: Should sip.conf allowguest=yes be the default

[Atis Lezdins]

On Tue, Nov 17, 2009 at 12:46 PM, Tzafrir Cohen
<tzafrir.cohen at xorcom.com> wrote:
> On Tue, Nov 17, 2009 at 12:56:02AM +0200, Atis Lezdins wrote:
>> On Mon, Nov 16, 2009 at 10:55 AM, Kai Hoerner <kai at ciphron.de> wrote:
>> > Hi Olle and others,
>> >
>> > Olle E. Johansson schrieb:
>> >>> If we allowguest=yes, unauthenticated calls will end up in the default
>> >>> context _as well_ but it's not guaranteed only unauthenticated calls go
>> >>> there.
>> >>>
>> >>> For that reason i suggest another, more clear context name: "unconfigured"
>> >>>
>> >> For trunk, we can separate the default context, that is inherited to unconfigured devices from the context that is used for calls where we can not match anyone. Like "guestcontext". That would make things very clear.
>> >
>> > Agreed.
>> >
>> >> Guestcontext can default to the default context, but the sample configuration could have an activated setting.
>> >
>> > This would impose the exact same behaviour for beginners:
>> > if they start adding things like dialout in the default context, the
>> > world can use it.
>> >
>> > i suggest we change the extensions.conf sample too.
>> > there should be a [demo] context, an [unconfigured] and a [default]
>> > context. Both the [unconfigured] and [default] contexts include [demo].
>> > in [demo] there would be a comment telling beginners to not use [demo]
>> > for messing around. (with the note that it is included for
>> > unauthenticated calls)
>> >
>> > that way, if they add anything like dialout in [default], the
>> > [unconfigured] context would still be "secure".
>> >
>>
>> I have an alternative solution in my mind.
>>
>> How about every peer/user/friend is given an "authenticated" property
>> if it has set password or specific IP address. It might very well be
>> set also on peer options with:
>>
>> [inbound]
>> allow=192.168.0.0/255.255.255.0
>> authenticated=yes
>>
>> Then we introduce channel variable "authenticated" which is initially
>> inherited from originating peer, but can be altered in dialplan. For
>> example:
>>
>> context inbound {
>>   _X. => {
>>     Set(CHANNEL(authenticated)=1);
>>     Dial(SIP/whatever,30)
>>   }
>> }
>>
>> So, Dial App could warn (or in next major releases - deny) dialing any
>> other peer if caller is not authenticated and tries to Dial some other
>> device.
>
> What does that buy you?
>
> That magic "authenticated" variable has to be explicitly set. Which
> means it will be wrongly set. For instance (in your example)
>
>  [guestuser]
>  context = inbound
>
> Others will just blantly ignore that ugly warning. We have enough of
> them already. There are enough legitimate circimstances where this
> warning can be safely ignored and thus a google search about the warning
> will provide mean hits that suggest "ignore", or suggest simple ways to
> work around it.
>
> This is a type of solution that tries to make life more difficult and
> will simply get worked around. And it still does nothing about
> inintended relay of authenticated users.
>

The idea was to create simple per-peer or entry-point switch. A simple
work-around would be to authenticate users in their first entry
context, which would make deployer to think where is that, and is it
really secure.

However I believe my previous reply with fresh idea deals with this better.

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835