How to audit account logins and disuser

[Victor Mendham]

How can I audit for accounts getting disusered?

Should I search for the account first?
Should I search for the disuser flag?
Should I search for failed logins?

Does anyone have any examples of these audits calls or one which would search for what is required?

[Lokesh_2]

Hi Victor,

The following command will enable the SYSUAF changes.

$SET AUDIT/ENABLE=AUTHORIZATION/AUDIT
$SET AUDIT/ENABLE=AUTHORIZATION/ALARAM

HTH,
Thanks,
Lokesh

[Ian Miller.]

you should look for SYSUAF modify audit records
/EVENT_TYPE=AUTH and look for the SYSUAF_MODIFY records for the usernames

If you have people altering other usernames when they are don't supposed to then thats bad.

[Willem Grooters]

Failed logins can be found in accounting (if enabled - it usually is) regardless audit:

ACC/TYPE=LOGFAIL

/BRIEF for an overview, /FULL for detaild information.

Another one you may want to use:

SHOW INTRUSION

(requires SECURITY privilege) to find break-in attempts. (Tailoring has been discussed before in this forum)

I know both are 'after the event', quite useful for control.

Willem

[Ian Miller.]

Tools such as these
ftp://ftp.process.com/vms-freeware/fileserv/scanuaf.zip
ftp://ftp.process.com/vms-freeware/fileserv/uaf.zip
can be used to scan the uaf for usernames with the DISUSER flag set. Or doing LIST/FU and searching the resulting file can find them too.

if you have audit records enabled for failed logins then these can be looked at using

ANAL/AUDIT/EVENT_TYPE=LOGFILE

[Victor Mendham]

Thanks,

I already have the server set to audit login, logfail etc.

But it's weird for one account I can see the failed login, then the next failed login, then the next failed login. The changing the analyze, I can see the account getting disusered.

But for the other account, I can not see more than one failed login attempt and then I do not see the other failed attempts, yet
I do see all the batches failing becuase the account is disusered. Do I have to specify the type of logfailure when auditing?

Vic...

[Jan van den Ende]

Victor,

probably your account GETS disusered by the detection of multiple failed logins!

There are quite a few handles to turn to fine-tune HOW your system reacts to login trials and failures thereoff. They are the SYSGEN LGI group of params.

Perhaps the quickest overview you will get from MCR SYSGEN HELP SYS_PAR LGI

hth

Jan

[Dale A. Marcy]

Victor,

You stated:

"But it's weird for one account I can see the failed login, then the next failed login, then the next failed login. The changing the analyze, I can see the account getting disusered

But for the other account, I can not see more than one failed login attempt and then I do not see the other failed attempts, yet
I do see all the batches failing becuase the account is disusered."

Is the second failed login coming from the same source as the first failed account? If so, I believe that is the way the intrusion records work. Once a specific source has been flagged as an intruder, a failed attempt to any valid account from that source disusers that account.

[Victor Mendham]

Jan,

Many Thanks on the "MCR SYSGEN HELP SYS_PAR LGI" cmd...

I do know these and have many of them set.

I now have another question... related to the user UIC's

lets say the following are set
LGI_BRK_TERM is 0
LGI_BRK_DISUSER is 1
LGI_RETRY_LIM is 3
LGI_BRK_LIM is 3
LGI_BRK_LIM is 1000

Ok now lets say the main account which is disusered due to incorrect pwd is [500,1]
now the next account which a copy and is [500,1] as well will it gets disusered as well? Now lets say I have 50 accounts with the same uic [500,1], what about them. Is this (disuser, intrusion watching, actioning ) by specific uic or by group uic?

Ok now lets say the next account is [500,2], it should not be affected it [500,1] is disusered right?

[Bojan Nemec]

Victor,

The disuser flag is set only to one user. If other users have the same UIC this doesnt affect them.

Bojan

[Lawrence Czlapinski]

Victor, if we had LGI_BRK_DISUSER set to 1, I would be getting calls all hours of the night. Unless your site is extremely concerned about security, I would recommend setting LGI_BRK_DISUSER 0.
After setting alarms on authorization file changes, system.dis mail list should get emails about changes. These emails should tell you what accounts are getting disusered.
BREAK-IN emails would also tell you the accounts being disusered on the 4th attempt.
Most of the time you could look through LOGFAIL emails. However if a terminal is stuck on attempting logins, that day's LOGFAIL email can be filled with many logfail messages.
CAUTION: With LGI_BRK_LIM of 3, any account on your system could be disused by anyone attempting to get into it three times including SYSTEM and your personal account if the username is known.

[Victor Mendham]

Lawrence, I hear you, it has happened.
This is what we use each night to get a list of possible instrusion accounts within a script..

$ ANALYZE/AUDIT/SINCE="-1-00"/EVENT=BREAKIN/OUTPUT/BRIEF 'aud'
$ IF F$FILE_ATTRIBUTES( "audit.lis", "ALQ") .EQ. 0 THEN GOTO nomail
$ MAIL/SUBJECT="Nodename Daily Security Check." audit.lis "''mail_list'"

Regards,
Vic...

[Jan van den Ende]

Victor,


Now lets say I have 50 accounts with the same uic [500,1],


maybe a little off-topic, but, if you have (as obvious) a more-than-absent interest in system security, then WHY do you have multiple usernames at the same UIC??

--- MOST system security aspects are UIC-based rather than username-based!!

--- just wondering.


Jan

[Ian Miller.]

Your problem appears to be that you dont see some activity in the audit record that you think you should - is this correct?

change your ANAL/AUDIT to remove the /EVENT=BREAKIN to see all the records. The event type may someother type not BREAKIN.

Can you post the result of SHOW AUDIT/ALL so the various events you have selected can be seen.

[Lawrence Czlapinski]

Victor, modifying of authorization flags is included in AUDIT type SYSUAF, subtype SYSUAF_MODIFY.
Method 1 without pipe.
You should create an output file:
$analyze/audit/event_type=sysuaf/since=yest/before/FULL/OUT=AUDIT.OUTPUT
Then:
$SEA file_spec "disuser"/window=(lines_above,lines_below)/out=file_spec_disuser
Method 2:On OS versions with a PIPE command, a PIPE command could be used. A PIPE command something like the following format with appropriate subsitutionsshould work .
PIPE analyze /audit /event_type=sysuaf
/since=yest/before/FULL/OUT=SYS$PIPE | SEA file_spec "disuser"/window=(lines_above, lines_below)/out=file_spec_disuser.report
Lawrence

[Ian Miller.]

unfortunally SEAR/WIN does not work with PIPEs so use the first version

[Victor Mendham]

This is what happens when you inhert a system, and the vendor convinces someone that all id's need the same uic, then try convincing them that they can't use group [1,*], for everything or asking them what exact privileges they need cause they don't need everything.

To track some of this we even started capturing those using OPER priv a few mth's ago, and guess what, they stopped mucking about, I bet if I remove it, they'll start up again.

Mickeymouse>sho audit/all
List of audit journals:
Journal name: SECURITY
Journal owner: (system audit journal)
Destination: SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL
Monitoring: enabled
Warning thresholds, Block count: 100 Duration: 2 00:00:00.0
Action thresholds, Block count: 25 Duration: 0 00:30:00.0

Security auditing server characteristics:
Database version: 4.4
Backlog (total): 100, 200, 315
Backlog (process): 5, 2
Server processing intervals:
Archive flush: 0 00:01:00.00
Journal flush: 0 00:05:00.00
Resource scan: 0 00:05:00.00
Final resource action: purge oldest audit events

Security archiving information:
Archiving events: none
Archive destination:

System security alarms currently enabled for:
ACL
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached,server
Logfailure: batch,dialup,local,remote,network,subprocess,detached,server
FILE access:
Failure: read,write,execute,delete,control

System security audits currently enabled for:
ACL
Authorization
SYSGEN
Audit: illformed
Breakin: dialup,local,remote,network,detached
Login: batch,dialup,local,remote,network,subprocess,detached,server
Logfailure: batch,dialup,local,remote,network,subprocess,detached
Logout: batch,dialup,local,remote,network,subprocess,detached,server
Privilege use:
OPER
FILE access:
Failure: read,write,execute,delete,control
SYSPRV: read,write,execute,delete,control
BYPASS: read,write,execute,delete,control
GRPPRV: read,write,execute,delete,control
READALL: read,write,execute,delete,control

Do we have enough stuff???

[Ian Miller.]

you could add time and I think you can do the process control services like STOP/ID

[Ian Miller.]

See HELP SET AUDIT/ENA for the PROCESS keyword.

However I think you have a people problem. the audit trail just collects data but the fundamental problem is the people misusing privs.