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

[Atis Lezdins]

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.

This is just general conclusions about how users edit their dialplans.
Initially they take examples, modify them a lot, jump forward and
back, and might actually not have clear overview of their dialplan.
This should provide an initial point of protection.

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