Короткий ответ
Локальный uid 0 всегда сможет стереть /var/log. Защита — вторая копия на другом хосте (rsyslog/omfwd, systemd-journal-remote, SIEM) плюс persistent journal с лимитом, плюс auditd. На Ubuntu 22.04/24.04: Storage=persistent, SystemMaxUse, права 750 на /var/log/journal, не world-writable. Не chattr +i на весь journal как единственный план: сломаете ротацию. Не отключайте journald «чтобы не писали». Хост host.example (10.0.20.10).
Симптомы и как отличить
- После reboot
journalctl -b -1пуст; ls /var/log/journalнет;- auth.log крутится 1 день и vacuum;
- инцидент, а логов нет — «места не было» или rm.
| Состояние | Смысл |
|---|---|
| volatile | только RAM |
| persistent | диск /var/log/journal |
| auto | persistent если каталог создан |
Отличие от «journal забил диск»: там режут SystemMaxUse, не выносят копию. Эта статья про невозможность расследования, не про inode. Аудит syscall: auditd.
Возможные причины
- Cloud-образ без
/var/log/journal. Storage=volatileвjournald.conf.- rsyslog не установлен на 24.04 minimal — нет
auth.log. - Cron
journalctl --vacuum-time=1s«для места». - Права 777 на
/var/log— любой процесс чистит. - Нет egress на syslog-порт, копия не уходит; админ в ответ
ufw disable— не делайте.
Диагностика
systemd-analyze cat-config systemd/journald.conf
ls -ld /var/log /var/log/journal
sudo journalctl --disk-usage
sudo journalctl -b -1 --no-pager | headdpkg -l rsyslog | grep ^ii || echo 'no rsyslog'
ls -l /var/log/auth.log /var/log/syslog 2>/dev/null
sudo ss -ulnp | grep -E '514|6514|19532'Кто может писать/удалять:
stat -c '%a %U:%G %n' /var/log /var/log/journal
sudo find /var/log -maxdepth 2 -perm -0002Vacuum в истории:
sudo grep -R vacuum /etc/cron* /etc/systemd/system /lib/systemd/system 2>/dev/null | headРешение
Сценарий A. Persistent journal с лимитом
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo tee /etc/systemd/journald.conf.d/99-persistent.conf >/dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=500M
RuntimeMaxUse=50M
MaxRetentionSec=2month
ForwardToSyslog=yes
Compress=yes
EOF
sudo systemctl restart systemd-journald
sudo journalctl --disk-usage500M подберите под диск. Не бесконечный рост. ForwardToSyslog=yes полезен если есть rsyslog.
Права: каталог journal не 777. Пакет ставит ACL для группы systemd-journal — не ломайте.
Сценарий B. rsyslog на диск + удалённо
sudo apt-get install -y rsyslog
sudo systemctl enable --now rsyslog/etc/rsyslog.d/40-remote.conf (порт и протокол согласуйте с приёмником; пример TCP 6514 — если у вас TLS, настраивайте по доке rsyslog, не выдумывайте сертификаты):
*.* action(type="omfwd" target="10.0.20.10" port="514" protocol="tcp"
queue.filename="fwd1" queue.maxdiskspace="1g" queue.type="LinkedList"
action.resumeRetryCount="-1")10.0.20.10 здесь как placeholder приёмника — на самом сервере-источнике укажите IP лог-коллектора, не себя, иначе петля. Firewall: allow исходящий к коллектору, incoming на коллекторе с CIDR источников. Не any-any.
Проверка logger -t testaaadmin testmsg и хвост на коллекторе.
Сценарий C. systemd-journal-upload
Пакеты systemd-journal-remote / systemd-journal-upload — если выбран этот контур. Сертификаты, URL= в /etc/systemd/journal-upload.conf. Не оставляйте HTTP без TLS на WAN.
Сценарий D. Защита от случайного vacuum
Запретите в cron несогласованный vacuum. Ротация — через journald MaxUse. Watch audit на journalctl не обязателен; важнее remote copy. World-writable /var/log: права. Cron-скрипты очистки: cron.
chattr +a на отдельных logfile (append only) — для текстовых логов приложения, не для бинарного journal. Снимается тем же root: это защита от скрипта www-data, не от uid 0.
Модель угроз честно: uid 0 на той же машине выключит rsyslog.service, сотрёт диск, подменит unit. Поэтому heartbeat на коллекторе обязателен для заявлений «логи защищены». Локальные меры (persistent, 750, append-only на текстовых логах приложения) закрывают www-data и ошибочный vacuum, не APT-атаку с root.
Разделение дисков: /var/log на отдельном LV. Тогда filling / приложением не душит journal и не включает emergency vacuum. SystemMaxUse всё равно нужен.
Права systemd-journal группа: admin в этой группе читает journal без root — удобно и риск. Не кладите туда прикладных пользователей. journalctl как sudoers Cmnd_Alias лучше gid на всех подряд.
Шифрование канала до коллектора: голый UDP 514 по WAN недопустим. TCP+TLS (omfwd с StreamDriver=ossl) или VPN admin-сети. Firewall: исходящий только к коллектору, не any.
Ротация на коллекторе не должна быть короче политики IR (часто 90–365 дней). Локальные 500M — кэш, не архив.
Проверка после reboot: journalctl --list-boots ≥ 2 после второго включения. Если всегда один boot — Storage снова volatile (каталог не создался, ReadWritePaths сломали journald — не трогайте ProtectSystem у journald).
Не логируйте секреты: ротация журнала не отменяет попадание пароля в SIEM. Чините приложение.
Как проверить, что проблема устранена
ls /var/log/journal/*/system.journal
sudo journalctl --list-boots | head
logger -t aaadmin-check "persistent-ok"
sudo journalctl -t aaadmin-check -n 1На коллекторе есть та же строка. Storage=persistent. /var/log не world-writable. UFW/nft active. После ребута -b -1 читается (если уже был предыдущий boot).
Если не помогло
- journald restart обнулил RAM-only: каталог не создался, tmpfiles.
- Remote не доходит: DNS, порт, TLS, очередь omfwd; смотрите
systemctl status rsyslog. - Секреты в логах — чините приложение: секреты, не открывайте логи 644 с паролями.
- Диск снова полный — MaxUse и отдельный том под
/var/log. - Атакующий с root выключил rsyslog: мониторинг heartbeat логов на коллекторе (тишина N минут = алерт). Это и есть модель.
Профилактика
- Образ: persistent + rsyslog/upload.
- Алерт: нет событий с хоста N минут; journal Storage.
- Права 750 на log-деревья приложений.
- IR: время на коллекторе NTP-синхронно.
FAQ
Можно ли запретить root удалять логи?
Полноценно — нет на том же ядре. Нужны другой узел, firmware BMC, WORM. append-only против не-root.
Ubuntu 24.04 без auth.log
journald есть. Поставьте rsyslog или читайте journalctl -u ssh. Не считайте отсутствие файла = отсутствие sshd логов.
ForwardToSyslog дублирует
Да. Дубль дешевле потери. Настройте фильтры на коллекторе.
vacuum после внедрения MaxUse
Нормально, это ротация. Вреден vacuum до нуля по cron.
audit.log тоже копировать?
Да, audisp-remote или syslog. Иначе сотрут вместе с journal.