Короткий ответ
Логи фильтра, которые живут только в ring buffer RouterOS или volatile journal шлюза, исчезают после ребута и переполнения. Нужен отдельный syslog-хост в mgmt 10.0.99.20, доставка с FW (и с Suricata, если есть), срок хранения по политике (часто 90–365 дней — зафиксируйте свой). На самом периметре — короткий локальный хвост. Не храните единственную копию на WAN-устройстве. Не отключайте логирование и firewall, «чтобы диск не кончался» — сужайте volume и выносите.
Сначала должны существовать события: включить журналирование.
WAN 203.0.113.10 не должен принимать syslog с улицы.
Симптомы и как отличить
«Неделю назад стучали» — /log print на MikroTik без той даты. Ubuntu-шлюз: journalctl --list-boots один boot, Storage=volatile. kern.log ротируется ежедневно с rotate 4. SIEM пустой.
| Где лежит | Переживёт ребут FW | Годно для IR |
|---|---|---|
| RouterOS memory | нет | нет |
| /var/log на самом FW без бэкапа | да, пока диск/компрометация | слабо |
syslog 10.0.99.20 + бэкап | да | да |
| только IDS eve на сенсоре | частично | не filter |
Отличие от шума IDS: там много файлов. Здесь ноль истории.
Возможные причины
- Default RouterOS memory 1000.
- journald volatile на шлюзе.
- Syslog на
0.0.0.0:514с WAN — закрыли пакетный фильтр и забыли открыть с FW в mgmt, или наоборот торчит в интернет. - UDP 514 теряется, никто не смотрит.
- Диск syslog заполнен, rsyslog drop.
- Нет политики retention — админ чистит «когда красный диск».
Диагностика
На FW Ubuntu:
timedatectl
mkdir -p /tmp/fwlog-check
journalctl -k -n 5 --no-pager
systemd-analyze cat-config systemd/journald.conf | grep -i storage
ls -l /var/log/kern.log /var/log/syslogНа RouterOS:
/system logging print
/system logging action print
/log print count-onlyaction=memory единственный — хранения нет.
На предполагаемом syslog 10.0.99.20:
ss -lntup | grep -E '514|6514'
sudo grep -R "203.0.113.10\\|10.0.10.1" /var/log | tail
df -h /var/logСкан своего WAN на 514:
nmap -Pn -p 514,6514 203.0.113.10Open 514/udp с улицы — инцидент, не «успешный syslog». Слушать только 10.0.99.0/24 / адрес FW в mgmt.
Проверьте NTP: рассинхрон = мусор при расследовании.
Решение
Сценарий A. rsyslog на узле mgmt
Хост log01.contoso.example 10.0.99.20. Слушать TCP 6514 (предпочтительно) или UDP 514 только с адресов FW.
# идея rsyslog: module imtcp, listener 10.0.99.20:6514
# шаблон файлов /var/log/fw/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.logПрава: syslog не root-world-writable. nft на log01: input 6514 только с IP шлюзов.
Retention: logrotate rotate 12 monthly или time-based, плюс копия на backup. Цифру SLA запишите в регламент.
Firewall на log01 не disable.
Сценарий B. RouterOS remote
/system logging action add name=to-log01 target=remote remote=10.0.99.20 remote-port=514 src-address=10.0.99.1
/system logging add topics=firewall action=to-log01
/system logging add topics=system,error,critical action=to-log01Если есть src в mgmt 10.0.99.1 — слать с него, не с WAN 203.0.113.10 (NAT путает источник, см. NAT). Filter: allow UDP/TCP syslog из FW в 10.0.99.20, не из LAN users.
Проверка: /log print локально + файл на log01 после WAN-DROP теста своего IP.
Сценарий C. Ubuntu-шлюз journald + forward
sudo mkdir -p /var/log/journal
# journald Storage=persistent, SystemMaxUse=
sudo systemctl restart systemd-journaldИ forward в rsyslog на 10.0.99.20. Не надейтесь только на persistent на edge.
# rsyslog omfwd *.info @@10.0.99.20:6514 (TCP)Сверьте синтаксис вашей версии rsyslog в man, не копируйте устаревший $Action.
Сценарий D. Диск кончился из‑за log all
Сначала limit на FW log, потом хранение. Не rm /var/log/* на syslog без архива. Не stop nft.
Сценарий E. Концептуальный периметр
Remote syslog server в GUI, TLS если вендор умеет штатно. Ring buffer на appliance — не единственное хранилище. Пакеты «Insight/syslog» не отменяют фильтр порта 514 на WAN.
Для eve.json Suricata — тот же log01 или SIEM, иначе IDS тоже без истории.
Канарейка доставки, без которой retention — самообман
На log01 cron раз в 15 минут: файл сегодняшнего дня от fw01 не пустой и mtime свежий. Алерт в ту же очередь, что «диск 95%». Иначе вы узнаете об обрыве UDP 514 через месяц на инциденте.
Схема адресов: слать с 10.0.99.1, не с 203.0.113.10, чтобы исход в логах не схлопывался в белый NAT. На log01 nft: 514/6514 только с IP шлюзов. Скан своего WAN 514 должен быть closed/filtered. Ретеншн: logrotate плюс копия на backup; раз в квартал учение «достань WAN-DROP 40-дневной давности». Если не достаётся — срок в регламенте вранье, чините архив, не вините nft.
Как проверить, что проблема устранена
- Сгенерируйте свой
WAN-DROPна свой IP. - Через 1 минуту строка на
10.0.99.20с timestamp, prefix, src. - Ребут FW (окно!): старые строки на log01 на месте, на FW кольцо пустое — и это ок.
nmapсвоего WAN: 514 закрыт с улицы.dfна log01 после недели не 100%.- Документ: срок N дней, где архив.
sudo grep WAN-DROP /var/log/fw/*/$(date +%F).log | tailПуть подставьте свой шаблон.
Если не помогло
- UDP теряется — переходите на TCP 6514.
- FW в NAT не туда src — укажите
src-addressmgmt. - SELinux на log01 режет imtcp.
- Часовой пояс UTC vs local — зафиксируйте UTC.
- Пишете в NFS, который отвалился.
Профилактика
- Канарейка: cron на log01 «файл за сегодня не пустой».
- Backup логов отдельно от backup VM приложений.
- Права: админы FW ≠ право delete на log01 без audit.
- Не открывать syslog в интернет «для подрядчика».
- Учения: достать лог 30-дневной давности.
FAQ
UDP 514 достаточно?
Для начала да, с канарейкой. TCP/TLS лучше. Не оставляйте без проверки доставки.
Сколько дней хранить?
Решает комплаенс. Техминимум: столько, сколько вы реально расследуете (часто ≥90). Запишите число, не «пока диск».
Можно ли syslog на самом гипервизоре FW?
Лучше отдельный узел. Компрометация гипервизора не должна забирать и фильтр, и улики в одном ударе — но отдельный VLAN mgmt уже шаг.
Windows Event Forwarding вместо syslog
Для Windows-хостов да. Для nft/RouterOS — syslog. SIEM может принимать оба.
Шифровать логи на диске?
Имеет смысл для IR. Не заменяет закрытый 514 на WAN и ACL mgmt.