| Summary: | ASTERISK-18862: Change default for sip.conf 'nat' setting | ||||||
| Reporter: | Kevin P. Fleming (kpfleming) | Labels: | |||||
| Date Opened: | 2011-11-14 10:45:32.000-0600 | Date Closed: | 2011-11-21 14:01:15.000-0600 | ||||
| Priority: | Blocker | Regression? | |||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability | ||||
| Versions: | 1.4.42 1.6.2.20 1.8.7.1 10.0.0-rc1 | Frequency of Occurrence | |||||
| Related Issues: |
| ||||||
| Environment: | Attachments: | ||||||
| Description: | As per the discussion on the asterisk-dev mailing list (link to the archives in the URL field of this issue), the following changes should be made: * In the Asterisk 1.4, and 1.6.2 branches, change the default for the chan_sip 'nat' setting to 'yes' (currently 'no'). Add a strongly-worded warning about setting 'nat' to a different value in the [general] section of sip.conf than it is for a specific user/peer/friend (see mailing list discussion for summary). * In the Asterisk 1.8 and 10 branches, change the default for the chan_sip 'nat' setting to 'force_rport' (currently 'no'). Add a strongly-worded warning about setting 'nat' to a different value in the [general] section of sip.conf than it is for a specific user/peer/friend (see mailing list discussion for summary). * In Asterisk trunk, change the default for the chan_sip 'nat' setting to 'force_rport' (currently 'no'). Add a strongly-worded warning about setting 'nat' to a different value in the [general] section of sip.conf than it is for a specific user/peer/friend (see mailing list discussion for summary). In addition, investigate whether an option to respond to *both* candidate ports for unauthenticated requests would be feasible and practical. * Provide truth-tables in the sample sip.conf files that show combinations of 'nat' settings available for that version of Asterisk that are vulnerable to this attack. * Produce a security advisory documenting the issue and the steps that have been put in place to allow users to mitigate it (even though it cannot be resolved completely). These changes should be documented in the UPGRADE files, since they are behavior-affecting changes that users will experience when upgrading. | ||||||
| Comments: | |||||||