Analysing Audit in VMS server

[Sk Noorul Hassan]

Hi,

When I am trying to analyse the audit journal log, it is only showing me the information after the crash time i.e. the server crashed at 13:57 hrs yesterday. I want information before crash also. I am using

ANA/AUDIT/SINCE=01-MAR-2007 ......

Can anybody help me in this please?

[labadie_1]

you must add the name of the previous audit server file

$ ana/audit/since=... sys$common:[sysmgr]SECURITY.AUDIT$JOURNAL;-1

or another location if you use the logical name for audit.

[Sk Noorul Hassan]

There are no more journal file & this is the only file which system has dated back year 1994.

[Mobeen_1]

Noorul...you should have a version prior to the crash...after the crash a new version would be created.

I am not sure if the audit files are being moved to a different location. I would suggest that you search

regards
Mobeen

[Wim Van den Wyngaert]

When audit restarts after a crash, no new file is created. You should be able to read the info from before the crash. But remind this : audit_server writes info defered. Thus some info is lost when you have a crash

Check "journal flush" in show aud/all. I have it at 15 seconds.

If this is not it, post show audit/all.

Wim

[Sk Noorul Hassan]

Hi Wim,
Journal Flush is showing 0 00:05:00.00 to me

[Wim Van den Wyngaert]

Just "crashed" my station and :

I do get previous records in audit ...

Try removing the /sin to see if there are record from before 1-mar (meaning the system was doing any audit violations between 1-mar and the crash).

I hope you did do show audit/all to find the name of the file to use in anal/aud. Very often an (old) file is present in the default location (your current directory). But of course, if you see the events from after the crash this could not be the case.

Wim

[Wim Van den Wyngaert]

... meaning the system was NOT ...
Missed 1 word.

Wim

[Sk Noorul Hassan]

Wim,

Yes I tried for Ana/Audit and it is displaying all the information since 1996 excluding the part just before the crash in which I am interested.

[Wim Van den Wyngaert]

So, there was no audit event (violation)between 1-mar and 5 minutes before the crash (your setting).

Sure you need audit and not accounting (which also uses defered write and thus you may be missing some stuff too).

Wim

[atul sardana]

Hassan,

hi,

you can check in SDA> for crash information.

Atul Sardana

[atul sardana]

Hassan,

hi,

you can check in SDA> for crash information.
and error log also

Atul Sardana

[Martin Hughes]

Is it possible that audit_server was not writing events just prior to the crash because of the problem that caused the crash?. What was the bugcheck? and in what state was the audit_server process?.

[Jon Pinkley]

Unless the system was sitting idle, or you were auditing only a very few things, it seems unlikely to me that you would have no audited events during the last 6 days.

Did a disk fill up?

Can you tell us anything about the crash?

Did you get a valid crash dump file? If so it has a higher chance of providing some useful information.

Are you sure auditing was not disabled before the crash? Was there a logical name redirecting the audit journal file to a non-standard location?

What events were you expecting to be audited, i.e. what does the output of "show audit" show? You stated that there are new audit records since the system was rebooted; have you determined when the previous audit record before the crash was written? If it was from before the previous boot, then auditing was either disabled, or being written to a different journal file.

If the crash was not maliciously induced, then there will probably be useful information in the crash dump file.

[Sk Noorul Hassan]

Crash dump shows that the server crashed due to UCX problem. Audit was enabled beore crash.

On the time of crash some body (planned test) has very frequently tried to ping/telnet the server, which resulted the server to crash. The servers which did not crash becuase of this ping/telnet, reveals this in the audit file. I want to know, Is the server crashed due to excessive UCX packets received.

[Volker Halle]

If you want to know why the server crashed, you need to examine the system dump file...

PINGs will not be logged in AUDIT server.

Whether TELNET login attempts will be audited, depends on your audit settings.

You could also check for TELNET login failures using ACCOUNTING, if that was enabled at the time of the problem.

Volker.

[atul sardana]

Hi Hassan,

if you want to know who.....
you can check which ip continuous tried before crash on server in operator.log file in sys$manager.

Thanks ,

Atul Sardana

[Volker Halle]

you can check which ip continuous tried before crash on server in operator.log file in sys$manager.


If the system ahd time to write to the OPERATOR.LOG file before the crash. otherwise you could still try to find those OPCOM messages in the system dump (in P0 space of the OPCOM process).

And this will depend on whether your IP service is set up to log events to OPCOM...

Volker.

[Sk Noorul Hassan]

Thanks all, the issue is resolved.