I have already defined an alarm for the VM login attempts with the existing attempt limitation(3) in a session. We may lock the account as in the issue description or block the IP manually, but may be after a second attempt, i.e. assuming superadmin is notified with the first.
But I am not sure about the idea of a "fail2ban integration(?)" in the concept of this issue. Are we talking here about shipping sipx with fail2ban and editing its configuration files after this failed attempts in VM? Shouldn't this be implemented under a more general issue that aims preventing call fraud etc.? On Wed, May 11, 2011 at 4:15 PM, Tony Graziano <tgrazi...@myitdepartment.net > wrote: > > > On Wed, May 11, 2011 at 8:17 AM, Gerald Drouillard < > gerryl...@drouillard.ca> wrote: > >> On 5/11/2011 4:29 AM, barisyanar wrote: >> > Raised more questions: >> > >> > 1 - IP Ban: How would this work if the call is made via gateway (e.g. >> > Audiocodes). Should we do something with caller ID? >> Just like in fail2ban you can choose to whitelist IP's or networks. >> > >> > 2- Account blocking: Shouldn't this be a generic mechanism including >> > also user portal access failures and then password renewal automation >> > etc. (Does there exist an issue for this? I don't know ) >> Almost all the web only services send a link to your email when you >> account is locked any you try to log in. With the link you can reset >> your password. We have to think about the 2 kinds of access devices an >> maybe have different locks accordingly: >> phone >> web browser >> > >> > 3- If we come back to VM; shouldn't there be a warning playback saying >> > remaining access numbers during multiple wrong login attempts in >> > "short period". >> If you wanted to get totally automated, then the system could ask if the >> user wants a password reset link sent to their email. >> > >> > 4- The definition of "short period"? Is it a single call made to VM >> > or may it include multiple calls in a "short period"? >> I still think we can do all this with more efficient logging to >> something like sipxauth.log and use fail2ban to setup all the rules. >> The phone service can be treated just like any other public web service. >> >> It would be nice if the resulting file can be used by more than fail2ban. > Meaning an XML or text file which the admin can use to pull into their > firewall via another method. I have the opinion if the security is enacted > at the sipx level only, it requires super-superamin actions to make > something like this more permanent.I think the admin is fine using an auto > protection mechanisim inside sipx, but I also think it is necessary to be > able to harvest this and use it at the network edge and such. > > I also think it would be prudent to instantiate a blacklist of UA's inside > sipx. If the UA is "friendly scanner" it should simply be denied at sipx, no > matter how many attempts it makes. This would be a proxy function, though I > believe it would be somewhat simple to enact. > > Proxy>UA blacklist>text, one per line. > >> >> -- >> Regards >> -------------------------------------- >> Gerald Drouillard >> Technology Architect >> Drouillard& Associates, Inc. >> http://www.Drouillard.biz >> >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
