Tilghman Lesher wrote:
On Thursday 12 November 2009 09:53:17 Lee Howard wrote:
These people should need to deliberately use allowguest=yes. I would
venture to guess that these people already know who they are and
deliberately have this set. I would venture to guess that there are
far, far more people who have it turned on by default who really don't
want it that way than there are who expected it to be that way and
desire it to so be.
And the people who use this probably believe that YOU should be the one
who has to deliberately turn this option off. I would venture to guess that
90% of all statistics are made up on the spot, including this one and the
two you specified above.
I made it clear that they were guesses. But, please *DO* take a vote on
this. I'm not seeing anyone but you stand up to support the default
setting. Unless you take a vote there's really nothing I can do but guess.
The fact that this problem is being exploited leads me to believe that
this is far-more prevalent a problem than just my single case. Take
care of your users when you can do something so easily. Don't
deliberately let them learn things the hard way on the basis that they
should have known better. The mere fact that this issue is addressed in
doc/security.txt should be an indication that there is a common risk
that could be averted.
And yet this point is not even made clear in the doc/security.txt file.
It says to not use "default" for anything you don't want to get abused,
but it doesn't say *why*. So I can envision, then, someone reading the
document and then changing context=internal in the [general] section of
sip.conf... and thinking that they responded correctly to what the
document said.
You've just made a case for enhancing the documentation, not for changing
the defaults. If you contribute documentation changes to this effect on the
issue tracker, I would be more than happy to commit them.
The patch is attached. Feel free to add it to bug tracker issue ID
16226 which some maintainer was happy enough to close already.
And, for what it's worth let me restate my vote that the default for
allowguest be changed to "no" on the basis of keeping ignorant people
from making a stupid mistake.
Thanks,
Lee.
--- asterisk-1.4.21.2/doc/security.txt.old 2009-11-12 09:53:03.000000000 -0800
+++ asterisk-1.4.21.2/doc/security.txt 2009-11-12 09:56:38.000000000 -0800
@@ -48,12 +48,15 @@
Therefore, you should NOT allow access to outgoing or toll services in
contexts that are accessible (especially without a password) from incoming
-channels, be they IAX channels, FX or other trunks, or even untrusted
-stations within you network. In particular, never ever put outgoing toll
-services in the "default" context. To make things easier, you can include
-the "default" context within other private contexts by using:
+channels, be they IAX channels, SIP channels, FX or other trunks, or even
+untrusted stations within you network. Keep in mind that the default setting
+for SIP configuration is allowguest=yes. So unauthenticated SIP users will,
+by default, be able to access the context specified in the [general] section.
+Therefore, never ever put outgoing toll services in the "public" context.
+To make things easier, you can include the "default" context within other
+private contexts by using:
- include => default
+ include => public
in the appropriate section. A well designed PBX might look like this:
@@ -63,9 +66,9 @@
[local]
exten => _9NXXNXXX,1,Dial(Zap/g2/${EXTEN:1})
-include => default
+include => public
-[default]
+[public]
exten => 6123,Dial(Zap/1)
--- asterisk-1.4.21.2/configs/sip.conf.sample.old 2009-11-12 09:57:19.000000000 -0800
+++ asterisk-1.4.21.2/configs/sip.conf.sample 2009-11-12 09:58:41.000000000 -0800
@@ -24,7 +24,7 @@
;
[general]
-context=default ; Default context for incoming calls
+context=public ; Default context for incoming calls
;allowguest=no ; Allow or reject guest calls (default is yes)
allowoverlap=no ; Disable overlap dialing support. (Default is yes)
;allowtransfer=no ; Disable all transfers (unless enabled in peers or users)
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
