Где на микротике хранятся логи

Инструкции по настройке MikroTik

Краткое описание: Руководство по сохранению текущего лога MikroTik в файл, а также вывод в окно терминала.

Нужно настроить Логи(Log) в MikroTik?

Настройка сервисов на маршрутизаторах MikroTik: подключение интернета, DHCP, brige, VLAN, WiFi, Capsman, VPN, IpSec, PPTP, L2TP, Mangle, NAT, проброс портов, маршрутизация(routing), удаленное подключение и объединение офисов.

Как увеличить лог MikroTik

Текущий лог устройства MikroTik выводится в виде списка, состоящий из событий, определенных в настройках System->Logging. Как правило количество строк по умолчанию 100 и этого бывает недостаточно, чтобы провести зафиксировать интересующие событие. Для изменения нужно поменять значение Lines.

Настройка находится в System->Logging

Как сохранить лог MikroTik в файл

Консоль System->Logging не имеет функционала поиска или фильтрации по событиям, что доставляет ряд неудобств при диагностике. Решить эту проблему можно с помощью команд:

для вывода текущего лога в терминал(доступ буфер обмена)

или в файл флеш памяти

Очистить лог в MikroTik

Для удалениея лога на роутере MikroTik необходимо последовательно выполнить две команды:

• первая сократит количество строк до 1шт;
• вторая – увеличит до 1000шт.

Весь лог, который окажется до выполнения 1-ой команды будет сокращен(удалён) до одной строки, а вторая команда восстановить нормальный размер лога.

Есть вопросы или предложения по настройке Log в MikroTik? Активно предлагай свой вариант настройки! Оставить комментарий →

Записки IT специалиста

Централизованный сбор логов Mikrotik на сервер The Dude

• Автор: Уваров А.С.
• 24.07.2021

Сбор и изучение логов — важная часть работы системного администратора, помогающая разобраться в любой, даже самой сложной и запутанной ситуации. Точно также и если вы обратитесь за помощью, то первым делом от вас попросят предоставить логи. Когда устройств и сервисов в вашей сети немного, то каждый из них может собирать логи самостоятельно, но по мере увеличения количества устройств хочется иметь единую точку сбора информации. И ей вполне может стать сервер The Dude, который хоть и не дотягивает до полноценного сервера сбора логов, но все-таки может оказаться полезен.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

В первую очередь коснемся особенностей ведения логов на устройствах Mikrotik. В целях экономии ресурсов флеш-памяти лог пишется в оперативную память и ограничен 1000 последних записей. При выключении или перезагрузке устройства логи теряются. В целом, если пользоваться логами грамотно и направлять туда только действительно важные события, то 1000 строк вполне достаточно, а в случае диагностики всегда можно включить подробные логи для нужных служб.

The Dude предоставляет функции сервера логов, но в крайне ограниченном виде, какие-либо инструменты поиска и анализа отсутствуют, а сам сервер фактически является только централизованной точкой сбора логов, со всеми присущими Mikrotik особенностями. Собираемые The Dude логи также хранятся в оперативной памяти и ограничены 10 000 записей, при перезагрузке роутера с The Dude они теряются. Также нет никаких настроек, позволяющих изменить такое поведение, даже если вы используете CHR и не стеснены в ресурсах, как по памяти, так и по дисковому пространству.

Но несмотря на очень и очень ограниченные возможности пренебрегать сервером логов в The Dude не стоит, при грамотном подходе он способен принести вполне ощутимую пользу, да и вообще ситуация, когда есть хоть какой-то сервер логов всегда лучше ситуации, когда никакого сервера логов нет.

По умолчанию лог-сервер в The Dude включен, чтобы убедиться в этом перейдем в Settings — Syslog где увидим установленный флаг Enable и порт на котором работает служба — 514, ниже расположено правило, указывающее принимать логи из любого источника и записывать их в syslog.

Сам сервер логов по-спартански лаконичен: из возможностей присутствует только поиск и возможность распечатать лог или выгрузить его в CSV. Даже нет возможности наложить фильтр, как это можно сделать в интерфейсе RouterOS.

Естественно все это не добавляет привлекательности данному инструменту, но некоторые плюсы становятся видны уже здесь и сейчас. Даже в таком виде сервер логов позволяет удобно отлаживать межсетевое взаимодействие. Вы будете в одном месте видеть в реальном времени и логи клиента, и логи сервера, что гораздо удобнее, чем парсить и сопоставлять два лога.

Чтобы перенаправить логи на удаленный сервер в Mikrotik перейдем в System — Logging. На закладке Rules представлены правила для логирования различных событий, т.е. какой уровень логов куда следует направить. Как видим критические события выводятся прямо в терминал, а остальные пишутся в память.

На закладке Action перечислены возможные действия, нас интересует remote, откроем его и укажем в поле Remote Address адрес нашего The Dude сервера.

Теперь мы можем перенаправить лог любого уровня на удаленный сервер, просто изменив Action для него, но в этом случае мы окажемся без локального лога, что тоже неправильно. Поэтому мы вернемся на закладку Rules и скопируем нужное правило, указав поле Action для него remote.

Возвращаемся в The Dude и видим, что на наш сервер пошли логи от удаленного устройства:

По умолчанию они все пишутся в syslog, в принципе это можно изменить, только практической пользы от этого немного, все, что изменится — это строка Message, что, учитывая отсутствие каких либо инструментов аналитики, практически ничего не даст.

Исходя из того, что возможности хранения логов в The Dude ограничены 10 000 строк напрашивается вывод, что не следует отправлять на удаленный сервер все подряд, а только те логи, которые представляют практический интерес. Допустим мы хотим передавать на удаленный сервер события, связанные с подключением и отключением SSTP-клиентов. Находим в логе нужное событие и смотрим что указано в поле Topics, затем на основании полученных данных создаем новое правило:

Но фильтровать логи можно не только на стороне отправляющего устройства, но и со стороны The Dude. Если мы взглянем на приведенный выше лог, то увидим, что он заполнен событиями о неудачном подключении к некому OpenVPN-серверу, но это тестовый сервер и в настоящий момент он выключен, поэтому избавимся от этих событий в логе. Снова перейдем в Settings — Syslog и создадим нажатием на кнопку «плюс» новое правило. В поле Source Address укажем адрес источника, в поле Regexp — выражение по которому будем осуществлять фильтрацию, в нашем случае это часть строки, но вы можете использовать всю мощь регулярных выражений. И наконец действие с отобранными строками — drop.

Создали правило, сохранили и. никакого эффекта. Почему? А потому что правила применяются в порядке их перечисления в списке и более общее правило перекрывает созданное нами более частное.

Способа изменить порядок правил в The Dude нет, но можно скопировать вышестоящее правило, после чего оно попадет в самый низ списка, а затем удалить его. После этого, когда правила выстроятся в правильном порядке, фильтр начнет работать. Неудобно? Да. Поэтому основную фильтрацию следует производить на конечных устройствах, которые отправляют логи.

Что еще можно делать при помощи сервера логов The Dude? Можно собирать логи с Linux узлов. Для этого откройте файл /etc/rsyslog.conf и перейдите в секцию Rules. Ее содержимое достаточно понятно и в комментариях не нуждается.

Допустим, мы хотим передавать на удаленный сервер содержимое syslog, для этого скопируем строку:

И приведем ее к виду:

Где после символа @ укажем адрес нашего сервера логов и порт.

При этом не забываем, что возможности сервера логов The Dude имеют существенные ограничения и следует стараться максимально фильтровать логи, собирая только действительно нужную и полезную информацию.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Настройка сохранения системных журналов Mikrotik RouterOS на карту памяти microSD или USB-накопитель

Сама по себе RouterOS способна собирать и выводить разную системную информацию, начиная с обычных действий в системе и заканчивая debug-логами. Системный журнал (log) при этом может храниться, как в оперативной памяти устройства (memory), так и на внутреннем диске (disk). Помимо этого, журнал можно отправлять по e-mail или напрямую на удаленный syslog-сервер.
Настройка логов Mikrotik находится в подменю System — Logging. По-умолчанию, системный журнал настроен со следующими параметрами:

• info: memory
• error: memory
• warning: memory
• critical: echo

Полную документацию по Logging вы можете найти на официальном Mikrotik Wiki, мы же рассмотрим только некоторые интересные аспекты. В той же документации вы найдете все «топики» и их описание. Самих топиков огромное количество, RouterOS позволяет выгрузить практически любую отладочную информацию. К примеру, в логи можно выгружать все DNS-запросы или все журналы wireless.
Наиболее интересные категории:

• account — сохраняет логи авторизации как для PPP, так и для входа в панель управления (webfig, winbox) с указанием даты, времени и IP. Помимо этого сюда же пишутся логи отключений.
• firewall — сохраняет логи срабатывания правил Firewall, для которых установлена опция записи в лог (action=log). К примеру, выше стандартного правила «input drop» я использую дополнительное правило, запрещающее «нестандартный» порт 8291. Таким образом, в логах вы сразу будете видеть все попытки обращения к порту winbox из WAN (целенаправленное сканирование портов или попытка подключения);
• interface — логи всех изменений интерфейсов;
• script — логи скриптов;

Большинство современных RouterBOARD имеют всего 16 МБ встроенной памяти, из которых часть уже занята системой, так что в конечном итоге пользователю доступно еще меньше памяти.
Для хранения логов этого более, чем достаточно, если бы не одно но, которое поставит крест на такой идее. Дело в том, что Flash-память имеет определенный ресурс — количество циклов перезаписи. В зависимости от сценариев использования и настроек самого журнала, логи могут писаться постоянно, байт за байтом изнашивая ресурс чипа. Как вы понимаете, заменить флеш-память самостоятельно нельзя, эту процедуру может выполнить только специалист при наличии необходимого оборудования, программатора и дампа флешки. Но и это еще не все, после установки нового модуля памяти, вы получите нулевой уровень лицензии RouterOS.

Другое дело карта памяти microSD или USB-накопитель — меняются они без проблем, имеют стоимость менее $ 10 и куда больший ресурс перезаписи.
Да, порт USB присутствует не во всех устройства, не говоря уже о слоте для карт памяти microSD. Если у вас нет ни первого, ни второго, наиболее оптимальный вариант — отправка логов на удаленный сервер (actions — remote).
Мы же рассмотрим процесс выгрузки логов на диск на примере Mikrotik hEX (RB750Gr3), который я использую в качестве VPN-сервера на одном из объектов.

hEX примечателен тем, что у него есть слот для карт памяти microSD, который можно использовать, в том числе, для Dude.

Мой MikroTik – моя цифровая крепость (часть 3)

Статья является продолжением первой и второй частей, посвящённых организации практической безопасности сетей, построенных на оборудовании MikroTik. Ранее были рассмотрены общие рекомендации, безопасность уровней L1, L2 и L3. Настало время показать варианты реализации централизованного логирования. Поехали!

9. Централизованное логирование Rsyslog

Регулярный анализ логов – важная задача в поддержании должного уровня информационной безопасности. Каждый раз заходить на MikroTik-и и просматривать, что же там новенького, с учётом удаления старых записей, совсем неинтересно, поэтому важно собирать всё в едином месте. Со стороны RouterOS это делается просто:

«3» означает формат отправляемых сообщений Syslof facility daemon (бывает ещё auth, authpriv, cron, daemon, ftp, kern, local0, local1, local2, local3, local4, local5, local6, local7, lpr, mail, news, ntp, syslog, user, uucp), 10.0.0.10 – это адрес лог коллектора. В качестве него будем использовать Rsyslog , системные требования минимальны. Здесь остановимся подробнее и немного отвлечёмся от темы. С учётом того, что сетевая инфраструктура может быть мультивендорная, то, возможно, в качестве первичного коллектора нельзя будет выбрать устройство за пределами вашей LAN: либо не будет необходимых протоколов VPN или служб логирования, либо сложности с маршрутизацией. Поэтому для начала сделаем так:

В качестве транспортного протокола выбран не шифрованный UDP, порт 514. Сообщения от роутера MikroTik (IP адрес 192.168.1.1) будут сохраняться на коллекторе в файле /var/log/mikrotik.log, а также ретранслироваться по UDP на коллектор второго уровня на порт 2000. Сообщения от роутера, например, Cisco (IP адрес 192.168.1.14) будут сохраняться на коллекторе в файле /var/log/cisco.log, а также ретранслироваться по UDP на коллектор второго уровня на порт 2001. Гонять логи по открытому каналу – плохая идея, ведь по ним можно установить полную карту вашей сети, найти в ней слабые места или даже изъяны в информационной безопасности. Поэтому передачу вложим в закрытый VPN туннель. Особых требований к ресурсам сервера не предъявляются, поэтому для тестов можно использовать самый простой VPS:

Коллектор второго уровня будет собирать логи со всей администрируемой сети и ориентироваться по доменному имени устройства, сохранённого коллектором первого уровня:

В качестве переменных можно использовать:

• msg – тело сообщения;
• hostname – имя хоста, отправившего сообщение;
• source – алиас hostname (как показано в примере);
• fromhost – имя хоста, от которого было получено сообщение;
• fromhost-ip – то же самое, что и fromhost, только всегда ip-адрес;
• programname – имя программы;
• syslogfacility – источник лог сообщения в форме цифры;
• syslogfacility-text – источник лог сообщения в текстовой форме;
• syslogseverity – уровень важности в цифровом виде;
• syslogseverity-text – уровень важности в текстовом виде;
• pri – источник и приоритет в виде числа;
• pri-text – источник и приоритет в текстовом формате;
• timegenerated – время, когда сообщение было получено.

Подпись клиентского сертификата:

Серверный ключ (2048 бит нам вполне хватит):

Подпись серверного сертификата:

Правим конфиг для первичного коллектора. Принимает сообщения от роутеров так же по UDP (может оказаться единственным универсальным решением для всего зоопарка), сохраняем в локальные файлы mikrotik.log и cisco.log и ретранслируем уже по TLS за пределы охраняемого нами периметра на сервер log.your_dns_name.ru:

Вносим изменения на вторичном сервере логирования log.your_dns_name.ru:

Здесь уже, возможно, понадобится траблшутинг для обоих коллекторов. Для этого можно воспользоваться анализатором сетевых пакетов tcpdump, попробовать подключиться в нашему серверу извне по TLS, а также просмотреть запущенные демоны и прослушиваемые ими сетевые интерфейсы и порты:

Подведём промежуточный итог. Программное обеспечение настроили. Логи собираем в два этапа. Коллектор первого уровня работает внутри защищаемого периметра, коллектор второго уровня отвечает за всю сеть в целом. Логи просматриваем примерно так:

Результат есть, но админу работать так не хочется, поэтому пойдём ещё дальше и прикрутим в нашу историю красивый, удобный и функциональный интерфейс, а именно развернём решение на базе Graylog .

10. Централизованное логирование Graylog

В идеале, конечно, архитектура должна быть похожа на рисунок ниже, но мы будем придерживаться нашей схемы.

Самым простым сервером здесь не обойдёшься, рекомендуемый минимум выйдет 1828 рублей в месяц. Важно отметить, что для развёртывания необходимо использовать архитектуру процессора AMD64:

Приступим к установке и настройке. База данных:

Генерируем ключи для доступа к web интерфейсу по TLS:

Если всё прошло корректно, то можно будет увидеть такой вот web интерфейс, протокол HTTPS (graylog.your_dns_name.ru:9000):

На сайте получаем бесплатную лицензию и вставляем ее в своё приложение (this Graylog cluster ID is 674E8B34-224…):

Чтобы получать сообщения от первичного коллектора по UDP, необходимо настроить вводы нашего Graylog, примерно так:

У нас уже всё готово для общения по TLS, поэтому просто выбираем соответствующий режим и заполняем необходимые поля. Как совет, не пытайтесь перенести веб-морду на 443 порт (ни NAT-ом, ни с помощью прокси), столкнётесь с проблемами на уровне API. В результате просматривать логи стало гораздо приятнее:

В конечном итоге мы рекомендуем вкладывать получение сообщений от первичного коллектора по TLS в VPN канал, тогда открытый TCP порт не будет светиться в интернет, и не будет сохраняться флуд, вроде такого:

Здесь нужно дополнительно рассказать не только о важности и способе, хранении и анализе логов, но так же и о такой вещи, как развёртывание «черного ящика», который будет собирать информацию обо всех сетевых соединениях. Это поможет восстановить полную хронологию событий, в случае компрометации системы. Мы рекомендуем использовать для этого протокол netflow .

Активируем его в RouterOS и указываем IP адрес коллектора:

Настраиваем принимающую сторону – netflow коллектор:

Просмотрим получаемую статистику:

Непосредственно результаты накопления можно увидеть таким образом:

Сохраняемые объёмы выходят небольшими. Своего рода биллинг сетевых соединений, проходящих через маршрутизатор.

11. Заключение

На этом все. В нашем распоряжении полноценный графический анализатор логов, который уже можно стилизовать под свои задачи, вкусы и предпочтения. Функционала для этого предостаточно: Search, Streams, Alerts, Dashboards и Enterprise функции. Настало время добавить в нашу сеть полноценную систему обнаружения вторжений, но про это в следующей и завершающей части.