On Mar 10, 2009, at 5:55 AM, Remco Barendse wrote: > On Tue, 10 Mar 2009, Trixter aka Bret McDanel wrote: > >> On Tue, 2009-03-10 at 05:40 +0000, Vikram Rangnekar wrote: >>> The main reasons for all this brute force hacking of Asterisk (a new >>> phenomenon) is the proliferation of Asterisk (obviously) and >>> configurations >>> where the extension is the same as the authentication credentials >>> for the >>> phones (My extension is 100 my pin is 1234 and I use this for my >>> voicemail as >>> well as for authenticating my phone with the server) >>> >>> Ok well its possible your pin if 3214 even that does not really >>> matter to a >>> brute force attack over SIP where there is no real forced delay >>> between retry >>> attempts. > > I guess there should be some configurable options in Asterisk to > cover for > that. Like 10 consecutive failed login attempts should invoke > asterisk to reply a login denied to that IP address and another option > that would allow for let's say 5 attempts in 5 minutes and then > block the > extension for login. > > Make the login attempts number and blocking time configurable, > settable system wide with an option to override per extension would > close > the hole.
As Greg noted in other reply to this thread, there has been discussion on this topic in creating a generalized security framework for all IP operations. There have been a number of people who have stated clear cases as to why Asterisk should do something about these security problems. Personally, I think it's a mixed model, where Asterisk determines what is "bad", and then has rudimentary internal filters, plus (more importantly) some ability to inform external agents about those bad behaviors in order to elicit a response that is more full- featured than what Asterisk should be doing at layer 3. I can see why some would want Asterisk to stay out of the way of doing filters, but I also would suggest that some basic self-preservation would not be overly difficult to have embedded in Asterisk, and which would be impossible to detect otherwise without configuration that would be daunting to most PBX administrators. We already do account-based authorization and IP-based permissions - expanding that a bit to be reactive would probably not be a bad idea for some of the most overt attack methods such as brute-force password attempts by IP or by username, or by quantity of SIP requests in general. IAX2 would be next, then AMI... it's a slippery slope, but it's not a bad slope to slide down, unlike some others. The COPS system might work for this, or a customized interface such as the one I halfway outlined. http://astridevcon.pbwiki.com/Network+Security+Framework.2008-09-28-23-35-38 Note that there was also a response earlier (in this thread?) about DenyHost, which is a third-party app that looks at logfiles and parses out "bad" things and then takes action with filters. This would work for many of you who have written about SIP brute-force attacks being a problem. That's available right now, immediately, to mitigate some of the effects of the problems that people are commenting on. Lastly, I'd like to again note to all of you that Asterisk is Open Source, and that implies some very powerful things. If you think you have a way to author a method that will elegantly and successfully limit brute force attacks, please feel compelled to write some code! This is a very relevant problem for many of you, and would probably see a lot of interest, assistance, and testing if you come up with a viable solution. Even if it is not as full-featured as a total security model - you should think about how perhaps a short-term patch might be a part of a much larger solution. Please submit all features to bugs.digium.com and let's get started! JT --- John Todd email:[email protected] Digium, Inc. | Asterisk Open Source Community Director 445 Jan Davis Drive NW - Huntsville AL 35806 - USA direct: +1-256-428-6083 http://www.digium.com/ _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
