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

[Alec Davis]

At Tilghman's request.

We need to agree to change the sip.conf default from allowguest=yes to
allowguest=no
and extensions.conf to have a warning in the [default] section that sip.conf
may have allowguest=yes or nothing which will default of yes.

Reference mantis bugs;
<https://issues.asterisk.org/view.php?id=15101>
https://issues.asterisk.org/view.php?id=15101 SIP allowguest defaults to yes
with 'make samples'
<https://issues.asterisk.org/view.php?id=16226>
https://issues.asterisk.org/view.php?id=16226 1.4.26.3 security issue -
Chinese IPs somehow are making calls without authentication

There are many installations out there where newbies are playing in the
[default] context in their dialplan, getting things working, then opening
port 5060 in their firewall without understanding what they've just done.

Initially I thought it was great that we allow any SIP phone to connect to
asterisk, with no configuration required at the astrisk end, how wrong I
was.

Alec Davis

[Olle E. Johansson]

Post by Alec Davis
At Tilghman's request.
We need to agree to change the sip.conf default from allowguest=yes to allowguest=no

There are many installations that not use peer/user matching at all and require allowguest to be yes. Not all installations are PBXs. We can change, as you propose, the sip.conf sample but *not* the default behaviour in the source.

Post by Alec Davis
and extensions.conf to have a warning in the [default] section that sip.conf may have allowguest=yes or nothing which will default of yes.

Here we need to explain that anything here is exposed to anyone if you have allowguest=yes in sip.conf.

/O

[Kaloyan Kovachev]

Post by Olle E. Johansson

Post by Alec Davis
At Tilghman's request.
We need to agree to change the sip.conf default from allowguest=yes to allowguest=no

There are many installations that not use peer/user matching at all and

require allowguest to be yes. Not all installations are PBXs. We can change,
as you propose, the sip.conf sample but *not* the default behaviour in the source.

Post by Olle E. Johansson

Post by Alec Davis
and extensions.conf to have a warning in the [default] section that

sip.conf may have allowguest=yes or nothing which will default of yes.

Post by Olle E. Johansson
Here we need to explain that anything here is exposed to anyone if you have

allowguest=yes in sip.conf.

Why not change the default context in sip.conf (and iax.conf for guest on make
samples) to [unauthenticated_call] instead of just default, which will be more
prominent for the admin of what is happening?

Post by Olle E. Johansson
/O
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Jared Smith]

Post by Olle E. Johansson
Here we need to explain that anything here is exposed to anyone if you have allowguest=yes in sip.conf.

Although the majority of the malicious activity I'm seeing is related to
the SIP protocol, we should probably make the same warnings for the IAX
channel driver as well.

[Alec Davis]

allowguest=yes as default is IMO a breach of AST-2008-003 which states
"A fix has been added which checks for the option 'allowguest' to be enabled
before determining that authentication is not required"

please refer.http://downloads.asterisk.org/pub/security/AST-2008-003.pdf

Sorry I missed that on my original posting.

Alec Davis
_____

From: asterisk-dev-***@lists.digium.com
[mailto:asterisk-dev-***@lists.digium.com] On Behalf Of Alec Davis
Sent: Thursday, 12 November 2009 8:34 p.m.
To: asterisk-***@lists.digium.com
Subject: [asterisk-dev] Security Request for discussion: Should sip.conf
allowguest=yes be the default


At Tilghman's request.

We need to agree to change the sip.conf default from allowguest=yes to
allowguest=no
and extensions.conf to have a warning in the [default] section that sip.conf
may have allowguest=yes or nothing which will default of yes.

Reference mantis bugs;
<https://issues.asterisk.org/view.php?id=15101>
https://issues.asterisk.org/view.php?id=15101 SIP allowguest defaults to yes
with 'make samples'
<https://issues.asterisk.org/view.php?id=16226>
https://issues.asterisk.org/view.php?id=16226 1.4.26.3 security issue -
Chinese IPs somehow are making calls without authentication

There are many installations out there where newbies are playing in the
[default] context in their dialplan, getting things working, then opening
port 5060 in their firewall without understanding what they've just done.

Initially I thought it was great that we allow any SIP phone to connect to
asterisk, with no configuration required at the astrisk end, how wrong I
was.

Alec Davis

[Olle E. Johansson]

I've changed the sip.conf.sample in trunk to say the following.

Like Tzafrir, I don't want to change the channel setting in the code which might break current installations.

If enough people are behind it, we can change sip.conf.sample to have allowguest=no as a default setting
without the semicolon in front.

Feedback?

/O

Modified: trunk/configs/sip.conf.sample
URL: http://svnview.digium.com/svn/asterisk/trunk/configs/sip.conf.sample?view=diff&rev=229606&r1=229605&r2=229606
==============================================================================
--- trunk/configs/sip.conf.sample (original)
+++ trunk/configs/sip.conf.sample Thu Nov 12 04:22:30 2009
@@ -1,5 +1,17 @@
;
; SIP Configuration example for Asterisk
+;
+; Note: Please read the security documentation for Asterisk in order to
+; understand the risks of installing Asterisk with the sample
+; configuration. If your Asterisk is installed on a public
+; IP address connected to the Internet, you will want to learn
+; about the various security settings BEFORE you start
+; Asterisk.
+; Specially note the following settings:
+; - Allowguest (default enabled)
+; - Permit/deny - IP address filters
+; - Contactpermit/contactdeny - IP address filters for registrations
+; - Context - Which set of services you offer various users
;
; SIP dial strings
;-----------------------------------------------------------
@@ -87,6 +99,10 @@
[general]
context=default ; Default context for incoming calls
;allowguest=no ; Allow or reject guest calls (default is yes)
+ ; If your Asterisk is connected to the Internet
+ ; and you have allowguest=yes
+ ; you want to check which services you offer everyone
+ ; out there, by enabling them in the default context (see below).
;match_auth_username=yes ; if available, match user entry using the
; 'username' field from the authentication line
; instead of the From: field.

[Michiel van Baak]

Post by Olle E. Johansson
I've changed the sip.conf.sample in trunk to say the following.
Like Tzafrir, I don't want to change the channel setting in the code which might break current installations.
If enough people are behind it, we can change sip.conf.sample to have allowguest=no as a default setting
without the semicolon in front.
Feedback?

In my opinion this change is enough.
Changing the default is a no-no in my opinion. This will break too many
systems out there.

If people see the warning in sip.conf and decide to ignore it, it's
their responsibility. Same as with every other piece of software that
has settings and documentation like this. (bind being recursive by
default for example, or sshd that allows root password based logins by
default)

[Kai Hoerner]

Post by Michiel van Baak

Post by Olle E. Johansson
I've changed the sip.conf.sample in trunk to say the following.

In my opinion this change is enough.
Changing the default is a no-no in my opinion. This will break too many
systems out there.

Changing the default in code will break existing configs that rely on
the defaults. (e.g. not have explicitly set "allowguest=yes")

Changing the default in the sample config will break nobody's config and
nobody's setup.

Post by Michiel van Baak
If people see the warning in sip.conf and decide to ignore it, it's
their responsibility. Same as with every other piece of software that
has settings and documentation like this. (bind being recursive by
default for example, or sshd that allows root password based logins by
default)

I don't see the argument here. "Because the others do.."

Is setting senseless defaults now considered best practise or something?
Helping beginners with meaningful defaults is generally a good thing, i
thought.
Who really wants to open his box to the world can do it, but it should
_really_ not be the default.

To shorten up discussion, i know the default context is secured by default.
But beginners tend to start using it, because of its tempting name.

Changing the default in configuration (not code) will break no one's
config but will help beginners start with a more secure sample config.
Just my 2 cents.


Best regards,

Kaii

[Michiel van Baak]

Post by Kai Hoerner

Post by Michiel van Baak

Post by Olle E. Johansson
I've changed the sip.conf.sample in trunk to say the following.

In my opinion this change is enough.
Changing the default is a no-no in my opinion. This will break too many
systems out there.

Changing the default in code will break existing configs that rely on
the defaults. (e.g. not have explicitly set "allowguest=yes")
Changing the default in the sample config will break nobody's config and
nobody's setup.

Agreed.

Post by Kai Hoerner

Post by Michiel van Baak
If people see the warning in sip.conf and decide to ignore it, it's
their responsibility. Same as with every other piece of software that
has settings and documentation like this. (bind being recursive by
default for example, or sshd that allows root password based logins by
default)

I don't see the argument here. "Because the others do.."
Is setting senseless defaults now considered best practise or something?
Helping beginners with meaningful defaults is generally a good thing, i
thought.
Who really wants to open his box to the world can do it, but it should
_really_ not be the default.

I really fail to see how we are setting senseless defaults.
even with this enabled the sample config does not allow anything
unsecure.

Post by Kai Hoerner
To shorten up discussion, i know the default context is secured by default.
But beginners tend to start using it, because of its tempting name.

Beginners should read documentation first, dont you think ?

Post by Kai Hoerner
Changing the default in configuration (not code) will break no one's
config but will help beginners start with a more secure sample config.
Just my 2 cents.

[Kai Hoerner]

Hi Olle,

IMO this will help a lot of beginners to configure their asterisk "the
right way".
I really appreciate this and can fully understand why changing the
default behaviour is too risky.

I feel very comfortable with the new security note right at the
beginning of the file.

But I would feel even more comfortable with changing the value of
"allowguest" to "no" in the default config.
For beginners, this would have nearly the same effect as changing the
default behaviour.

I suggest an additional comment to that option, again mentioning the
risk of having allowguest=yes.
That way, if any beginner removes the line from the config (or comments
it out), he should be aware of what he's doing.

The current comment below "allowguest" tries to inform the reader about
the risks of having this setting.
But i think it doesn't get that clear to most beginners. There should be
a sentence like:

"ATTENTION: If your Asterisk is connected to the internet and you have
allowguest=yes, everybody out there may use your default context without
authentication. In that case you want to double check which services you
offer to the world."

I've seen some expensive phone bills, that could have been easily
avoided by such a simple, clear and direct information.


Thx,
Kaii

Post by Olle E. Johansson
I've changed the sip.conf.sample in trunk to say the following.
Like Tzafrir, I don't want to change the channel setting in the code which might break current installations.
If enough people are behind it, we can change sip.conf.sample to have allowguest=no as a default setting
without the semicolon in front.
Feedback?
/O
Modified: trunk/configs/sip.conf.sample
URL: http://svnview.digium.com/svn/asterisk/trunk/configs/sip.conf.sample?view=diff&rev=229606&r1=229605&r2=229606
==============================================================================
--- trunk/configs/sip.conf.sample (original)
+++ trunk/configs/sip.conf.sample Thu Nov 12 04:22:30 2009
@@ -1,5 +1,17 @@
;
; SIP Configuration example for Asterisk
+;
+; Note: Please read the security documentation for Asterisk in order to
+; understand the risks of installing Asterisk with the sample
+; configuration. If your Asterisk is installed on a public
+; IP address connected to the Internet, you will want to learn
+; about the various security settings BEFORE you start
+; Asterisk.
+; - Allowguest (default enabled)
+; - Permit/deny - IP address filters
+; - Contactpermit/contactdeny - IP address filters for registrations
+; - Context - Which set of services you offer various users
;
; SIP dial strings
;-----------------------------------------------------------
@@ -87,6 +99,10 @@
[general]
context=default ; Default context for incoming calls
;allowguest=no ; Allow or reject guest calls (default is yes)
+ ; If your Asterisk is connected to the Internet
+ ; and you have allowguest=yes
+ ; you want to check which services you offer everyone
+ ; out there, by enabling them in the default context (see below).
;match_auth_username=yes ; if available, match user entry using the
; 'username' field from the authentication line
; instead of the From: field.
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Leif Madsen]

Post by Kai Hoerner
"ATTENTION: If your Asterisk is connected to the internet and you have
allowguest=yes, everybody out there may use your default context without
authentication. In that case you want to double check which services you
offer to the world."

I don't think this is a bad idea, and I've created the following documentation
patch which implements this note. I've also changed (in my patch) the
sip.conf.sample file which has 'allowguest=no' uncommented, but which preserves
the note and code to keep allowguest=yes the default.

I know many people start with the sample configurations and then work from there
because there is a lot going on, and most of it is commented out anyways. The
things we leave uncommented should probably keep new users as safe as possible.

This is my suggested change, and think this is something (along with the
documentation Olle added to trunk) to be backported to 1.4, 1.6.0, etc.. as well.


Index: sip.conf.sample
===================================================================
--- sip.conf.sample (revision 229639)
+++ sip.conf.sample (working copy)
@@ -98,7 +98,7 @@

[general]
context=default ; Default context for incoming calls
-;allowguest=no ; Allow or reject guest calls (default is yes)
+allowguest=no ; Allow or reject guest calls (default is yes)
; If your Asterisk is connected to the Internet
; and you have allowguest=yes
; you want to check which services you offer everyone
Index: extensions.conf.sample
===================================================================
--- extensions.conf.sample (revision 229638)
+++ extensions.conf.sample (working copy)
@@ -615,6 +615,13 @@

[default]
;
+; ATTENTION: If your Asterisk is connected to the internet and you have
+; allowguest=yes, everybody out there may use your default context without
+; authentication. In that case you want to double check which services you
+; offer to the world. Also note that if you do not define allowguest=no
+; in sip.conf, that the default is allowguest=yes.
+;
+;
; By default we include the demo. In a production system, you
; probably don't want to have the demo there.
;

[Michiel van Baak]

Post by Leif Madsen

Post by Kai Hoerner
"ATTENTION: If your Asterisk is connected to the internet and you have
allowguest=yes, everybody out there may use your default context without
authentication. In that case you want to double check which services you
offer to the world."

I don't think this is a bad idea, and I've created the following documentation
patch which implements this note. I've also changed (in my patch) the
sip.conf.sample file which has 'allowguest=no' uncommented, but which preserves
the note and code to keep allowguest=yes the default.
I know many people start with the sample configurations and then work from there
because there is a lot going on, and most of it is commented out anyways. The
things we leave uncommented should probably keep new users as safe as possible.
This is my suggested change, and think this is something (along with the
documentation Olle added to trunk) to be backported to 1.4, 1.6.0, etc.. as well.
Index: sip.conf.sample
===================================================================
--- sip.conf.sample (revision 229639)
+++ sip.conf.sample (working copy)
@@ -98,7 +98,7 @@
[general]
context=default ; Default context for incoming calls
-;allowguest=no ; Allow or reject guest calls (default is yes)
+allowguest=no ; Allow or reject guest calls (default is yes)
; If your Asterisk is connected to the Internet
; and you have allowguest=yes
; you want to check which services you offer everyone
Index: extensions.conf.sample
===================================================================
--- extensions.conf.sample (revision 229638)
+++ extensions.conf.sample (working copy)
@@ -615,6 +615,13 @@
[default]
;
+; ATTENTION: If your Asterisk is connected to the internet and you have
+; allowguest=yes, everybody out there may use your default context without
+; authentication. In that case you want to double check which services you
+; offer to the world. Also note that if you do not define allowguest=no
+; in sip.conf, that the default is allowguest=yes.
+;
+;
; By default we include the demo. In a production system, you
; probably don't want to have the demo there.
;

Looks good to me.
As Jared mentioned, you should probably add the warning you have in
sip.conf.sample to at least iax.conf.sample (and I dont know if there
are other channeldrivers that have this kind of functionality)

[Tilghman Lesher]

Post by Leif Madsen

Post by Kai Hoerner
"ATTENTION: If your Asterisk is connected to the internet and you have
allowguest=yes, everybody out there may use your default context without
authentication. In that case you want to double check which services you
offer to the world."

I don't think this is a bad idea, and I've created the following
documentation patch which implements this note. I've also changed (in my
patch) the sip.conf.sample file which has 'allowguest=no' uncommented, but
which preserves the note and code to keep allowguest=yes the default.

I agree with your note, but I disagree with disabling guest access in the
sample configuration. The reasoning is that we want new users to be able
to get Asterisk to work as easily as possible in the sample configuration.
Even if their SIP phone is not correctly configured with a password. they
should be able to operate the demo. Once we start complicating the samples,
we run the risk of new users being unable to get over that initial hump and
losing interest, all because they become unable to get Asterisk to respond
with anything other than an error.

There is something magical about the first time you get Asterisk to "respond",
and we don't want to make that moment harder for new users.

[Jared Smith]

Post by Tilghman Lesher
I agree with your note, but I disagree with disabling guest access in the
sample configuration. The reasoning is that we want new users to be able
to get Asterisk to work as easily as possible in the sample configuration.
Even if their SIP phone is not correctly configured with a password. they
should be able to operate the demo. Once we start complicating the samples,
we run the risk of new users being unable to get over that initial hump and
losing interest, all because they become unable to get Asterisk to respond
with anything other than an error.

I tend to agree with Tilghman here, and believe that the proper thing to
do might be to put a note in extensions.conf (in the [default] context)
stating that the user should be careful what they put in the [default]
context, as unauthenticated calls go to that context by default.

In short, I'd rather have an educated user than an uneducated user who
can't get Asterisk to work for them.

[Michiel van Baak]

Post by Jared Smith

Post by Tilghman Lesher
I agree with your note, but I disagree with disabling guest access in the
sample configuration. The reasoning is that we want new users to be able
to get Asterisk to work as easily as possible in the sample configuration.
Even if their SIP phone is not correctly configured with a password. they
should be able to operate the demo. Once we start complicating the samples,
we run the risk of new users being unable to get over that initial hump and
losing interest, all because they become unable to get Asterisk to respond
with anything other than an error.

I tend to agree with Tilghman here, and believe that the proper thing to
do might be to put a note in extensions.conf (in the [default] context)
stating that the user should be careful what they put in the [default]
context, as unauthenticated calls go to that context by default.
In short, I'd rather have an educated user than an uneducated user who
can't get Asterisk to work for them.

I totally agree here.

[Atis Lezdins]

Post by Jared Smith

Post by Tilghman Lesher
I agree with your note, but I disagree with disabling guest access in the
sample configuration.  The reasoning is that we want new users to be able
to get Asterisk to work as easily as possible in the sample configuration.
Even if their SIP phone is not correctly configured with a password. they
should be able to operate the demo.  Once we start complicating the samples,
we run the risk of new users being unable to get over that initial hump and
losing interest, all because they become unable to get Asterisk to respond
with anything other than an error.

I tend to agree with Tilghman here, and believe that the proper thing to
do might be to put a note in extensions.conf (in the [default] context)
stating that the user should be careful what they put in the [default]
context, as unauthenticated calls go to that context by default.

That's good addition anyway, and don't forget extensions.ael and extensions.lua

However, how many users actually read all the comments in sample
config files? If You need to get something to work - you go and read
it, otherwise - why bother?

Post by Jared Smith
In short, I'd rather have an educated user than an uneducated user who
can't get Asterisk to work for them.

How educated would be user who can't set up username and password?

So, I agree that it could be changed in next major version.

Regards,
Atis

[Kai Hoerner]

Post by Tilghman Lesher
There is something magical about the first time you get Asterisk to "respond",
and we don't want to make that moment harder for new users.

I partially agree with Tilghman here.
But I also agree with Atis: how educated is a user who is unable to
setup credentials, a thing they need for mostly any server<>client stuff
out there?

Not that very. So we can expect any linux/*nix administrator to
understand authentication mechanisms.
What we can *not* expect from any linux/*nix admin is that he's
automagically aware of that "allowguest" implication.

I think learning how to setup credentials correctly is easier for
beginners, than learning how to configure dialplans securely.
since it's something *special* to asterisk, which does not apply to most
other software. but the need of using credentials does, i think.


I'd like to throw in another suggestion from Kaloyan which ended up in

Post by Tilghman Lesher
Why not change the default context in sip.conf (and iax.conf for guest on make
samples) to [unauthenticated_call] instead of just default, which will be more
prominent for the admin of what is happening?

I know, problem is that there is no such context. There is a default
context (hence the name) which can be used for unauthenticated calls _as
well_, when allowguest=yes.
Nevertheless, i love self-documenting systems and IMHO this is a good idea.

There should have been seperated default contexts for authenticated and
unauthenticated calls right from the beginning.
Best practise is to not use the "default" context at all, i believe.


Regards,
Kaii

[Tzafrir Cohen]

Post by Alec Davis
At Tilghman's request.
We need to agree to change the sip.conf default from allowguest=yes to
allowguest=no
and extensions.conf to have a warning in the [default] section that sip.conf
may have allowguest=yes or nothing which will default of yes.

Regardless of the arguments for and against setting the defaults in
sip.conf, keep in mind that configs/sip.conf.sample and to a much
greater extent configs/extennsions.conf.sample are sample/reference
configuration files. The user's configuration is not required to rely on
them.

So you basically ask to change the hard-wired default in chan_sip.c (and
maybe also the sample configuration file).

As for extensions.conf - here there's no "hardcoded default". Some users
would prefer to use extensions.ael insted. Generally
extensions.conf.sample is a nice demo but won't be used by most users.
Which means that adding anything there is purely documentation.

Post by Alec Davis
Reference mantis bugs;
<https://issues.asterisk.org/view.php?id=15101>
https://issues.asterisk.org/view.php?id=15101 SIP allowguest defaults to yes
with 'make samples'
<https://issues.asterisk.org/view.php?id=16226>
https://issues.asterisk.org/view.php?id=16226 1.4.26.3 security issue -
Chinese IPs somehow are making calls without authentication

Changing the defaults for a production version is not such a great idea.
The idea of a security update breaking my setup does not make me want to
install the next update.

Post by Alec Davis
There are many installations out there where newbies are playing in the
[default] context in their dialplan, getting things working, then opening
port 5060 in their firewall without understanding what they've just done.
Initially I thought it was great that we allow any SIP phone to connect to
asterisk, with no configuration required at the astrisk end, how wrong I
was.

So maybe the example configuration should document that. Free VoIP calls
from anywhere and to anywhere is a great motivator to use Asterisk. How
do you avoid needless relays?

(I have SMTP in my mind when writing this)

[Alexandre Cavalcante Alencar]

Hi all

Post by Alec Davis
At Tilghman's request.
We need to agree to change the sip.conf default from allowguest=yes to
allowguest=no and extensions.conf to have a warning in the [default] section that sip.conf
may have allowguest=yes or nothing which will default of yes.

I think it can be changed (hardcoded and config samples) to
allowguest=no for the next major release. In the past, Asterisk Team
changed and informed users about default behavior change and we (as
users) get the way to adjust our systems.

It will be very welcome to change the default insecure behavior to a
more secure one. But it's not the solution for all the security
problems out there.

Post by Alec Davis
Reference mantis bugs;
https://issues.asterisk.org/view.php?id=15101 SIP allowguest defaults to yes
with 'make samples'
https://issues.asterisk.org/view.php?id=16226 1.4.26.3 security issue -
Chinese IPs somehow are making calls without authentication
There are many installations out there where newbies are playing in the
[default] context in their dialplan, getting things working, then opening
port 5060 in their firewall without understanding what they've just done.
Initially I thought it was great that we allow any SIP phone to connect to
asterisk, with no configuration required at the astrisk end, how wrong I
was.
Alec Davis

[Alexander Harrowell]

Post by Alexandre Cavalcante Alencar
It will be very welcome to change the default insecure behavior to a
more secure one. But it's not the solution for all the security
problems out there.

Look at the impact Microsoft's decisions to leave various things in an
insecure state by default had on the global Internet community. How many major
botnets would there be had XP shipped with WinFirewall set ON?

Arguably, shipping software designed to be connected to the Internet at one
end and possibly to a telecomms network which is both metered and considered
safety critical at the other without leaving its defaults in a secure state is
irresponsbile.

[Tzafrir Cohen]

Post by Alexander Harrowell

Post by Alexandre Cavalcante Alencar
It will be very welcome to change the default insecure behavior to a
more secure one. But it's not the solution for all the security
problems out there.

Look at the impact Microsoft's decisions to leave various things in an
insecure state by default had on the global Internet community. How many major
botnets would there be had XP shipped with WinFirewall set ON?

You mean: that stupid thing that annoys users so much and getting the
user to authorize access through it is a trivial exercise of human
engeneering?

Makeing life pointlessly difficult for the users also has similar
consequeces.

Post by Alexander Harrowell
Arguably, shipping software designed to be connected to the Internet at one
end and possibly to a telecomms network which is both metered and considered
safety critical at the other without leaving its defaults in a secure state is
irresponsbile.

Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

[Atis Lezdins]

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

[Jeff LaCoursiere]

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

That sounds like the most reasonable suggestion yet.

j

[Tilghman Lesher]

Post by Jeff LaCoursiere

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

That sounds like the most reasonable suggestion yet.

That sounds fine to me.

[Michiel van Baak]

Post by Tilghman Lesher

Post by Jeff LaCoursiere

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

That sounds like the most reasonable suggestion yet.

That sounds fine to me.

And me.

[Kaloyan Kovachev]

Post by Jeff LaCoursiere

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

That was exactly my suggestion here -
http://lists.digium.com/pipermail/asterisk-dev/2009-November/040571.html

demo is now included in default ... leave default with only invalid and
timeout instead and include the demo in unauthenticated_call and default in
both ... this is how i make my configs with s,i,t,T,h being the only
extensions in default and included everywhere

Post by Jeff LaCoursiere
That sounds like the most reasonable suggestion yet.
j
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Tzafrir Cohen]

Post by Kaloyan Kovachev

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

That was exactly my suggestion here -
http://lists.digium.com/pipermail/asterisk-dev/2009-November/040571.html
demo is now included in default ... leave default with only invalid and
timeout instead and include the demo in unauthenticated_call and default in
both ... this is how i make my configs with s,i,t,T,h being the only
extensions in default and included everywhere

What's insecure in the demo context?

Is it a problem that someone can make you relay a test IAX2 to Digium?
Leave a voicemail message?

[Kaloyan Kovachev]

Post by Tzafrir Cohen

Post by Kaloyan Kovachev

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

That was exactly my suggestion here -
http://lists.digium.com/pipermail/asterisk-dev/2009-November/040571.html
demo is now included in default ... leave default with only invalid and
timeout instead and include the demo in unauthenticated_call and default in
both ... this is how i make my configs with s,i,t,T,h being the only
extensions in default and included everywhere

What's insecure in the demo context?

Nothing at all. I meant to leave demo included in the [unauthenticated_call]
where 'the first try' would ended on a freshly installed system, but have an
almost empty [default]

Post by Tzafrir Cohen
Is it a problem that someone can make you relay a test IAX2 to Digium?
Leave a voicemail message?
--
Tzafrir Cohen
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Kai Hoerner]

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

What we should keep in mind here is that all users/friends/accounts that
do not explicitly set "context" to another value will end up there, too.
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"

[Kai Hoerner]

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

we should keep in mind here is that all users/friends/accounts that
do not explicitly set "context" to another value will end up there, too.

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"

[Olle E. Johansson]

Post by Kai Hoerner

Post by Atis Lezdins

Post by Tzafrir Cohen
Please explain to me why exactly allowing guests is a bad thing. How can
I allow people to call me from the internet? Create a local account for
each and every one in my addressbook?

How about creating context "guest" or "public", and setting it as
default in samples? That would make user to think much more before
adding some code there.

we should keep in mind here is that all users/friends/accounts that
do not explicitly set "context" to another value will end up there, too.
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. Guestcontext can default to the default context, but the sample configuration could have an activated setting.

While this would not work with released versions, it might make things better with future releases.

Feedback?

/O

[Kai Hoerner]

Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

Post by Olle E. Johansson
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".

Post by Olle E. Johansson
but the sample configuration could have an activated setting.

IMO the sip.conf.sample should contain an activated "allowguest=no"

Post by Olle E. Johansson
While this would not work with released versions, it might make things better with future releases.

Agreed.

[Atis Lezdins]

Post by Kai Hoerner
Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

Post by Olle E. Johansson
Guestcontext can default to the default context, but the sample configuration could have an activated setting.

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

[Tzafrir Cohen]

Post by Atis Lezdins

Post by Kai Hoerner
Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

Post by Olle E. Johansson
Guestcontext can default to the default context, but the sample configuration could have an activated setting.

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
[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
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.

[Atis Lezdins]

On Tue, Nov 17, 2009 at 12:46 PM, Tzafrir Cohen

Post by Tzafrir Cohen

Post by Atis Lezdins

Post by Kai Hoerner
Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

Post by Olle E. Johansson
Guestcontext can default to the default context, but the sample configuration could have an activated setting.

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
[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
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

[Tzafrir Cohen]

Post by Kai Hoerner
Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

Post by Olle E. Johansson
Guestcontext can default to the default context, but the sample configuration could have an activated setting.

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".

Post by Olle E. Johansson
but the sample configuration could have an activated setting.

IMO the sip.conf.sample should contain an activated "allowguest=no"

Post by Olle E. Johansson
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.


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.

[1] I use "paid calls" for the sake of clarity. It may be paid PSTN
calls, paid SIP calls, or maybe some unpaid calls you assume those
incling callers should not be able to do. For instance, a special
extension to switch between day-time and night-time.

[2] don't mix authorization and authentication.

[Atis Lezdins]

On Tue, Nov 17, 2009 at 11:59 AM, Tzafrir Cohen

Post by Tzafrir Cohen

Post by Kai Hoerner
Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

Post by Olle E. Johansson
Guestcontext can default to the default context, but the sample configuration could have an activated setting.

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".

Post by Olle E. Johansson
but the sample configuration could have an activated setting.

IMO the sip.conf.sample should contain an activated "allowguest=no"

Post by Olle E. Johansson
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.

Post by Tzafrir Cohen
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[incoming]
; We don't trust those callers, and thus only allow them the things they
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

[Chris Lee]

Post by Tzafrir Cohen

Post by Kai Hoerner
Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

Post by Olle E. Johansson
Guestcontext can default to the default context, but the sample configuration could have an activated setting.

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".

Post by Olle E. Johansson
but the sample configuration could have an activated setting.

IMO the sip.conf.sample should contain an activated "allowguest=no"

Post by Olle E. Johansson
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.

In that case could a restriction not be placed on the contexts so that
only users in the local subnet can make calls as guest type users unless
a variable is set to allow guests from outside the local subnet? That
way you protect newbies ability to play without getting too badly hurt
but allow the operation when it is desired.

Something like
RemoteGuest=No

in sip.conf.

Regards,
Chris.

[Tzafrir Cohen]

Post by Chris Lee

Post by Tzafrir Cohen
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.

In that case could a restriction not be placed on the contexts so that
only users in the local subnet can make calls as guest type users unless
a variable is set to allow guests from outside the local subnet? That
way you protect newbies ability to play without getting too badly hurt
but allow the operation when it is desired.
Something like
RemoteGuest=No
in sip.conf.

My toy box is behind NAT. I'm a complete newb and did not set up any
forwarding. Is there any reason I should fear the l33t internet
attackers? Do I have to explicitly set my subnet mask in sip.conf for
all phones for things to work?

Also: what about incoming calls from:

* PSTN
* an IAX2 trunk
* a H.323 trunk (is there such a beast?)

[Alec Davis]

I've been pondering what has been suggested in this email since I sent the
original request for discussion.

The idea is to default 'allowguest to 'local' using the following.

'allowguest=local'
only computers on the same subnet as asterisk, 'That magic moment is
still preserved when first connecting to asterisk.
'allowguest=no'
A locked down system, where you definately don't want guest.
'allowguest=yes'
You know what your doing, and guests are allowed.

Alec Davis


-----Original Message-----
From: asterisk-dev-***@lists.digium.com
[mailto:asterisk-dev-***@lists.digium.com] On Behalf Of Chris Lee
Sent: Wednesday, 18 November 2009 3:30 a.m.
To: asterisk-***@lists.digium.com
Subject: Re: [asterisk-dev] Security Request for discussion: Should sip.conf
allowguest=yes be the default

Post by Tzafrir Cohen

Post by Kai Hoerner
Hi Olle and others,

Post by Olle E. Johansson

Post by Kai Hoerner
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.

"unconfigured"

Post by Tzafrir Cohen

Post by Kai Hoerner

Post by Olle E. Johansson
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.

Post by Tzafrir Cohen

Post by Kai Hoerner
Agreed.

Post by Olle E. Johansson
Guestcontext can default to the default context, but the sample

configuration could have an activated setting.

Post by Tzafrir Cohen

Post by Kai Hoerner
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".

Post by Olle E. Johansson
but the sample configuration could have an activated setting.

IMO the sip.conf.sample should contain an activated "allowguest=no"

Post by Olle E. Johansson
While this would not work with released versions, it might make things

better with future releases.

Post by Tzafrir Cohen

Post by Kai Hoerner
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.

In that case could a restriction not be placed on the contexts so that only
users in the local subnet can make calls as guest type users unless a
variable is set to allow guests from outside the local subnet? That way you
protect newbies ability to play without getting too badly hurt but allow the
operation when it is desired.

Something like
RemoteGuest=No

in sip.conf.

Regards,
Chris.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Alexandre Cavalcante Alencar]

Hi Alec

Post by Alec Davis
I've been pondering what has been suggested in this email since I sent the
original request for discussion.
The idea is to default 'allowguest to 'local' using the following.
'allowguest=local'
       only computers on the same subnet as asterisk, 'That magic moment is
still preserved when first connecting to asterisk.
'allowguest=no'
       A locked down system, where you definately don't want guest.
'allowguest=yes'
       You know what your doing, and guests are allowed.

This seems to be simple and effective proposal. Adding the [public]
context for guest proposal, make things clear and simple.

So, we have a allowguest=<local|no|yes> that defaults to 'local' and
the guests all go to '[public]' context. Above '[public]' a
explanation about that context usage...

Post by Alec Davis
Alec Davis

[Tzafrir Cohen]

Post by Alec Davis
I've been pondering what has been suggested in this email since I sent the
original request for discussion.
The idea is to default 'allowguest to 'local' using the following.
'allowguest=local'
only computers on the same subnet as asterisk, 'That magic moment is
still preserved when first connecting to asterisk.

Where is that subnet defined? "localnet" or something more automatic?

Post by Alec Davis
'allowguest=no'
A locked down system, where you definately don't want guest.
'allowguest=yes'
You know what your doing, and guests are allowed.

[Olle E. Johansson]

Post by Alec Davis
I've been pondering what has been suggested in this email since I sent the
original request for discussion.
The idea is to default 'allowguest to 'local' using the following.
'allowguest=local'
only computers on the same subnet as asterisk, 'That magic moment is
still preserved when first connecting to asterisk.

This is becoming too complicated to be a simple security protection.

I still think we should separate incoming context for guests and the one we use as a default for devices, then let the dialplan control what services we provide to anyone. That the default context configuration in sip.conf is used in two ways is confusing and may lead to problems.

That new config in combination with allowguest yes/no is enough.
/O

[Kai Hoerner]

Post by Olle E. Johansson

Post by Alec Davis
The idea is to default 'allowguest to 'local' using the following.
'allowguest=local'
only computers on the same subnet as asterisk, 'That magic moment is
still preserved when first connecting to asterisk.

This is becoming too complicated to be a simple security protection.
I still think we should separate incoming context for guests and the one we use as a default for devices, then let the dialplan control what services we provide to anyone. That the default context configuration in sip.conf is used in two ways is confusing and may lead to problems.

Additionally, if we change the default from "yes" to "local", we may
break existing setups that do not have the setting explicitly set. (we
already had this in the beginning of the discussion)

Regards,
Kaii

[Olle E. Johansson]

Post by Kai Hoerner

Post by Olle E. Johansson

Post by Alec Davis
The idea is to default 'allowguest to 'local' using the following.
'allowguest=local'
only computers on the same subnet as asterisk, 'That magic moment is
still preserved when first connecting to asterisk.

This is becoming too complicated to be a simple security protection.
I still think we should separate incoming context for guests and the one we use as a default for devices, then let the dialplan control what services we provide to anyone. That the default context configuration in sip.conf is used in two ways is confusing and may lead to problems.

Additionally, if we change the default from "yes" to "local", we may
break existing setups that do not have the setting explicitly set. (we
already had this in the beginning of the discussion)

I dont' agree with "local" since it assumes a lot of other configurations and doesn't really help. We already have settings for handling ACLs that users are free to use.

I am beginning to think that we should propably divide the "sample" configurations and the "reference". The "sample" could be much more simple and just have some basic settings to get things going and security information.

/O

[Jared Smith]

Post by Olle E. Johansson
I am beginning to think that we should propably divide the "sample"
configurations and the "reference". The "sample" could be much more
simple and just have some basic settings to get things going and
security information.

I'm very glad to hear you say this, as this is something I've been
advocating for a while now. The current sample files are too unwieldy
for the beginner, and most beginners I see don't bother to read the
sample files because they're so big. I'd rather have them start with a
short (one page!) sample config that gives them the basic, and then show
them where they can go to research every possible configuration option.

I'd be happy to share the simplified sip.conf and extensions.conf files
that I use as part of my Asterisk training classes, if people are
interested.

[Miguel Molina]

Post by Jared Smith

Post by Olle E. Johansson
I am beginning to think that we should propably divide the "sample"
configurations and the "reference". The "sample" could be much more
simple and just have some basic settings to get things going and
security information.

I'm very glad to hear you say this, as this is something I've been
advocating for a while now. The current sample files are too unwieldy
for the beginner, and most beginners I see don't bother to read the
sample files because they're so big. I'd rather have them start with a
short (one page!) sample config that gives them the basic, and then show
them where they can go to research every possible configuration option.
I'd be happy to share the simplified sip.conf and extensions.conf files
that I use as part of my Asterisk training classes, if people are
interested.

+1 for this, as some people usually tend to start uncommenting options
and writing the dialplan below the (long) sample configuration, which
makes it annoying to read, understand and modify, to not say insecure.
It would be very nice if such thing as very short working sample
configurations are seen on more files like iax.conf, and another big
ones. BTW, sometimes I use the original .sample files as a reference.

Regards,

[Alec Davis]

'allowguest=local' may not have been the best keyword. But you got the idea.

If the source (not SIP source) were one of the non routable ipaddress
ranges, (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 or 169.254.0.0/16), then
it should be 'fairly' safe that this is 'local' access, and if
allowguest=local then allow a guest connection.

The flaw: Some shared cable networks may use the 'non routeable' address
ranges, leaving you open to other users on your cable network, maybe easier
to trace abuse with help from your local service provider, maybe not?

But still you have to change the extensions.conf [default] context to have
any damage done.

Alec

-----Original Message-----
From: asterisk-dev-***@lists.digium.com
[mailto:asterisk-dev-***@lists.digium.com] On Behalf Of Tzafrir Cohen
Sent: Wednesday, 18 November 2009 9:39 a.m.
To: asterisk-***@lists.digium.com
Subject: Re: [asterisk-dev] Security Request for discussion: Should
sip.confallowguest=yes be the default

Post by Alec Davis
I've been pondering what has been suggested in this email since I sent
the original request for discussion.
The idea is to default 'allowguest to 'local' using the following.
'allowguest=local'
only computers on the same subnet as asterisk, 'That magic moment is
still preserved when first connecting to asterisk.

Where is that subnet defined? "localnet" or something more automatic?

Post by Alec Davis
'allowguest=no'
A locked down system, where you definately don't want guest.
'allowguest=yes'
You know what your doing, and guests are allowed.

--
Tzafrir Cohen
icq#16849755 jabber:***@xorcom.com
[phone] mailto:***@xorcom.com
http://www.xorcom.com iax:***@local.xorcom.com/tzafrir

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Kai Hoerner]

Post by Tzafrir Cohen
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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[incoming]
; We don't trust those callers, and thus only allow them the things they
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.
[1] I use "paid calls" for the sake of clarity. It may be paid PSTN
calls, paid SIP calls, or maybe some unpaid calls you assume those
incling callers should not be able to do. For instance, a special
extension to switch between day-time and night-time.
[2] don't mix authorization and authentication.
I still don't agree. I believe that focusing on guests here misses the

Hi Tzafrir,

I do not see where i mixed up authorization and authentication.

Authenticated users are not automatically authorized to use special
extensions for dialout or internal day/night switches for example.
That's where the contexts come into play. [2]

Authenticated trunks/peers/friends/users should have a context
specified, that authorizes them for the use of a set of extensions.
If it is not specified, the "defaultcontext" in inherited, okay.

I suggested an additional option like "guest_context" to seperate
"unauthenticated" (guest) calls from "authenticated but maybe not
authorized" (trunk) calls.
With the solution as-is, both of them end up in the default context.

I do not understand how unintended relay applies at all to this topic.
Isn't bad dialplan design a configuration issue?

It is, but this difficulty can be aided by adding more control over what
calls go into which context.


Regargs,

Kaii

[Tzafrir Cohen]

Post by Kai Hoerner

Post by Tzafrir Cohen
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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
[incoming]
; We don't trust those callers, and thus only allow them the things they
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.
[1] I use "paid calls" for the sake of clarity. It may be paid PSTN
calls, paid SIP calls, or maybe some unpaid calls you assume those
incling callers should not be able to do. For instance, a special
extension to switch between day-time and night-time.
[2] don't mix authorization and authentication.
I still don't agree. I believe that focusing on guests here misses the

Hi Tzafrir,
I do not see where i mixed up authorization and authentication.

That was a general comment, and I was not referring to anything specific
in the discussion.

Post by Kai Hoerner
Authenticated users are not automatically authorized to use special
extensions for dialout or internal day/night switches for example.
That's where the contexts come into play. [2]
Authenticated trunks/peers/friends/users should have a context
specified, that authorizes them for the use of a set of extensions.
If it is not specified, the "defaultcontext" in inherited, okay.
I suggested an additional option like "guest_context" to seperate
"unauthenticated" (guest) calls from "authenticated but maybe not
authorized" (trunk) calls.

As per that comment, the dialplan is exatly about authrization. There
are no unauthorized actions in the dialplan[1].

You can set up an arbitrary variable at channel creation time (e.g.:
'setvar'.

Sounds like we could really use a dummy entry for the "guest user"[2]
in sip.conf . So you could set up context, extra variables, language and
whatever. This sounds so simple and obvoius, that there must be some
sound technical reasons why it won't work well.

Post by Kai Hoerner
With the solution as-is, both of them end up in the default context.
I do not understand how unintended relay applies at all to this topic.
Isn't bad dialplan design a configuration issue?

This whole problem is about bad dialplan design. It is about beginners
not planning their dialplan well.

I want to allow random Joe SIP user call my phone. I consider this a
feature. This call takes out a bit of my bandwidth. But if this is a
problem, I can hang up.

I do not want Joe to call into my PBX and from there out through another
trunk.

Post by Kai Hoerner
It is, but this difficulty can be aided by adding more control over what
calls go into which context.

The dialplan already gives you good control.

Post by Kai Hoerner
Regargs,
Kaii

[1] Or rather: there maybe some actions that the sysadmin thinks are
unauthorized but sadly are authorized.

[2] If Olle doesn't kill it first.

[Kai Hoerner]

Hi,

Post by Tzafrir Cohen
Sounds like we could really use a dummy entry for the "guest user"[2]
in sip.conf . So you could set up context, extra variables, language and
whatever. This sounds so simple and obvoius, that there must be some
sound technical reasons why it won't work well.

Great idea. 1+
Waiting for comments from Olle on technical reasons.

Post by Tzafrir Cohen

Post by Kai Hoerner
With the solution as-is, both of them end up in the default context.
I do not understand how unintended relay applies at all to this topic.
Isn't bad dialplan design a configuration issue?

This whole problem is about bad dialplan design. It is about beginners
not planning their dialplan well.

I thought this discussion was about the sample configs, and how they can
aid beginners in using them as a starting point in a more secure manner
without further knowledge.
Bad dialplan design by beginners is not avoidable, but we can aid them
to start with a better sample design.

Post by Tzafrir Cohen
I want to allow random Joe SIP user call my phone. I consider this a
feature. This call takes out a bit of my bandwidth. But if this is a
problem, I can hang up.
I do not want Joe to call into my PBX and from there out through another
trunk.

Still agreed.

Post by Tzafrir Cohen

Post by Kai Hoerner
It is, but this difficulty can be aided by adding more control over what
calls go into which context.

The dialplan already gives you good control.

Only if you know how to use your tools properly, which i believe beginners
do not.

One can check if the call comes from an authenticated peer in dialplan. Agreed.

But i thought the discussion was about how to aid beginners who don't know
such things.

Post by Tzafrir Cohen
[1] Or rather: there maybe some actions that the sysadmin thinks are
unauthorized but sadly are authorized.

Thx for the correction, that is exactly what i intended to say.


Regards,
Kaii

[Atis Lezdins]

Post by Kai Hoerner
Hi,

Post by Tzafrir Cohen
Sounds like we could really use a dummy entry for the "guest user"[2]
in sip.conf . So you could set up context, extra variables, language and
whatever. This sounds so simple and obvoius, that there must be some
sound technical reasons why it won't work well.

Great idea. 1+
Waiting for comments from Olle on technical reasons.

Actually, as Tzafrir mentioned before, this isn't affecting only SIP,
you could have the same
kind of security risk with anonymous pass-through also on DAHDI, mobile, etc..

Post by Kai Hoerner

Post by Tzafrir Cohen

Post by Kai Hoerner
With the solution as-is, both of them end up in the default context.
I do not understand how unintended relay applies at all to this topic.
Isn't bad dialplan design a configuration issue?

This whole problem is about bad dialplan design. It is about beginners
not planning their dialplan well.

I thought this discussion was about the sample configs, and how they can
aid beginners in using them as a starting point in a more secure manner
without further knowledge.
Bad dialplan design by beginners is not avoidable, but we can aid them
to start with a better sample design.

Post by Tzafrir Cohen
I want to allow random Joe SIP user call my phone. I consider this a
feature. This call takes out a bit of my bandwidth. But if this is a
problem, I can hang up.
I do not want Joe to call into my PBX and from there out through another
trunk.

Still agreed.

Post by Tzafrir Cohen

Post by Kai Hoerner
It is, but this difficulty can be aided by adding more control over what
calls go into which context.

The dialplan already gives you good control.

Only if you know how to use your tools properly, which i believe beginners
do not.
One can check if the call comes from an authenticated peer in dialplan. Agreed.
But i thought the discussion was about how to aid beginners who don't know
such things.

Post by Tzafrir Cohen
[1] Or rather: there maybe some actions that the sysadmin thinks are
unauthorized but sadly are authorized.

Thx for the correction, that is exactly what i intended to say.

[Olle E. Johansson]

Post by Kai Hoerner

Post by Tzafrir Cohen
Sounds like we could really use a dummy entry for the "guest user"[2]
in sip.conf . So you could set up context, extra variables, language and
whatever. This sounds so simple and obvoius, that there must be some
sound technical reasons why it won't work well.

Great idea. 1+
Waiting for comments from Olle on technical reasons.

Sounds like a reasonable idea. We have to design it so that we can have one
of these templates per domain in the future.

/O

[Tilghman Lesher]

Post by Alexander Harrowell

Post by Alexandre Cavalcante Alencar
It will be very welcome to change the default insecure behavior to a
more secure one. But it's not the solution for all the security
problems out there.

Look at the impact Microsoft's decisions to leave various things in an
insecure state by default had on the global Internet community. How many
major botnets would there be had XP shipped with WinFirewall set ON?
Arguably, shipping software designed to be connected to the Internet at one
end and possibly to a telecomms network which is both metered and
considered safety critical at the other without leaving its defaults in a
secure state is irresponsbile.

I agree with you 100%. But the point is that the defaults are ALREADY in a
safe state. Once you start modifying configurations, you can make millions
of unsafe configurations, none of which we can really prevent without
significantly limiting the functionality.

[Alec Davis]

Proposed patches are up at https://issues.asterisk.org/view.php?id=15101

Of which satisfy most of my initial concerns.

Alec Davis


_____

From: asterisk-dev-***@lists.digium.com
[mailto:asterisk-dev-***@lists.digium.com] On Behalf Of Alec Davis
Sent: Thursday, 12 November 2009 8:34 p.m.
To: asterisk-***@lists.digium.com
Subject: [asterisk-dev] Security Request for discussion: Should sip.conf
allowguest=yes be the default


At Tilghman's request.

We need to agree to change the sip.conf default from allowguest=yes to
allowguest=no
and extensions.conf to have a warning in the [default] section that sip.conf
may have allowguest=yes or nothing which will default of yes.

Reference mantis bugs;
<https://issues.asterisk.org/view.php?id=15101>
https://issues.asterisk.org/view.php?id=15101 SIP allowguest defaults to yes
with 'make samples'
<https://issues.asterisk.org/view.php?id=16226>
https://issues.asterisk.org/view.php?id=16226 1.4.26.3 security issue -
Chinese IPs somehow are making calls without authentication

There are many installations out there where newbies are playing in the
[default] context in their dialplan, getting things working, then opening
port 5060 in their firewall without understanding what they've just done.

Initially I thought it was great that we allow any SIP phone to connect to
asterisk, with no configuration required at the astrisk end, how wrong I
was.

Alec Davis