Re: Handling Invalid Login Requests in Firewall

[DLN Krishna <dlnk () intotoinc com>]

    Yeah this is a good idea.

    Only problem could be that the user now has to remember two passwords
    for same user.(:-(

Thanks
Krishna.
At 08:19 PM 1/22/2004 +0530, Ravi wrote:
> Hi Krishna,
> A simple solution I think of is to
>    - send emails to the user and to the administrator
>    - There will be two passwords: A master password and a normal password
>    - Normal password will be used to authenticate the user
>    - Master password will be used to change normal password
>    - The screen to enter passwords will be same to complicate life
>    - Master password can only be used once, after which the user has to 
> get it from admin
>    - On entering master password, you will be directed to a link wherein 
> you will change the normal password
> On these lines
>    - If the attacker tries X times, the normal password become useless/locked
>    - As the user also receives email of this event, it is assumed he may 
> take quick action before the admin ..( ultimately he Could be the victim 
> not the admin ;) )
>    - User with his master password changes his normal password
>    - Master password can only be used after normal password is locked
>
> Drawbacks I can think of:
>    - It is a fact that passwords are always a weak link to security
>    - The attacker may spend all of his time only to block the user  ;) , 
> first he tries for normal password locking and then when it is locked 
> tries for master password locking that results in entire blocking  !!
>
> Again to improve
>    - X should be random number less than a critical value say 20
>    - Once the normal password is locked, the user MUST login from a diff 
> IP address ( Attacker will not know this number X, so he MAY keep on 
> trying on the same PC )
>    - The logic should be: After normal password is locked, and again 
> attempts come from same IP then ignore all attempts even if genuine 
> unless admin  clears this flag
>
>
> Tell me if this OK, or we will work further to improve the security.
> Thanks,
> Ravi
> Rendezvous On Chip (I) Pvt Ltd.,
> Hyderabad
> INDIA
>
>
> Don Parker wrote:
>
> > The lockout approach after n amount of failed logins is still the best imho.
>
> > Sending an email to the sys admin about repeated failed attempts may just 
> > as easily not be addressed for as you say they are normally fairly busy. 
> > Though it could be a form of DoS as you say, the person doing it would 
> > still have to obtain valid user names to do so with. There is no silver 
> > bullet for this scenario unfortunately, but the lock out after failed 
> > attempts is still the best that I am aware of.
> >
> > Cheers
> >
> > -------------------------------------------
> > Don Parker, GCIA
> > Intrusion Detection Specialist
> > Rigel Kent Security & Advisory Services Inc
> > www.rigelksecurity.com
> > ph :613.249.8340
> > fax:613.249.8319
> > --------------------------------------------
> >
> > On Jan 16, DLN Krishna <dlnk () intotoinc com> wrote:
> >
> > Hi,
> >
> >     In one of ASIAN countries, firewall criteria indicates that, if user 
> > tries to log into
> >     the firewall appliance for more than X number of times, appliance 
> > MUST not
> >     allow that user to log-in until the password of the user is changed.
> >
> >     There is another school of thought that this type of behavior might 
> > become
> >     DoS for genuine users.  It is possible that, the attacker might try 
> > to log-in
> >     multiple times with victim's user name and give wrong password. When 
> > this happens,
> >     victim will not be able to access, until his password is changed by 
> > Administrator.
> >     Administrator might take many hours to change the password and also 
> > this can
> >     become a big head-ache for administrator.
> >
> >     I feel that, logging a message (or sending alert to the 
> > administrator) when
> >     log-in is not successful for X number of times with information such as
> >     source IP and source Port and user name, which is being used to log-in,
> >     would be good, over denying any further log-in attempts.
> >
> >      I would appreciate, if somebody could shed some light on any better
> >      approaches to handle this.
> >
> > Thanks,
> > Krishna
> > CTO Office
> > Intoto Inc.
> > www.intotoinc.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ***********************************************************************
> > * D L N Krishna,     dlnk () intotoinc com
> > * Intoto Inc.                             voice : (408)844-0480 Ext 332
> > * 3160, De La Cruz Blvd, #100,            fax   : (408)844-0488
> > * Santa Clara, CA - 95054
> > ***********************************************************************
> >
> >
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () honor icsalabs com
> > <a href='http://honor.icsalabs.com/mailman/listinfo/firewall-
> > >wizards'>http://honor.icsalabs.com/mailman/listinfo/firewall-wizards</a>
> >
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () honor icsalabs com
> > http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
















***********************************************************************
* D L N Krishna,     dlnk () intotoinc com
* Intoto Inc.                             voice : (408)844-0480 Ext 332
* 3160, De La Cruz Blvd, #100,            fax   : (408)844-0488
* Santa Clara, CA - 95054
***********************************************************************


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards