On Thu, Feb 16, 2012 at 12:30 PM, Kevin P. Fleming <[email protected]>wrote:
> On 02/11/2012 06:59 PM, Bruce B wrote: > >> If your server is open to the internet and in SIP general section you >> have nat=no and in peers you have nat=yes or vice versa then it's >> possible to enumerate your extension. Because Asterisk responds with >> different messages if the extension exists or not based on that >> difference in the nat setting then it's possible to tell if an extension >> 100 exists or not. Over the past few years, Digium has come to >> realization to respond to all unauthenticated calls the same way in >> order to thwart any attack attempts or guesses on the extension but it's >> still not perfect yet as these improvements are done at a really slow >> pace. Regardless, they are being made and there truely is a security risk. >> > > "really slow pace"? Please point out any one of these issues that took an > unnecessarily long time to resolve once it was identified and brought to > the development team's attention. > > Was referring to general state and mindset of logging and standardizing it for security tools. I was not referring to any Jira issues particularly though sometimes it takes a lot to convince the dev team something is a bug or missing. Security should be taken more importantly and I don't feel it is. A good example is that of "core set verbose 0" effecting all the logging and rendering all security tools useless. There is another thread going on about this right now... > >> I always use nat=yes. I don't even know why nat=no exists as there is >> nothing that can't be done with nat=yes. Plus nat=yes will take care of >> some of the surprise one-way audio scenarios as well so why use nat=no >> at all?! I vote to totally get rid of the nat setting all together and >> hard code it and set it to yes but again there are others who may not >> agree. >> > > As was already pointed out in the discussions that lead up to the 'nat' > default being changed, there are SIP endpoints out there that do not work > properly with 'nat=yes' (or 'nat=force_rport'). They behave improperly when > Asterisk adds an 'rport' parameter to the top-level Via header in its > responses. Setting 'nat=no' is the only way to keep this from happening. I agree. Wish they followed a standard to make everyone's life easier. > > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: [email protected] | SIP: [email protected] | 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 -- > 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<http://lists.digium.com/mailman/listinfo/asterisk-users> >
-- _____________________________________________________________________ -- 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
