Gregory Boehnlein wrote: >> 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. >> > > This is one of the things that we discussed at Astridevcon in 2008, and > several questions came up; > > 1. Should this even be Asterisk's responsibility, when it can already be > implemented w/ external tools that are much better suited to the task, are > already well supported and work really well: > > http://www.voip-info.org/wiki/view/Fail2Ban+(with+iptables)+And+Asterisk >
Responsibility? That's a difficult word. Is it irresponsible to build a program without additional security if building in that security is possible? Whose responsibility is the security of the Asterisk system as a whole? ONLY the administrator? Or both the dev team AND the administrator? If it's ONLY the administrator, then that could speed things up in development (who needs to worry about clean threads or buffer checking?). I'm of the opinion it should be both. Yes, there are other cobbled together hacks out there that can help protect things here and there, but how many hacks does it take before the whole system itself is nothing more than a hack? > 2. What are the implementations of having a blocking scheme like this when > you have 100 phones behind NAT? (The simple answer to this is to allow > whitelisting of known address blocks) > Most banning logic in ANY firewall scenario simply assumes every and all machines are suspect unless you specifically say they're not. Whitelisting blocks and IPs, or having 'lesser' stringent checks on blocks and IPs is a good way to handle this. > 3. It would be very difficult to develop a security model that works for ALL > channel drivers. It is easier to think about using a method that works for > chan_sip, but a more detailed framework is necessary for all other channel > drivers. > If the big problem is chan_sip, then you start there and build the others as you decide how. It's a far better idea to secure what can be secured when you can secure it, instead of waiting around for a grand unified theory of security models for an indeterminately long period of time while the holes still exist. Like any sort of warfare, you fortify the things that need fortification, and you can skimp on the areas that are unlikely or drastically more difficult targets, as the likelihood of an enemy going after those first is slim. N. _______________________________________________ --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