<div class="gmail_quote">On Thu, Dec 8, 2011 at 4:47 PM, Asterisk Security Team <span dir="ltr"><<a href="mailto:security@asterisk.org">security@asterisk.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Asterisk Project Security Advisory - AST-2011-013<br>
<br>
<br></blockquote><div><br><snip><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Description It is possible to enumerate SIP usernames when the general<br>
and user/peer NAT settings differ in whether to respond to<br>
the port a request is sent from or the port listed for<br>
responses in the Via header. In 1.4 and 1.6.2, this would<br>
mean if one setting was nat=yes or nat=route and the other<br>
was either nat=no or nat=never. In 1.8 and 10, this would<br>
mean when one was nat=force_rport or nat=yes and the other<br>
was nat=no or nat=comedia.<br>
<br>
Resolution Handling NAT for SIP over UDP requires the differing<br>
behavior introduced by these options.<br>
<br>
To lessen the frequency of unintended username disclosure,<br>
the default NAT setting was changed to always respond to the<br>
port from which we received the request-the most commonly<br>
used option.<br>
<br>
Warnings were added on startup to inform administrators of<br>
the risks of having a SIP peer configured with a different<br>
setting than that of the general setting. The documentation<br>
now strongly suggests that peers are no longer configured<br>
for NAT individually, but through the global setting in the<br>
"general" context.<br>
<br></blockquote><div><br>This seems very counter-intuitive for anyone that has their asterisk server on a public IP address and serves clients both behind and not behind NAT. I've always viewed it as the nat= setting inside the [general] context is for whether or not the asterisk server itself is behind a NAT, and then the nat= setting inside each [peer] definition is based on whether or not that particular peer / endpoint was behind nat or not. Have I viewed it incorrectly all this time?<br>
<br>On that note, why have the nat= setting on peers in the first place if it's insecure / not recommended to have a setting that differs from the general nat= setting. I'm not trying to be smug, I'm generally curious about the reasoning behind taking this approach to deal with this security issue, instead of changing code somewhere (I'm not a programming, and thus have no idea how complicated such a change would be).<br>
</div></div><br>-- <br>Thanks,<br>--Warren Selby, dCAP<br><a href="http://www.selbytech.com" target="_blank">http://www.SelbyTech.com</a><br><br>