In this post I would like to cover two main topics: auditing the administrative access to the Control Station, and auditing events. Auditing is a specialized form of logging. The purpose of auditing is to record the “security-relevant events” that happen on a system and provide sufficient information about who initiated the event and the event’s affect on the system (eg. success or failure).
Auditing on the VNX Control Station
Auditing is one of the highest priority customer requests in the system management arena. The auditing feature on VNX Control Station is enabled by default and starts when the CS is booted.
Default Audit Events
The default audit events are in audit.rules file, that is located in /etc/audit/audit.rules. The file is configured to provide auditing events important to the VNX. The file can be modified to provide any custom audit requirements. By default the audit is enabled for:
- root file system access by Administrators
- a list of “sensitive” system files
- changes to the audit infrastructure
- users authenticating to the system
Audit Events types
There are several main record types associated to the audit events:
- SYSCALL – information associated with a system call invocation
- PATH – information about a file being accessed
- CWD – the current working directory of the process
- USER_XXXX – events associated with a user authenticating to the system
- FS_WATCH – associated with accessing a file system object that has an explicit watch placed on it.
The commands for auditing are native Linux commands. There are no VNX specific commands for auditing. Of course all commands have man pages if you wish to gather more information, but in summary the commands are:
- /sbin/auditctl – this command controls the kernel’s audit subsystem.
- /sbin/ausearch – this command reads the audit trail
- The audit.log file is a plain text, but it contains numeric values that make it difficult to read. The ausearch command offers options that translate the values to names.
- /sbin/aureport – this command produces summary reports of the audit logs.
- /sbin/service auditd – this command controls the audit subsystem and has the listed options.
The auditing configuration files and the current audit log file are back up to the backend file system /nas/var/auditing. Every 180 seconds the auditing backup is performed for each Control Station. If the Control Station in slot 0 is replaces, the software recovery steps try to automatically restore the audit configuration from the backend backups. Recovery of the slot 1 Control Stations auditing has to be performed manually.