Monthly cleanup - how to reset audit server on a cluster using sysman

[Victor Mendham]

I run a script each day, which resets the operator.log, accountng.dat, searches the security.audit$journal for breakin attempts etc.

On a monthly basis, it resets the errlog and audit server as well. I have a situation where the other nodes in the cluster are not having the audit_server reset, and so they log to the old non-existant secuirty journal file and nothing is logged to the current log.

Does anyone know how to stop the audit server via sysman and restart it?

I'm thinking to stop and restart, can anyone confirm?

$!
$ RUN SYS$SYSTEM:SYSMAN
SET ENVIRONMENT/CLUSTER
DO SHO SYSTEM/PROC=AUD*
DO SET AUDIT/SERVER=EXIT
EXIT
$!
$ WAIT 00:00:10
$!
$ RENAME/log SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL; -
SYS$COMMON:[SYSMGR]SECURITY.OLD;
$!
$ COPY/log SYS$COMMON:[SYSMGR]SECURITY.OLD;-1 -
sys$sysdevice:[accounting.may04]SECURITY.AUDIT$JOURNAL;
$!
$ RUN SYS$SYSTEM:SYSMAN
SET ENVIRONMENT/CLUSTER
DO @SYS$SYSTEM:STARTUP AUDIT_SERVER
DO SHO SYSTEM/PROC=AUD*
EXIT

Any thoughts?

Also, one other thing, How can I make it so that each month the files are copied to a new directory with the month naming convention.

What I mean is instead of ..
$ COPY/log SYS$COMMON:[SYSMGR]SECURITY.OLD;-1 -
sys$sysdevice:[accounting.may04]SECURITY.AUDIT$JOURNAL;

replace the .may04] with a symbol or lexical function to automate the process for each month?

Like copy files to the current month subdir. l

[Lokesh_2]

Hi ,

To create now log file, the command is

SET AUDIT/SERVER=NEW_LOG.

For more information see VMS online help. Here is a portion of that for your reference:

NEW_LOG Creates a new clusterwide audit log file.
Typically, this is used daily to generate a
new version of the audit log file.


HTH,
Thanks & regards,
Lokesh Jain

[Victor Mendham]

But does the NEW_LOG reset the size back to zero?

My journal file is between 1-2 million blocks due to the amount of auditing we do. So I need to shutdown the audit server, to allow a new clean zero size log to be created. This is one reason I move it from sys$manager to another dir, where it is offloaded to tape. If I had another disk, I would offload all of it to improve performance of the system disk.

[Lokesh_2]

Hi,

NEW_LOG will create new version of security.audit$jounal file. You can do whatever you want with older versions .

Thanks & regards,
Lokesh

[Willem Grooters]

Victor,

I solved a similar problem with a TCPIP-service using the templates in the attachement. You can use them as an example to setup your environment.

Basic problem: the service is used many times a day and within a few days the version overflows. Also, there is a heavy requirement on audit. Now I have all logs stored by date, preventing overflow.

Willem

[James C. Nix]

One strategy is to start a new file nightly (NEW_LOG). Use lexicals to incorporate the date into the name of the "old" log file (i.e. SECURITY_040503.AUDIT$JOURNAL) and delete any log files older than the on-line retention period (30, 60, 90... days).

Assuming a proper backup plan, log files older than the on-line retention period can be recovered from tape, etc.

In a cluster all log files can be placed in a node specific sub-directory for ease of analysis (incorporating the node name in the log file name suggested).

Because of their possible size and I/O, the storage should be located on a dedicated high availability drive (NOT the sytem drive or the swapfile drive).

The same applies to the accounting log files.

[John Gillings]

Victor,

First make certain that all nodes share a common VMS$AUDIT_SERVER file. The default is SYS$COMMON:[SYSMGR]VMS$AUDIT_SERVER.DAT. If you're a single system disk cluster it will all "just work", but for multi system disk clusters you MUST arrange for all nodes to share a physically common file by defining /SYSTEM/EXEC logical names on all nodes.

Once you have a common VMS$AUDIT_SERVER file, you can redirect all journals to a single common file with:

SET AUDIT/JOURNAL=SECURITY/DESTINATION=file-spec

Make sure the filespec translates to the same physical file on all nodes.

For the audit journal file you only need to perform the SET AUDIT/JOURNAL=NEW_FILE on ONE node. Yes the AUDIT_SERVER will use the size of the current file as a guide to preallocating the new file. This is GOOD, please don't try to defeat it by stopping the audit servers (leaving potential holes in your security!). Chances are the new file will grow to the same size, so by preallocating you avoid fragmenting the disk, and don't give yourself a false idea of how much space you have.

If the file becomes too big for some unusual reason, you can reset the size "memory" by modifying any of the space threshold values. For example:

$ SET AUDIT/JOURNAL=SECURITY/THRESH=WARN=200

Beware that the creation of the new file is ASYNCHRONOUS, so you need to make certain the changeover has occurred BEFORE renaming or copying the old file.

Here's a DCL fragment that starts a new journal file, then waits until the new file is created before attempting to archive any old versions (beware of wrapping):

$ ArchiveFile=F$SEARCH("COMMON$LOGS:SECURITY.AUDIT$JOURNAL")
$ SET AUDIT/SERVER=NEW_LOG
$ date=F$CVTIME(,"ABSOLUTE","DATE")
$!
$! Wait for new file to be created before archiving the old one
$ aud_loop: WAIT 00:00:01.00
$ NewFile=F$SEARCH("COMMON$LOGS:SECURITY.AUDIT$JOURNAL")
$ IF NewFile.EQS.ArchiveFile THEN GOTO aud_loop
$ @CLUSTER$FILES:ARCHIVE_OLD_VERSIONS 'NewFile' COMMON$ARCHIVE:

I've included ARCHIVE_OLD_VERSIONS.COM and ARCHIVE_FILE.COM as (TXT) attachments. These procedures tag the files with date stamps, you should be able to modify them to distribute the files into directories instead. Obviously you will also need to modify the code to use your own logical names rather than mine.

Note that there are similar issues with the node specific log files OPERATOR.LOG, ACCOUNTNG.DAT and ERRORLOG.SYS. Unfortunately each has it's own mechanism for rollover!

[Wim Van den Wyngaert]

Note that anal/audit accepts wildcards in the filenames.

[Victor Mendham]

John,

Here is the file which I use to reset the files. It automatically resets operator.log, account.dat and then monthly audit_server, security.audit$journal and errorlogs.

[John Gillings]

Victor,

Three potential problems with your procedure.

First, with a resubmitting batch job, it's always better to do the SUBMIT before anything else. It reduces the chances that an error or change further down the procedure will prevent the resubmission.

Second, your RENAME commands don't check that the file has actually updated. Although your code will work as you intend MOST of the time, the commands you're using are asynchronous, so you really need to check that the new file has been created before doing something with the old one.

Third, stopping the audit server across the cluster is definitely NOT a good idea. It creates a security blind spot. It's also unnecessary as you can use /NEW_FILE to rollover the journal.