On Wed, May 11, 2011 at 8:17 AM, Gerald Drouillard
<[email protected]>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
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to