Logfail monitoring

[Trace Trembath]

I'm running OpenVMS 7.3-1 (although I think my question is version independent). What is the relationship between the Login Failures parameter of a user's authorize record and the security journal?

I have a job that does the following;

1) Produces a report of all of the login failures since the previous day.

Anal/Audit/even=(logfail,breakin)/noint sys$manager:security.old

(Where a new security auditing file is created everyday and yesterdays is now security.old.)

2) Scans the authorize record for any users with Login Fails greater than 2.

What I'm seeing is that part 2 above seems to find user records with Login Fails greater than 2, but there aren't 2 or more login failures being reported by part 1 above.

How does a user get login failures which are recorded in the SYSUAF, but don't get reported in the AUDIT file? I did some testing and each of my login failures was counted in the SYSUAF and came up when I checked the security audit file. So I'm confused.

Thanks for any and all helpful hints.

Regards,
Trace Trembath

[Garry Fruth]

Your audit files only reflect yesterday. Is it possible that some of the login failures were from two or more days ago? E.G., I tried twice to login on 1/1/05, but never tried again. SYSUAF would show two failures, but yesterdays audit log would show none.

[Garry Fruth]

Another possibility, does SHOW AUDIT show all types of login failures? Dialup, Local, Remote, Network....

[Eberhard Wacker]

Hi Trace,

only an INTERACTIVE login of the user resets by default the value of the login failure count in the SYSUAF although the counter raises also with any other e.g. network login failure.
(an own written program would be an alternative to zeroes the login failure count of other accounts)

So your analysis job must run immediatley after the creation of the new security journal file, the user must have made a successful interactive login the day before and you must encounter the mismatch you've described: only in this case it's a real mismatch and a further analysis of your AUDIT settings has to be done.

Cheers,
EW

[Jan van den Ende]

... or,
your scan of SYSUAF login fails should register all nonzero loginfail counts, and todays run should subtract yesterdays counts for each account with nonzero fails.
But even then you have to somehow deal with accounts that HAD a nonzero count, cleared it by a corrent interactive login, and then accumulated other login fails. THOSE however should show as more fails in AUDIT than in SYSUAF.

hth.

Proost.

Have one on me.

jpe

[Trace Trembath]

The job that analyzes the audit file renames the audit file before it performs the analysis and, since it runs everyday, the analysis should always be based on the previous days data.

One thing about the sysuaf job I failed to mention is that it sets the password of the account as "pre-expired" when it encounters a "Log Fails" setting geater than 2. The next day it skips any accounts with passwords that are pre-expired.

Therefore, I'm pretty sure that;

1) The logfail count in authorize is from the previous day.

2) The audit job is reporting all login failures since yesterday.

3) I think the audit process is set to call all login failures. Here's the setting of the audit server.

System security audits currently enabled for:
ACL
Authorization
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached

I'm still consfused. Thanks for all help.

Regards,
Trace Trembath

[Garry Fruth]

I noticed that SSH in my test environment has an odd way of reporting login failures. Try this:
- REPLY/ENABLE=SECURITY
- SSH localhost
enter an incorrect password

From the OPCOM messages regarding security, I found that the user TCPIP$SSH increased the number of login failures; indicated as a "System UAF record modification". Followed by a "Network login failure" for the username TCPIP$SSH. With enough failed attempts, a "Network breaking detection" event for my username occured.

HP TCP/IP 5.4 ECO 4.

[Jan van den Ende]

Trace,


One thing about the sysuaf job I failed to mention is that it sets the password of the account as "pre-expired" when it encounters a "Log Fails" setting geater than 2. The next day it skips any accounts with passwords that are pre-expired


Unless you also forgot to mention some special processing for 1 or 2 login fails :-)

If yesterday there was 2 login fails - no action.
Tpday 1 login fail: totals to 3, but AUDIT correctly only noticed one.

Can this explain it, or is this not enough slack for your observations?

hth

Proost.

Have one on me.

jpe