Running ANALYZE/AUDIT on a remote node via DCL

[stinehelferw]

I need to run the command:

ANALYZE/AUDIT/EVENT=LOGIN SYS$MANAGER /OUT=USER_LOGINS.TXT

on remote nodes to extract login data from audit logs.

The command requires privledges on the remote node above standard privledges.

How to I raise to privledges similar to SET PROC/PRIV=ALL remotely before issuing the command?

One approach would be to have a DCL file on each node that has both commands in it and can be run remotely. I'd like to do this without that extra baggage though.

[Steven Schweda]

> How to I raise to privledges similar to SET
> PROC/PRIV=ALL [...]

Use a command like "SET PROC/PRIV=ALL" before
the ANALYZE command?


MCR SYSMAN HELP DO

Also, [...] HELP SET ENVIRONMENT /NODE


Have you already tried something which didn't
work? (What? How?)

[Robert Gezelter]

stinehelferw,

(posted once, but ITRC dropped it during the post)

One must be careful in this situation not to create a facility that can be exploited to compromise or damage the system.

I recommend a thorough reading of the manual and the HELP text. I do not believe that SET PROCESS/PRIVILEGE=ALL is needed to analyze the security log. I am sure that turning on all privileges gets the job done, but it can (and should in a recurring procedure) be done with the minimum needed privilege.

The safest way to set up privileged accounts on OpenVMS is to set the authorized privileges to the minimum (often NETMBX, TMPMBX) and provide that the user can raise privileges using the SET PROCESS/PRIVILEGE command.

An account can be created that has the necessary privileges enabled by default.

Accounts are maintained on each system using the AUTHORIZE utility.

If a special account is created for this purpose, it should probably be restricted to network logins AND have the minimum privilege required.

A batch job that runs at a specified time (and resubmits itself; with each run saving the file under a different name) is a far safer alternative. In that case, the file can be retrieved over the network, but the running environment cannot be abused from another machine.

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

[Jon Pinkley]

stinehelferw,

Obviously these commands must be executed from privileged context. You haven't specified how the remote systems are connected to the location that you are in. Is there a DECnet connection, or better yet a cluster interconnect? In any case you will need access to a privileged account on the systems you need to execute the commands on.

I do agree with Bob's suggestion to create the report in a batch job that runs periodically on the remote systems. Do you have something that creates new audit journal files on a daily, weekly or other periodic basis? That would be the most "logical" time to create the report, immediately after closing the old file and creating a new one, analyze the old one and then send the file back to the central location (this could even be done with mail).

Jon

[Hoff]

Either run it locally and email it up or (if you have DECnet Phase IV or DECnet-Plus) use some variation of the RDECW.COM tool I posted up and put onto the Freeware a while back.

http://h71000.www7.hp.com/wizard/wiz_5409.html

You could also use CGI.

http://64.223.189.234/node/277

That sort of thing (mail or HTML/CGI) could be tweaked over into XML, too.

There are other approaches around, and various monitoring tools are available that can roll up OpenVMS data into a distributed network-based management system.

If you can connect in and run "it" remotely (via web CGI, DECnet or any other such) then you also have a target for security attacks. Be careful with what you accept in, and what you then send back.

It's likely safest to use the local path; to run a periodic batch job and roll up the data and ship it off. (Possibly encrypted, depending on your data and sensitivity and how far away your receiving target is in terms of networks.)

http://64.223.189.234/node/501
http://64.223.189.234/node/97

[stinehelferw]

Yes we are running DECnet.
The computers are not clustered.
The network is issolated.
There is no connection to any other network or the outside world.
This is in a software maintenance lab.

[Robert Gezelter]

stinehelferw,

I happened to have a spare moment to try a few tests.

There are NO privileges required (repeat) no privileges required to access the default audit event file (SYS$MANAGER:SECURITY.AUDIT$JOURNAL).

What is required is that the process doing the access have authorization to read the file.

Before this thread goes further, please do a DIRECTORY/SECURITY SYS$MANAGER:SECURITY.AUDIT$JOURNAL and a SHOW PROCESS. If the UIC shown in SHOW PROCESS is symbolic, please display the actual numeric value.

Based upon this experiment, it would appear that the problem is a simple question of file protection and can be addressed as such.

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

[Hoff]

>Yes we are running DECnet....

Then you're good to go with most any of the options, quite possibly with nothing more than an ACL on the audit file and on the username for the DECnet server process or the batch job. This is five minutes of DCL.

At its simplest, add an identifier in AUTHORIZE and then establish the ACL on the audit file and within the process that will use the DCL, then follow the batch job link I posted.

http://64.223.189.234/node/97

Here's the DCL:

$ SET NOON
$ ANALYZE /AUDIT /EVENT=LOGIN -
/OUT=SYS$SCRATCH:USER_LOGINS.TXT -
SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ MAIL SYS$SCRATCH:USER_LOGINS.TXT - "user@example.com" - ! or host::user
/SUBJECT="Whatever you want"
$ DELETE SYS$SCRATCH:USER_LOGINS.TXT;*

Run that daily, at a few minutes past midnight, or later. (Avoid using midnight in clusters due to the vulnerabilty to repeated submissions within the potential time skew.) I tend to use "TOMORROW+0:7:0" or such.

I'd probably enhance that DCL above a little to use f$unique or a date stamp and the host node name on the temporary file, just to avoid collisions.

For additional information in these areas of OpenVMS, the usual manuals I recommend are the User's Guide, then the DCL Dictionary, and then (specifically for this stuff) the security manual. That latter manual gets you the ADD /IDENTIFIER command and GRANT /ID within AUTHORIZE, and then the EDIT /ACL or SET SECURITY or such; the ways to create and grant the identifier and to then tie the identifier to an object.

And the RDECW.COM approach works, too.

[Hoff]

ITRC. Gag.

There was a line wrap missed in that.

$ MAIL SYS$SCRATCH:USER_LOGINS.TXT -
"user@example.com" - ! or host::user