Re: [fw-wiz] Handling Invalid Login Requests in Firewall

• Previous message: Vinicius Moreira Mello: "Re: [fw-wiz] [1/2 OT] Tool to "draw" network topology"
• In reply to: Ravi: "Re: [fw-wiz] Handling Invalid Login Requests in Firewall"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: Ravi <ravivsn@roc.co.in>
Date: Thu, 22 Jan 2004 18:44:54 -0800

     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>
>>
>>_______________________________________________
>>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

• Previous message: Vinicius Moreira Mello: "Re: [fw-wiz] [1/2 OT] Tool to "draw" network topology"
• In reply to: Ravi: "Re: [fw-wiz] Handling Invalid Login Requests in Firewall"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]