[asterisk-dev] Summary: SIP, NAT, security concerns, oh my!

[Bruce B]

Hi Kevin,

** For Asterisk trunk (and possibly Asterisk 10), consider sending failure
responses to *both* the port the request was received from *and* the port
listed in the top-most Via header. This would only be done for
non-authenticated requests, e.g. any request that cannot be definitively
associated with a user/peer/friend (through actual authentication, or IP
address/port matching, or any other valid mechanism). A configuration
option (valid only at the [general] level) would be provided to disable
this behavior if necessary.*

How about an *option* that will allow for NO RESPONSE at all if all
authentications fail? This would make Asterisk the most secure because then
the server won't announce what it's running so the hackers will move on
when they don't hear a response back. DDoS will be a thing of past if they
can't establish that there is an Asterisk server. As an option in sip.conf
this can be set to OFF by default but can be turned on if the user wants to
set it to ON. So, at times of debugging the system, one can set this to NO
and other times keep it to YES so outsiders are not told that we are
running an Asterisk server. This adds a very unique layer to security to
the system.

-Bruce


On Tue, Nov 8, 2011 at 6:11 PM, Kevin P. Fleming <kpfleming at digium.com>wrote:

> OK, in order to bring this to a close (after the thread died a bit while
> many of us were at AstriCon and our post-AstriCon recovery locations), this
> is the current proposal on the table:
>
> * Change the default for the sip.conf 'nat' configuration option to
> 'force_rport' in versions of Asterisk that offer that value, and to 'yes'
> in versions that do not.
>
> * Add a strongly-worded warning in the sample sip.conf file (and on the
> wiki, and anywhere else that seems appropriate) about changing the 'nat'
> setting for a specific user/peer/friend to any value other than the one in
> the [general] section (or the default, if no value has been set in the
> [general] section). For some combinations of 'nat' settings, the
> user/peer/friend so configured could become discoverable through the method
> documented in this thread.
>
> * For Asterisk trunk (and possibly Asterisk 10), consider sending failure
> responses to *both* the port the request was received from *and* the port
> listed in the top-most Via header. This would only be done for
> non-authenticated requests, e.g. any request that cannot be definitively
> associated with a user/peer/friend (through actual authentication, or IP
> address/port matching, or any other valid mechanism). A configuration
> option (valid only at the [general] level) would be provided to disable
> this behavior if necessary.
>
> The first two changes would be made to the release branches for Asterisk
> 1.4, 1.6.2, and 1.8, with a suitable security advisory published (and new
> releases made from those branches). These same changes would be made to the
> release branch for Asterisk 10 and trunk, along with investigating whether
> a patch to implement the dual-response mechanism would be feasible in a
> short time frame (less than two weeks). Based on the result of that
> process, a decision can be made whether it would be merged at all, and into
> the Asterisk 10 branch, or just trunk (depending on its risk of causing
> regressions).
>
> If I've incorrectly represented the consensus here please speak up; I'd
> like to get moving on making these changes in the next few days so we can
> put this behind us. Thanks for all your input on this subject, it has been
> very valuable!
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at www.digium.com & www.asterisk.org
>
> --
> ______________________________**______________________________**_________
> -- 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<http://lists.digium.com/mailman/listinfo/asterisk-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111109/770394ad/attachment-0001.htm>