The daily edition.

Scope: Rocket Enterprise Developer / Enterprise Server 12.0, Linux/UNIX documentation (Eclipse UNIX bundle). This article covers auditing of ESCWA (Enterprise Server Common Web Administration).

ESCWA's Auditing page describes two methods for auditing different types of activity. They are separate settings in separate places in the interface, and they record different things. Enabling one does not enable the other.

The two switches

• Enable Auditing (CTF-based process auditing)
  • Location: the configuration icon at the top right of ESCWA, then Tracing and Logging Settings, then Enable Auditing, then Apply.
  • Effect: ESCWA collects information on security-related events and preserves it for later review. The documentation says this logs ESCWA audit events in categories 2 and 5.
• Create audit events (External Security Facility auditing)
  • Location: Security in the menu bar, then ESCWA Configuration, which shows the ESCWA Security Facility Configuration page. Check Create audit events and click Apply.
  • Effect: collects information about ESCWA ESF events.

The Tracing and Logging Settings page adds an important qualifier: Enterprise Server Auditing must be set up for Enable Auditing to take effect. Ticking the box alone is not enough.

What the ESCWA events look like

The Audit Event Codes page lists the ESCWA-specific events. Category 2 (system) includes ESCWA starting and terminating (2 15, 2 16), ESCWA auditing starting and stopping (2 17, 2 18), ESCWA ESF auditing starting and stopping (2 19, 2 20), and a user logging off or an expired session being removed (2 21). Category 5 includes event 5 10, an ESCWA API modify request response. Its parameters are the session username, request URI, request method (for example POST, PUT or DELETE), HTTP response status code, session token, and the client IP for logon requests. It also records whether the stop and start scripts are enabled when a region is stopped or started.

The request body is optional on event 5 10. It is only received if Audit Request Bodies is checked in ESCWA Tracing and Logging Settings. That option requires Enable Auditing to be checked, and the documentation warns that it significantly increases the amount of data ESCWA emits. Treat it as a deliberate choice rather than a default.

The audit.cfg dependency

Both switches rely on the audit facility, which Configuring Enterprise Server Auditing describes in three requirements:

1. A syslog facility listening on a specific port.
2. The security configuration for the audited service (for example MFDS or a region) set to generate audit events.
3. An audit.cfg file configured to send audit events to the syslog port.

The nuance that matters operationally: you must create and configure audit.cfg first. The documentation states that without this file, auditing fails and the security manager is not initialized. The file goes in the bin directory of the installation, which by default is $COBDIR, and uses standard INI format. It is read when the audit process is initialized, so changes are not picked up by a running audit process. You must restart the audit process to reload a modified file.

The documented example begins as follows (abridged here to the core settings):

[audit]
; valid values [syslog]|[oldaudit]
emitter=syslog

[syslog]
hostname=
port=
; protocol: valid values [TCP]|[TLS]
protocol=TLS
; maxRetryTime: seconds to keep retrying a failed send.
; Negative values mean an infinite timeout. Defaults to 1.
maxRetryTime=1

[TLS]
; CA root file used to verify the syslog server's certificate
CARootFile=<path to CA root certificate>
; verifyServer defaults to true
verifyServer=true

The same example includes optional TLS client certificate, key file and passphrase settings, and serverCertHostname for hostname verification. If serverCertHostname is present with no value, hostname verification is disabled. If it is absent, the hostname from the syslog section is used. Treat the empty-value form as a deliberate weakening and not as a harmless placeholder.

Delivery and performance

If the syslog receiver runs on a different server and there is a connectivity problem, the auditing process resends events. Syslog Auditing Performance warns this can cause unacceptable performance degradation for as long as events cannot be delivered. Its documented mitigation is to run a local syslog daemon on the auditing server as the primary receiver. That daemon can log to a file, forward to external SIEMs, or both, and can queue messages in memory during network problems. This is also relevant to the maxRetryTime setting above, since a negative value retries indefinitely.

Takeaway

For ESCWA in 12.0, auditing is two independent settings, Enable Auditing for ESCWA's own category 2 and 5 events and Create audit events for ESF events, and both depend on a correctly created audit.cfg that points at a reachable syslog receiver. Create and test that file before enabling either switch, and consider a local syslog daemon so a remote outage does not slow the audited server. See Auditing.