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

Tzafrir Cohen tzafrir.cohen at xorcom.com
Tue Nov 17 04:46:12 CST 2009


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.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir



More information about the asterisk-dev mailing list