Audit & syslog
Taranac keeps an immutable audit trail of every administrative change — who did what, to which object, from which IP, and when — and can forward both that trail and the live AAA logs (TACACS+, RADIUS, NAC) to an external syslog server or SIEM. Together these cover the two questions every audit asks: what happened inside the admin console and can we prove it to an external, tamper-resistant system.
The audit log answers the first question on its own and is always on — there is nothing to enable. Syslog forwarding answers the second: you point Taranac at a collector (Splunk, Elastic, Graylog, rsyslog, QRadar, etc.) and choose which event streams it should ship.
<182>1 2026-06-24T12:34:56Z taranac USER_DELETED [taranac actor="admin" targetType="user" src="10.0.0.5"] Key concepts
Section titled “Key concepts”| Term | What it means in the UI |
|---|---|
| Audit log | The append-only record of admin actions (create / update / delete, logins, config reloads, secret reveals). Viewed under the logging / audit section, never editable. |
| Audit event type | A stable code such as USER_DELETED, DEVICE_SECRET_REVEALED, TACACS_CONFIG_RELOADED. You filter the log by it. |
| Actor / target | Actor is the admin who performed the action (blank for system-generated events); target is the object affected (its type and ID). |
| Syslog destination | An external syslog/SIEM endpoint — host, port, transport, format. |
| Log binding | A rule attached to a destination saying which stream to send there (e.g. system:audit, tacacs:authorization). Without a binding, nothing is sent. |
| Log exclusion | A separate rule that suppresses noisy AAA events; one of its toggles controls whether matching events reach syslog. |
The admin activity / audit log
Section titled “The admin activity / audit log”Every state change in Taranac calls into a single audit service, which writes one immutable row and then (fire-and-forget) hands the event to syslog forwarding. Each entry records:
- Event type — one of roughly 150 codes grouped by domain: user lifecycle, groups, RBAC, authentication, MFA, crypto/settings, LDAP config and sync, network objects, devices, TACACS+/RADIUS templates/profiles/command sets/config, AAA policy, NAC (endpoints, policy, PKI, captive portal), backups, and secret reveals.
- Actor — username snapshot plus user ID; empty for automatic/system events.
- Target — type and ID of the affected object.
- IP address and user agent of the request.
- Details — an event-specific JSON payload. For updates this typically records what changed as old → new field diffs, so a row is self-explanatory without cross-referencing.
- Node — on an HA cluster, the node that wrote the entry, stamped best-effort. It is left blank on a standalone install (and for events written before the cluster resolver is available at early boot). Surfaced as a Node column in the audit viewer.
- Timestamp — server time, timezone-aware.
The actor and target are stored as snapshots: even if you later rename or delete the user or object, the audit row still shows who and what it was at the time.
Filtering, searching and export
Section titled “Filtering, searching and export”The audit view supports pagination plus filters on event type, actor, target ID / target type, and a date range (from / to), as well as a free-text search across actor, event type, target type and IP. Default sort is newest first (created_at descending); you can also sort by event type, actor or target type.
You can export the current view to XLSX or CSV. Exporting with the page selected gives you exactly what is on screen; exporting without a page gives all matching records up to a hard cap of 10,000 rows. The export columns are: ID, Time, Event Type, Actor, Target Type, Target ID, IP Address, User Agent, Details.
Forwarding to an external syslog / SIEM
Section titled “Forwarding to an external syslog / SIEM”Forwarding is built around three objects — destination (where), binding (what), exclusion (what to suppress) — feeding two independent delivery paths.
Two delivery paths
Section titled “Two delivery paths”| Path | Carries | How it ships | Latency |
|---|---|---|---|
| A — core events | system:audit, system:config_change | Pushed in real time from the audit write-path, fire-and-forget | Immediate |
| B — AAA daemon logs | tacacs / radius / nac (authentication / authorization / accounting) | A background forwarder reads new rows from the log tables and ships them on a short interval | A few seconds behind |
Both paths use the same formatter and sender, so everything looks identical on the wire. Path B exists because the AAA daemons write their logs straight into the database; the backend owns those tables and is the natural place to forward from. (Notably, the bundled FreeRADIUS cannot send to a remote syslog itself, so doing it in the backend gives one consistent mechanism across all three protocols.)
Step 1 — create a destination
Section titled “Step 1 — create a destination”Add a syslog destination and set:
| Field | Notes |
|---|---|
| Host / port | Hostname or IP; default port 514. |
| Transport | udp or tcp. |
| TLS (TCP only) | Optional CA cert, client cert and client key for mutual TLS, plus a verify toggle. The stored client key is shown back as a sentinel, never in clear. |
| Format | The Syslog Standard: RFC3164 (BSD, single line), RFC5424 (modern, structured data), or CEF (ArcSight / Common Event Format). Default RFC3164. |
| Facility / severity | Default local6 / info. |
| Ident | Syslog tag / app name; default taranac. |
| Enabled | Disabled destinations send nothing. |
Use Test on the destination to send a probe message and confirm the collector receives it before relying on it.
Step 2 — add bindings
Section titled “Step 2 — add bindings”A destination is silent until you bind streams to it. Each binding picks a module and a log type; valid combinations:
| Module | Log types |
|---|---|
system | audit, config_change |
tacacs | authentication, authorization, accounting |
radius | authentication, accounting |
nac | authentication, accounting |
Each binding can optionally override the destination’s facility or severity, which is handy for routing one stream to a different SIEM index. A binding is unique per (destination, module, log type).
Step 3 — control noise with exclusions
Section titled “Step 3 — control noise with exclusions”Log exclusions suppress chatty AAA events (a polling monitor hitting a switch every minute, a service account, an entire subnet). An exclusion matches on who (exact username, username regex, or user group), where (any NAS, a specific network object, or a device group), scope (all / tacacs / radius) and which event types (authentication / authorization / accounting). It then has three independent output toggles:
| Toggle | Effect |
|---|---|
exclude_from_db | The event is not written to the database log tables. |
exclude_from_syslog | The event is not forwarded to syslog (enforced by Path B). |
exclude_from_alerts | The event does not trigger alerts. |
These toggles are independent — you can keep events in the database for forensics yet stop them flooding the SIEM. The on-disk file backup of AAA logs is always written regardless of exclusions, so suppressing syslog never means losing the forensic copy.
What gets emitted, and in what format
Section titled “What gets emitted, and in what format”The PRI value is computed the usual way: facility * 8 + severity. Severity is chosen automatically per event:
- Audit events map by type — failures (
USER_LOGIN_FAILED, reload-failed, LDAP-sync-failed) →err; security-significant events (deletions,MFA_DISABLED,KEY_ROTATED, every*_SECRET_REVEALED) →warning; logins and config reloads →notice; everything else →info. - AAA events — authentication failures/rejects and authorization denies →
warning; accounting is alwaysinfo.
A destination’s or binding’s facility/severity override takes precedence over these defaults.
RFC3164
Section titled “RFC3164”A single line, control characters stripped:
<PRI>Mmm dd HH:MM:SS hostname taranac: event=USER_DELETED actor=admin target_type=user src=10.0.0.5RFC5424
Section titled “RFC5424”Includes a structured-data block your SIEM can parse without regex:
<PRI>1 2026-06-24T12:34:56.000000Z hostname taranac - USER_DELETED [taranac eventType="USER_DELETED" actor="admin" targetType="user" targetId="…" src="10.0.0.5" details="{…}"] event=USER_DELETED actor=admin target_type=user src=10.0.0.5For AAA records the structured data carries protocol, log type, and the relevant fields (username, NAS IP/port, status/action, service, command, rule, profile, session ID). Audit details are serialized as compact JSON and truncated to ~1 KB to keep messages within syslog limits.
CEF (ArcSight)
Section titled “CEF (ArcSight)”Choose CEF to emit events in Common Event Format, wrapped in a syslog envelope — the dialect ArcSight, Microsoft Sentinel and many other SIEMs parse out of the box:
<PRI>Mmm dd HH:MM:SS hostname CEF:0|Taranac|Taranac|<version>|USER_DELETED|USER_DELETED|6|rt=1750766096000 cat=audit act=USER_DELETED suser=admin src=10.0.0.5 cs1Label=targetType cs1=user …The CEF header carries a fixed vendor and product of Taranac, the running app version, a signature ID and name (the event_type for audit events; PROTOCOL_LOGTYPE, e.g. TACACS_AUTHENTICATION, for AAA logs), and a severity mapped to CEF’s 0–10 scale. The extension carries typed fields — real IPs go into src / dvc, and free-form values into labelled custom strings (cs1…cs6 with csNLabel), so a SIEM never has to guess a field’s type.
The detail that matters for correlation: every CEF event leads with the canonical rt (event-time) field — epoch milliseconds of when the event happened, derived from the same UTC instant as the header timestamp. Your SIEM never has to reconstruct the time from the year-less, timezone-less BSD header, so a slow collector or a timezone gap can’t smear your timeline.
The AAA logs the forwarder ships
Section titled “The AAA logs the forwarder ships”Path B forwards the same authentication, authorization and accounting records you see in the AAA log views. Those records carry snapshot fields (device name and groups, network object, user display name and groups) captured at log time, so they survive renames and deletions.
The authentication log: per-event who / where / outcome, with the same fields the forwarder ships to syslog.
Active sessions are derived from accounting records — the radius/nac accounting streams you bind for syslog.
When to use what
Section titled “When to use what”| You need to… | Use this |
|---|---|
| See who changed an object inside the console | Audit log, filtered by target or event type |
| Hand auditors a monthly record of admin actions | Audit log export (CSV/XLSX, all records, date-ranged) |
| Get admin actions into the SIEM in real time | A destination with a system:audit binding |
| Track only configuration / policy changes | system:config_change binding |
| Stream TACACS+ command authorization to the SIEM | tacacs:authorization binding |
| Capture session start/stop for accounting/billing | radius:accounting and/or nac:accounting bindings |
| Stop a noisy monitor from flooding the SIEM but keep it on disk | Log exclusion with exclude_from_syslog on, exclude_from_db off |
| Mutual-TLS to a hardened collector | TCP transport + TLS certs on the destination |
Meeting audit requirements
Section titled “Meeting audit requirements”- Tamper-evidence — audit rows are never edited or deleted in-product; forward
system:auditto an external, append-only SIEM so the record lives somewhere the Taranac admins cannot reach. - Privileged-action visibility — every secret reveal (
*_SECRET_REVEALED), key rotation, MFA change and deletion is its own event type; filter or alert on them specifically. - Retention — the SIEM owns long-term retention; database AAA logs have their own retention setting, while the audit log itself is retained in the database and exported as needed.
- Completeness — keep the on-disk AAA file backup enabled (it ignores exclusions) so forensic data exists even for events you deliberately drop from the DB or SIEM.
Related
Section titled “Related”- Logging & accounting — the AAA log tables and views that Path B forwards
- AAA policy — the rules whose changes appear as
config_changeevents - Alerts — in-product alerting, and the third exclusion output
- Roles & permissions — the
audit_logsandsyslogpermissions that gate this section - Taranac on GitHub