Mikrotik настройка лог сервера

Topics

 Each log entry have topic which describes the origin of log message. There can be more than one topic assigned to log message. For example, OSPF debug logs have four different topics: route, ospf, debug and raw. 

11:11:43 route,ospf,debug SEND: Hello Packet 10.255.255.1 -> 224.0.0.5 on lo0 
11:11:43 route,ospf,debug,raw PACKET: 
11:11:43 route,ospf,debug,raw 02 01 00 2C 0A FF FF 03 00 00 00 00 E7 9B 00 00 
11:11:43 route,ospf,debug,raw 00 00 00 00 00 00 00 00 FF FF FF FF 00 0A 02 01 
11:11:43 route,ospf,debug,raw 00 00 00 28 0A FF FF 01 00 00 00 00 

 List of Facility independent topics 

 Topics used by various RouterOS facilities 

12:41:40 route,bgp,debug,timer KeepaliveTimer expired 
12:41:40 route,bgp,debug,timer     RemoteAddress=2001:470:1f09:131::1 

Настраиваем пересылку логов в Mikrotik

Теперь настраиваем в роутере хранение логов на удаленном сервере. Для этого заходим в раздел System -> Logging, выбираем закладку Actions, два раза щелкаем по строчке remote. Открывается окно настроек. В нем вводим адрес удаленного сервера сбора логов. Порт на свое усмотрение либо оставляем по-умолчанию, либо меняем на свой. Больше ничего добавлять не надо.

Дальше в разделе Rules создаем необходимое правило хранения:

Все готово. Теперь все наши логи будут храниться на удаленном сервере. Необходимо не забыть настроить ротацию логов, дабы в один прекрасный день они не заняли все свободное место.

Если вы используете ELK Stack для централизованного сбора логов, то у меня есть статья по отправке логов mikrotik в elk stack.

Напоминаю, что данная статья является частью единого цикла статьей про Mikrotik.

Рекомендую полезные материалы по схожей тематике:

Отправка логов Mikrotik в syslog

Первым делом настроим сбор логов с микротиков на любой syslog сервер. В моем случае это будет сам сервер мониторинга на базе rsyslog и centos 7, но это не принципиально. Главное, чтобы на нем был zabbix-agent, который будет отправлять логи микротиков на заббикс сервер.

Для этого в rsyslog включим возможность слушать udp port 514. Открываем конфиг /etc/rsyslog.conf и раскомментируем там строки:

Дальше в этом же файле в самом начале перечисления правил, добавляем свое.

Данное правило будет автоматически раскладывать все логи с удаленных устройств по файлам в директории /var/log/mikrotik с именами в виде IP адресов. При этом не будет создан лог 127.0.0.1.log, куда бы складывались все локальные лог файлы. В своей предыдущей статье я не учитывал этот нюанс, что приводило к дублированию всех локальных логов. Сейчас я это исправляю.

Сразу же настроим ротацию лог файлов, чтобы они не забили нам весь диск. Для этого создаем конфиг для logrotate в файле /etc/logrotate.d/mikrotik примерно следующего содержания:

Я ротирую файлы логов раз в неделю, сразу сжимаю и кладу их в директорию /var/log/mikrotik/old, где будут храниться 12 последних версий файла.

Не забудьте создать указанные директории и дать пользователю zabbix права на чтение. Потом проследите, чтобы у самих логов тоже были права на чтение для zabbix

Это важно, так как агент должен их читать

После завершения настройки, надо перезапустить rsyslog.

Отправляемся на Mikrotik и настраиваем отправку логов на наш syslog сервер. Для этого переходите в раздел System -> Logging -> Actions и добавляйте новое действие.

Дальше открывайте вкладку Rules и добавляйте темы логов, которые вы будете отправлять в Zabbix. Для мониторинга за логинами достаточно темы System.

Чтобы проверить отправку логов, достаточно тут же в Mikrotik открыть новый терминал. Создастся событие в логе, который улетит на удаленный сервер. На сервере с rsyslog будет создан лог файл с содержимым.

Если у вас так же, можно двигаться дальше. Если же логи не поступают на syslog сервер, разбирайтесь в чем может быть причина. Первым делом проверьте настройки firewall. Убедитесь, что доступ к udp порту 514 есть. Дальше проверьте, что ваш rsyslog сервер реально слушает этот порт.

Topics

Each log entry have topic which describes the origin of log message. There can be more than one topic assigned to log message. For example, OSPF debug logs have four different topics: route, ospf, debug and raw.

List of Facility independent topics

Topics used by various RouterOS facilities

Log messages

Sub-menu level: /log

All messages stored in routers local memory can be printed from /log menu. Each entry contains time and date when event occurred, topics that this message belongs to and message itself.

If logs are printed at the same date when log entry was added, then only time will be shown. In example above you can see that second message was added on sep/15 current year (year is not added) and the last message was added today so only the time is displayed.

Note: print command accepts several parameters that allows to detect new log entries, print only necessary messages and so on. For more information about parameters refer to scripting manual

For example following command will print all log messages where one of the topics is info and will detect new log entries until Ctrl+C is pressed

If print is in follow mode you can hit ‘space’ on keyboard to insert separator:

Отправка логов Mikrotik в syslog

Первым делом настроим сбор логов с микротиков на любой syslog сервер. В моем случае это будет сам сервер мониторинга на базе rsyslog и centos 7, но это не принципиально. Главное, чтобы на нем был zabbix-agent, который будет отправлять логи микротиков на заббикс сервер.

Для этого в rsyslog включим возможность слушать udp port 514. Открываем конфиг /etc/rsyslog.conf и раскомментируем там строки:

$ModLoad imudp
$UDPServerRun 514

Дальше в этом же файле в самом начале перечисления правил, добавляем свое.

$template FILENAME,»/var/log/mikrotik/%fromhost-ip%.log»
if $fromhost-ip != ‘127.0.0.1’ then ?FILENAME
& stop

Данное правило будет автоматически раскладывать все логи с удаленных устройств по файлам в директории /var/log/mikrotik с именами в виде IP адресов. При этом не будет создан лог 127.0.0.1.log, куда бы складывались все локальные лог файлы. В своей предыдущей статье я не учитывал этот нюанс, что приводило к дублированию всех локальных логов. Сейчас я это исправляю.

Сразу же настроим ротацию лог файлов, чтобы они не забили нам весь диск. Для этого создаем конфиг для logrotate в файле /etc/logrotate.d/mikrotik примерно следующего содержания:

/var/log/mikrotik/*.log {
weekly
rotate 12
compress
olddir /var/log/mikrotik/old
missingok
notifempty
create 0640 root zabbix
}

Я ротирую файлы логов раз в неделю, сразу сжимаю и кладу их в директорию /var/log/mikrotik/old, где будут храниться 12 последних версий файла.

Не забудьте создать указанные директории и дать пользователю zabbix права на чтение. Потом проследите, чтобы у самих логов тоже были права на чтение для zabbix

Это важно, так как агент должен их читать

После завершения настройки, надо перезапустить rsyslog.

# systemctl restart rsyslog

Отправляемся на Mikrotik и настраиваем отправку логов на наш syslog сервер. Для этого переходите в раздел System -> Logging -> Actions и добавляйте новое действие.

Дальше открывайте вкладку Rules и добавляйте темы логов, которые вы будете отправлять в Zabbix. Для мониторинга за логинами достаточно темы System.

Чтобы проверить отправку логов, достаточно тут же в Mikrotik открыть новый терминал. Создастся событие в логе, который улетит на удаленный сервер. На сервере с rsyslog будет создан лог файл с содержимым.

Если у вас так же, можно двигаться дальше. Если же логи не поступают на syslog сервер, разбирайтесь в чем может быть причина. Первым делом проверьте настройки firewall. Убедитесь, что доступ к udp порту 514 есть. Дальше проверьте, что ваш rsyslog сервер реально слушает этот порт.

Simple queue vs Queue Tree

В Mikrotik присутствуют 2 типа очередей:

• Simple Queues — простой тип очередей.
• Queue Tree — очереди из иерархических деревьев с правилами.

Отличий у этих очередей много. Показываю наиболее значимые в виде таблицы. Автор этой таблицы — Дмитрий Скоромнов. По крайней мере я ее увидел у него.

В целом, настройка Simple Queues более простая и очевидная, в то время как Queue Tree позволяют строить более сложные конфигурации QOS с обязательным использованием маркировки в Mangle. В случае же с Simple Queues в простых ситуациях достаточно будет информации об адресах источника и получателя. Маркировать ничего не придется.

Что же выбрать для настройки QOS — Simple queue или Queue Tree? Я советую начать с простых очередей. Если ваша задача не решается с их помощью, переходите на иерархические деревья правил с маркировкой. И еще нужно понимать, что Simple queue это частный случай Queue Tree, поэтому при использовании обоих типов очередей нужно внимательно смотреть на то, чтобы правила не пересекались в разных очередях.

Мониторинг подключений (авторизаций) в Mikrotik

Логи с устройств мы собрали в одном месте. Теперь будем их анализировать и отправлять уведомления при каждом подключении к Mikrotik через Winbox. Я для этого сделал отдельный шаблон, где созданы элементы данных типа Журнал (лог) для анализа лог файла от каждого устройства.

Для каждого элемента данных есть триггер, который с помощью регулярного выражения анализирует лог файл и срабатывает тогда, когда видит строки с подключением к микротику через winbox. Имя триггера формируется таким образом, чтобы в нем была информация об имени пользователя и ip адрес, с которого он подключился.

Я не стал делать в шаблоне автообнаружение. Настраивал это в системах до 10-ти точек и мне банально было лень это делать, хотя и не сложно. Я просто копировал и исправлял итемы и триггеры, меняя ip адреса устройств. Для автообнаружения надо скрипт на сервер класть, который будет передавать список логов в мониторинг. А если руками делать, то можно все на сервере в шаблоне добавлять.

Итак, создаем простой итем.

К итему делаем триггер.

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

Если триггеры настроены правильно, то при каждом подключении по Winbox вы будете получать уведомление на почту.

И еще одно после отключения.

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

Пример моего шаблона с двумя микротиками — zabbix-mikrotik-logs.xml. Если у вас много устройств, настройте автообнаружение лог файлов, чтобы автоматически создавать итемы и триггеры. Пример настройки автообнаружения в Zabbix можете посмотреть на примере мониторинга openvpn подключений. Там как раз показан очень похожий пример, когда анализируется список файлов в директории и передается в zabbix server.

На этом по мониторингу микротиков в Zabbix у меня все. По идее, рассмотрел все актуальные задачи по этой теме.

Logging to file

To log everything to file, add new log action:

/system logging action add name=file target=disk disk-file-name=log

and then make everything log using this new action:

/system logging add action=file

You can log only errors there by issuing command:

/system logging add topics=error action=file 

This will log into files log.0.txt and log.1.txt.

You can specify maximum size of file in lines by specifying disk-lines-per-file. <file>.0.txt is active file were new logs are going to be appended and once it size will reach maximum it will become <file>.1.txt, and new empty <file>.0.txt will be created.

You can log into USB flashes or into MicroSD/CF (on Routerboards) by specifying it’s directory name before file name. For example, if you have accessible usb flash as usb1 directory under /files, you should issue following command:

/system logging action add name=usb target=disk disk-file-name=usb1/log

Note: Logging entries from files will be stored back in the memory after reboot.

Logging configuration

Sub-menu level:

Actions

Sub-menu level:

Note: default actions can not be deleted or renamed.

Настройка logstash на прием логов микротик

В конфиге /etc/logstash/conf.d/input.conf добавляем секцию для приема syslog логов. Вместе с логами от beats конфиг будет выглядеть вот так:

input {
    beats {
	port => 5044
    }
    syslog {
	port => 5045
	type => syslog
    }
}

В конфиге с фильтрами filter.conf я разделил с помощью тэгов логи обычных роутеров, свитчей и wifi точек доступа по ip адресам. Получилось примерно так:

    else if  == "10.1.4.19" or  == "10.1.5.1" {
        mutate {
            add_tag => 
        }
    }
    else if  == "10.1.4.66" or  == "10.1.3.110" or  == "10.1.3.111" {
        mutate {
            add_tag => 
        }
    }
    else if  == "10.1.4.14" or  == "10.1.5.33" {
        mutate {
            add_tag => 
	}
    }

Это простой случай, когда устройств мало. Если у вас много устройств, то лучше наверно придумать что-то другое, чтобы не нагружать logstash лишними правилами. Да и в ручную править конфиг неудобно. Как лучше поступать в таком случае — не знаю, не продумывал тему. Наверно имеет смысл разделить потоки по разным портам и на этом основании принимать решение о дальнейшей обработке.

Отправляем полученные логи в elasticsearch, настроив конфиг output.conf:

    else if "mikrotik" in  {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "mikrotik-%{+YYYY.MM}"
        }
    }

Я просто складываю все логи с тэгом mikrotik в один индекс с разбивкой по месяцам. На типы gateway, switch и wifi не разделяю, хотя можно это сделать. Тэги я добавил просто для удобства просмотра логов. С помощью тэгов можно будет быстро группировать логи по типу устройств.

Перезапускаем logstash и идем настраивать микротики на отправку логов на удаленный сервер.

Заключение

Мониторинг подключений и авторизаций в микротиках настроен в рамках построения простенькой самодельной системы информационной безопасности. Сюда можно будет добавить мониторинг за подключениями по ssh и openvpn. Затем свести все это в единый dashboard.

источник

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

Данная статья является частью единого цикла статьей про Mikrotik.