Topic: logging
-
Audit logs: what to record, how to keep them intact, and who may read them
An audit log answers who did what to which object, when and with what result; it is written by the application for every security-relevant action, kept separate from debug logs, protected against alteration by moving it promptly to append-only or write-once storage, and read only under recorded, restricted access.
-
Sudo policy as drop-in files in /etc/sudoers.d, checked with visudo -c
Adding a scoped rule as its own file under /etc/sudoers.d, validated with visudo before it takes effect, keeps sudo policy auditable and avoids a syntax error locking everyone out. This methodology also covers the risk of broad NOPASSWD rules and where sudo logs its decisions.
-
Logging from admin scripts: logger and systemd-cat on Linux, Write-EventLog/New-WinEvent and Start-Transcript on Windows
Every platform has a way to put an admin script's output where a human or another tool will find it later, distinct from writing to stdout: logger(1) or systemd-cat into the system log on Linux, the Windows Event Log via Write-EventLog (Windows PowerShell 5.1 only) or New-WinEvent, and Start-Transcript for a raw session capture. None of them should ever receive a secret.
-
Log sampling for high-volume events: keep every error, sample the repetitive lines
Sampling drops a fraction of similar log events on purpose; the useful forms are one-in-N, burst-then-rate per period, per-level rules that leave warnings and errors untouched, and pipeline sampling keyed on a request ID so a whole request is kept or dropped together, with the applied rate written into the surviving events.
-
journald forwarding and remote collection: ForwardToSyslog, systemd-journal-upload/-remote, and rate limits
journald can hand its entries to a local syslog daemon with ForwardToSyslog=, or ship them directly over HTTPS with systemd-journal-upload to a systemd-journal-remote listener that writes its own journal files. Both paths are subject to journald's own per-service rate limiting, which drops excess messages once a burst threshold is crossed and records only a count of what it dropped.
-
Terminal escape sequences in untrusted output: why raw bytes should not reach a terminal or a log viewer
Text printed to a terminal can contain control sequences that move the cursor, hide lines, change the window title or, in some terminals, create clickable links. Untrusted output from tools, logs or files should be neutralised before display, both for human operators and for agents that read terminal captures.
-
Windows Event Forwarding: a source-initiated subscription, wecutil, and the EventLog Readers group
In a source-initiated WEF subscription, each source computer pulls its configuration from a collector via Group Policy and pushes matching events to it; wecutil manages the subscription on the collector, and forwarding the Security log needs the NETWORK SERVICE account added to the EventLog Readers group on every source.
-
Brute-force mitigation with fail2ban: jails, backends, status, and unbanning your own address
fail2ban watches logs for repeated authentication failures and bans the source with a firewall action; configuration belongs in jail.local overrides rather than the packaged jail.conf, and ignoreip is what keeps a management address from banning itself.
-
Where Solaris keeps its logs, and using fmadm/fmdump for hardware and software faults
General system messages accumulate in /var/adm/messages (what dmesg replays), each SMF instance logs its own start-method output under /var/svc/log/, and the Fault Management Architecture (fmadm, fmdump) separately diagnoses hardware and some software faults into a correlated record with a UUID.
-
LiteLLM's October 2026 incident: confirmed token exposure and gateway-log precautions
LiteLLM's later postmortem replaced its initial log-theft theory with evidence of token exposure through an Agent Platform API. The incident still illustrates why agent credentials, response bodies and privileged automation must have separate access boundaries.
-
Forwarding syslog with rsyslog over TCP behind a disk-assisted queue
A drop-in file under /etc/rsyslog.d/ can forward every message to a central collector over TCP while a disk-assisted action queue buffers messages locally, so a collector outage or network blip does not drop logs. rsyslogd -N1 validates the syntax before the change is applied.
-
Where operating systems keep their logs, and how to query each one
An agent troubleshooting a service needs to know which subsystem holds the log before it can read it. This reference lists the log store and the query command for Linux (journald/rsyslog), macOS's unified log, the Windows Event Log, AIX's error report, and FreeBSD's syslog files.
-
Access logs for personal data: recording who read which record
An access log for personal data records reads, not only writes: actor, subject, object, reason and time, emitted at the application read path and reconciled with database-level statement logging for paths that bypass it; it must answer subject-centric questions such as who looked at this person's record in the last year.
-
Minimize personal data in evidence
Retain the smallest evidence record needed to reproduce a decision, excluding unrelated identity and payload data.
-
Data minimisation as a schema and logging discipline
Store only the personal data a feature needs, at the coarsest precision that serves it, and keep identifiers out of logs by allowlisting fields; every column, log field and derived store that carries personal data is a design decision with a purpose, an owner and an expiry, not a default.
-
Log retention and disk budgeting on a host: journald, logrotate and Windows event log sizing
journald's SystemMaxUse caps the journal's own disk footprint, logrotate's maxage and rotate counts cap rotated files elsewhere, and wevtutil sl sets a Windows event log's maximum size. All three are disk-budgeting settings the operator or an agent chooses; how long records must be kept for legal or organisational reasons is a policy decision this article does not make.
-
Querying the systemd journal with journalctl: unit, boot, priority, time range and JSON output
journalctl can filter the systemd journal by unit, boot, priority and time range and emit machine-readable output, but only if the journal is configured to persist across reboots. This methodology covers precise queries, persistent storage, and the size caps in journald.conf.
-
Redact secrets before writing logs
Log an allowlisted diagnostic record rather than raw tool requests, and verify redaction at every output sink.
-
JSON Lines: one value per line for logs, datasets and streamed responses
JSON Lines (also called NDJSON) puts one complete JSON value per line, UTF-8 without a byte order mark and newline-terminated; files can be appended, split, grepped and compressed, and a truncated stream loses only its last line. RFC 7464 JSON text sequences add a record-separator byte for recovery. Use either instead of one large JSON array whenever records are produced or consumed one at a time.
-
The Linux audit framework: writing auditd rules, watching files, and reading the results back
auditd rules live in /etc/audit/rules.d and are merged with augenrules --load; syscall and watch rules feed ausearch and aureport, and setting the enabled flag to 2 makes the running configuration immutable until the next reboot.
Machine-readable: JSON