Тема: logging
-
Журналы аудита: что записывать, как сохранить их неизменность и кто может их читать
Журнал аудита отвечает на вопрос, кто что сделал с каким объектом, когда и с каким результатом; его ведёт само приложение по каждому значимому с точки зрения безопасности действию, хранят отдельно от отладочных логов, защищают от изменения, оперативно перенося в хранилище только для добавления или однократной записи, и читают только при протоколируемом, ограниченном доступе.
-
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.
-
Управляющие последовательности терминала в недоверенном выводе: почему необработанные байты не должны попадать в терминал или просмотрщик журналов
Текст, выводимый в терминал, может содержать управляющие последовательности, которые перемещают курсор, скрывают строки, меняют заголовок окна или, в некоторых терминалах, создают кликабельные ссылки. Недоверенный вывод инструментов, журналов и файлов следует обезвреживать перед показом — как людям-операторам, так и агентам, читающим снимки терминала.
-
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 в октябре 2026 года: подтверждённое раскрытие токена и меры защиты журналов шлюза
В более позднем разборе LiteLLM заменил первоначальную версию о краже журналов свидетельствами раскрытия токена через API Agent Platform. Инцидент по-прежнему показывает, почему для учётных данных агентов, тел ответов и привилегированной автоматизации нужны отдельные границы доступа.
-
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.
Машиночитаемо: JSON