Summary:ASTERISK-20622: Default enabling of the "allowguest" setting in Asterisk should be revisited, as it allows systems by default to be potentially vulnerable
Reporter:Dirk-Michael Brosig (dbrosig)Labels:
Date Opened:2012-10-29 16:32:26Date Closed:2012-11-06 09:52:23.000-0600
Versions: Frequency of
Environment:openSUSE 12.1 32bit Linux dmbsrv 3.1.10-1.16-pae #1 SMP Wed Jun 27 05:21:40 UTC 2012 (d016078) i686 athlon i386 GNU/LinuxAttachments:
Description:an attacker can make a dial in default context without valid authentification
Comments:By: Rusty Newton (rnewton) 2012-10-29 17:53:57.735-0500

I only see a failed registration in your debug. Can you attach a file demonstrating the call made into the default context without authentication? (be sure to include both VERBOSE and DEBUG message types set to level 5)

Also, can you attach your sip.conf and users.conf with passwords scrubbed?

Are you using allowguest=yes in sip.conf?

By: Matt Jordan (mjordan) 2012-10-30 06:51:33.165-0500

I'm sorry your system was attacked.  It isn't an enjoyable experience, and not a lot of fun when you end up on the hook for the costs associated with it.  The {{allowguest}} option has been enabled for some time in Asterisk by default, and we've had lots of debate about it in the past.  In fact, just making the suggested setting in the sample {{sip.conf}} ";allowguest=no" was a lot of debate - see ([here|http://lists.digium.com/pipermail/asterisk-dev/2009-November/040555.html] and [here|http://lists.digium.com/pipermail/asterisk-dev/2009-November/040392.html]).  For a variety of reasons, while we've added lots of warnings and caveats, we've held back from changing the default value for this setting inside Asterisk for a variety of reasons (I'll let the mailing list discussions speak for themselves).

I'm okay with proposing (yet again) that the default inside Asterisk be made to "no".

That being said, I want to point out that there are some clear indications in the sample configuration files (and I stress the world *sample*, they are not meant for production use) that should have warned you that this option was enabled:

; 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.
; Especially 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

Second, the sample configuration file states the following for the {{allowguest}} setting:
;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).

This means that you not only had an option that you didn't want enabled in your {{sip.conf}}, but you also had your dialplan configured such that the default context specified in {{sip.conf}} allowed outbound calls.  Essentially, you have multiple vulnerabilities in your configuration that allowed the situation to occur.

Based on this, you may want to consider not exposing your services to the public until you've had a chance to fully read up on security best practices in Asterisk and double check all of your configuration for additional vulnerabilities.

A few things you should read before deploying your system:
* The README-SERIOUSLY.bestpractices.txt delivered with Asterisk
* [Asterisk: The Definitive Guide|http://ofps.oreilly.com/titles/9780596517342/], particularly the sections on Outside Connectivity and Security
* [Important Security Considerations|https://wiki.asterisk.org/wiki/display/AST/Important+Security+Considerations] on the Asterisk wiki

Finally, if you're on Asterisk 10+, there are some facilities available to you that will help you track security threats to your system.  They certainly beat having to look at CDR records!  (1.8 has mechanisms other than that as well, but nothing terribly formal)  See [Asterisk Security Framework|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Security+Framework] for more information.