Периодическая смена MAC на Bridge-интерфейсе.

  У меня работает скрипт, который с периодичностью меняет пароль Wi-Fi на всех офисах одновременно и отсылает коллегам уведомление. Это сделано в целях безопасности и для удобства пользователей. Название сети везде одинаковое и сотрудникам не нужно каждый раз вводить новый пароль при приходе в другой офис. Этот скрипт писался еще до ввода нового функционала в RouterOS - CAPsMAN, но так как он работает довольно успешно - функционирует до сих пор. Офисов достаточное количество, и поэтому перед отправкой нового пароля на роутер каждого офиса, сам офис или подразделение проверяется пингом.

  Если в офисе стоит Wi-Fi-роутер, который получает IP по DHCP на бридж-интерфейс, и в раздающем по DHCP роутере  IP-получателя привязан к MAC-адресу, то периодически Wi-Fi-роутер начинает получать совершенно другой IP. Это связанно с особенностью RouterOS: по умолчанию мост наследует MAC-адрес от его портов, при чем это происходит в рандомном порядке. Поэтому маршрутизатор на другой MAC - выдает другой IP.

  Для того, что-бы этого не происходило есть 2 настройки в /interface bridge. 

auto-mac - автоматически формировать MAC-адрес на  Bridge-интерфейсе (по-умолчанию да)
admin-mac - указать свой статический MAC-адрес. Работает при условии, что настройка auto-mac=no.

Опция Random в Firewall Mikrotik - имитация плохого соединения.

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

  По факту, опция указывает в процентном соотношении количество пакетов для которых будет применяться данное правило.
  Для примера создадим правило, которое будет имитировать потерю пинга на сервер 8.8.8.8 в 20%.

Пакеты RouterOS.

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

  Доступность пакетов может отличатся от выбранной платформы (mipsle, mipsbe, ppc, x86). Главным пакетом является пакет system, его нельзя удалить, он является дефолтным на всех роутерах. Кроме него "с коробки" довольно большое количество пакетов включено в поставку для устройства Mikrotik. Это и пакет DHCP, ppp и другие. Стоит помнить, что эти пакеты не являются обязательными и могут быть отключены или удалены с маршрутизатора.

Защита Wi-Fi в Mikrotik.

Версия RoS 6.39rc27 

  За защиту WiFi сети в Mikrotik отвечают три вкладки: Access List (/interface wireless access-list), Connect List (/interface wireless connect-list), Security Profiles (/interface wireless security-profiles).

  Access List - список правил, которые ограничивают соединения других устройств к вашей точке, а также служат для управления параметрами подключения. (режим ap mode). 

  Пример: вы хотите ограничить подключение к вашей точке доступа по MAC-адресам.
  Connect List - список правил, которые ограничивают соединение вашего устройства к другим точкам доступа (режим station mode). 

  Пример: вы хотите автоматически подключать свою клиентскую станцию к точке доступа с максимальным уровнем сигнала (при наличии нескольких базовых станций).

  Security Profiles - настраиваются профили методов защиты и, непосредственно, ключи защиты беспроводной сети.

Защита SIP-порта. Часть 2: анализ пакетов.

  Для защиты SIP-порта можно использовать анализ пакетов с помощью опции "content" в Firewall Mikrotik. Но, для начала, нам нужно узнать, что именно посылает наш сервер телефонии на неправильный логин и пароль. Для примера возьмем самый популярный сервер телефонии - Asterisk с веб-интерфейсом FreePBX. Перво-наперво можно изучить, какие именно стандартные ответы дает SIP-сервер:

SIP/2.0 400 Bad Request - запрос не понят из-за синтаксических ошибок в нем, ошибка в сигнализации, скорее всего что-то с настройками оборудования
SIP/2.0 401 Unauthorized - нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль
SIP/2.0 401 Expired Authorization - время регистрации истекло
SIP/2.0 402 Payment Required - требуется оплата (зарезервирован для использования в будущем)
SIP/2.0 403 No Such User - нет такого пользователя, ошибка в номере, логине или пароле
SIP/2.0 403 User Disabled - пользователь отключен
SIP/2.0 403 Wrong Guess - ошибка в пароле
SIP/2.0 403 Conflict - такой SIP-номер уже используется
SIP/2.0 403 Forbidden - абонент не зарегистрирован
SIP/2.0 403 Empty Route Set - нет ни одного шлюза в роутинге
SIP/2.0 403 Caller Not Registered - нет такого пользователя
SIP/2.0 403 Out of Look-Ahead Retries - перебор узлов закончен
SIP/2.0 403 Invalid Phone Number - нет такого направления
SIP/2.0 403 No Money Left on RFC Account - на счету нет денег для совершения звонка
SIP/2.0 404 Not found - вызываемый абонент не найден, нет такого SIP-номера
SIP/2.0 404 Undefined Reason - неопределенное направление
SIP/2.0 404 Unknown user account - логин и пароль не найдены
SIP/2.0 404 Out of Order - в заявке на маршрутизацию по этому направлению нет ни одного шлюза, проверьте настройку маршрутизации по этому направлению.
SIP/2.0 405 Method Not Allowed - метод не поддерживается, может возникать если пользователь пытается отправлять голосовую почту и т.п.
SIP/2.0 406 No codecs match - неправильная конфигурация кодеков
SIP/2.0 406 Not Acceptable - пользователь не доступен
SIP/2.0 407 Proxy Authentication Required - необходима аутентификация на прокси-сервере
SIP/2.0 408 Request Timeout - время обработки запроса истекло: Абонента не удалось найти за отведенное время
SIP/2.0 408 Login timed out - за отведенное время не получен ответ от сервера на запрос авторизации
SIP/2.0 410 No Route - вариант SIP/2.0 403 Empty Route Set; нет доступа к ресурсу: Ресурс по указанному адресу больше не существует
SIP/2.0 413 Request Entity Too Large - размер запроса слишком велик для обработки на сервере
SIP/2.0 415 No Media - звонок совершается неподдерживаемым кодеком
SIP/2.0 416 Unsupported Scheme - сервер не может обработать запрос из-за того, что схема адреса получателя ему непонятна
SIP/2.0 420 Bad extension - неизвестное расширение: Сервер не понял расширение протокола SIP
SIP/2.0 421 Extension Required - в заголовке запроса не указано, какое расширение сервер должен применить для его обработки
SIP/2.0 423 Interval Too Brief - сервер отклоняет запрос, так как время действия ресурса короткое
SIP/2.0 480 Invalid Phone Number - неправильный номер телефона, не соответствует к-во цифр или неправильный код страны или города
SIP/2.0 480 Destination Not Found In Client Plan - направления нет в тарифном плане абонента
SIP/2.0 480 Wrong DB Response - проблемы с центральной базой сети
SIP/2.0 480 DB Timeout - проблемы с центральной базой сети
SIP/2.0 480 Database Error - проблемы с центральной базой сети
SIP/2.0 480 Codec Mismatch - несоответствие кодеков
SIP/2.0 480 No Money Left on RFC Account - нет денег на счету, обратитесь к администратору сети!!!
SIP/2.0 480 Empty Route Set - пустое направление, нет принемающих шлюзов
SIP/2.0 480 No money left - недостаточно денег на счете
SIP/2.0 480 Temporarily Unavailable - временно недоступное направление попробуйте позвонить позже
SIP/2.0 481 Call Leg/Transaction Does Not Exist - действие не выполнено, нормальный ответ при поступлении дублирующего пакета
SIP/2.0 482 Loop Detected - обнаружен замкнутый маршрут передачи запроса
SIP/2.0 483 Too Many Hops - запрос на своем пути прошел через большее число прокси-серверов, чем разрешено
SIP/2.0 484 Address Incomplete - принят запрос с неполным адресом
SIP/2.0 485 Ambiguous - адрес вызываемого пользователя не однозначен
SIP/2.0 486 Busy Here - абонент занят
SIP/2.0 487 Request Terminated - запрос отменен, обычно приходит при отмене вызова
SIP/2.0 488 Codec Mismatch - нет шлюзов с поддержкой заказанного кодека
SIP/2.0 488 Private IP Address - адрес RTP media из сетей RFC1918
SIP/2.0 491 Request Pending - запрос поступил в то время, когда сервер еще не закончил обработку другого запроса, относящегося к тому же диалогу
SIP/2.0 493 Undeciperable - сервер не в состоянии подобрать ключ дешифрования: невозможно декодировать тело S/MIME сообщения
SIP/2.0 499 Codec Mismatch - отсутствует кодек

Защита SIP-порта с помощью Mikrotik.

  Иногда нужно выбросить наружу SIP-порт для клиентов, которые подключаются к вашей IP-телефонии. Открытый SIP-порт, особенно стандартный (5060 UDP), очень уязвим и рано или поздно вас начнут взламывать, подбирать пароли и т.д. Это чревато не только возможностью угадать пароль, но и нагрузкой на ваш сервер телефонии и интернет-канал. Есть несколько рекомендаций для защиты.

  Общая рекомендация - не использовать стандартный порт. В дополнение, на стандарнтый порт можно повесить ловушку:

/ip firewall filter
add action=add-src-to-address-list address-list=sip_drop address-list-timeout=30m chain=input comment=sip_add_list dst-port=5060 in-interface=ether1-wan log=yes log-prefix=Sip-Attack protocol=udp
add action=drop chain=input comment=sip_list_drop in-interface=ether1-wan src-address-list=sip_drop

MikroTik News - January 2017 (Issue #75)

Юникод в SSID: Смайлики в названии сетей.

  На официальном форуме поднимался вопрос поддержки Mikrotik Unicode (UTF-8) в SSID для создания прикольных названий сетей (можно использовать спецсимволы, различные шрифты, смайлики и прочее в имени WIFI-сети). На форму обсуждалось то, что если ввести символы Юникода в следующем виде

ssid="\C4\9B\C5\A1\C4\8D\C5\99\C5\BE\C3\BD\C3\A1\C3\AD\C3\A9"

  Причем ОБЯЗАТЕЛЬНО через командную строку, то, несмотря на то, что в винбоксе отображаются крякозябры - в устройствах поддерживающих Unicode в названии сети он отображается корректно.
  Пользователь R1CH пошел дальше - создал специальный генератор, который преобразует символы Юникода уже в код добавления SSID на интерфейс RouterOS. Сам генератор доступен по адресу:

https://r-1.ch/mikrotik-unicode-ssid-generator.php

Подключение к веб-интерфейсу Mikrotik используя ssl протокол.

  Выставляя в "мир" нужные нам сервисы мы всегда рискуем. Поэтому желательно по-максимуму защитить наше оборудование. Удаленное подключение к нашим маршрутизаторам следует оставлять только с определенных подсетей, оставляя минимум сервисом, меняя стандартные логины и применяя сложные пароли с регулярной сменой. Так-же в обязательном порядке менять порты сервисов по-умолчанию. Можно организовать открытие портов через определенный порядок действий (например, технология port knocking).
  Незащищённое http-соединение опасно тем, что любой, кто слушает трафик, прекрасно видит все данные, которые вы передаете на сайт, по протоколам POST или GET. Так как мы не хотим, что-бы злоумышленники получили доступ к нашему роутеру - для этого нам необходим специальный сертификат. Как правило, сертификаты подтверждают центры сертификации. Но мы можем сгенерировать сертификат самостоятельно - такой сертификат называется самоподписанным, так как его подтверждаете лично вы. Для сайтов самоподписанный сертификат, конечно, не подойдет, но для личных целей вполне будет достаточно.
  Обращаю ваше внимание на то, что при использовании самоподписного сертификата вы будете видеть окно: "Сертификат безопасности сайта не является доверенным", что может быть не очень понятно неосведомленным пользователям.
 Сейчас я хочу описать как можно сгенерировать самоподписанный сертификат и включить безопасное соединение www-ssl для управления нашим роутером.
  Открываем System/Certificates, добавляем новый сертификат.

Защита Mikrotik. Часть 2: Мания преследования.

  В дополнение к основной статье Защита WAN-интерфейса в Mikrotik хочется отметить несколько важных моментов в безопасности вашего маршрутизатора. Описанные тут пункты не имеют критически важное значение в защите роутера Mikrotik, но, в комплексе, помогают защитить маршрутизатор еще лучше. Я специально буду продолжать пункты, описанные в предыдущем материале, что бы подчеркнуть - эта статья является продолжением и дополнением первой и отдельно рассматриваться не может.
  Не смотря на запрещающее правило в пункте 13 ("add action=drop chain=input comment=Drop_all_WAN in-interface=ether1-velton")  в конце первой статьи, рекомендую проверить активность сервисов. Если какой-то сервис не используется - в целях безопасности его отключить.

14) Проверяем сервис SNMP в IP/SNMP. По-умолчанию он выключен. Если мы его не используем - проследите что-бы не стояла галочка Enabled. Если используем - позаботитесь о его защите.