Fail2ban на MikroTik: как остановить перебор паролей на роутере

🔍 Что именно защищает Fail2ban на MikroTik

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

Fail2ban реагирует на ошибки входа. После заданного числа событий он добавляет адрес нарушителя в список блокировки. Межсетевой экран затем не пропускает трафик от этого адреса.

Важно правильно назвать технологию. Fail2ban — сервис Linux. Его нельзя установить на MikroTik как обычный пакет. На RouterOS работает похожая схема на базе журналов, триггеров, скрипта и address-list.

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

Сделайте прямо сейчас простую проверку: определите, откуда разрешён вход на роутер. Если управление доступно из всех сетей, сначала исправьте firewall.

🛡️ Почему одной блокировки недостаточно

Fail2ban не заменяет базовые настройки безопасности. Он реагирует на уже начавшиеся попытки входа. Открытая служба управления всё равно остаётся видимой для атакующих.

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

Отдельно проверьте SSH, Winbox, WebFig и API. Защита только SSH не закрывает перебор через другие интерфейсы. Веб-интерфейс и Winbox также требуют ограничения.

IPv6 проверяйте отдельно. Правила IPv4 не защищают IPv6 автоматически. В описанной схеме для IPv6 используется отдельный address-list и отдельное правило межсетевого экрана.

• Отключите неиспользуемые службы управления.
• Не оставляйте Winbox и WebFig открытыми для внешних сетей.
• Ограничьте API теми адресами, которым он действительно нужен.
• Проверьте правила IPv6 firewall.
• Сохраните рабочий аварийный доступ до изменения конфигурации.

Перенос SSH на нестандартный порт может уменьшить шум автоматического сканирования. Это только вторичная мера. Она не заменяет фильтрацию источников и сильную аутентификацию.

Используйте уникальные пароли. Удаляйте или блокируйте ненужные стандартные учётные записи. Где это поддерживается, применяйте ключевую аутентификацию.

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

⚙️ Вариант RouterOS без внешнего сервера

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

Скрипт ищет адрес в тексте системного сообщения. В сообщении он ориентируется на фрагмент from и извлекает адрес до фрагмента via. После этого он проверяет тип адреса.

Для IPv4 скрипт добавляет адрес в обычный firewall address-list. Для IPv6 он использует отдельный список в IPv6 firewall. Это важное различие нельзя скрывать одной настройкой.

В примере используется список с именем BlackList1. Время блокировки задаётся переменной BanTime и равно одному дню. Названия списка и срок можно изменить под рабочую политику.

Скрипт также пишет предупреждение в журнал. При успешном добавлении появляется сообщение с адресом и названием списка. Если адрес уже есть, журнал сообщает о существующей записи.

При отсутствии распознанного адреса скрипт пишет отдельное предупреждение. Это помогает заметить изменение формата сообщения или ошибку в разборе строки.

Перед внедрением сохраните текущую конфигурацию. Затем добавляйте скрипт и правила по одному. После каждого шага проверяйте журнал.

Сделайте сейчас резервную копию конфигурации. Не применяйте блокировку без заранее подготовленного локального или безопасного аварийного доступа.

📋 Как связать журнал и скрипт

Сначала скрипт помещают в системную библиотеку скриптов RouterOS. В примере ему присваивается имя loginfail2ban. Это имя затем указывается в действии журналирования.

Далее создаётся действие с целью script. Оно вызывает скрипт loginfail2ban. Само действие не ищет пароль и не блокирует адрес. Оно только передаёт системное сообщение скрипту.

Затем добавляется правило журналирования. Оно использует регулярное выражение ^login failure. Правило срабатывает для сообщений с темами system, error и critical.

Такой порядок важен. Сначала появляется обработчик события. Потом RouterOS получает триггер. Если поменять порядок без проверки, журнал может фиксировать ошибки, но блокировка не запустится.

1. Создайте резервную копию конфигурации.
2. Добавьте скрипт в системную библиотеку.
3. Создайте действие журналирования с целью script.
4. Добавьте правило с регулярным выражением для ошибки входа.
5. Проверьте появление записи в address-list.

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

Не копируйте правило без проверки журнала. Сначала найдите точную строку ошибки. Затем сопоставьте её с выражением в триггере.

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

🎯 Как работает динамический address-list

Address-list хранит адреса, к которым применяются правила firewall. Динамическая запись существует ограниченное время. В описанной реализации срок блокировки задаёт переменная BanTime.

Список BlackList1 получает адрес после события неудачного входа. Затем правило firewall использует этот список как условие. Трафик от адресов из списка блокируется выбранным действием.

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

Ошибочные блокировки особенно опасны для общей сети. Один адрес может принадлежать нескольким пользователям. Это бывает при общем выходе в интернет или использовании общего шлюза.

\div>

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

• Задайте отдельный список для IPv4.
• Используйте отдельный список для IPv6.
• Разместите правило блокировки до разрешающих правил.
• Исключите доверенные адреса из автоматической блокировки.
• Контролируйте срок жизни динамических записей.

Списки не должны заменять белый список управления. Сначала разрешите доступ из management. Затем блокируйте подозрительные адреса внутри этой зоны.

Сделайте сейчас просмотр текущих address-list. Найдите динамические записи и убедитесь, что они не перекрывают доступ администратора.

🧰 Внешний Linux-сервер и классический Fail2ban

Классическая схема использует отдельный Linux-сервер. Он принимает журналы MikroTik по syslog, анализирует ошибки входа и формирует список нарушителей.

После анализа сервер передаёт адреса обратно на роутер. Для этого применяют API или SSH. На MikroTik адрес попадает в firewall address-list.

Такая архитектура отличается от локального варианта. На роутере не запускается Fail2ban. RouterOS только отправляет события и применяет полученную блокировку.

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

Канал передачи журналов тоже нужно контролировать. Ограничьте источники syslog. Не принимайте сообщения от неизвестных адресов.

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

Проверьте обратную связь. Адрес должен появляться в списке на MikroTik. Одной записи на Linux-сервере недостаточно.

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

🚧 Ограничения метода и риск ложных блокировок

Ограничение числа соединений не равно защите от перебора паролей. Один нарушитель может использовать небольшое число соединений. Перебор при этом всё равно продолжится.

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

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

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

Автоматическая блокировка может затронуть администратора за общим NAT-адресом. Она также может закрыть критичный доступ при неверном правиле. Поэтому оставляйте аварийный канал.

Обязательно проверяйте действие после изменения. Убедитесь, что разрешённый адрес входит. Затем проверьте, что адрес из списка действительно блокируется.

• Проверьте разрешённый адрес.
• Проверьте адрес из BlackList1.
• Проверьте повторную ошибку по уже заблокированному адресу.
• Проверьте истечение срока динамической записи.
• Проверьте доступ через локальную консоль.

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

🔐 Отдельная защита служб управления

SSH, Winbox, WebFig и API имеют разные сценарии доступа. Общее правило для них одно: управление не должно быть открыто всем сетям.

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

Winbox требует отдельного контроля. Для него можно отслеживать ошибки входа и добавлять адрес в список блокировки. Но доступ к порту всё равно ограничивает firewall.

WebFig также нельзя оставлять доступным без необходимости. Если интерфейс нужен, разрешите его только из management-сегмента. Не считайте защиту Winbox защитой веб-интерфейса.

API открывайте только для конкретных систем автоматизации. Проверьте, какие адреса обращаются к API. Уберите доступ со всех остальных интерфейсов.

IPv6 настраивайте отдельно. Для него применяются отдельные команды и отдельный address-list. Ошибка здесь оставляет альтернативный путь к управлению.

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

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

✅ План проверки после настройки

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

Сначала выполните неудачный вход из разрешённого источника. Найдите в журнале событие с ошибкой. Убедитесь, что действие вызывает скрипт.

Затем проверьте address-list. Для IPv4 адрес должен попасть в список IPv4. Для IPv6 проверьте отдельный список IPv6.

После этого проверьте firewall. Адрес из списка должен получать блокировку. Разрешённый адрес должен продолжать входить.

Проверьте Winbox и WebFig отдельно. Ошибка в одном интерфейсе не доказывает работу защиты другого. Повторите тест для SSH и API.

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

1. Сделайте резервную копию.
2. Проверьте журнал неудачного входа.
3. Проверьте запуск скрипта.
4. Проверьте запись в address-list.
5. Проверьте блокировку firewall.
6. Проверьте вход с доверенного адреса.
7. Проверьте IPv6 и все службы управления.
8. Проверьте аварийный доступ.

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

Сделайте сейчас контрольный тест с разрешённого адреса. Если доступ пропал, немедленно используйте аварийный канал и откатите последнее изменение.

📈 Как поддерживать защиту в рабочем состоянии

Защита деградирует, если о ней забывают. Со временем меняются адреса управления, учётные записи и правила firewall. Документация быстро перестаёт соответствовать реальной конфигурации.

Регулярно просматривайте успешные и неудачные входы. Сопоставляйте события с действиями администраторов. Неудобные или неизвестные события требуют проверки.

Контролируйте состояние скрипта и журналирования. Проверяйте, что action всё ещё вызывает правильное имя. Убедитесь, что регулярное выражение совпадает с текущим сообщением RouterOS.

Следите за address-list. Проверяйте старые записи, доверенные адреса и срок блокировки. Удаляйте ошибочные правила после анализа причины.

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

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

Практический шаг: назначьте периодическую проверку журналов и address-list. После каждого изменения RouterOS или firewall повторяйте полный план тестирования.

📚 Читайте также

• Скрытые сервисы в инфраструктуре: как найти активы и оценить риск
• Видеосервис на VPS: как изолировать домашнюю сеть и скрыть IP
• Секреты перед push: как защитить ключи и подписи в Git
• Rootless-контейнеры под прицелом: что выдаёт SSH-доступ
• Secure Debug под лазером: разбор физической атаки на RP2350

📖 Термины

API · IPv6 · SSH · Автоматизированное сканирование

🔗 Источники

• Настраиваем защиту от атак BruteForce на роутерах Mikrotik(2026-10-11 ✓)
• Почему средства защиты информации после внедрения перестают работать. Часть 1. Приемка и ввод в эксплуатацию(2026-10-11 ✓)
• Реализация fail2ban на MikroTik RouterOS(2026-10-11 ✓)