Auditing

📘

Auditing is not supported by all Seq subscription types. Please refer to the subscription tier details on datalust.co and contact us if you need any help with licensing.

What is auditing?

Seq's internal auditing produces a detailed external log of security-relevant events and configuration changes on the Seq server.

You may choose to enable auditing:

• To detect suspicious activity taking place on the server,
• To aid in responding to security incidents and attacks, or
• To demonstrate compliance with various policies, rules, standards, or regulations.

Auditing scope and capabilities

Seq auditing is designed with the following goals, scope and capabilities in mind.

Externalization of audit data

Audit events are written to an external location separate from Seq's metadata and event stores. The auditing target can be physically separate from the Seq server being audited to ensure that the audit is preserved regardless of activities on the audited server.

Independence from Seq user roles and permissions

Auditing is configured via the host server's filesystem/environment, and cannot be switched off through the Seq API at runtime. This increases the difficulty of manipulating auditing settings through a breached user account.

📘

Because Seq apps execute under the Seq service account on the server machine, and therefore could potentially influence local configuration, app installation can be locked down using the appHost.installPolicy and appHost.executionPolicy settings in order to harden this feature if required.

User-initiated actions only

Seq auditing only captures user events initiated through the Seq UI and HTTP API. For a full listing of events supported by the current Seq version, see Audit Events. Contact Seq support for advice on capturing events not currently listed on that page.

Full audit events are generated for local (username/password) and Active Directory authentication operations. Currently, some OpenID Connect/Azure Active Directory events are recorded, however the authentication provider itself must be used for login auditing in this configuration.

Durability guarantees

Audit events with the Begin or Record types are synchronously written to the audit target, with changes fully flushed, before Seq continues executing the audited operation. If auditing fails, an exception will be internally thrown, and the operation will be blocked from proceeding.

This ensures that audit records always exist for critical operations, but does introduce implications for performance and stability:

• Auditing may reduce the perceived responsiveness of some operations in the Seq UI, and
• If the audit target becomes unavailable for writes, certain Seq features and operations will not be usable until either the auditing target recovers, the auditing target is changed to an available destination, or auditing is disabled.

Enabling auditing

🚧

Broken auditing will prevent some operations

To preserve the integrity of the audit log Seq will not be able to complete audited activities if auditing is enabled but not working (e.g. if the audit server is not reachable).

Ingestion will not be affected.

Auditing is disabled by default, and must be enabled by configuring an audit target, which must be either a second Seq instance, or a local file.

Once auditing has been enabled using the instructions for the required target, you can confirm that auditing is enabled by downloading a diagnostic report from Settings > Diagnostics > Download a full diagnostic report. If auditing is correctly configured, the Auditing section of the report will show the text "Auditing is enabled".

Auditing to another Seq instance

The recommended target for auditing is a second, isolated, locked down Seq instance. To configure it, specify the Seq server's address and an API key for ingestion.

Windows:

seq config set -k audit.auditServerUrl -v https://seq.example.com:45341
seq secret set -k audit.auditServerApiKey -v abcde12345
seq service restart

Docker:

SEQ_AUDIT_AUDITSERVERURL=https://seq.example.com:45341
SEQ_AUDIT_AUDITSERVERAPIKEY=abcde12345

📘

In most auditing scenarios, the target servers should expose only an ingestion port to most client IP ranges, should require API keys for ingestion, and should serve only HTTPS requests. For assistance with configuring Seq as an audit target, please contact Seq support.

To reverse this configuration, remove/clear the audit.auditServerUrl setting.

Auditing to local files

Seq also supports auditing to a set of log files in newline-delimited JSON format.

🚧

File auditing is not recommended for long-term use. It's provided as a fallback that can be used during provisioning or maintenance of a secondary Seq audit server.

To configure file auditing, specify a path accessible to the Seq instance where audit files can be written:

Windows:

seq config set -k audit.auditPath -v "E:\Audit\"
seq service restart

Docker:

SEQ_AUDIT_AUDITPATH=/data/Audit

Files will be written using names in the format seq-audit-YYYYMMDD-SESSION.ndjson, where YYYYMMDD is the file creation year, month, and day (UTC), and SESSION is the unique audit session identifier.

For performance reasons, Seq will write to a single audit file for an entire application run. To roll to a new file, restart the Seq service or container.

To reverse this configuration, remove/clear the audit.auditPath setting.

Auditing and PII

Audit events include the details of searches, queries, and various related entities which may under some circumstances involve personally-identifiable information (PII), for example, when this is incorporated into searches and queries by users, or when it appears unexpectedly in internal error descriptions.

Audit events never contain raw log event data.