Логирование на MikroTik — syslog, rsyslog и ELK

Логирование — фундамент диагностики и безопасности сетевого оборудования. MikroTik RouterOS записывает события (логи) обо всех ключевых процессах: подключения пользователей, изменения конфигурации, срабатывания firewall, ошибки VPN, DHCP-leases и десятки других категорий. По умолчанию логи хранятся в оперативной памяти и теряются при перезагрузке. Для полноценного анализа необходимо отправлять логи на внешний сервер — через syslog-протокол на rsyslog, а для визуализации и поиска — в ELK Stack (Elasticsearch + Logstash + Kibana) или Graylog. В этом руководстве настроим встроенное логирование, экспорт в rsyslog, развернём ELK Stack и создадим скрипт отправки критических логов в Telegram.

Руководство актуально для RouterOS 7.20+.

Описание

Встроенная система логирования RouterOS

RouterOS имеет гибкую систему логирования с двумя ключевыми понятиями:

• Topics (темы) — категории событий. Каждое сообщение лога принадлежит одной или нескольким темам.
• Actions (действия) — куда записывать логи: память, диск, remote syslog, email.

Основные topics:

Topics можно комбинировать. Например, firewall,info — информационные сообщения firewall (разрешённые пакеты). firewall,warning — заблокированные.

Actions (действия):

Зачем отправлять логи на внешний сервер

1. Сохранность — логи не теряются при перезагрузке или сбросе устройства
2. Объём — внешний сервер хранит месяцы и годы логов (на MikroTik — сотни строк)
3. Поиск — полнотекстовый поиск по логам (grep, Elasticsearch)
4. Корреляция — логи с нескольких роутеров в одном месте
5. Безопасность — злоумышленник не сможет стереть логи на удалённом сервере
6. Визуализация — графики, дашборды, аналитика (Kibana, Grafana)

Настройка

Шаг 1: просмотр и настройка локальных логов

Просмотр текущих логов:

[admin@MikroTik] >
Копировать
# Все логи
/log/print

# Последние 50 записей
/log/print count=50

# Фильтр по теме
/log/print where topics~"firewall"

# Фильтр по тексту
/log/print where message~"login"

# Логи в реальном времени (Ctrl+C для выхода)
/log/print follow

Настройка правил логирования:

[admin@MikroTik] >
Копировать
# Просмотр текущих правил
/system/logging/print

# По умолчанию есть правила:
# 0  info         memory
# 1  error        memory
# 2  warning      memory
# 3  critical     memory

Добавление правил для firewall:

[admin@MikroTik] >
Копировать
# Логируем firewall в memory
/system/logging/add topics=firewall action=memory

# Логируем DHCP
/system/logging/add topics=dhcp action=memory

# Логируем Wi-Fi подключения
/system/logging/add topics=wireless action=memory

# Логируем SSH и Winbox
/system/logging/add topics=ssh action=memory

Настройка размера буфера в памяти:

[admin@MikroTik] >
Копировать
# Увеличиваем memory-буфер (по умолчанию ~100 строк)
/system/logging/action/set memory memory-lines=1000 memory-stop-on-full=no

Шаг 2: логирование на диск

Для сохранения логов между перезагрузками можно писать на диск. Однако будьте осторожны — flash-память имеет ограниченный ресурс записи.

[admin@MikroTik] >
Копировать
# Создаём action для записи на диск
/system/logging/action
add name=disk-log target=disk disk-file-name=routerlog \
  disk-file-count=10 disk-lines-per-file=1000 disk-stop-on-full=no

# Привязываем topics к action
/system/logging/add topics=critical action=disk-log
/system/logging/add topics=error action=disk-log
/system/logging/add topics=warning,account action=disk-log

# Проверяем файлы логов
/file/print where name~"routerlog"

Параметры:

• disk-file-count — количество файлов ротации (10 файлов)
• disk-lines-per-file — строк в файле перед ротацией (1000)
• disk-stop-on-full — остановить запись при заполнении (no — перезаписывать старые)

Рекомендация: Не пишите на диск topics с большим объёмом (firewall, dhcp). Используйте disk только для critical/error/account.

Шаг 3: Remote Syslog — отправка логов на внешний сервер

Настройка отправки по syslog:

[admin@MikroTik] >
Копировать
# Создаём action для remote syslog
/system/logging/action
add name=remote-syslog target=remote remote=10.0.1.50 \
  remote-port=514 src-address=0.0.0.0 bsd-syslog=yes

# Привязываем topics
/system/logging/add topics=info action=remote-syslog
/system/logging/add topics=warning action=remote-syslog
/system/logging/add topics=error action=remote-syslog
/system/logging/add topics=critical action=remote-syslog
/system/logging/add topics=firewall action=remote-syslog
/system/logging/add topics=dhcp action=remote-syslog
/system/logging/add topics=wireless action=remote-syslog
/system/logging/add topics=ipsec action=remote-syslog
/system/logging/add topics=ssh action=remote-syslog
/system/logging/add topics=account action=remote-syslog

# Проверяем
/system/logging/action/print where name=remote-syslog
/system/logging/print

Параметры:

• remote — IP-адрес syslog-сервера
• remote-port — порт (514 по умолчанию, UDP)
• bsd-syslog — формат BSD syslog (RFC 3164), совместим с большинством серверов
• src-address — source IP (полезно если у роутера несколько IP)

Важно: syslog по умолчанию использует UDP (без гарантии доставки). Для критически важных логов рассмотрите TCP syslog или VPN-канал до syslog-сервера.

Ограничение firewall-логов (чтобы не заваливать syslog-сервер):

[admin@MikroTik] >
Копировать
# Вместо логирования каждого пакета — только определённые правила
# Добавляем log к firewall-правилу с prefix для фильтрации
/ip/firewall/filter
add chain=input action=log log-prefix="FW:DROP:INPUT:" log=yes
add chain=input action=drop

# В syslog на сервере можно фильтровать по prefix "FW:DROP:"

Шаг 4: настройка rsyslog на Linux

rsyslog — стандартный syslog-демон в большинстве Linux-дистрибутивов.

Включение приёма UDP syslog:

[admin@MikroTik] >
Копировать
# Редактируем конфигурацию rsyslog
sudo nano /etc/rsyslog.conf

Раскомментируйте или добавьте:

[admin@MikroTik] >
Копировать
# Приём UDP syslog на порту 514
module(load="imudp")
input(type="imudp" port="514")

# Приём TCP syslog на порту 514 (опционально, для гарантированной доставки)
module(load="imtcp")
input(type="imtcp" port="514")

Фильтрация логов MikroTik в отдельный файл:

Создайте файл /etc/rsyslog.d/10-mikrotik.conf:

[admin@MikroTik] >
Копировать
# Фильтр по IP-адресу источника
if $fromhost-ip == '192.168.88.1' then /var/log/mikrotik/gw-01.log
& stop

if $fromhost-ip == '192.168.88.2' then /var/log/mikrotik/gw-02.log
& stop

# Или фильтр по hostname (если настроен system identity)
if $hostname == 'MikroTik-GW-01' then /var/log/mikrotik/gw-01.log
& stop

# Или все MikroTik в один файл
if $fromhost-ip startswith '192.168.88.' then /var/log/mikrotik/all-routers.log
& stop

Создайте каталог и перезапустите rsyslog:

bash
Копировать
sudo mkdir -p /var/log/mikrotik
sudo chown syslog:adm /var/log/mikrotik
sudo systemctl restart rsyslog

# Проверяем, что rsyslog слушает порт 514
ss -tulnp | grep 514

Ротация логов с logrotate:

Создайте /etc/logrotate.d/mikrotik:

[admin@MikroTik] >
Копировать
/var/log/mikrotik/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 640 syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Это сохранит логи за 90 дней с ежедневной ротацией и сжатием.

Шаг 5: ELK Stack — визуализация логов

ELK Stack (Elasticsearch + Logstash + Kibana) — мощная платформа для сбора, хранения и визуализации логов.

Архитектура:

code
Копировать
MikroTik → [syslog UDP 514] → Logstash → Elasticsearch → Kibana

Docker Compose для ELK:

yaml
Копировать
version: '3.8'

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.12.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - "ES_JAVA_OPTS=-Xms2g -Xmx2g"
    volumes:
      - es-data:/usr/share/elasticsearch/data
    ports:
      - "9200:9200"
    restart: unless-stopped

  logstash:
    image: docker.elastic.co/logstash/logstash:8.12.0
    container_name: logstash
    volumes:
      - ./logstash/pipeline:/usr/share/logstash/pipeline
    ports:
      - "514:514/udp"
      - "514:514/tcp"
    depends_on:
      - elasticsearch
    restart: unless-stopped

  kibana:
    image: docker.elastic.co/kibana/kibana:8.12.0
    container_name: kibana
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch
    restart: unless-stopped

volumes:
  es-data:

Конфигурация Logstash (logstash/pipeline/mikrotik.conf):

code
Копировать
input {
  udp {
    port => 514
    type => "syslog"
  }
  tcp {
    port => 514
    type => "syslog"
  }
}

filter {
  # Парсинг syslog
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:source_host} %{DATA:syslog_program}: %{GREEDYDATA:syslog_message}" }
  }

  # Парсинг MikroTik-специфичных полей
  if [syslog_message] =~ /^FW:/ {
    grok {
      match => { "syslog_message" => "FW:%{WORD:fw_action}:%{WORD:fw_chain}: in:%{DATA:in_interface} out:%{DATA:out_interface}, src-mac %{MAC:src_mac}, proto %{WORD:protocol}, %{IP:src_ip}:%{INT:src_port}->%{IP:dst_ip}:%{INT:dst_port}" }
      tag_on_failure => ["_mikrotik_fw_parse_failure"]
    }
    mutate {
      add_field => { "event_type" => "firewall" }
    }
  }

  # Определение типа события
  if [syslog_message] =~ /login failure/ {
    mutate { add_field => { "event_type" => "auth_failure" } }
  }
  if [syslog_message] =~ /logged in/ {
    mutate { add_field => { "event_type" => "auth_success" } }
  }
  if [syslog_message] =~ /dhcp/ {
    mutate { add_field => { "event_type" => "dhcp" } }
  }

  # GeoIP для внешних IP (опционально)
  if [src_ip] {
    geoip {
      source => "src_ip"
      target => "src_geoip"
    }
  }

  # Timestamp
  date {
    match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    target => "@timestamp"
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "mikrotik-logs-%{+YYYY.MM.dd}"
  }
}

Запустите стек:

bash
Копировать
mkdir -p logstash/pipeline
# Скопируйте конфиг выше в logstash/pipeline/mikrotik.conf
docker compose up -d

На MikroTik направьте syslog на Logstash:

[admin@MikroTik] >
Копировать
# Направляем логи на ELK (Logstash)
/system/logging/action
add name=elk-syslog target=remote remote=10.0.1.50 \
  remote-port=514 bsd-syslog=yes

/system/logging/add topics=info action=elk-syslog
/system/logging/add topics=warning action=elk-syslog
/system/logging/add topics=error action=elk-syslog
/system/logging/add topics=firewall action=elk-syslog
/system/logging/add topics=account action=elk-syslog

Откройте Kibana (http://<IP>:5601), создайте Data View для индекса mikrotik-logs-* и начните анализировать логи.

Шаг 6: Graylog как альтернатива ELK

Graylog — более простая альтернатива ELK с удобным веб-интерфейсом.

yaml
Копировать
version: '3.8'

services:
  mongodb:
    image: mongo:6.0
    container_name: graylog-mongo
    volumes:
      - mongo-data:/data/db
    restart: unless-stopped

  opensearch:
    image: opensearchproject/opensearch:2.12.0
    container_name: graylog-opensearch
    environment:
      - discovery.type=single-node
      - plugins.security.disabled=true
      - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g"
    volumes:
      - os-data:/usr/share/opensearch/data
    restart: unless-stopped

  graylog:
    image: graylog/graylog:6.0
    container_name: graylog
    environment:
      GRAYLOG_PASSWORD_SECRET: "atleast16characters!"
      # echo -n admin | sha256sum
      GRAYLOG_ROOT_PASSWORD_SHA2: "8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918"
      GRAYLOG_HTTP_EXTERNAL_URI: "http://10.0.1.50:9000/"
    ports:
      - "9000:9000"    # Web UI
      - "1514:1514/udp" # Syslog UDP
      - "1514:1514/tcp" # Syslog TCP
      - "12201:12201/udp" # GELF UDP
    depends_on:
      - mongodb
      - opensearch
    restart: unless-stopped

volumes:
  mongo-data:
  os-data:

На MikroTik:

[admin@MikroTik] >
Копировать
/system/logging/action
add name=graylog target=remote remote=10.0.1.50 remote-port=1514 bsd-syslog=yes

/system/logging/add topics=info,warning,error,critical action=graylog
/system/logging/add topics=firewall action=graylog
/system/logging/add topics=account action=graylog

В Graylog: создайте Input типа Syslog UDP на порту 1514, затем настройте Streams и Dashboards.

Шаг 7: анализ логов — обнаружение угроз

Обнаружение brute-force атак:

В Kibana создайте визуализацию: фильтр event_type: auth_failure, агрегация по src_ip, сортировка по количеству. Хосты с >10 неудачными попытками за час — потенциальные атакующие.

На MikroTik для firewall-логов:

[admin@MikroTik] >
Копировать
# Логирование заблокированных подключений к Winbox/SSH
/ip/firewall/filter
add chain=input action=log log-prefix="FW:BRUTE:" protocol=tcp \
  dst-port=8291,22 connection-state=new \
  src-address-list=!trusted-admins

Обнаружение подозрительных подключений:

[admin@MikroTik] >
Копировать
# Поиск в rsyslog логах
grep "login failure" /var/log/mikrotik/gw-01.log | \
  awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# Поиск частых firewall drops (возможное сканирование)
grep "FW:DROP" /var/log/mikrotik/gw-01.log | \
  grep -oP 'src-ip=\K[\d.]+' | sort | uniq -c | sort -rn | head -20

Мониторинг VPN-ошибок:

[admin@MikroTik] >
Копировать
# Логируем VPN-события
/system/logging/add topics=ipsec,error action=remote-syslog
/system/logging/add topics=l2tp,error action=remote-syslog
/system/logging/add topics=ppp,error action=remote-syslog

Шаг 8: отправка критических логов в Telegram

Скрипт для MikroTik, отправляющий критические события в Telegram:

[admin@MikroTik] >
Копировать
# Переменные для Telegram
/system/script
add name=telegram-alert source={
  :local botToken "1234567890:AAHxxxxxxxxxxxxxxxxxxxxxx"
  :local chatId "-1001234567890"
  :local message $msg

  # URL-encode сообщения
  :local url ("https://api.telegram.org/bot" . $botToken . \
    "/sendMessage?chat_id=" . $chatId . "&text=" . $message . \
    "&parse_mode=HTML")

  # Отправка
  :do {
    /tool/fetch url=$url mode=https keep-result=no
  } on-error={
    :log error "Telegram alert failed"
  }
}

Использование в скриптах или scheduler:

[admin@MikroTik] >
Копировать
# Проверка логов на критические события каждые 5 минут
/system/scheduler
add name=check-critical-logs interval=5m on-event={
  :local logCount [:len [/log/find where topics~"critical" \
    time>([/system/clock/get time] - 00:05:00)]]
  :if ($logCount > 0) do={
    :local lastLog [/log/get [/log/find where topics~"critical"] message]
    :local identity [/system/identity/get name]
    :local msg ("<b>CRITICAL on $identity</b>%0A" . $lastLog)
    /system/script/run telegram-alert msg=$msg
  }
}

Более простой подход — использовать topic critical с email-action и SMTP-to-Telegram gateway:

[admin@MikroTik] >
Копировать
# Email при критических событиях
/tool/e-mail/set address=smtp.gmail.com port=587 \
  from=mikrotik@company.ru user=mikrotik@company.ru \
  password="AppPassword123" start-tls=yes

/system/logging/action
add name=email-alert target=email email-to=admin@company.ru \
  email-start-tls=yes

/system/logging/add topics=critical action=email-alert
/system/logging/add topics=error,system action=email-alert

Проверка

Проверка локального логирования

[admin@MikroTik] >
Копировать
# Просмотр правил логирования
/system/logging/print

# Просмотр actions
/system/logging/action/print

# Текущие логи в памяти
/log/print count=20

# Логи firewall (должны быть, если есть правила с log=yes)
/log/print where topics~"firewall" count=10

# Логи на диске
/file/print where name~"routerlog"

Проверка remote syslog

[admin@MikroTik] >
Копировать
# Генерируем тестовое сообщение
:log warning "Test syslog message from MikroTik"

На syslog-сервере:

[admin@MikroTik] >
Копировать
# Проверяем, что сообщение пришло
tail -f /var/log/mikrotik/gw-01.log

# Или если логи идут в общий syslog
tail -f /var/log/syslog | grep -i mikrotik

# Проверяем порт
ss -tulnp | grep 514

Проверка ELK

[admin@MikroTik] >
Копировать
# Проверяем, что Elasticsearch получает данные
curl -s http://localhost:9200/mikrotik-logs-*/_count | python3 -m json.tool

# Проверяем логи Logstash
docker logs logstash --tail 20

# Проверяем, что индекс создан
curl -s http://localhost:9200/_cat/indices | grep mikrotik

В Kibana: Discover → выберите Data View mikrotik-logs-* → должны появиться логи.

Типичные ошибки

1. Логи не приходят на syslog-сервер

Причины и решения:

• rsyslog не слушает UDP 514:

[admin@MikroTik] >
Копировать
# Проверяем
ss -tulnp | grep 514
# Если пусто — раскомментируйте imudp в /etc/rsyslog.conf и перезапустите
sudo systemctl restart rsyslog

• Firewall на сервере блокирует UDP 514:

bash
Копировать
sudo iptables -A INPUT -p udp --dport 514 -j ACCEPT
# Или через ufw
sudo ufw allow 514/udp

• Неправильный IP в action:

[admin@MikroTik] >
Копировать
/system/logging/action/print where name=remote-syslog
# Проверьте, что remote= указывает на правильный IP

• Firewall на MikroTik блокирует исходящий UDP 514:

[admin@MikroTik] >
Копировать
# Проверяем output chain
/ip/firewall/filter/print where chain=output
# Добавляем разрешение
/ip/firewall/filter
add chain=output action=accept protocol=udp dst-port=514 \
  dst-address=10.0.1.50 comment="Allow syslog export"

2. Лог-файл переполняет диск

Симптомы: Свободное место на MikroTik или syslog-сервере заканчивается.

На MikroTik:

[admin@MikroTik] >
Копировать
# Проверяем размер лог-файлов
/file/print where name~"log"

# Уменьшаем ротацию
/system/logging/action/set disk-log disk-file-count=5 disk-lines-per-file=500

# Удаляем старые файлы
/file/remove [find where name~"routerlog" type=".log"]

На syslog-сервере: настройте logrotate (см. Шаг 4).

В ELK: настройте ILM (Index Lifecycle Management) для автоматического удаления старых индексов:

[admin@MikroTik] >
Копировать
# Удаление индексов старше 90 дней
curl -X DELETE "localhost:9200/mikrotik-logs-$(date -d '90 days ago' +%Y.%m.%d)"

3. Время в логах не совпадает

Причина: На MikroTik не настроен NTP, время отличается от сервера.

[admin@MikroTik] >
Копировать
# Настройте NTP
/system/ntp/client/set enabled=yes
/system/ntp/client/servers
add address=pool.ntp.org
add address=time.google.com

# Установите timezone
/system/clock/set time-zone-name=Europe/Moscow

# Проверяем
/system/clock/print

Также убедитесь, что timezone совпадает на MikroTik и syslog-сервере.

4. Logstash не парсит логи MikroTik

Симптомы: Логи приходят в Elasticsearch, но поля не разобраны (всё в поле message).

Причина: Grok-паттерн не совпадает с форматом сообщений.

Решение: Проверьте формат сообщений MikroTik и адаптируйте grok-паттерн. Используйте Kibana Dev Tools → Grok Debugger для тестирования.

Формат MikroTik syslog:

code
Копировать
Mar 28 14:30:00 MikroTik-GW-01 firewall,info: FW:DROP:INPUT: in:ether1 out:(unknown), src-mac 00:11:22:33:44:55, proto TCP, 1.2.3.4:12345->192.168.88.1:22, len 60

5. Слишком много firewall-логов заваливают сервер

Причина: Firewall генерирует тысячи записей в минуту (особенно drop-правила на WAN).

Решение:

[admin@MikroTik] >
Копировать
# Ограничьте логирование: не логируйте каждый drop
# Логируйте только новые connections
/ip/firewall/filter
set [find where action=drop chain=input] log=no

# Вместо этого — логируйте только определённые правила
/ip/firewall/filter
add chain=input action=log log-prefix="FW:SSH-BRUTE:" protocol=tcp \
  dst-port=22 connection-state=new src-address-list=ssh-blacklist

Или используйте rate-limiting на rsyslog:

[admin@MikroTik] >
Копировать
# /etc/rsyslog.d/10-mikrotik.conf
# Ограничиваем до 100 сообщений в секунду
module(load="imudp")
input(type="imudp" port="514" ratelimit.interval="1" ratelimit.burst="100")

6. Elasticsearch потребляет слишком много RAM

Решение: Ограничьте heap size в docker-compose.yml:

yaml
Копировать
environment:
  - "ES_JAVA_OPTS=-Xms1g -Xmx1g"  # Не более 50% RAM сервера

Для маленьких серверов (4 GB RAM) используйте 1 GB для ES. Для больших объёмов логов рассмотрите:

• TimescaleDB вместо Elasticsearch (меньше потребление)
• Graylog с OpenSearch (менее прожорливый)
• Loki + Grafana (минимальное потребление)

7. Скрипт Telegram не отправляет сообщения

Причины:

• Неправильный Bot Token или Chat ID
• MikroTik не может разрешить DNS (api.telegram.org)
• HTTPS заблокирован firewall
• Сертификаты не обновлены

[admin@MikroTik] >
Копировать
# Проверяем DNS
/ping api.telegram.org count=3

# Проверяем fetch
/tool/fetch url="https://api.telegram.org/bot<TOKEN>/getMe" \
  mode=https keep-result=yes dst-path=tg-test.txt
/file/print file=tg-test.txt

# Обновляем сертификаты
/certificate/set [find] trusted=yes
# Или скачайте CA bundle
/tool/fetch url="https://curl.se/ca/cacert.pem" dst-path=cacert.pem
/certificate/import file-name=cacert.pem passphrase=""

Правильная система логирования — основа безопасности и диагностики сети. Минимальный набор: remote syslog на rsyslog-сервер с ротацией 90 дней и firewall-логи с prefix для фильтрации. Для продвинутого анализа — ELK Stack или Graylog с визуализацией в Kibana. Не забывайте синхронизировать время через NTP, ограничивать объём firewall-логов и настраивать ротацию — иначе логи быстро съедят диск. Для оперативного реагирования настройте Telegram-оповещения о критических событиях.

# Все логи
/log/print

# Последние 50 записей
/log/print count=50

# Фильтр по теме
/log/print where topics~"firewall"

# Фильтр по тексту
/log/print where message~"login"

# Логи в реальном времени (Ctrl+C для выхода)
/log/print follow
# Просмотр текущих правил
/system/logging/print

# По умолчанию есть правила:
# 0  info         memory
# 1  error        memory
# 2  warning      memory
# 3  critical     memory
# Логируем firewall в memory
/system/logging/add topics=firewall action=memory

# Логируем DHCP
/system/logging/add topics=dhcp action=memory

# Логируем Wi-Fi подключения
/system/logging/add topics=wireless action=memory

# Логируем SSH и Winbox
/system/logging/add topics=ssh action=memory
# Увеличиваем memory-буфер (по умолчанию ~100 строк)
/system/logging/action/set memory memory-lines=1000 memory-stop-on-full=no
# Создаём action для записи на диск
/system/logging/action
add name=disk-log target=disk disk-file-name=routerlog \
  disk-file-count=10 disk-lines-per-file=1000 disk-stop-on-full=no

# Привязываем topics к action
/system/logging/add topics=critical action=disk-log
/system/logging/add topics=error action=disk-log
/system/logging/add topics=warning,account action=disk-log

# Проверяем файлы логов
/file/print where name~"routerlog"
# Создаём action для remote syslog
/system/logging/action
add name=remote-syslog target=remote remote=10.0.1.50 \
  remote-port=514 src-address=0.0.0.0 bsd-syslog=yes

# Привязываем topics
/system/logging/add topics=info action=remote-syslog
/system/logging/add topics=warning action=remote-syslog
/system/logging/add topics=error action=remote-syslog
/system/logging/add topics=critical action=remote-syslog
/system/logging/add topics=firewall action=remote-syslog
/system/logging/add topics=dhcp action=remote-syslog
/system/logging/add topics=wireless action=remote-syslog
/system/logging/add topics=ipsec action=remote-syslog
/system/logging/add topics=ssh action=remote-syslog
/system/logging/add topics=account action=remote-syslog

# Проверяем
/system/logging/action/print where name=remote-syslog
/system/logging/print
# Вместо логирования каждого пакета — только определённые правила
# Добавляем log к firewall-правилу с prefix для фильтрации
/ip/firewall/filter
add chain=input action=log log-prefix="FW:DROP:INPUT:" log=yes
add chain=input action=drop

# В syslog на сервере можно фильтровать по prefix "FW:DROP:"
# Редактируем конфигурацию rsyslog
sudo nano /etc/rsyslog.conf
# Приём UDP syslog на порту 514
module(load="imudp")
input(type="imudp" port="514")

# Приём TCP syslog на порту 514 (опционально, для гарантированной доставки)
module(load="imtcp")
input(type="imtcp" port="514")
# Фильтр по IP-адресу источника
if $fromhost-ip == '192.168.88.1' then /var/log/mikrotik/gw-01.log
& stop

if $fromhost-ip == '192.168.88.2' then /var/log/mikrotik/gw-02.log
& stop

# Или фильтр по hostname (если настроен system identity)
if $hostname == 'MikroTik-GW-01' then /var/log/mikrotik/gw-01.log
& stop

# Или все MikroTik в один файл
if $fromhost-ip startswith '192.168.88.' then /var/log/mikrotik/all-routers.log
& stop
sudo mkdir -p /var/log/mikrotik
sudo chown syslog:adm /var/log/mikrotik
sudo systemctl restart rsyslog

# Проверяем, что rsyslog слушает порт 514
ss -tulnp | grep 514
/var/log/mikrotik/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 640 syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
MikroTik → [syslog UDP 514] → Logstash → Elasticsearch → Kibana
**Конфигурация Logstash** (`logstash/pipeline/mikrotik.conf`):
Запустите стек:
На MikroTik направьте syslog на Logstash:
Откройте Kibana (`http://<IP>:5601`), создайте Data View для индекса `mikrotik-logs-*` и начните анализировать логи.

#### Шаг 6: Graylog как альтернатива ELK

Graylog — более простая альтернатива ELK с удобным веб-интерфейсом.
На MikroTik:
В Graylog: создайте **Input** типа `Syslog UDP` на порту 1514, затем настройте Streams и Dashboards.

#### Шаг 7: анализ логов — обнаружение угроз

**Обнаружение brute-force атак:**

В Kibana создайте визуализацию: фильтр `event_type: auth_failure`, агрегация по `src_ip`, сортировка по количеству. Хосты с >10 неудачными попытками за час — потенциальные атакующие.

На MikroTik для firewall-логов:
**Обнаружение подозрительных подключений:**
**Мониторинг VPN-ошибок:**
#### Шаг 8: отправка критических логов в Telegram

Скрипт для MikroTik, отправляющий критические события в Telegram:
Использование в скриптах или scheduler:
Более простой подход — использовать topic `critical` с email-action и SMTP-to-Telegram gateway:
### Проверка

#### Проверка локального логирования
#### Проверка remote syslog
На syslog-сервере:
#### Проверка ELK
В Kibana: **Discover** → выберите Data View `mikrotik-logs-*` → должны появиться логи.

### Типичные ошибки

#### 1. Логи не приходят на syslog-сервер

**Причины и решения:**

- **rsyslog не слушает UDP 514:**
- **Firewall на сервере блокирует UDP 514:**
- **Неправильный IP в action:**
- **Firewall на MikroTik блокирует исходящий UDP 514:**
#### 2. Лог-файл переполняет диск

**Симптомы:** Свободное место на MikroTik или syslog-сервере заканчивается.

**На MikroTik:**
**На syslog-сервере:** настройте logrotate (см. Шаг 4).

**В ELK:** настройте ILM (Index Lifecycle Management) для автоматического удаления старых индексов:
#### 3. Время в логах не совпадает

**Причина:** На MikroTik не настроен NTP, время отличается от сервера.
Также убедитесь, что timezone совпадает на MikroTik и syslog-сервере.

#### 4. Logstash не парсит логи MikroTik

**Симптомы:** Логи приходят в Elasticsearch, но поля не разобраны (всё в поле `message`).

**Причина:** Grok-паттерн не совпадает с форматом сообщений.

**Решение:** Проверьте формат сообщений MikroTik и адаптируйте grok-паттерн. Используйте Kibana **Dev Tools → Grok Debugger** для тестирования.

Формат MikroTik syslog:
#### 5. Слишком много firewall-логов заваливают сервер

**Причина:** Firewall генерирует тысячи записей в минуту (особенно drop-правила на WAN).

**Решение:**
Или используйте rate-limiting на rsyslog:
#### 6. Elasticsearch потребляет слишком много RAM

**Решение:** Ограничьте heap size в docker-compose.yml:
Для маленьких серверов (4 GB RAM) используйте 1 GB для ES. Для больших объёмов логов рассмотрите:
- TimescaleDB вместо Elasticsearch (меньше потребление)
- Graylog с OpenSearch (менее прожорливый)
- Loki + Grafana (минимальное потребление)

#### 7. Скрипт Telegram не отправляет сообщения

**Причины:**
- Неправильный Bot Token или Chat ID
- MikroTik не может разрешить DNS (api.telegram.org)
- HTTPS заблокирован firewall
- Сертификаты не обновлены