Mikrotik очистить лог: Как очистить лог Mikrotik | Реальные заметки Ubuntu & Mikrotik

Как очистить лог Mikrotik | Реальные заметки Ubuntu & Mikrotik

Прочитано:
10 182

Задача: Как очистить лог Mikrotik

Когда такая задача может возникнуть у настоящего системного администратора? Он ведь должен понимать, что имея на руках логи он может обозначить, как проникновение в свою систему, понять что подтолкнуло систему работать не стабильно и что делает система в течении всего дня. Но это с одной стороны, а если системный администратор хочет узнать почему так произошло и вдруг Mikrotik перестал вести логи — значит имело место быть несанкционированное проникновение или шутка коллег дабы подбавить важности их работы в компании. Я же хочу для себя разобрать, как очищается лог Mikrotik и как в случае чего восстановить его работу.

Мой Mikrotik (v6.39.2 on hAP lite), а так видит его утилита winbox → RB941-2nD

Дефолтные значения настройки ведения лога на Mikrotik:

[ekzorchik@MikroTik] > /system logging action print where name="memory"

Flags: * - default

0 * name="memory" target=memory memory-lines=1000 memory-stop-on-full=no

если поставить значение 1 а после вернуть как по дефолту, то лог очистится:

[ekzorchik@MikroTik] > /system logging action set memory memory-lines=0

value of memory-lines out of range (1..65535)

[ekzorchik@MikroTik] > /system logging action set memory memory-lines=1

после в логе появляется запись: log action changed by ekzorchik (я авторизован под этой учетной запись на микротике)

[ekzorchik@MikroTik] > /system logging action set memory memory-lines=1000

но как я понял это было до версии 6, а после якобы должна отработать команда:

[ekzorchik@MikroTik] > console clear-history

но увы также ничего не изменилось.

Обновил прошивку до версии на момент написания заметки: v6.41.2

но увы также ничего не изменилось.

Проверяю данные действия на RB951Ui-2HnD (v6.41.2):

[admin@MikroTik] > system logging action set memory memory-lines=1

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

Возвращаю обратно:

[admin@MikroTik] > system logging action set memory memory-lines=1000

Итого получает что нельзя полностью скрыть свои действия.

А если отключить топики:

[admin@MikroTik] > system logging set disabled=yes numbers=0

[admin@MikroTik] > system logging set disabled=yes numbers=1

[admin@MikroTik] > system logging set disabled=yes numbers=2

[admin@MikroTik] > system logging set disabled=yes numbers=3

[admin@MikroTik] > system logging action set memory memory-lines=1

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

[admin@MikroTik] > user add name=test password=test group=full — в логах ничего.

На заметку: Чтобы отобразить, что все подчистилось нужно зайти под новым пользователем и не будет записи, что до этого было сделано, в частности отключение ведения логов и под кем, останется только что «log action removed by test»

На заметку: Мой совет для тех кто использует логи и желает видеть что делается с системой это настроить их пересылку на удаленную Ubuntu систему, чтобы если что случится с Mikrotik, у Вас была полная картина что произошло. Вот я себя дома делаю так, да и в организациях которые администрирую, к примеру я оформил ранее о таком способе в этой заметке: «Как завести Mikrotik на LogAnalyzer»

На этом у меня всё, я добился своего и рассмотрел на применении двух железок как можно отключить ведение логов оборудования. С уважением автор блога Олло Александр aka ekzorchik.

Mikrotik как очистить логи

вторник, 4 августа 2015 г.

Полная очистка логов Mikrotik RouterOS

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

Решение: Решение описано много где в интернетах и сводится к двум вещам — очистке логов и очистке истории введённых команд консоли (к примеру https://aacable.wordpress.com/2013/12/19/howto-clear-mikrotik-loghistory/).
Однако есть команда /system history print которая выводит список изменений конфигурации и который стандартными средствами не удаляется!

Для полного удаления следов пребывания можно использовать метод создания и последующего восстановления резервной копии, который выполняется за 2 команды
system backup save name=test
system backup load name=test

Плюсы данного решения в том, что чистится всё — и логи, и история консоли, и system history.

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

Задача: Как очистить лог Mikrotik

Когда такая задача может возникнуть у настоящего системного администратора? Он ведь должен понимать, что имея на руках логи он может обозначить, как проникновение в свою систему, понять что подтолкнуло систему работать не стабильно и что делает система в течении всего дня. Но это с одной стороны, а если системный администратор хочет узнать почему так произошло и вдруг Mikrotik перестал вести логи — значит имело место быть несанкционированное проникновение или шутка коллег дабы подбавить важности их работы в компании. Я же хочу для себя разобрать, как очищается лог Mikrotik и как в случае чего восстановить его работу.

Мой Mikrotik (v6.39.2 on hAP lite), а так видит его утилита winbox → RB941-2nD

Дефолтные значения настройки ведения лога на Mikrotik:

[ekzorchik@MikroTik] > /system logging action print where name=»memory»

0 * name=»memory» target=memory memory-lines=1000 memory-stop-on-full=no

если поставить значение 1 а после вернуть как по дефолту, то лог очистится:

[ekzorchik@MikroTik] > /system logging action set memory memory-lines=0

value of memory-lines out of range (1..65535)

[ekzorchik@MikroTik] > /system logging action set memory memory-lines=1

после в логе появляется запись: log action changed by ekzorchik (я авторизован под этой учетной запись на микротике)

[ekzorchik@MikroTik] > /system logging action set memory memory-lines=1000

но как я понял это было до версии 6, а после якобы должна отработать команда:

[ekzorchik@MikroTik] > console clear-history

но увы также ничего не изменилось.

Обновил прошивку до версии на момент написания заметки: v6.41.2

но увы также ничего не изменилось.

Проверяю данные действия на RB951Ui-2HnD (v6.41.2):

[admin@MikroTik] > system logging action set memory memory-lines=1

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

[admin@MikroTik] > system logging action set memory memory-lines=1000

Итого получает что нельзя полностью скрыть свои действия.

А если отключить топики:

[admin@MikroTik] > system logging set disabled=yes numbers=0

[admin@MikroTik] > system logging set disabled=yes numbers=1

[admin@MikroTik] > system logging set disabled=yes numbers=2

[admin@MikroTik] > system logging set disabled=yes numbers=3

[admin@MikroTik] > system logging action set memory memory-lines=1

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

[admin@MikroTik] > user add name=test password=test group=full — в логах ничего.

На заметку: Чтобы отобразить, что все подчистилось нужно зайти под новым пользователем и не будет записи, что до этого было сделано, в частности отключение ведения логов и под кем, останется только что « log action removed by test »

На заметку: Мой совет для тех кто использует логи и желает видеть что делается с системой это настроить их пересылку на удаленную Ubuntu систему, чтобы если что случится с Mikrotik, у Вас была полная картина что произошло. Вот я себя дома делаю так, да и в организациях которые администрирую, к примеру я оформил ранее о таком способе в этой заметке: «Как завести Mikrotik на LogAnalyzer»

На этом у меня всё, я добился своего и рассмотрел на применении двух железок как можно отключить ведение логов оборудования. С уважением автор блога Олло Александр aka ekzorchik.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще 🙂

Карта МКБ: 4432-7300-2472-8059
Yandex-деньги: 41001520055047

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

А не подскажете, как отключить в логе только одну запись: fetch: file «getUpdates» downloaded

если нужно просто обращение, без сохранения вывода то можно использовать опцию keep-result (yes | no). Например: /tool fetch url=»http://joshaven.com/openbl.rsc» mode=http keep-result=no

Помогите. Как удалить всю информацию с чипа что бы он не светился на ядре главного микротика

Mikrotik: отправляем логи на удаленную машину

В данной заметке хочу с вами поделится простым рецептом передачи логов Mikrotik на удаленный сервер по протоколу syslog.
Что даст нам возможность хранить логи с нашего маршрутизатора, анализировать их и т.п.
Тем самым мы сможем оставить в логе самого Mikotik только критически значимые для нас данные, которые нам помогут быстрее разобраться с какой-либо проблемой на устройстве.
Удаленный сервер с syslog в рамках этой заметки будет использоваться FreeBSD, но если вы используете linux отличия будут небольшие в конфигурации syslog.conf или rsyslog.conf 

Syslog (англ. system log — системный журнал) — стандарт отправки и регистрации сообщений о происходящих в системе событиях (то есть создания событийных журналов), использующийся в компьютерных сетях, работающих по протоколу IP. Термином «syslog» называют как ныне стандартизированный сетевой протокол syslog, так и программное обеспечение (приложение, библиотеку), которое занимается отправкой и получением системных сообщений.wikipedia.org

Небольшая предыстория.
Организовал на маршрутизаторе Mikrotik RB3011UiAS контроллер CAPsMAN и после этого лог в Winbox стал представлять такое:
99,9% в логах стали записи о регистрации пользователей на wi-fi точках.
Можно конечно подавить логи CAPsMAN, но если будут проблемы с ним, то  будет сложно их решать без логов.
Вообщем решил вывести логи CAPsMAN на удаленную машину, по данному примеру вы сможете дальше вывести остальные нужные вам логи.
Как выше упоминал удаленный сервер с операционной системой FreeBSD.
Перед тем как начать, убедитесь, что трафик UDP на 514 порт беспрепятственно ходит с Mikrotitik в сторону нашего сервера.

• IP адрес Mikrotik 192.168.6.2
• IP адрес сервера 192.168.6.20

Настройку в Mikrotik будем делать в консоли (Winbox или SSH)

Создаем действие (action)

system logging action add bsd-syslog=yes name=CapsRemote remote=192.168.6.20 syslog-facility=local5 target=remote

• Где указываем, что мы используем syslog FreeBSD (bsd-syslog=yes)
• Даем имя CapsRemote
• Указываем адрес удаленного сервера (remote=192.168.6.20)
• Указываем syslog-facility=local5 (Далее будем с помощью этого разбирать лог в syslog.conf)
• Указываем цель как удаленный (target=remote)

Создаем правило (Rule)

system logging add topics=caps action=CapsRemote

• Где указываем, что обрабатывать только сообщения CAPsMAN (topics=caps)
• И применяем ранее созданное действие CapsRemote

Уберем вывод caps в общий лог Mikrotik

Узнаем ID топика info:

system logging print                                                                                            
Flags: X - disabled, I - invalid, * - default 
 #    TOPICS                          ACTION
 5    info                            memory
 6    warning                         memory
 7    error                           memory
 9    caps                            CapsRemote

Запрещаем топику caps отправлять данные в info с помощью символа отрицания «!«:

system logging set numbers=5 topics=info,!caps

Сделаем еще раз вывод топиков:

system logging print                                                                                            
Flags: X - disabled, I - invalid, * - default 
 #    TOPICS                          ACTION
 5    info                            memory
      !caps
 6    warning                         memory
 7    error                           memory
 9    caps                            CapsRemote

Видим, что из info исключен caps

Настраиваем syslog на прием логов Mikrotik

В начало конфигурационного файла /etc/syslog.conf вписываем следующие строки:

+192.168.6.2
local5.*                                        /var/log/mikrotik/caps.log
+*
+@

Где 192.168.6.2 — адрес нашего Mikrotik
Создадим директорию для нашего лога:

mkdir /var/log/mikrotik

Перезапустим syslogd

/etc/rc.d/syslogd restart

Должен создаться лог-файл:

# less /var/log/mikrotik/caps.log
Feb 27 11:19:46 <local5.info> 192.168.6.2 18:F0:E4:FF:EC:09@cap15 connected, signal strength -66
Feb 27 11:19:46 <local5.info> 192.168.6.2 18:F0:E4:FF:EC:09@cap13 disconnected, registered to other interface
Feb 27 11:20:25 <local5.info> 192.168.6.2 80:82:23:6D:6C:08@cap11 connected, signal strength -55
Feb 27 11:20:25 <local5.info> 192.168.6.2 80:82:23:6D:6C:08@cap7 disconnected, registered to other interface
Feb 27 11:20:26 <local5.info> 192.168.6.2 20:47:DA:33:B1:01@cap9 connected, signal strength -62
Feb 27 11:21:28 <local5.info> 192.168.6.2 CC:78:5F:AC:FC:71@cap19 connected, signal strength -58
Feb 27 11:21:28 <local5.info> 192.168.6.2 CC:78:5F:AC:FC:71@cap7 disconnected, registered to other interface
Feb 27 11:21:33 <local5.info> 192.168.6.2 80:82:23:6D:6C:08@cap9 connected, signal strength -73
Feb 27 11:21:39 <local5.info> 192.168.6.2 80:82:23:6D:6C:08@cap9 disconnected, received deauth: 4-way handshake timeout (15)
Feb 27 11:21:40 <local5.info> 192.168.6.2 80:82:23:6D:6C:08@cap11 reassociating
Feb 27 11:21:40 <local5.info> 192.168.6.2 80:82:23:6D:6C:08@cap11 connected, signal strength -76
Feb 27 11:21:44 <local5.info> 192.168.6.2 D4:38:9C:03:24:21@cap17 connected, signal strength -61
Feb 27 11:21:44 <local5.info> 192.168.6.2 D4:38:9C:03:24:21@cap5 disconnected, received deauth: class 3 frame received (7)
Feb 27 11:23:02 <local5.info> 192.168.6.2 80:82:23:6D:6C:08@cap5 connected, signal strength -77

В логе на самом Mikrotik данная информация не дублируется, то что нам и нужно.

Настроим ротацию лога

# vi /etc/newsyslog.conf
/var/log/mikrotik/caps.log    600  7  *    @T00     JC

Будем ежедневно архивировать (bz2 архив) логи, срок хранения 7 дней

Перезапустим newsyslog

# /etc/rc.d/newsyslog restart

Собственно все:)
Если что непонятно — оставляйте комментарии.

Разбор настройки ELK 7.5 для анализа логов Mikrotik / Хабр

Давно была мысль посмотреть, что можно делать с 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 система, которая умеет логировать.

Отправка syslog сообщений на удалённый сервер

В Mikrotik для настройки логирования на удалённый сервер через CLI достаточно ввести пару команд:

/system logging action add remote=192.168.88.130 remote-port=5145 src-address=192.168.88.1 name=logstash target=remote
/system logging add action=logstash topics=info

Настройка правил 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 на соответствующий.

/ip firewall nat
add action=netmap chain=dstnat comment="HONEYPOT RDP" dst-port=3389 in-interface=bridge-wan log=yes log-prefix=honeypot_rdp protocol=tcp to-addresses=192.168.88.201 to-ports=3389
add action=netmap chain=dstnat comment="HONEYPOT ELASTIC" dst-port=9200 in-interface=bridge-wan log=yes log-prefix=honeypot_elastic protocol=tcp to-addresses=192.168.88.201 to-ports=9211
add action=netmap chain=dstnat comment=" HONEYPOT TELNET" dst-port=23 in-interface=bridge-wan log=yes log-prefix=honeypot_telnet protocol=tcp to-addresses=192.168.88.201 to-ports=2325
add action=netmap chain=dstnat comment="HONEYPOT DNS" dst-port=53 in-interface=bridge-wan log=yes log-prefix=honeypot_dns protocol=udp to-addresses=192.168.88.201 to-ports=9953
add action=netmap chain=dstnat comment="HONEYPOT FTP" dst-port=21 in-interface=bridge-wan log=yes log-prefix=honeypot_ftp protocol=tcp to-addresses=192.168.88.201 to-ports=9921
add action=netmap chain=dstnat comment="HONEYPOT SMTP" dst-port=25 in-interface=bridge-wan log=yes log-prefix=honeypot_smtp protocol=tcp to-addresses=192.168.88.201 to-ports=9925
add action=netmap chain=dstnat comment="HONEYPOT SMB" dst-port=445 in-interface=bridge-wan log=yes log-prefix=honeypot_smb protocol=tcp to-addresses=192.168.88.201 to-ports=9445
add action=netmap chain=dstnat comment="HONEYPOT MQTT" dst-port=1883 in-interface=bridge-wan log=yes log-prefix=honeypot_mqtt protocol=tcp to-addresses=192.168.88.201 to-ports=9883
add action=netmap chain=dstnat comment="HONEYPOT SIP" dst-port=5060 in-interface=bridge-wan log=yes log-prefix=honeypot_sip protocol=tcp to-addresses=192.168.88.201 to-ports=9060
add action=dst-nat chain=dstnat comment="HONEYPOT SSH" dst-port=22 in-interface=bridge-wan log=yes log-prefix=honeypot_ssh protocol=tcp to-addresses=192.168.88.201 to-ports=9922

В Winbox то же самое настраивается в разделе IP > Firewall > вкладка NAT.

Теперь роутер будет перенаправлять полученные пакеты на локальный адрес 192.168.88.201 и кастомный порт. Сейчас пока что никто не слушает на этих портах, так что коннекты будут обрываться. В дальнейшем в докере можно запустит honeypot, коих множество под каждый сервис. Если этого делать не планируется, то вместо правил NAT следует прописать правило с действием drop в цепочке Filter.

Запуск ELK с помощью docker-compose

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

❯❯ git clone https://github.com/mekhanme/elk-mikrot.git

В тестовом или dev окружении удобнее всего запускать docker контейнеры c помощью docker-compose. В этом проекте я использую docker-compose файл последней на данный момент версии 3.7, он требует docker engine версии 18.06.0+, так что не лишним обновить docker, а так же docker-compose.

❯❯ curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
❯❯ chmod +x /usr/local/bin/docker-compose

Так как в последних версиях docker-compose выпилили параметр mem_limit и добавили deploy, запускающийся только в swarm mode (docker stack deploy), то запуск docker-compose up конфигурации с лимитами приводит к ошибке. Так как я не использую swarm, а лимиты ресурсов иметь хочется, запускать приходится с опцией —compatibility, которая конвертирует лимиты из docker-compose новых версий в нон-сварм эквивалент.

Пробный запуск всех контейнеров (в фоновом режиме -d):

❯❯ docker-compose --compatibility up -d

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

❯❯ docker-compose --compatibility ps

Благодаря тому, что все контейнеры будут в одной сети (если явно не указывать сеть, то создаётся новый бридж, что подходит в этом сценарии) и в docker-compose.yml у всех контейнеров прописан параметр container_name, между контейнерами уже будет связность через встроенный DNS докера. Вследствие чего не требуется прописывать IP-адреса в конфигах контейнеров. В конфиге Logstash прописана подсеть 192.168.88.0/24 как локальная, дальше по конфигурации будут более подробные пояснения, по которым можно оттюнить пример конфига перед запуском.

Настройка сервисов ELK

Дальше будут пояснения по настройке функционала компонентов ELK, а также ещё некоторые действия, которые нужно будет произвести над Elasticsearch.

Для определения географических координат по IP-адресу потребуется скачать free базу GeoLite2 от MaxMind:

❯❯ cd elk-mikrot && mkdir logstash/geoip_db
❯❯ curl -O https://geolite.maxmind.com/download/geoip/database/GeoLite2-City-CSV.zip && unzip GeoLite2-City-CSV.zip -d logstash/geoip_db && rm -f GeoLite2-City-CSV.zip
❯❯ curl -O https://geolite.maxmind.com/download/geoip/database/GeoLite2-ASN-CSV.zip && unzip GeoLite2-ASN-CSV.zip -d logstash/geoip_db && rm -f GeoLite2-ASN-CSV.zip

Настройка Logstash

Основным файлом конфигурации является logstash.yml, там я прописал опцию автоматического релоада конфигурации, остальные настройки для тестового окружения не значительные. Конфигурация самой обработки данных (логов) в Logstash описывается в отдельных conf файлах, обычно хранящихся в директории pipeline. При схеме, когда используются multiple pipelines, файл pipelines.yml описывает активированные пайплайны. Пайплайн — это цепочка действий над неструктурированными данными, чтобы на выходе получить данные с определённой структурой. Схема с отдельно настроенным pipelines.yml не обязательная, можно обойтись и без него, загружая все конфиги из примонтированной директории pipeline, однако с определённым файлом pipelines.yml настройка получается более гибкая, так как можно не удаляя conf файлы из директории pipeline, включать и выключать необходимые конфиги. К тому же перезагрузка конфигов работает только в схеме multiple pipelines.

❯❯ cat logstash/config/pipelines.yml
- pipeline.id: logstash-mikrot
  path.config: "pipeline/logstash-mikrot.conf"

Дальше идёт самая важная часть конфига Logstash. Описание pipeline состоит из нескольких секций — в начале в секции Input указываются плагины, с помощью которых Logstash получает данные. Наиболее простой способ собирать syslog с сетевого устройства — использовать input плагины tcp/udp. Единственный обязательный параметр этих плагинов — это port, его нужно указать таким же, как и в настройках роутера.

Второй секцией идёт Filter, в которой прописываются дальнейшие действия с пока ещё не структурированными данными. В моём примере удаляются лишние syslog сообщения от роутера с определённым текстом. Делается это с помощью условия и стандартного действия drop, которое отбрасывает всё сообщение, если условие удовлетворяется. В условии проверяется поле message на наличие определённого текста.

Если сообщение не дропнулось, оно идёт дальше по цепочке и попадает в фильтр grok. Как написано в документации, grok is a great way to parse unstructured log data into something structured and queryable. Этот фильтр применяют для обработки логов различных систем (linux syslog, веб-сервера, БД, сетевые устройства и т.д.). На основе готовых паттернов можно, не тратя много времени, составить парсер для любой более-менее повторяющейся последовательности. Для валидации удобно использовать онлайн парсер (в последней версии Kibana аналогичный функционал есть в разделе Dev Tools).

В docker-compose.yml прописан volume «./logstash/patterns:/usr/share/logstash/patterns», в директории patterns лежит файл со стандартными community-паттернами (просто для удобства, посмотреть если забыл), а так же файл с паттернами нескольких типов сообщений Mikrotik (модули Firewall и Auth), по аналогии можно дополнить своими шаблонами для сообщений другой структуры.

Стандартные опции add_field и remove_field позволяют внутри любого фильтра добавить или удалить поля из обрабатываемого сообщения. В данном случае удаляется поле host, которое содержит имя хоста, с которого было получено сообщение. В моём примере хост всего один, так что смысла в этом поле нет.

Дальше всё в той же секции Filter я прописал фильтр cidr, который проверяет поле с IP-адресом на соответствие условию вхождения в заданную подсеть и ставит тег. На основе тега в дальнейшей цепочке будут производиться или не производиться действия (если конкретно, то это для того, чтобы в дальнейшем не делать geoip lookup для локальных адресов).

Секций Filter может быть сколько угодно, и, чтобы было меньше условий внутри одной секции, в новой секции я определил действия для сообщений без тега src_local, то есть тут обрабатываются события файрволла, в которых нам интересен именно адрес источника.

Теперь надо немного подробнее рассказать про то, откуда Logstash берёт GeoIP информацию. Logstash поддерживает базы GeoLite2. Есть несколько вариантов баз, я использую две базы: GeoLite2 City (в которой есть информация о стране, городе, часовом поясе) и GeoLite2 ASN (информация об автономной системе, к которой принадлежит IP-адрес).

Плагин geoip и занимается добавлением GeoIP информации в сообщение. Из параметров надо указать поле, в котором содержится IP-адрес, используемую базу, и название нового поля, в которое будет прописана информация. У меня в примере тоже самое делается и для destination IP-адреса, но пока что в этом простом сценарии эта информация будет неинтересна, так как адрес назначения всегда будет являться адресом роутера. Однако в дальнейшем в этот пайплайн можно будет добавить логи не только с файрволла, но и с других систем, где актуально будет смотреть на оба адреса.

Фильтр mutate позволяет изменять поля сообщения и модифицировать сам текст в полях, в документации подробно написано много примеров того, что можно делать. В данном случае используется для добавления тега, переименования полей (для дальнейшей визуализации логов в Kibana требуется определённый формат объекта geo-point, дальше я ещё коснусь этой темы) и удаления ненужных полей.

На этом секция обработки данных заканчивается и остаётся только обозначить, куда слать структурированное сообщение. В данном случае сбором данных будет заниматься Elasticsearch, нужно только ввести IP-адрес, порт и название индекса. Индекс рекомендуется вводить с variable полем даты, чтобы каждый день создавался новый индекс.

Настройка Elasticsearch

Возвращаемся к Elasticsearch. Для начала надо удостовериться, что сервер запущен и функционирует. С Elastic эффективнее всего взаимодействовать через Rest API в CLI. С помощью curl можно посмотреть состояние ноды (localhost заменить на ip-адрес докер хоста):

❯❯ curl localhost:9200

Дальше можно пробовать открыть 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).

❯❯ curl -X POST -H "Content-Type: application/json" -d @elasticsearch/logstash_mikrot-template.json http://192.168.88.130:9200/_template/logstash-mikrot

После изменения мапинга нужно удалить индекс:

❯❯ curl -X DELETE http://192.168.88.130:9200/logstash-mikrot-2019.12.16

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

❯❯ curl http://192.168.88.130:9200/logstash-mikrot-2019.12.16/_mapping

Для дальнейшего использования данных в 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:

❯❯ docker logs logstash --tail 100 -f

Logstash не будет работать, если нет связности с Elasticsearch, или ошибка в конфигурации пайплайна — это основные причины и о них становится ясно после внимательного изучения логов, которые по умолчанию пишутся в json докером.

Если ошибок в логе нет, нужно убедиться, что Logstash ловит сообщения на своём настроенном сокете. Для целей дебага можно использовать stdout в качестве output:

stdout { codec => rubydebug }

После этого Logstash будет писать дебаг информацию при полученном сообщении прямо в лог.

Проверить Elasticsearch очень просто — достаточно сделать GET запрос curl`ом на IP-адрес и порт сервера, либо на определённый API endpoint. Например посмотреть состояние индексов в человекочитаемой таблице:

❯❯ curl -s 'http://192.168.88.130:9200/_cat/indices?v'

Kibana тоже не запустится, если не будет коннекта до Elasticsearch, увидеть это легко по логам.

Если веб-интерфейс не открывается, то стоит убедиться, что в Linux правильно настроен или отключён firewall (в Centos были проблемы с iptables и docker, решились по советам из топика). Также стоит учитывать, что на не очень производительном оборудовании все компоненты могут загружаться несколько минут. При нехватке помяти сервисы вообще могут не загрузиться. Посмотреть использование ресурсов контейнерами:

❯❯ docker stats

Если вдруг кто-то не знает, как корректно изменить конфигурацию контейнеров в файле docker-compose.yml и перезапустить контейнеры, это делается редактированием docker-compose.yml и с помощью той же команды с тем же параметрами перезапускается:

❯❯ docker-compose --compatibility up -d

При этом в изменённых секциях старые объекты (контейнеры, сети, волюмы) стираются и пересоздаются новые согласно конфигу. Данные сервисов при этом не теряются, так как используется named volumes, которые не удаляются с контейнером, а конфиги монтируются с хостовой системы, Logstash так умеет даже мониторить файлы конфигов и перезапускать пайплайн конфигурацию при изменении в файле.

Перезапустить сервис отдельно можно командой docker restart (при этом не обязательно находиться в директории с docker-compose.yml):

❯❯ docker restart logstash

Посмотреть конфигурацию объекта докер можно командой docker inspect, совместно с jq использовать удобнее.

Заключение

Хочу отметить, что security в этом проекте не доложено потому, что это тестовое (dev) окружение и не планируется выпуск наружу за пределы роутера. Если разворачивать для более серьёзного использования, то нужно следовать best practice, устанавливать сертификаты для HTTPS, делать резервирование, нормальный мониторинг (который запускается не рядом с основной системой). К слову, на моём сервере работает Traefik в докере, который является обратным прокси для некоторых сервисов, а так же терминирует TLS на себя и делает аутентификацию. То есть, благодаря настроенному DNS и reverse proxy, появляется возможность из интернета зайти в веб-интерфейс Kibana с ненастроенным HTTPS и паролем (насколько я понял, в комьюнити версии Kibana не поддерживает парольную защиту веб-интерфейса). Планирую в дальнейшем описать свой опыт настройки Traefik для использования в домашней сети с Docker.

Разбор настройки ELK 7.5 для анализа логов Mikrotik

Давно была мысль посмотреть, что можно делать с 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 система, которая умеет логировать.

Отправка syslog сообщений на удалённый сервер

В Mikrotik для настройки логирования на удалённый сервер через CLI достаточно ввести пару команд:

/system logging action add remote=192.168.88.130 remote-port=5145 src-address=192.168.88.1 name=logstash target=remote
/system logging add action=logstash topics=info

Настройка правил 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 на соответствующий.

/ip firewall nat
add action=netmap chain=dstnat comment="HONEYPOT RDP" dst-port=3389 in-interface=bridge-wan log=yes log-prefix=honeypot_rdp protocol=tcp to-addresses=192.168.88.201 to-ports=3389
add action=netmap chain=dstnat comment="HONEYPOT ELASTIC" dst-port=9200 in-interface=bridge-wan log=yes log-prefix=honeypot_elastic protocol=tcp to-addresses=192.168.88.201 to-ports=9211
add action=netmap chain=dstnat comment=" HONEYPOT TELNET" dst-port=23 in-interface=bridge-wan log=yes log-prefix=honeypot_telnet protocol=tcp to-addresses=192.168.88.201 to-ports=2325
add action=netmap chain=dstnat comment="HONEYPOT DNS" dst-port=53 in-interface=bridge-wan log=yes log-prefix=honeypot_dns protocol=udp to-addresses=192.168.88.201 to-ports=9953
add action=netmap chain=dstnat comment="HONEYPOT FTP" dst-port=21 in-interface=bridge-wan log=yes log-prefix=honeypot_ftp protocol=tcp to-addresses=192.168.88.201 to-ports=9921
add action=netmap chain=dstnat comment="HONEYPOT SMTP" dst-port=25 in-interface=bridge-wan log=yes log-prefix=honeypot_smtp protocol=tcp to-addresses=192.168.88.201 to-ports=9925
add action=netmap chain=dstnat comment="HONEYPOT SMB" dst-port=445 in-interface=bridge-wan log=yes log-prefix=honeypot_smb protocol=tcp to-addresses=192.168.88.201 to-ports=9445
add action=netmap chain=dstnat comment="HONEYPOT MQTT" dst-port=1883 in-interface=bridge-wan log=yes log-prefix=honeypot_mqtt protocol=tcp to-addresses=192.168.88.201 to-ports=9883
add action=netmap chain=dstnat comment="HONEYPOT SIP" dst-port=5060 in-interface=bridge-wan log=yes log-prefix=honeypot_sip protocol=tcp to-addresses=192.168.88.201 to-ports=9060
add action=dst-nat chain=dstnat comment="HONEYPOT SSH" dst-port=22 in-interface=bridge-wan log=yes log-prefix=honeypot_ssh protocol=tcp to-addresses=192.168.88.201 to-ports=9922

В Winbox то же самое настраивается в разделе IP > Firewall > вкладка NAT.

Теперь роутер будет перенаправлять полученные пакеты на локальный адрес 192.168.88.201 и кастомный порт. Сейчас пока что никто не слушает на этих портах, так что коннекты будут обрываться. В дальнейшем в докере можно запустит honeypot, коих множество под каждый сервис. Если этого делать не планируется, то вместо правил NAT следует прописать правило с действием drop в цепочке Filter.

Запуск ELK с помощью docker-compose

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

❯❯ git clone https://github.com/mekhanme/elk-mikrot.git

В тестовом или dev окружении удобнее всего запускать docker контейнеры c помощью docker-compose. В этом проекте я использую docker-compose файл последней на данный момент версии 3.7, он требует docker engine версии 18.06.0+, так что не лишним обновить docker, а так же docker-compose.

❯❯ curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
❯❯ chmod +x /usr/local/bin/docker-compose

Так как в последних версиях docker-compose выпилили параметр mem_limit и добавили deploy, запускающийся только в swarm mode (docker stack deploy), то запуск docker-compose up конфигурации с лимитами приводит к ошибке. Так как я не использую swarm, а лимиты ресурсов иметь хочется, запускать приходится с опцией —compatibility, которая конвертирует лимиты из docker-compose новых версий в нон-сварм эквивалент.

Пробный запуск всех контейнеров (в фоновом режиме -d):

❯❯ docker-compose --compatibility up -d

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

❯❯ docker-compose --compatibility ps

Благодаря тому, что все контейнеры будут в одной сети (если явно не указывать сеть, то создаётся новый бридж, что подходит в этом сценарии) и в docker-compose.yml у всех контейнеров прописан параметр container_name, между контейнерами уже будет связность через встроенный DNS докера. Вследствие чего не требуется прописывать IP-адреса в конфигах контейнеров. В конфиге Logstash прописана подсеть 192.168.88.0/24 как локальная, дальше по конфигурации будут более подробные пояснения, по которым можно оттюнить пример конфига перед запуском.

Настройка сервисов ELK

Дальше будут пояснения по настройке функционала компонентов ELK, а также ещё некоторые действия, которые нужно будет произвести над Elasticsearch.

Для определения географических координат по IP-адресу потребуется скачать free базу GeoLite2 от MaxMind:

❯❯ cd elk-mikrot && mkdir logstash/geoip_db
❯❯ curl -O https://geolite.maxmind.com/download/geoip/database/GeoLite2-City-CSV.zip && unzip GeoLite2-City-CSV.zip -d logstash/geoip_db && rm -f GeoLite2-City-CSV.zip
❯❯ curl -O https://geolite.maxmind.com/download/geoip/database/GeoLite2-ASN-CSV.zip && unzip GeoLite2-ASN-CSV.zip -d logstash/geoip_db && rm -f GeoLite2-ASN-CSV.zip

Настройка Logstash

Основным файлом конфигурации является logstash.yml, там я прописал опцию автоматического релоада конфигурации, остальные настройки для тестового окружения не значительные. Конфигурация самой обработки данных (логов) в Logstash описывается в отдельных conf файлах, обычно хранящихся в директории pipeline. При схеме, когда используются multiple pipelines, файл pipelines.yml описывает активированные пайплайны. Пайплайн — это цепочка действий над неструктурированными данными, чтобы на выходе получить данные с определённой структурой. Схема с отдельно настроенным pipelines.yml не обязательная, можно обойтись и без него, загружая все конфиги из примонтированной директории pipeline, однако с определённым файлом pipelines.yml настройка получается более гибкая, так как можно не удаляя conf файлы из директории pipeline, включать и выключать необходимые конфиги. К тому же перезагрузка конфигов работает только в схеме multiple pipelines.

❯❯ cat logstash/config/pipelines.yml
- pipeline.id: logstash-mikrot
  path.config: "pipeline/logstash-mikrot.conf"

Дальше идёт самая важная часть конфига Logstash. Описание pipeline состоит из нескольких секций — в начале в секции Input указываются плагины, с помощью которых Logstash получает данные. Наиболее простой способ собирать syslog с сетевого устройства — использовать input плагины tcp/udp. Единственный обязательный параметр этих плагинов — это port, его нужно указать таким же, как и в настройках роутера.

Второй секцией идёт Filter, в которой прописываются дальнейшие действия с пока ещё не структурированными данными. В моём примере удаляются лишние syslog сообщения от роутера с определённым текстом. Делается это с помощью условия и стандартного действия drop, которое отбрасывает всё сообщение, если условие удовлетворяется. В условии проверяется поле message на наличие определённого текста.

Если сообщение не дропнулось, оно идёт дальше по цепочке и попадает в фильтр grok. Как написано в документации, grok is a great way to parse unstructured log data into something structured and queryable. Этот фильтр применяют для обработки логов различных систем (linux syslog, веб-сервера, БД, сетевые устройства и т.д.). На основе готовых паттернов можно, не тратя много времени, составить парсер для любой более-менее повторяющейся последовательности. Для валидации удобно использовать онлайн парсер (в последней версии Kibana аналогичный функционал есть в разделе Dev Tools).

В docker-compose.yml прописан volume «./logstash/patterns:/usr/share/logstash/patterns», в директории patterns лежит файл со стандартными community-паттернами (просто для удобства, посмотреть если забыл), а так же файл с паттернами нескольких типов сообщений Mikrotik (модули Firewall и Auth), по аналогии можно дополнить своими шаблонами для сообщений другой структуры.

Стандартные опции add_field и remove_field позволяют внутри любого фильтра добавить или удалить поля из обрабатываемого сообщения. В данном случае удаляется поле host, которое содержит имя хоста, с которого было получено сообщение. В моём примере хост всего один, так что смысла в этом поле нет.

Дальше всё в той же секции Filter я прописал фильтр cidr, который проверяет поле с IP-адресом на соответствие условию вхождения в заданную подсеть и ставит тег. На основе тега в дальнейшей цепочке будут производиться или не производиться действия (если конкретно, то это для того, чтобы в дальнейшем не делать geoip lookup для локальных адресов).

Секций Filter может быть сколько угодно, и, чтобы было меньше условий внутри одной секции, в новой секции я определил действия для сообщений без тега src_local, то есть тут обрабатываются события файрволла, в которых нам интересен именно адрес источника.

Теперь надо немного подробнее рассказать про то, откуда Logstash берёт GeoIP информацию. Logstash поддерживает базы GeoLite2. Есть несколько вариантов баз, я использую две базы: GeoLite2 City (в которой есть информация о стране, городе, часовом поясе) и GeoLite2 ASN (информация об автономной системе, к которой принадлежит IP-адрес).

Плагин geoip и занимается добавлением GeoIP информации в сообщение. Из параметров надо указать поле, в котором содержится IP-адрес, используемую базу, и название нового поля, в которое будет прописана информация. У меня в примере тоже самое делается и для destination IP-адреса, но пока что в этом простом сценарии эта информация будет неинтересна, так как адрес назначения всегда будет являться адресом роутера. Однако в дальнейшем в этот пайплайн можно будет добавить логи не только с файрволла, но и с других систем, где актуально будет смотреть на оба адреса.

Фильтр mutate позволяет изменять поля сообщения и модифицировать сам текст в полях, в документации подробно написано много примеров того, что можно делать. В данном случае используется для добавления тега, переименования полей (для дальнейшей визуализации логов в Kibana требуется определённый формат объекта geo-point, дальше я ещё коснусь этой темы) и удаления ненужных полей.

На этом секция обработки данных заканчивается и остаётся только обозначить, куда слать структурированное сообщение. В данном случае сбором данных будет заниматься Elasticsearch, нужно только ввести IP-адрес, порт и название индекса. Индекс рекомендуется вводить с variable полем даты, чтобы каждый день создавался новый индекс.

Настройка Elasticsearch

Возвращаемся к Elasticsearch. Для начала надо удостовериться, что сервер запущен и функционирует. С Elastic эффективнее всего взаимодействовать через Rest API в CLI. С помощью curl можно посмотреть состояние ноды (localhost заменить на ip-адрес докер хоста):

❯❯ curl localhost:9200

Дальше можно пробовать открыть 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).

❯❯ curl -X POST -H "Content-Type: application/json" -d @elasticsearch/logstash_mikrot-template.json http://192.168.88.130:9200/_template/logstash-mikrot

После изменения мапинга нужно удалить индекс:

❯❯ curl -X DELETE http://192.168.88.130:9200/logstash-mikrot-2019.12.16

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

❯❯ curl http://192.168.88.130:9200/logstash-mikrot-2019.12.16/_mapping

Для дальнейшего использования данных в 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:

❯❯ docker logs logstash --tail 100 -f

Logstash не будет работать, если нет связности с Elasticsearch, или ошибка в конфигурации пайплайна — это основные причины и о них становится ясно после внимательного изучения логов, которые по умолчанию пишутся в json докером.

Если ошибок в логе нет, нужно убедиться, что Logstash ловит сообщения на своём настроенном сокете. Для целей дебага можно использовать stdout в качестве output:

stdout { codec => rubydebug }

После этого Logstash будет писать дебаг информацию при полученном сообщении прямо в лог.

Проверить Elasticsearch очень просто — достаточно сделать GET запрос curl`ом на IP-адрес и порт сервера, либо на определённый API endpoint. Например посмотреть состояние индексов в человекочитаемой таблице:

❯❯ curl -s 'http://192.168.88.130:9200/_cat/indices?v'

Kibana тоже не запустится, если не будет коннекта до Elasticsearch, увидеть это легко по логам.

Если веб-интерфейс не открывается, то стоит убедиться, что в Linux правильно настроен или отключён firewall (в Centos были проблемы с iptables и docker, решились по советам из топика). Также стоит учитывать, что на не очень производительном оборудовании все компоненты могут загружаться несколько минут. При нехватке помяти сервисы вообще могут не загрузиться. Посмотреть использование ресурсов контейнерами:

❯❯ docker stats

Если вдруг кто-то не знает, как корректно изменить конфигурацию контейнеров в файле docker-compose.yml и перезапустить контейнеры, это делается редактированием docker-compose.yml и с помощью той же команды с тем же параметрами перезапускается:

❯❯ docker-compose --compatibility up -d

При этом в изменённых секциях старые объекты (контейнеры, сети, волюмы) стираются и пересоздаются новые согласно конфигу. Данные сервисов при этом не теряются, так как используется named volumes, которые не удаляются с контейнером, а конфиги монтируются с хостовой системы, Logstash так умеет даже мониторить файлы конфигов и перезапускать пайплайн конфигурацию при изменении в файле.

Перезапустить сервис отдельно можно командой docker restart (при этом не обязательно находиться в директории с docker-compose.yml):

❯❯ docker restart logstash

Посмотреть конфигурацию объекта докер можно командой docker inspect, совместно с jq использовать удобнее.

Заключение

Хочу отметить, что security в этом проекте не доложено потому, что это тестовое (dev) окружение и не планируется выпуск наружу за пределы роутера. Если разворачивать для более серьёзного использования, то нужно следовать best practice, устанавливать сертификаты для HTTPS, делать резервирование, нормальный мониторинг (который запускается не рядом с основной системой). К слову, на моём сервере работает Traefik в докере, который является обратным прокси для некоторых сервисов, а так же терминирует TLS на себя и делает аутентификацию. То есть, благодаря настроенному DNS и reverse proxy, появляется возможность из интернета зайти в веб-интерфейс Kibana с ненастроенным HTTPS и паролем (насколько я понял, в комьюнити версии Kibana не поддерживает парольную защиту веб-интерфейса). Планирую в дальнейшем описать свой опыт настройки Traefik для использования в домашней сети с Docker.

Очистка логов для системы средствами wmic в Windows Server 2008 R2.

Прочитано:
2 115

“Логи в системе Windows7/Windows Server 2008 R2 Std хранятся по адресу c:\windows\system32\winevt\logs\”

Сейчас я покажу, как их очистить с помощью командной строки (cmd.exe) с использованием wmic.

Заходим в систему (dc1.polygon.local) с правами Администратора (ekzorchik) и запускаем командную строку (cmd.exe) в Административном окружении.

(,так делается в Windows 7 && Windows Server 2008/R2)

Пример синтаксиса:

"Wmic nteventlog where filename=”<имя_журнала>” call ClearEventlog"

Предлагаю Вам ознакомиться с примерами очистки логов в системе:

Очищаем лог Application:

C:\Windows\system32>wmic nteventlog where filename="Application" call ClearEventlog

Executing (\\DC1\ROOT\CIMV2:Win32_NTEventlogFile.Name=»C:\\Windows\\System32\\Wi

nevt\\Logs\\Application.evtx»)->ClearEventlog()

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;

};

При очистке лога его размер будет соответствовать (68KB), см скриншот:

Очищаем лог Security:

C:\Windows\system32>wmic nteventlog where filename="Security" call ClearEventlog

Executing (\\DC1\ROOT\CIMV2:Win32_NTEventlogFile.Name=»C:\\Windows\\System32\\Wi

nevt\\Logs\\Security.evtx»)->ClearEventlog()

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;

};

Очищаем лог System:

C:\Windows\system32>wmic nteventlog where filename="System" call ClearEventlog

Executing (\\DC1\ROOT\CIMV2:Win32_NTEventlogFile.Name=»C:\\Windows\\System32\\Wi

nevt\\Logs\\System.evtx»)->ClearEventlog()

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;

};

Очищаем лог Active Directory Web Services:

C:\Windows\system32>wmic nteventlog where filename="Active Directory Web Services" call ClearEventlog

Executing (\\DC1\ROOT\CIMV2:Win32_NTEventlogFile.Name=»C:\\Windows\\System32\\Wi

nevt\\Logs\\Active Directory Web Services.evtx»)->ClearEventlog()

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;

};

Очищаем лог DFS Replication:

C:\Windows\system32>wmic nteventlog where filename="DFS Replication" call ClearEventlog

Executing (\\DC1\ROOT\CIMV2:Win32_NTEventlogFile.Name=»C:\\Windows\\System32\\Wi

nevt\\Logs\\DFS Replication.evtx»)->ClearEventlog()

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;

};

Очищаем лог DFS Replication:

C:\Windows\system32>wmic nteventlog where filename="Directory Service" call ClearEventlog

Executing (\\DC1\ROOT\CIMV2:Win32_NTEventlogFile.Name=»C:\\Windows\\System32\\Wi

nevt\\Logs\\Directory Service.evtx»)->ClearEventlog()

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;

};

Очищаем лог DNS Server:

C:\Windows\system32>wmic nteventlog where filename="DNS Server" call ClearEventlog

Executing (\\DC1\ROOT\CIMV2:Win32_NTEventlogFile.Name=»C:\\Windows\\System32\\Wi

nevt\\Logs\\DNS Server.evtx»)->ClearEventlog()

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;

};

Вот собственно и всё, может, кому  и пригодится. Удачи.

новости, обзоры, настройка Mikrotik и Ubiquiti

В Mikrotik уже неоднократно напоминали о необходимости своевременно обновления. К сожалению, большинство владельцев пропускают данную информацию мимо ушей и не уделяют ей должного внимания.

Ситуация, с которой я столкнулся, вынуждает еще раз написать о необходимости обновления RouterOS, а также использования «правильных» настроек RouterOS. Также мы поговорим о том, чем чревато невыполнение этих рекомендаций.

Всё началось с одного из уведомлений Mikrotik, в котором говорилось о массовом сканировании сети на предмет использования маршрутизаторов под управлением RouterOS. Что это дает? Во-первых, возможность эксплуатации более старых уязвимостей, во-вторых – формирование базы с IP-адресами устройств RouterBOARD.

Если Вы хотите научиться настраивать MikroTik, предлагаем пройти онлайн обучение. Более подробную информацию Вы можете найти в конце данной публикации.И вот, буквально на днях, Mikrotik заговорили о критическом баге версий 6.29-6.42, который позволяет заполучить файл базы данных и расшифровать связку логин@пароль администратора устройства. Собственно подробностей в компании не сообщили, в интересах клиентов.

Многие успешно обновились и попросту забыли про данный баг. Но на этом история не заканчивается. Буквально вчера я наткнулся на специализированное программное обеспечение для поиска уязвимостей внутри сети.

Если Вы хотите научиться настраивать MikroTik, предлагаем пройти онлайн обучение. Более подробную информацию Вы можете найти в конце данной публикации.

Свои устройства я давно обновил, так что настроен был очень скептически.

Изначально я запустил процесс сканирования для своей сети, которая состоит из 9 подсетей. Поиск принес первые «плоды» – один из доверенных клиентских Mikrotik’ов, подключенный по L2TP+IPsec оказался со старой версией ROS. Но это не все… программа отобразила для него логин и пароль. Устройство было не наше, а одной из фирм, которая разрабатывает для фирмы, в которой я работаю, программное обеспечение. Логин и пароль подошли, что позволило мне успешно авторизоваться на чужом устройстве.

Пакостить я, конечно же, не стал и сразу же уведомил владельцев данного устройства.

Далее было принято решение запустить поверхностный скан локальной подсети местного провайдера (пара подсетей 192.168.х.х). То, что я увидел, меня шокировало – 58 устройств с критическими проблемами безопасности. Сам софт сканирует уязвимость не только микротиков, но и других устройств.
Структура проблемных устройств, которые мне удалось обнаружить в локальной сети, следующая:

• ASUS – 24;
• Mikrotik – 16;
• TP-Link – 5;
• Edimax – 3;
• Totolink – 2;
• Камеры Hikvision – 2;
• Камеры Hipcam – 2;
• DD-WRT – 1;
• Tenda – 1;
• Upvel – 1;

Как видим, абсолютный рекордсмен ASUS, в частности это модели RT-N10, RT-N10E, RT-N10P, RT-N10PV2, RT-N10U, RT-N12, RT-N12+, RT-N12E, RT-N12LX, RT-N12VP и даже топовые RT-AC51U и RT-N66U. Я не думаю, что пользователи намеренно открывали доступ к WebUI из WAN, скорее всего это баг прошивок.

Второе место по количеству уязвимых устройств занимает Mikrotik. Забавно, правда? И корень проблемы даже не в баге RouterOS. К сожалению, большинство пользователей попросту не разбираются в правилах Firewall.

Чаще всего пользователи довольствуются стандартными правилами Firewall и настройками RouterOS, они самодостаточные и не допускают доступ извне к панели управления.

Многие из тех, кто считают себя «продвинутыми» пользователями, начинают бороздить просторы интернета в поисках «идеальных» и «правильных» правил для Firewall. В процессе такой настройки пользователи сносят стандартную конфигурацию, заменяя её правилами из публикаций. Зачастую пользователи даже не понимают суть правил, которые добавляют. Как итог, пользователь получает открытые наружу порты WebFig и winbox! Неожиданно, правда?

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

Идея обращения к провайдеру была отброшена сразу, провайдер попросту не даст личные данные клиентов по IP, а сам заниматься данным вопросом не станет.

На одном из таких устройств я обнаружил PPP-подключение, и не просто на IP, а на доменное имя очень крупной и известной компании. Нужно срочно уведомить владельца, но как это сделать? В параметрах RouterOS я обнаружил настройки e-mail, что и позволило мне найти контакты владельца, копию письма я отправил администратору компании, к ресурсам которой подключено устройство.

Какими могли быть последствия? Как минимум, некий школьник мог без проблем сбросить конфигурацию – потеря не велика и клиент списал бы все на ошибку ПО. Мог быть и другой сценарий – настройка прокси-сервера, подмена DNS, перехват личных данных и слив файлов на внешнем накопителе (если он подключен к Mikrotik). При желании, злоумышленник может даже поднять VPN-сервер, настроить маршрутизацию и заходить в вашу сеть.

Худший сценарий? Злоумышленник выгружает конфигурацию в RSC-файл и начинает изучение. Что интересного можно найти в файле конфигурации? Очень много… в том числе пароль для PPP-подключения, статические маршруты в удаленную сеть, DNS-записи при их наличии.

Все это было в конкретном случае – и данные VPN, и записи DNS для доступа к сервисам компании в удаленной сети, и все маршруты. По сути, сочетание неправильных правил Firewall и баг в RouterOS позволили бы потенциальному злоумышленнику получить полный доступ в удаленную сеть предприятия.

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

Владелец был незамедлительно уведомлен, после чего выполнил обновление ROS и полную смену паролей.

Я привел лишь единичный пример всего на одном устройстве, хотя из 16 обнаруженных, функционал PPP использовался, по меньшей мере, на 5.

Сейчас вы, наверное, подумаете, мол, это локальная сеть (все устройства за NAT провайдера) и тут никто не станет рисковать, да и в случае чего злоумышленника можно вычислить по логам. Во-первых, если к WAN есть доступ из локальной сети, значит при использовании «белого IP», будет доступ из Интернет, c любой точки мира. Во-вторых, при перезагрузке RouterOS по-умолчанию очищает логи, если не указано хранение на диск, либо не настроена выгрузка на внешний сервер.

Осознаете суть и масштаб проблемы?

В этом плане провайдеры, предоставляющие выход в сеть через NAT хотя-бы частично защищают клиента, те же клиенты у кого на WAN-интерфейсе сразу белый IP – могут рассчитывать только на себя.

Вот пример сканирования внешней подсети того же провайдера:

Как видим, ситуация ни чуть не лучше, можно даже сказать еще хуже – в логах RouterOS первого попавшего устройства видим непрекращающиеся попытки получения доступа из Интернет.

Но и это еще не все… по одному из логинов я заподозрил маршрутизатор одного из провайдеров, и не ошибся… собственно смотрите сами:

Да, это CCR1036. Названия интерфейсов скрыты в интересах пострадавшей стороны.

В логах видно, что кто-то из Интернет упорно брутфорсит маршрутизатор… Собственно, представители компании уже оповещены.

Возникает закономерный вопрос, что делать дальше?

Рекомендации по повышению защиты RouterOS и Mikrotik

#1: обновитесь до версии RouterOS 6.42.1 и выше

Первым делом обновите версию RouterOS на ВСЕХ ваших устройствах, критический баг исправлен в 6.42.1. Если же у вас версия ниже 6.29, о безопасности паролей волноваться не стоит, тем не менее, в старых версиях есть и другие уязвимости, так что в любом случае выполняйте обновление.

Регулярно следите за выпуском обновлений.

#2: смените ВСЕ пароли

На текущий момент не существует возможности гарантированно определить, была ли утечка данных. Единственный способ – просмотр логов на предмет успешных входов со сторонних IP и подсетей. Следует понимать, что ROS очищает лог при каждой перезагрузке устройства.

Правильное действие – полная смена всех паролей, которые использовались на устройстве, начиная с пароля админа, заканчивая паролем Wi-Fi и паролями VPN-подключений.

#3: используйте стандартные правила Firewall

Всё предельно просто – если вы не разбираетесь в тонкостях работы Firewall и не понимаете сути правил, воздержитесь от сторонних инструкций, используйте стандартную конфигурацию RouterOS со стандартными правилами Firewall. Они самодостаточные.

Стандартные правила имеют следующий вид:

/ip firewall filter
add action=accept chain=input comment="Allow PING (ICMP)" protocol=icmp
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=ether1
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related routing-mark=main
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=ether1

Где ether1 – это ваш WAN-интерфейс.

Иногда имеет смысл добавить блокировку доступа к DNS роутера, делает это запретом доступа к 53-му порту на WAN-интерфейсе.

add action=drop chain=input comment="Drop access to DNS from WAN" dst-port=53 in-interface=ether1 protocol=tcp
add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp

Само запрещающее правило надо поднять выше других разрешающих правил.

В случае, когда используется функционал VPN-сервера, потребуется открыть дополнительные порты. К примеру, для L2TP+IPsec потребуется следующее правило:

add action=accept chain=input comment="VPN  L2TP" dst-port=1701,500,4500 in-interface=ether1 protocol=udp
add action=accept chain=input comment="VPN L2TP IPsec" protocol=ipsec-esp

Порт 4500 открывать не требуется, если ваши VPN-клиенты не находятся за NAT провайдера. В идеале, порты следует открывать только для IP из «Address List», который заранее необходимо создать и внести в него подсети провайдера, из которого будут подключаться ваши клиенты. Если же вы в разъездах, данный вариант вам не подойдет.

RSC-файл для удобного импорта правил:

#4: отключите все неиспользуемые сервисы

Наиболее удобно устройствами Mikrotik управлять при помощи Winbox, изредка можно зайти в WebFig (WWW). Все остальное полностью отключаем в разделе IP – Services.

#5: используйте www-ssl вместо www

Обычный HTTP можно заменить на HTTPS, делается это все там же в подменю IP – Services.

Заранее вам потребуется создать самоподписный сертификат, делается это в разделе System – Certificates.

После заполнения формы нажмите последовательно Apply (применить) и Sign (подписать), в появившемся окне нажмите Start.

При заполнении формы можно указывать как IP роутера, так и его DNS-имя. В поле Days Valid необходимо указать период действия сертификата в днях, по желанию можно сразу создать сертификат на несколько лет.

Далее созданный сертификат укажите в выпадающем списке для www-ssl.

#6: ограничивайте доступ к сервисам

Также рекомендуется ограничивать список IP и подсетей, с которых разрешено подключение к сервисам управления. В подменю IP – Services при редактировании сервисов заполните поля Available From.

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

Обратите внимание, при использовании VPN, например L2TP, в качестве IP/подсети следует указывать адресное пространство, используемое внутри туннеля, а не удаленную подсеть! В противном случае вы не получите доступ. Собственно тут все просто, для роутера важен первый промежуточный узел, с которого осуществляется доступ. Если запутались – воспользуйтесь трассировкой маршрута (tracert).

#7: отключите admin

В обязательном порядке отключите или удалите встроенного пользователя с логином admin, заранее создав для себя нового пользователя с уровнем доступа full.

Как минимум, злоумышленник не будет знать логин администратора, что усложнит или сделает невозможным брутфорс. Тут также можно заполнять поле Allowed Address (аналог Available From), что удобно в больших сетях с несколькими админами.

#8: отключите UPnP

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

#9: для Wi-Fi используйте исключительно WPA2-PSK + AES

При использовании Wi-Fi, оставляйте активным только WPA2 PSK в связке с AES – наиболее защищенное сочетание.

Делается это в разделе Wireless – Security Profiles. WPA первого поколения и WEP уязвимы. То же самое касается TKIP.

#10: управляйте сетью при помощи DHCP

В больших сетях имеет смысл не просто отказаться от «ручных» настроек сети, но и вовсе запрещать подобные действия. Многие правила могут основываться на IP, поэтому в больших сетях следует доверять назначение IP исключительно DHCP-серверу.

Заходим в IP – DHCP Server и устанавливаем опцию «Add ARP for Leases».

Далее в настройках бриджа установите «ARP: reply only». После установки этих параметров, микротик будет обрабатывать запросы только от тех устройств, для которых IP выдан DHCP-сервером и они внесены в таблицу ARP.

С hAP ac2 данный трюк у меня не прошел, устройства попросту не имели доступа к сети. Как вариант решения – установка reply-only непосредственно на wan-интерфейсах.

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

В случаях, когда требуется статический IP, просто привяжите IP-адрес к MAC-адресу устройства. Делается это в разделе IP- DHCP Server – Leases, выбираете нужное устройство и нажимаете Make Static, после этого можно будет задать для устройства любой IP.

Каждый раз при подключении к сети, ваше устройство будет получать один и тот же IP.

#11: не давайте гостям пароль от своего Wi-Fi

Давая пароль от Wi-Fi всем подряд, вы подвергаете свою сеть дополнительному потенциальному риску. Для целей выхода в Интернет, лучше всего создать дополнительную гостевую сеть. Как это сделать, я подробно описывал в отдельной публикации: «Guest Wi-Fi: создание гостевой сети Wi-Fi с ограничением скорости на примере маршрутизаторов Mikrotik под управлением RouterOS».

#12: обезопасьте гостевой Wi-Fi

По возможности, для гостевой Wi-Fi сети или хотспота следует также использовать WPA2 вместо Open, что позволит отсеять большую часть «нежданных гостей». Используйте для этих целей дополнительный профиль безопасности.

#13: изолируйте гостей друг от друга

Еще одна рекомендация состоит в том, чтобы по возможности изолировать гостей друг от друга. Это повысит уровень защищенности каждого отдельного клиента, поскольку защитить сеть от сканирования на предмет активных устройств и открытых портов.

Делается это в настройках wlan, путем отключения опции «Default Forward».

Обратите внимание, для внутренней домашней сети этого делать не стоит.

#14: изолируйте гостей от внутренней подсети

Одна из самых главных рекомендаций, которые касаются гостевой подсети – её полная изоляция от основной сетевой инфраструктуры.

Один из вариантов описан в моей публикации по Guest Wi-Fi. Если коротко, гости используют отдельный бридж и отдельную подсеть, дополнительно настроены правила, запрещающие доступ из одной сети в другую (IP – Routes – Rules, правило с «action: unreachable»).

Видеокурс «Настройка оборудования MikroTik» (аналог MTCNA)

Учитесь работать с MikroTik? Рекомендую видеокурс «Настройка оборудования MikroTik». В курсе разобраны все темы из официальной учебной программы MTCNA и много дополнительного материала. Курс сочетает теоретическую часть и практику – настройку маршрутизатора по техническому заданию. Консультации по заданиям курса ведет его автор Дмитрий Скоромнов. Подойдет и для первого знакомства с оборудованием MikroTik, и для систематизации знаний опытным специалистам.

Как очистить журнал Mikrotik / История | Личный блог Сайеда Джаханзаиба для обмена знаниями!

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

▼

ОЧИСТИТЬ ИСТОРИЮ ОКНА ЖУРНАЛА Mikrotik [Jz]

/ действие системного журнала установить memory memory-lines = 1

 

Удаляет все предыдущие записи.

/ действие системного журнала установить memory memory-lines = 100

 

Он вернет количество строк по умолчанию. или установите значение 1, если вам не нужна информация, что не рекомендуется в любом случае not

ОЧИСТИТЬ ИСТОРИЮ КОНСОЛИ Mikrotik [Jz]

В более новой версии mikrotik 6.x вы можете очистить консольные команды с помощью

консоль clear-history

 

Примечание: использование более новой прошивки (но, безусловно, стабильной) — это всегда хорошая идея, чтобы оставаться в безопасности благодаря множеству новых функций 🙂

Однако я действительно хочу, чтобы Mikrotik мог добавить кнопку «ОЧИСТИТЬ ВСЕ ЖУРНАЛЫ» в будущем 😉

▼
Regard’s
Сайед Джаханзайб

24.851000
67,008300

Нравится:

Нравится Загрузка …

Связанные

.

Журнал — RouterOS — MikroTik

RouterOS может регистрировать различные системные события и информацию о состоянии. g (RFC 3164).

Сообщения журнала

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

 [admin @ uselogg Отмечено в 10.1.101.212 через winbox
сен / 15 12:33:18 система, информация добавлена ​​администратором
сен / 15 12:34:26 система, правило изменения информации добавлено администратором
сен / 15 12:34:29 система, правило изменения информации перенесено администратором
сен / 15 12:35:34 система, правила блокировки информации изменены администратором
сен / 15 12:42:14 система, информация, учетная запись пользователь admin вошел в систему с 10.1.101.212 через telnet
сен / 15 12:42:55 система, информация, учетная запись пользователь admin вышел из системы с 10.1.101.212 через telnet
01:01:58 брандмауэр, ввод информации: in: ether1 out: (none), src-mac 00: 21: 29: 6d: 82: 07, протокол UDP,
                          10.1.101.1:520->10.1.101.255:520, len 452 

Если журналы печатаются в тот же день, когда была добавлена ​​запись журнала, то будет отображаться только время. В приведенном выше примере вы можете видеть, что второе сообщение было добавлено 15 сентября текущего года (год не добавляется), а последнее сообщение было добавлено сегодня, поэтому отображается только время.

Примечание:

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

Например, следующая команда распечатает все сообщения журнала, в которых одна из тем — информация, и обнаружит новые записи журнала, пока не будет нажата Ctrl + C:

 [admin @ user] / log> print follow где темы ~ ".Информация"
12:52:24 скрипт, инфо привет из скрипта
- Ctrl-C, чтобы выйти. 

Если печать находится в режиме следования, вы можете нажать «пробел» на клавиатуре, чтобы вставить разделитель:

 [admin @ user] / log> print follow where themes ~ ".info"
12:52:24 скрипт, инфо привет из скрипта

 = = = = = = = = = = = = = = = = = = = = = = = = = = = =

- Ctrl-C, чтобы выйти. 

Конфигурация журнала

.