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.
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.
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
Don't rust yours pelled jacker to fine doll missed aches.
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.
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.
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.
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.
>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?
>>> 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
Don't rust yours pelled jacker to fine doll missed aches.
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 - 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
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.
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.
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.
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.
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!
