Hi Kevin,<div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); "><i><font class="Apple-style-span" color="#3333ff">* 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.</font></i></span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, sans-serif">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.</font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, sans-serif">-Bruce</font></div><div><font class="Apple-style-span" face="arial, sans-serif"><br>
</font><br><div class="gmail_quote">On Tue, Nov 8, 2011 at 6:11 PM, Kevin P. Fleming <span dir="ltr"><<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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:<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
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).<br>
<br>
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!<br>
<br>
-- <br>
Kevin P. Fleming<br>
Digium, Inc. | Director of Software Technologies<br>
Jabber: <a href="mailto:kfleming@digium.com" target="_blank">kfleming@digium.com</a> | SIP: <a href="mailto:kpfleming@digium.com" target="_blank">kpfleming@digium.com</a> | Skype: kpfleming<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br><font color="#888888">
<br>
--<br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-dev</a><br>
</font></blockquote></div><br></div>