On Thu, Dec 8, 2011 at 4:47 PM, Asterisk Security Team < [email protected]> wrote:
> Asterisk Project Security Advisory - AST-2011-013 > > > <snip> > Description It is possible to enumerate SIP usernames when the general > and user/peer NAT settings differ in whether to respond to > the port a request is sent from or the port listed for > responses in the Via header. In 1.4 and 1.6.2, this would > mean if one setting was nat=yes or nat=route and the other > was either nat=no or nat=never. In 1.8 and 10, this would > mean when one was nat=force_rport or nat=yes and the other > was nat=no or nat=comedia. > > Resolution Handling NAT for SIP over UDP requires the differing > behavior introduced by these options. > > To lessen the frequency of unintended username disclosure, > the default NAT setting was changed to always respond to the > port from which we received the request-the most commonly > used option. > > Warnings were added on startup to inform administrators of > the risks of having a SIP peer configured with a different > setting than that of the general setting. The documentation > now strongly suggests that peers are no longer configured > for NAT individually, but through the global setting in the > "general" context. > > 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? 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). -- Thanks, --Warren Selby, dCAP http://www.SelbyTech.com <http://www.selbytech.com>
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
