Настройка syslog на роутере
Обновлено: 06.07.2024
Возникло желание собирать логи с роутера Mikrotik. Была нужна информация о подключенных по pptp абонентах и логи firewall для настройки. По-умолчанию, Mikrotik пишет все логи в лог журнал, который можно просмотреть через winbox. Стандартно, там хранятся последние 100 строк лога.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Данная статья является частью единого цикла статьей про Mikrotik.
Настраиваем удаленный сервер rsyslog
У меня в хозяйстве имелся сервер Debian. Решил хранить логи с микротиков именно на нем. В составе Debian уже имеется сервис сбора логов с удаленных источников rsyslog. Необходимо только включить в нем необходимый функционал. Правим файл /etc/rsyslog.conf:
чтобы получать логи по UDP, либо
чтобы получать логи по TCP
И в секцию RULES добавим несколько строк для удобного хранения файлов логов от разных удаленных источников:
Перезапускаем rsyslog для применения настроек:
Теперь наш сервер готов принимать логи с удаленных источников. Хранить он их будет в папке /var/log/!remote Для каждого источника будет создана папка с именем IP адреса этого источника.
Настраиваем пересылку логов в Mikrotik
Теперь настраиваем в роутере хранение логов на удаленном сервере. Для этого заходим в раздел System -> Logging, выбираем закладку Actions, два раза щелкаем по строчке remote. Открывается окно настроек. В нем вводим адрес удаленного сервера сбора логов. Порт на свое усмотрение либо оставляем по-умолчанию, либо меняем на свой. Больше ничего добавлять не надо.
Дальше в разделе Rules создаем необходимое правило хранения:
Все готово. Теперь все наши логи будут храниться на удаленном сервере. Необходимо не забыть настроить ротацию логов, дабы в один прекрасный день они не заняли все свободное место.
Если вы используете ELK Stack для централизованного сбора логов, то у меня есть статья по отправке логов mikrotik в elk stack.
Напоминаю, что данная статья является частью единого цикла статьей про Mikrotik.
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.Рекомендую полезные материалы по схожей тематике:
Давно была мысль посмотреть, что можно делать с ELK и подручными источниками логов и статистики. На страницах хабра планирую показать практический пример, как с помощью домашнего мини-сервера можно сделать, например, honeypot с системой анализа логов на основе ELK стека. В этой статье расскажу про простейший пример анализа логов firewall с помощью стека ELK. В дальнейшем хотелось бы описать настройку окружения для анализа Netflow трафика и pcap дампов инструментом Zeek.
Если у вас есть публичный IP-адрес и более-менее умное устройство в качестве шлюза/файрволла, вы можете организовать пассивный honeypot, настроив логирование входящих запросов на «вкусные» TCP и UDP порты. Под катом пример настройки маршрутизатора Mikrotik, но если у вас под рукой маршрутизатор другого вендора (или какая-то ещё security система), нужно просто немного разобраться с форматами данных и вендоро-специфичными настройками, и получится тот же результат.
Disclaimer
Статья не претендует на оригинальность, здесь не рассматриваются вопросы отказоустойчивости сервисов, безопасности, лучших практик и т.д. Нужно рассматривать этот материал как академический, он подходит для ознакомления с базовым функционалом стека ELK и механизмом анализа логов сетевого устройства. Однако и не новичку может быть что-то интересно.
Проект запускается из docker-compose файла, соответственно развернуть своё подобное окружение очень просто, даже если у вас под рукой маршрутизатор другого вендора, нужно просто немного разобраться с форматами данных и вендоро-специфичными настройками. В остальном я постарался максимально подробно описать все нюансы, связанные с конфигурированием Logstash pipelines и Elasticsearch mappings в актуальной версии ELK. Все компоненты этой системы хостятся на github, в том числе конфиги сервисов. В конце статьи я сделаю раздел Troubleshooting, в котором будут описаны шаги по диагностике популярных проблем новичков в этом деле.
Введение
На самом сервере у меня установлена система виртуализации Proxmox, на ней в KVM машине запускаются Docker контейнеры. Предполагается, что вы знаете, как работает docker и docker-compose, благо примеров настройки о использования в интернете достаточно. Я не буду касаться вопросов установки Docker, про docker-compose немного напишу.
Идея запустить honeypot возникла в процессе изучения Elasticsearch, Logstash и Kibana. В профессиональной деятельности я никогда не занимался администрированием и вообще использованием этого стека, но у меня есть хобби проекты, благодаря которым сложился большой интерес изучить возможности, которые даёт поисковый движок Elasticsearch и Kibana, с помощью которых можно анализировать и визуализировать данные.
Моего не самого нового мини сервера NUC с 8GB RAM как раз хватает для запуска ELK стека с одной нодой Elastic. В продакшн окружениях так делать, конечно, не рекомендуется, но для обучения в самый раз. По поводу вопроса безопасности в конце статьи есть ремарка.
В интернете полно инструкций по установке и конфигурированию ELK стека для схожих задач (например, анализ brute force атак на ssh с помощью Logstash версии 2, анализ логов Suricata с помощью Filebeat версии 6), однако в большинстве случаев не уделяется должного внимания деталям, к тому же 90 процентов материала будет для версий от 1 до 6 (на момент написания статьи актуальная версия ELK 7.5.0). Это важно, потому что с 6 версии Elasticsearch решили убрать сущность mapping type, тем самым синтаксис запросов и структура мапингов изменились. Mapping template в Elastic вообще очень важный объект, и чтобы потом не было проблем с выборкой и визуализацией данных, советую не увлекаться копипастой и стараться понимать, что делаете. Дальше я постараюсь понятно объяснять, что значат описываемые операции и конфиги.
Настройка роутера
Для домашней сети в качестве маршрутизатора я использую Mikrotik, так что пример будет для него. Но на отправку syslog на удалённый сервер можно настроить почти любую систему, будь то маршрутизатор, сервер или ещё какая-то security система, которая умеет логировать.
В Mikrotik для настройки логирования на удалённый сервер через CLI достаточно ввести пару команд:
Настройка правил firewall с логированием
Нас интересуют только определённые данные (hostname, ip-adress, username, url etc.), из которых можно получить красивую визуализацию или выборку. В самом простом случае, чтобы получить информацию о сканировании портов и попытке доступа, нужно настроить компонент firewall на логирование срабатываний правила. Я на Mikrotik настроил правила в таблице NAT, а не Filter, так как в дальнейшем собираюсь поставить ханипоты, которые будут эмулировать работу сервисов, это позволит исследовать больше информации о поведении ботнетов, но это уже более продвинутый сценарий и о нём не в этот раз.
Внимание! В конфигурации ниже стандартный TCP порт сервиса SSH (22) натится в локальную сеть. Если вы используете SSH для доступа к роутеру извне и в настройках стоит порт 22 (ip service print в CLI и ip > services в Winbox), стоит переназначить порт для management SSH, либо не вводить последнее правило в таблице.
Так же, в зависимости от названия WAN-интерфейса (если не используется WAN bridge), нужно поменять параметр in-interface на соответствующий.
В Winbox то же самое настраивается в разделе IP > Firewall > вкладка NAT.
Теперь роутер будет перенаправлять полученные пакеты на локальный адрес 192.168.88.201 и кастомный порт. Сейчас пока что никто не слушает на этих портах, так что коннекты будут обрываться. В дальнейшем в докере можно запустит honeypot, коих множество под каждый сервис. Если этого делать не планируется, то вместо правил NAT следует прописать правило с действием drop в цепочке Filter.
Запуск ELK с помощью docker-compose
Дальше можно приступать к настройке компонента, который будет заниматься процессингом логов. Cоветую сразу заняться практикой и склонировать репозиторий, чтобы видеть конфигурационные файлы полностью. Все описываемые конфиги можно увидеть там, в тексте статьи я буду копировать только часть конфигов.
В тестовом или dev окружении удобнее всего запускать docker контейнеры c помощью docker-compose. В этом проекте я использую docker-compose файл последней на данный момент версии 3.7, он требует docker engine версии 18.06.0+, так что не лишним обновить docker, а так же docker-compose.
Так как в последних версиях docker-compose выпилили параметр mem_limit и добавили deploy, запускающийся только в swarm mode (docker stack deploy), то запуск docker-compose up конфигурации с лимитами приводит к ошибке. Так как я не использую swarm, а лимиты ресурсов иметь хочется, запускать приходится с опцией --compatibility, которая конвертирует лимиты из docker-compose новых версий в нон-сварм эквивалент.
Пробный запуск всех контейнеров (в фоновом режиме -d):
Придётся подождать, пока скачаются все образы, и после того как запуск завершится, проверить статус контейнеров можно командой:
Благодаря тому, что все контейнеры будут в одной сети (если явно не указывать сеть, то создаётся новый бридж, что подходит в этом сценарии) и в docker-compose.yml у всех контейнеров прописан параметр container_name, между контейнерами уже будет связность через встроенный DNS докера. Вследствие чего не требуется прописывать IP-адреса в конфигах контейнеров. В конфиге Logstash прописана подсеть 192.168.88.0/24 как локальная, дальше по конфигурации будут более подробные пояснения, по которым можно оттюнить пример конфига перед запуском.
Настройка сервисов ELK
Дальше будут пояснения по настройке функционала компонентов ELK, а также ещё некоторые действия, которые нужно будет произвести над Elasticsearch.
Для определения географических координат по IP-адресу потребуется скачать free базу GeoLite2 от MaxMind:
Настройка Logstash
Основным файлом конфигурации является logstash.yml, там я прописал опцию автоматического релоада конфигурации, остальные настройки для тестового окружения не значительные. Конфигурация самой обработки данных (логов) в Logstash описывается в отдельных conf файлах, обычно хранящихся в директории pipeline. При схеме, когда используются multiple pipelines, файл pipelines.yml описывает активированные пайплайны. Пайплайн — это цепочка действий над неструктурированными данными, чтобы на выходе получить данные с определённой структурой. Схема с отдельно настроенным pipelines.yml не обязательная, можно обойтись и без него, загружая все конфиги из примонтированной директории pipeline, однако с определённым файлом pipelines.yml настройка получается более гибкая, так как можно не удаляя conf файлы из директории pipeline, включать и выключать необходимые конфиги. К тому же перезагрузка конфигов работает только в схеме multiple pipelines.
Дальше идёт самая важная часть конфига Logstash. Описание pipeline состоит из нескольких секций — в начале в секции Input указываются плагины, с помощью которых Logstash получает данные. Наиболее простой способ собирать syslog с сетевого устройства — использовать input плагины tcp/udp. Единственный обязательный параметр этих плагинов — это port, его нужно указать таким же, как и в настройках роутера.
Дальше всё в той же секции Filter я прописал фильтр cidr, который проверяет поле с IP-адресом на соответствие условию вхождения в заданную подсеть и ставит тег. На основе тега в дальнейшей цепочке будут производиться или не производиться действия (если конкретно, то это для того, чтобы в дальнейшем не делать geoip lookup для локальных адресов).
Теперь надо немного подробнее рассказать про то, откуда Logstash берёт GeoIP информацию. Logstash поддерживает базы GeoLite2. Есть несколько вариантов баз, я использую две базы: GeoLite2 City (в которой есть информация о стране, городе, часовом поясе) и GeoLite2 ASN (информация об автономной системе, к которой принадлежит IP-адрес).
Настройка Elasticsearch
Возвращаемся к Elasticsearch. Для начала надо удостовериться, что сервер запущен и функционирует. С Elastic эффективнее всего взаимодействовать через Rest API в CLI. С помощью curl можно посмотреть состояние ноды (localhost заменить на ip-адрес докер хоста):
Дальше можно пробовать открыть Kibana по адресу localhost:5601. В веб-интерфейсе Kibana настраивать ничего нет необходимости (разве что поменять тему на тёмную). Нам интересно посмотреть, создался ли индекс, для этого нужно открыть раздел Management и слева вверху выбрать Elasticsearch Index Management. Здесь можно посмотреть, сколько документов заиндексировано, сколько это занимает места на диске, так же из полезного можно посмотреть информацию по мапингу индекса.
Как раз дальше нужно прописать правильный mapping template. Эта информация Elastic нужна для того, чтобы он понимал, к каким типам данных какие поля относить. Например, чтобы делать специальные выборки на основе IP-адресов, для поля src_ip нужно явно указать тип данных ip, а для определения географического положения нужно определить поле geoip.location в определённом формате и прописать тип geo_point. Все возможные поля описывать не надо, так как для новых полей тип данных определяется автоматически на основе динамических шаблонов (long для чисел и keyword для строк).
Записать новый template можно или с помощью curl, или прямо из консоли Kibana (раздел Dev Tools).
После изменения мапинга нужно удалить индекс:
Для дальнейшего использования данных в Kibana, нужно в разделе Management > Kibana Index Patternсоздать pattern . Index name ввести с символом * (logstash-mikrot*), чтобы матчились все индексы, выбрать поле timestamp в качестве поля с датой и временем. В поле Custom index pattern ID можно ввести ID паттерна (например, logstash-mikrot), в дальнейшем это может упростить обращения к объекту.
Анализ и визуализация данных в Kibana
После того, как создали index pattern, можно приступать к самому интересному — анализу и визуализации данных. В Kibana есть множество функционала и разделов, но нам пока что будут интересны только два.
Discover
Здесь можно просматривать документы в индексах, фильтровать, искать и смотреть полученную информацию. Важно не забывать про шкалу времени, которая задаёт временные рамки в условиях поиска.
Visualize
В этом разделе можно строить визуализацию на основе собранных данных. Самое простое — это отобразить источники сканирующих ботнетов на географической карте, точечно или в виде heatmap. Так же доступно множество способов построить графики, сделать выборки и т.д.
В дальнейшем я планирую рассказать подробнее про обработку данных, возможно визуализацию, может что-то ещё интересное. В процессе изучения буду стараться дополнять туториал.
Troubleshooting
В случае, если в Elasticsearch индекс не появляется, нужно в первую очередь смотреть логи Logstash:
Logstash не будет работать, если нет связности с Elasticsearch, или ошибка в конфигурации пайплайна — это основные причины и о них становится ясно после внимательного изучения логов, которые по умолчанию пишутся в json докером.
Проверить Elasticsearch очень просто — достаточно сделать GET запрос curl`ом на IP-адрес и порт сервера, либо на определённый API endpoint. Например посмотреть состояние индексов в человекочитаемой таблице:
Kibana тоже не запустится, если не будет коннекта до Elasticsearch, увидеть это легко по логам.
Если веб-интерфейс не открывается, то стоит убедиться, что в Linux правильно настроен или отключён firewall (в Centos были проблемы с iptables и docker, решились по советам из топика). Также стоит учитывать, что на не очень производительном оборудовании все компоненты могут загружаться несколько минут. При нехватке помяти сервисы вообще могут не загрузиться. Посмотреть использование ресурсов контейнерами:
Если вдруг кто-то не знает, как корректно изменить конфигурацию контейнеров в файле docker-compose.yml и перезапустить контейнеры, это делается редактированием docker-compose.yml и с помощью той же команды с тем же параметрами перезапускается:
При этом в изменённых секциях старые объекты (контейнеры, сети, волюмы) стираются и пересоздаются новые согласно конфигу. Данные сервисов при этом не теряются, так как используется named volumes, которые не удаляются с контейнером, а конфиги монтируются с хостовой системы, Logstash так умеет даже мониторить файлы конфигов и перезапускать пайплайн конфигурацию при изменении в файле.
Перезапустить сервис отдельно можно командой docker restart (при этом не обязательно находиться в директории с docker-compose.yml):
Посмотреть конфигурацию объекта докер можно командой docker inspect, совместно с jq использовать удобнее.
В любом сложном электронном устройстве необходима функциональность ведения журналов его работы (системных логов). Анализ записанных логов оказывает неоценимую помощь при диагностике сложных ситуаций.
В роутерах iRZ логи работы по умолчанию ведутся в буфере оперативной памяти, поэтому при перезагрузке устройства они полностью затираются. После старта устройства файлы логов и начинают записываться заново. Эта особенность работы не позволяет диагностировать ситуации приведшие к перезагрузке устройства или его недоступности по внешним интерфейсам.
Для решения этого вопроса мы предлагаем настроить ведение системных логов на внешнюю, энергонезависимую память.
Запись логов на внутреннюю память роутера
Для данной настройки необходимо подключиться к консоли роутера через протоколы Telnet или SSH и произвести необходимые манипуляции с настройками роутера.
Для внесения изменений ведения лог-файла необходимо отредактировать файл /etc/config/system.
В базовой настройке это можно сделать с помощью текстового редактора vi. Если же вы привыкли к другому текстовому редактору, то его можно поискать в репозиториях и установить с помощью менеджера пакетов - opkg.
А вот пример того выглядит файл system:
В выводе данного файла присутствует два блока информации из которых нас интересует первый - config system.
Строка option log_size '128' отвечает за размер файла (измеряется в килобайтах). Для того чтобы писать лог не в буфер оперативной памяти, а в файл, необходимо добавить строку в конце данного блока данных:
В роутере есть не затираемая область памяти. Она которая монтируется в папку /opt. Мы предлагаем записывать лог-файл log.txt именно в неё.
При изменении размера файла логов следует учитывать размеры свободного пространства в данной области памяти. Количество свободной памяти можно узнать по команде:
Это вывод с роутера серии R4 и для других серий будет выглядеть по другому. В данном случае мы видим что в разделе памяти, смонтированной в папку /opt , свободно 23 мегабайта.
Следует учесть ещё одну особенность ведения логов на роутере: при записи логов в файл, роутер при достижении граничного размера файла, указанного в настройках, перезапишет этот файл в файл с расширением .old. То есть если вы пишете в файл /opt/log.txt, то в этой папке появится второй файл - /opt/log.txt.old максимального размера, указанного в настройках. Таким образом эти два файла /opt/log.txt и /opt/log.txt.old будут максимум того размера, что вы укажете в настройках. Они будут циклически перезаписываться по мере накопления логов.
Итоговый файл настроек для записи логов во внутреннюю память роутера должен выглядеть приблизительно так:
После внесения данных изменений необходимо сделать рестарт служб командами:
Запись логов на внешние накопители
К роутерам серии R4 и R2 можно подключить внешние накопители. К роутерам серии R4 можно подключить USB flash-накопитель, а к роутерам серии R2 - microSD карту.
В случае записи логов на внешние накопители необходимо проделать все те же манипуляции с настройками что и в предыдущем пункте данного руководства с одним отличием - путь куда записывать файлы логов будет отличаться.
Чтобы понять как будет смонтирован ваш внешний накопитель необходимо подключиться к консоли роутера и выполнить команду:
пример вывода команды для роутеров серии R4
пример вывода команды для роутеров серии R2
В последней строке данных вывода будет искомый внешний накопитель и то путь монтирования. Следовательно в пункте option log_file (см. предыдущий раздел), необходимо указать путь до файла в соответствии с теми данными, которые вы получите из вывода команды mount.
Пример для роутер серии R4:
Пример для роутера серии R2:
Ведение логов на удалённый сервер
Во всех сериях роутеров есть возможность отправки логов работы на удалённый сервер по протоколу Syslog. Данная настройка находится в меню Tools => System log. Описание данного пункта есть в документации к роутерам - Средства управления и мониторинга на роутерах iRZ.
Пример на базе opensource проекта Visual Syslog Server for Windows.
Далее цитата со страницы проекта:
Далее необходимо включить необходимую функциональность на самом роутере. Это делается в разделе Tools => System Log. Следуя документации, приведённой выше, нужно включить ведение удаленного логирования и вписать IP адрес хост машины на которой вы запустили Visual Syslog Server.
Пример приведён на рисунке ниже:
Где то на просторах интернетов есть роутеры, хочется централизовать хранение логов их работы.
На шлюзе сделал такую настройку syslog.conf
Логи пишутся, но сразу в два файла с двух роутеров. Почему-то по файлам логи не делятся. помогите пожалуйста
syslog-ng поставь и настрой, есть куча примеров мониторинга по хостам, гугл в помощь
все круто )) а вопрос то в том что можно ли стандартным syslogd запилить
Где то на просторах интернетов есть роутеры
то есть, все твои логи plain-text-ом передаются через те самые просторы интернетов? ммм. круто, чо..
тут проблема даже не в том, что.
Почему-то по файлам логи не делятся
то есть, все твои логи plain-text-ом передаются через те самые просторы интернетов?
конечно это нехорошо согласен, но вопрос то не в этом
и почему сразу в открытом виде передаются. может у меня vpn-ы везде, и всюду все шифруется по 10-раз :)
rsyslog, mysql, bootstrap
как сговорились все ))) это троллинг такой, легкий? я знаю про rsyslog и syslog-ng в инэте кучи инфы, а про syslogd не знаю поэтому пишу на форум, подскажите если знаете как в syslogd реализовать.
Насколько мне известно, в кошерном виде не реализуемо, либо запускайте несколько инстанций. syslog-ng и rsyslog и были сделаны как замена тупого syslog'a, который предназначался для отладки и отдачи логов (sic! не сбора, а отдачи) от всяких свитчей и как легковесный демон локальной машины, но не как сборщик логов с нескольких машин.
Настраивал через rsyslog. Удобно было что создаются логика с айрин в качестве имени автоматически.
Насколько мне известно, в кошерном виде не реализуемо, либо запускайте несколько инстанций
ktulhu666 уже ответил, но все же напишу.
Логи пишутся, но сразу в два файла с двух роутеров. Почему-то по файлам логи не делятся.
нет, вы ставьте rsyslog и rsyslog-mysql, это тот же syslogd, но лучше :)
и к тому же еще можем писать в базу:
$ModLoad ommysql
*.* :ommysql:localhost,Syslog,$MYSQL_USER,$MYSQL_PASSWD
Читайте также: