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

[Atis Lezdins]

On Tue, Nov 17, 2009 at 11:59 AM, Tzafrir Cohen
<tzafrir.cohen at xorcom.com> wrote:
> On Mon, Nov 16, 2009 at 09:55:33AM +0100, Kai Hoerner 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".
>>
>> > but the sample configuration could have an activated setting.
>> >
>>
>> IMO the sip.conf.sample should contain an activated "allowguest=no"
>>
>> > While this would not work with released versions, it might make things better with future releases.
>> Agreed.
>
> I still don't agree. I believe that focusing on guests here misses the
> target. The problem is not guest users. The problem is unintended relays
> from one trunk to another. If you unintentionally allow authenticated
> incomming SIP calls to make outgoing paid calls[1].
>
> The basic tool Asterisk has for authorization[2] is dialplan contexts.

I completely agree with this, however Dialplans might get so complex
that it's hard to follow each possible step. Especially for new users
who just added something, they even don't know that there's still in
demo or whatever.

I'm just brainstorming about possible solutions that are simple to
user. Regarding TLS - good point.

Here's another idea.

Add option "paid" (or choose better naming) for sample trunks, and
"allowpaid" for sample users. Also some dialplan function to toggle
status of call. That way it will act as safety switch, users or trunks
without "allowpaid" won't be able to dial "paid" trunks.

>
>
> So, consider a sample context such as:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> [incoming]
> ; A separate context for incoming calls:
> ; We don't trust those callers, and thus only allow them the things they
> ; really need:
> include => demo
> ; Make sure this context will not allow outgoing calls through a paid
> ; trunk.
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> We must remember that the sample dialplan is mostly documentation. There
> are those who use it, but most people just write dialplan from scratch.

I disagree. Most people with asterisk experience write from scratch.
Newbies will just poke around samples and make them working mostly the
way they need to. They might leave the "demo" includes inside, etc.

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