audit logins for a particular user

[TMcB]

Hi everyone.
i would like to audit logins for one particular user.

At present we audit all logfailures and breakins.
But I'm not sure how to set up auditing the logins for just one user.

Any advice is greatly appreciated

[Craig A]

You need to make sure that your audits are properly enabled.

Do a $show audit and post the details here.

Have a look at the ANAL/AUDIT utility - This will allow you to interrogate the security audit journal file.

E.g. $ ANAL/AUDIT/FULL/SEL=USER= -

HTH

Craig

[TMcB]

Hi there.
Thanks for getting back to me.

current settings are :
System security alarms currently enabled for:
ACL
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached

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


I'm happy enough with using the ANALYZE/AUDIT commands for single users, but at present we dont audit successfull logins.

I know to set it up for all users would be :
set aud /audit /enable=( login=all),
but I dont want to record successful logins for all users - just for one particular user.

Cheers

[Craig A]

You can set an audit flag for each individual user but this will generate a LOT of audits for a typical user:

$ MC AUTHORIZE MOD /FLAG=AUDIT

What info do you want to capture regarding the login session?

Can you get it from ACCOUNTING instead?

Craig

[abrsvc · Accepted solution]

I have used a specific login procedure for an individual account to capture info with the final statment a reference to the standard login procedure. It all depends on what information you are trying to capture. If you can describe in more detail, what you with to log, we can provide some methods.

Dan

[TMcB]

Hi there
I just want to record the dates and times and from where the user logged in.

[Craig A]

You could add something in SYLOGIN.COM (maybe checking whether the caller holds an identifier - e.g. AUDIT$USER)

and log info lik:

f$getdvi("tt",""tt_accpornam")

or a $show term

That coupled with info from ACCOUNTING should get you what you want.

Craig

[Jan van den Ende]

TMcB,

this may or may not be usefull to you, but many moons ago we had a need to occasionally allow remote service access to our system by a remote package supplier.

We DID need to know if they ever touched sensitive info they had no business with.

We provided a captive login to an account, which only did a
$ SET HOST 0/LOG=
with embedded username/password
to another account on another device.
The "entry" account directory was pretty hard shielded and tripwired for any access by the "work" account.

The entry account was normally disusered, and only activited when needed, so we knew when a review was desired.

This may or may not be what you need, but it worked for us.

hth

Proost.

Have one on me.

jpe

[TMcB]

thanks -
i think using the users login.com file will be the easiest route. Will look into this

[Craig A]

That MIGHT work but also bear in mind that a user will typically have full access to their LOGIN.COM so could easily circumvent anything you place in it for auditing purposes.

Craig

[abrsvc]

If there is concern about a user modifying their own login procedure, than I would add a line in the system wide procedure for that specific user. The F$USER lexical will return the UIC. Usse that to filter the logging for your specific user in the common login file.

Dan

[Craig A]

Dan

Depending on how Change is managed in an environment will determine whether to go for a user-specific solution (i.e. username of UIC) or a more generic solution.

Personally, it is as much hassle to do the generica solution as it is to do the specific, so that would always be my route.

Craig

[abrsvc]

Craig,

Agreed, all is dependent upon the environment. Another possibility that I have used is to change the LGICMD field in the uaf to point to a "logging" procedure that chains to the standard common login procedure. This makes changing logging easy. All that is needed is to change the UAF entry to point to the logging procedure. I have used this technique in the past as well. The bottom line is that you need to determine the security level needed as well as what flexibility you need to accomplish your goal.

Dan

[Joseph Huber_1]

>TMcB:
>At present we audit all logfailures and breakins.

Since the workarounds in sylogin or /flag=defcli are all rather clumpsy,
could You explain why enabling audit for LOGIN (dialup,local,remote,network only) is not an option for Your system?

[Jan van den Ende]

Craih,

>>>
That MIGHT work but also bear in mind that a user will typically have full access to their LOGIN.COM so could easily circumvent anything you place in it for auditing purposes.
<<<

THAT is why the second user is completely distinct from the "tranfer" user!

The tranfer user has its own GROUP UIC, and the directory with SET HOST 0 /LOG in LOGIN.COM is as tight as can be!

TMcB:
Success!

Proost.

Have one on me.

jpe

[TMcB]

Hi
I didnt want to enable all logins as we have thousands of users and i thought I had read previous warnings that it would be too much to log ALL logins for every user.

If this is not the case, I could just turn on auditing for all successfull logins.

Thanks

[Craig A]

Jan

I've never been a fan of this sort of auditing as it is so easy to circumvent.

Craig

[Hein van den Heuvel]

>> thanks -
i think using the users login.com file will be the easiest route. Will look into this

Hmmm,

I guess a simple ACCOUNTING report does not give teh righ access port information?

If you need a specific log then I would NOT put it in the normal use LOGIN.COM.
Either put this(*) in SYLOGIN, in a IF "xxx".EQS.F$GETJPI("","USERNAME")

or...

How about modifying the user lgicmd in authorize and point it to a special loginLOG.com which does this(*) logging and then chains to the real login.com

Hein

(*) this =

$ OPEN/APPEN log system_directory:world_writable.log
$ WRITE log write sys$output F$CVTIME(""), " ",f$getjpi("","USERNAME"), " ",f$getdvi("SYS$COMMAND","TT_ACCPORNAM")
$ CLOSE log

Better still would be process creating a permanent mailbox with a system logical name. Loop reading the mailbox writing to the log which now no longer needs world write access.

[Joseph Huber_1]

>>warnings that it would be too much to log ALL

It of course depends (disk-space , do all the thousends user login/logout very frequently ?).
I think if the LOGIN audit is restricted to
/LOGIN=(DIALUP,LOCAL,REMOTE)
then all interactive logins are catched (maybe NETWORK for SSH logins ?).
The vast amount could be detached,batch,subprocess,server, and those would make grow the audit file, not the interactive ones, they occur on a "human" time scale.

[Joseph Huber_1]

Apropos audit file disk space usage:
How about rotating (set audit/server=new_log),
then after evaluation archive the old file into a ZIP archive:
audit log files compress with an avarage ratio of ~90%, so the increase for login auditing is easily compensated.

[John Gillings]

T,

Here's a neat trick for generating customised audits for whatever you like. An example for your specific case, I'll call your user AUDIT_ME.

First create an empty, world readable file, with a name that indicates what you want to audit:

$ CREATE/PROTECTION=(W:R) SYS$MANAGER:LOGIN.AUDIT

Now add an ACL which specifies a READ+FAIL security audit ACE, and an ACE to pick out who you want to trigger it:

$ SET SECURITY/ACL=((AUDIT=SECURITY,ACCESS=READ+FAIL),(IDENTIFIER=AUDIT_ME,ACCESS=NONE)) SYS$MANAGER:LOGIN.AUDIT

Now, in SYLOGIN.COM trigger the audit:

$ PIPE TYPE SYS$MANAGER:LOGIN.AUDIT >NL: 2>NL:

(we're using PIPE here to redirect any output or errors to NL:, since it's single stage PIPE everything occurs in the context of the current process, so no real expense).

Since the file is W:R, this will be a NOOP for most users. For user AUDIT_ME, they'll trigger the AUDIT ACE, and generate an event in the audit journal. You can identify it by the object name LOGIN.AUDIT.

In practice, I'd use identifier LOGIN_AUDIT and then:

UAF> GRANT/IDENTIFIER LOGIN_AUDIT AUDIT_ME

this gives you a simple way to request the audit for other users.

The same mechanism can be used for anything you like. Use the PIPE TYPE command to generate a message.

If you have a code path that only your target user(s) will execute, it's even easier. Same empty file, but:

$ SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=READ+SUCCESS)SYS$MANAGER:LOGIN.AUDIT

and:

$ TYPE SYS$MANAGER:LOGIN.AUDIT

(since you won't generate an error message, and the file is empty, you don't need to redirect output).

For this to work, you need to have ACL audits enabled. From your SHOW AUDIT posting, you already have that.

[John Gillings]

A couple of other points...


Why not audit all LOGINs for all users? For that matter throw in LOGOUTs as well. At today's storage prices, for a few cents you'll have capacity for hundreds of years worth of login traffic. Remember, it's easy to throw away data that you've gathered, but you can't recover data that you didn't capture.

Enabling AUDIT in the UAF will also work, but you'll also audit entries for literally everything that user does! Probably not what you want, especially if your objective of not capturing all logins is to save space. The data volume for a single login and immediate logout for a UAF AUDIT flagged user would probably exceed all the login and logout traffic for all your users across a week!

[Hein van den Heuvel]

Expanding on John's idea...

Set a success audit on the users LOGIN.COM ?

- Yeah you can have false positives
- Do not tell user about Username: xxx/NOCOM
:-)

Hein

[Jan van den Ende]

Hein,

>>>

- Yeah you can have false positives
- Do not tell user about Username: xxx/NOCOM
<<<

... OR... like I said before, have this user be CAPTIVE!! Blocks /NOCOMM

Proost.

Have one on me.

jpe

[John Gillings]

Taking Hein's idea of applying the audit ACE to LOGIN.COM one step further... the problems are:

1) User's LOGIN.COM is owned by them, so could be modified, breaking the mechanism

2) They may execute LOGIN.COM other than at login time, giving false positives

Try this.

Create a command procedure:

SYS$COMMON:[SYSMGR]AUDIT_LOGIN.COM (W:RE)
$ @SYS$LOGIN:LOGIN

put audit ACLs on this procedure:

$ SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=EXECUTE+SUCCESS)

For any users you wish to audit, change their UAF entry:

UAF> MODIFY user/LGICMD=SYS$STARTUP:AUDIT_LOGIN

Invoking the system level procedure will trigger the audit, and then execute the default login procedure for the user.

There is a 3rd issue:

3) /NOCOMMAND or /COMMAND=other-file

As Jan suggested /FLAG=CAPTIVE will block that, but it's a bit harsh. Perhaps /FLAG=RESTRICTED?

(an example of the application of Hext's rule - a further level of indirection solves all problems)