Command Logs in OpenVMS

[Shirish Desai]

Recentely one of our SMSC server using openVMS goes out of time sync with NTP server, because somebody changed NTP server IP.

We need to find out who has done the changes at what time.

Where I will get this informtion in OpenVMS

[Hein van den Heuvel]

>> Where I will get this informtion in OpenVMS

You'll have to ask all the folks which were trusted with the priviliges to achieve this.

Typically the system does not record commands for you.
There may or might not be information for forensic research. It's unlikely though.
- command history/recall is typically not saved, and here might just have the TCPIP command.
- I don't think this is security auditing or operator.log event. It could be audited as successful file open, but typically those are not recorded and you would still not know which open preceded the change.

Your best bet it to determine roughly the time it was changed and from there who might have been logged on.

For repeat cases you could consider adding some 3rd party Change Data Capture (CDC) for RMS to the system, but really you should just ask.

hth,
Hein

[Shirish Desai]

Thank you Sir

[Bob Blunt]

You weren't really clear about the amount of time your system went out of sync. If the variance was minimal it could be due to "natural" drift because NTP's processes weren't keeping things in check. If that's the case you could chase your tail for weeks.

However if the change was truly significant, adjustments of full minutes, hours or days, as Hein said there aren't many *default* mechanisms to check for "fingers in the pie." According to the documentation there are tools in auditing that can watch for changes to date/time but unless that's configured *before* your incident the tracking is non-existant. You could enable "image mode accounting" but the volume of data can be daunting on a very busy system. This, again, has to be setup in advance. You probably wouldn't get a true "smoking gun" with accounting data either. More likely a list of users who touched a more general utility routine instead of a specific time or data adjustment program.

Check into the OpenVMS DCL Dictionary and review the details of SET AUDIT. The specific commands to enable auditing of changes to system time don't seem to be explicitly spelled-out. This is because setting up system security and monitoring really should be done as part of a process instead of a "point solution" just to monitor one item.

Small disclaimer: I'm not at all sure if these are *recent* changes to the auditing tools, as in "for V8.4." I'd expect this information to be in the O/S release notes if it was. Our lab had additional auditing setup and I *think* that we were monitoring time changes back to the V7 timeframe.

bob

[The Brit]

If you are talking about changes to the Time server information in the TCPIP$NTP.CONF file, you might check the "Modify" timestamp on the file. i.e.

$ dir/date=m sys$specific:[tcpip$ntp]tcpip$ntp.conf

This might help to pin down the time.

Dave

[tsgdavid]

With apologies to Hein:

> Typically the system does not record
> commands for you.
> There may or might not be information for > forensic research. It's unlikely though.
> - command history/recall is typically not > saved, and here might just have the TCPIP > command.

If you are able to determine the time that the change was made and you have interactive users that are still logged in, it may be possible to view the command recall buffer for the processes that are still active using the System Dump Analyzer (SDA).

Of course, as Hein stated, this would only include commands issued at the DCL prompt - not any commands issued inside of some other utility like TCPIP. It may, however, contain and edit command for example.

Dave Williams

[cdan]

if audit is set to log modifications to TCPIP$NTP.CONF, you can analyze/audit the journal from the modification date of this file.

$ show audit/journal
$ analyze/audit/full/ 'journal_file'/out=audit.txt

this possibility depends on the protections of the file, on the audit settings but also on the account used for modifying the file.