lgi_brk_disuser seems to be not working

[mustafa_12]

Hello,

I have changed LGI_BRK_DISUSER to 1 by:

mc sysman param set lgi_brk_disuser 1
mc sysman param write active

The value of LGI_BRK_LIM is 5. However, after I enter six wrong passwords for a specific user, it does not be a DISUSER. Instead, it becomes an INTRUDER (by show intrusion) for a duration of LGI_HID_TIM * a nondeterministic number between 1 and 1.5.

What can be the reason for that?

BR...

[Volker Halle]

Mustafa,

it worked for me as expected on OpenVMS Alpha F8.3.

Consider to use REPLY/ENABLE=SECURITY to watch the OPCOM messages during your test.

Also re-check the parameters:

$ MC SYSGEN
SYSGEN> USE ACTIVE
SYSGEN> SHOW/LGI

Volker.

[Heinz W Genhart]

Hi Mustafa

LGI_BRK_LIM defines how many times a user can try to login until something happens.

I think you should also set the SYSGEN parameter LGI_BRK_DISUSER to 1, that a user account will be set to disuser after LGI_BRK_LIM failed logins.


Regards

Heinz

[Volker Halle · Accepted solution]

Mustafa,

I believe the problem is here:

mc sysman param set lgi_brk_disuser 1
mc sysman param write active

Once you exit SYSMAN the temporary parameter values are lost. You need to do this:

$ MC SYSMAN
SYSMAN> PARAM USE ACTIVE
SYSMAN> PARAM SET LGI_BRK_DISUSER 1
SYSMAN> PARAM WRITE ACTIVE
SYSMAN> EXIT

Then it will work.

Volker.

[Ian Miller.]

I think Volker has the solution. However why do you want to set LGI_BRK_DISUSER to 1. It's not recommended and causes all sorts of fun.

From the help file
"LGI_BRK_DISUSER turns on the DISUSER flag in the UAF record when an attempted break-in is detected, thus permanently locking out that account. The parameter is off (0) by default. You should set the parameter (1) only under extreme security watch conditions, because it results in severely restricted user service. "

[Robert Gezelter]

Mustafa,

I must agree with Ian. This imposes very tight security on a global basis. The downside of this is that it can lock large numbers of accounts very, very quickly. This will require each and every account to be unlocked manually, a manpower intensive process.

I have seen auditors insist on such severe measures. I recommend that you get such an instruction in writing, because the resulting workload can create problems on a variety of fronts.

- Bob Gezelter, http://www.rlgsc.com

[Ian Miller.]

Another reason is the potential for a DOS attack. Attempt to login using other peoples usernames and get their usernames disabled.

[mustafa_12]

Thanks Volker,

The way you've suggested worked.

I want to set this variable on, since, as you have guessed, COBIT auditors want this like that. I know the possibility of DoS attack and admin-power required, but is it possible to convince them with those reasons? is there anybody?

[Ian Miller.]

Record the additional work distruption (and therefore cost) inccured and report this to management.
I assume you have pointed at the recommendation not to use this from hp (its in the help and I guess its in the docs somewhere)

[Volker Halle]

Mustafa,

make really sure, that you (and all other system managers) known the current SYSTEM account password and the physical location and correct operation of your console terminal (OPA0:). Because this will be the ONLY way to get access to your system, once all privileged accounts have been disusered...

Volker.