No Description Provided

= Use Case Example =

== Hardware / Processing ==
Data center with:
1 aggregating machine (AuditMaster)
several audit producers (1-80)

Audit producers send continuous event stream to AuditMaster.
This machine is networked to site manager, system administrator (sysadm), site support rep (siterep), etc.
The AuditMaster also functions as a Prelude parent manager, so all IDS-type events go here.

The site manager monitors the Prelude display via network connection from another office.
If there are severe IDS events, the siterep is contacted.
Both parties look through the audit data (across the net) on the AuditMaster for sources of the problem.
It is desired that the siterep may only have a network login and no local login to the AuditMaster machine.

Occasionally the siterep and/or sysadm may look through the audit data for system anomalies which are not security-relevant. In this case they may be looking for a particular data receipt event sent from a trusted application. They may be verifying user login times from the past week/month.
This person may be in another office/building/country.

On audit producer machines, the logs are rotated at regular intervals to eliminate excess disk use. Depending on the time since the event occurred, it may no longer reside on the originating machine but is guaranteed to be stored on the AuditMaster.

== Summary ==

The read-only history of all the available audit data is desired to be seen across a network link by one or more parties. It is desired that these parties not have login-capable accounts on the AuditMaster machine.

The current searching and filtering ability of the audit-viewer is desired to be network-accessible, protected by SSL-enabled login/password authentication and transport.

Add to the above that (as in the title) it is preferred that the aggregation server (AuditMaster) not run an X server, since this will decrease the rpms and security update administration for this machine.

Thanks for your report.

I don't think implementing any of this requires any audit-viewer support (as long as audit-viewer can handle the amount of data fast enough): you should be able to use audisp-remote on the producers, and set up auditd on the master to accept TCP connections.

The administrators can (ssh -X) into the master to run audit-viewer (this is probably more efficient than copying the data to the local computers, and there's smaller risk of making unauthorized copies of the complete log). (ssh -X) does not require an X server on the master, and you can use ~/.ssh/authorized_keys to only permit the administrators to run audit-viewer (SELinux or a modification to audit-viewer might be necessary to make sure the administrators can't overwrite the file).

I'll need to test audit-viewer's handling of audit records submitted by audisp-remote.

Replying to [comment:3 mitr]:

Thanks for your report.

I don't think implementing any of this requires any audit-viewer support (as long as audit-viewer can handle the amount of data fast enough): you should be able to use audisp-remote on the producers, and set up auditd on the master to accept TCP connections.

The administrators can (ssh -X) into the master to run audit-viewer (this is probably more efficient than copying the data to the local computers, and there's smaller risk of making unauthorized copies of the complete log). (ssh -X) does not require an X server on the master, and you can use ~/.ssh/authorized_keys to only permit the administrators to run audit-viewer (SELinux or a modification to audit-viewer might be necessary to make sure the administrators can't overwrite the file).

I'll need to test audit-viewer's handling of audit records submitted by audisp-remote.

This presumes that the person watching the audit records from another machine has a linux/unix machine. We have no control over this person, and in fact for my particular instances of deployment I know this isn't true.
Also it will be impossible to host one, although I know there are Windows X server variants, since their machine configuration is tightly controlled and outside our influence.
So it really needs to be viewable from a network browser in order to be as useful as desired.

Also in order to export the display across ssh the person logging in will need an account on this machine, Part of the reason for moving the data to an aggregating machine is so that the administrators on the sending machines do not have any account access to the collection machine.
I realize I could enable a non-administrative account for them, however no account access reduces the administrative burden and concern.

Replying to [comment:4 lcbruzenak]:

This presumes that the person watching the audit records from another machine has a linux/unix machine. We have no control over this person, and in fact for my particular instances of deployment I know this isn't true.
Also it will be impossible to host one, although I know there are Windows X server variants, since their machine configuration is tightly controlled and outside our influence.
So it really needs to be viewable from a network browser in order to be as useful as desired.
So what you are really asking for is a reimplementation of audit-viewer as a web application?