Mikrotik firewall default configuration

Правила настройки Firewall в роутере MikroTik

Практический пример. Mikrotik hap Lite имеет активные службы: NAT(scrnat и dstnat), DHCP, WiFi, Firewall и VPN туннель типа Ipsec с аналогичной моделью. Правила Firewall-а были приняты в работу после инцидентов со 100% загрузкой CPU(роутер тормозит и зависает). Счетчики пакетов после 11 дней работы выглядят следующим образом:

Защита от атак типа Brute Force (метод перебора)

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

add chain=input protocol=tcp dst-port=22 src-address-list=ssh_blacklist action=drop comment=»Drop SSH brutforce» disabled=no

add chain=input protocol=tcp dst-port=22 connection-state=new action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m comment=»Stage1″ disabled=no

Вторую попытку нужно фиксировать в списке ssh_stage2, это гарантированно дает понять системе, что речь идет именно о дубле:

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage1 action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m comment=»Stage2″ disabled=no

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage2 action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=1m comment=»» disabled=no

Если на третьей попытке опять зафиксирована ошибка доступа, адрес переносится в ssh_blacklist, чтобы обеспечить гарантированную блокировку на 10 дней.

add chain=input protocol=tcp dst-port=22 connection-state=new src-address-list=ssh_stage3 action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=10d comment=»» disabled=no

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

Базовая настройка NAT

Mikrotik есть – это Port Forwarding, или «проброс портов». Эта методика позволяет обеспечить перенаправление внешнего запроса на нужное рабочее место. На уровне логики работа выглядит так: если порт XXXX получает TCP-запрос, маршрутизатор должен задать адрес 192.168.XXX.XXX на порт YYYY, куда требуется перенаправить его. Существует 2 способа настройки NAT на Mikrotik

ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade

ip firewall nat add chain=srcnat out-interface=ether1 action=src-nat to-addresses=XXX.XXX.XXX.XXX

ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=1122 action=dst-nat to-addresses=192.168.88.10 to-ports=22

Сразу уточним, что порт 1122 выбран специально. Нестандартные цифры сложнее атаковать извне, потому что боты чаще организуют их на стандартные порты. После применения указанных настроек маршрутизатор будет направлять TCP-пакеты, поступающие на порт 1122, на «местный» адрес 192.168.88.10 (через порт 22).

Настройка MikroTik Firewall

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

ВНИМАНИЕ! Неверное пользование инструкцией может произвести к потере связи с роутером MikroTik!

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

Будет описана ситуация, когда любой пакет не получивший предварительного разрешения будет отвергнут. Эта конфигурация также положительно отражается на состоянии загрузки CPU.

Правила работают сверху вниз, приоритетным считается правило c меньшим номером.

Разрешение установленных и связанных подключений для входящего и проходящего трафика

/ip firewall filter add action=accept chain=forward connection-state=established,related

/ip firewall filter add action=accept chain=in connection-state=established,related

Доверительные правила для локальной сети

/ip firewall filter
add action=accept chain=input in-interface=bridge1
add action=accept chain=forward in-interface=bridge1

Разрешить ICMP запросы с WAN интерфейсов

/ip firewall filter add action=accept chain=in protocol=icmp in-interface=pppoe-out1

Удалить все пакеты в состоянии invalid

/ip firewall filter add action=drop chain=forward connection-state=invalid

/ip firewall filter add action=drop chain=input connection-state=invalid

Удалить все остальные пакеты

Лженастройки

Эту категорию лженастроек я характеризую так: «Эта статья в Интернет выглядит умной. Я тоже хочу внедрить у себя такое». Администраторы берут какие-то настройки и абсолютно не понимая, что это, зачем это и с чем это едят копируют настройки к себе. Чаще всего встречаются следующие чудо-настройки.

Эта настройка находится в топе по популярности среди всевозможных лженастроек файервола. Выглядит она следующим образом: вначале делается список адресов с названием «BOGON» и после этого в файерволе этот самый «BOGON» запрещают для входящего интерфейса.

Через консоль это выглядит примерно так:

/ip firewall address list
add address=0.0.0.0/8 list=BOGON
add address=10.0.0.0/8 list=BOGON
add address=100.64.0.0/10 list=BOGON
add address=127.0.0.0/8 list=BOGON
add address=169.254.0.0/16 list=BOGON
add address=172.16.0.0/12 list=BOGON
add address=192.0.0.0/12 list=BOGON
add address=192.0.2.0/24 list=BOGON
add address=192.168.0.0/16 list=BOGON
add address=198.18.0.0/15 list=BOGON
add address=198.51.100.0/24 list=BOGON
add address=203.0.113.0/24 list=BOGON
add address=217.67.177.164 list=BOGON
add address=224.0.0.0/3 list=BOGON

/ip firewall filter
add action=drop chain=input in-interface=WAN src-address-list=BOGON

Здесь я люблю задавать вопрос. Почему Вы решили заблокировать сеть 192.0.2.0/24, но при этом не стали блокировать 192.0..0/24 или 192.0..0/24 или 192.0..0/24? На этот вопрос обычно не могут ответить. Более знающие ссылаются на rfc1166 в котором говорится, что сеть 192.0.2.0/24 зарезервирована для «TEST-NET-1», которая может быть использована в документации или в примерах. На встречный вопрос: «Чем не устраивает нормально закрытый файервол?» как правило ответить уже не могут, т. к. нормальной закрытый файрвол скорее всего уже используется и с этим вопросом приходит понимание, что такое правило это «масло маслянное».

Идем дальше. Допустим, каким-то образом мы получили динамические «BOGON» и «FULLBOGON» списки, которые всегда будут находиться в актуальном состоянии. Может быть тогда блокирование этих самых БОГОНОВ будет иметь смысл? Возможно тогда и будет иметь, но куда проще настроить файервол правильно так, чтобы не требовалось создавать дополнительные правила. Для этого нам достаточно настроить файервол в нормально закрытом режиме и заблокировать invalid-трафик.

Правило, блокирующее invalid-трафик обязательно должно идти вторым сразу за правилом, которое разрешает established и related трафик. Если сделать, например, так:

/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=accept chain=input protocol=icmp
add action=drop chain=input connection-state=invalid

то мы рискуем получить уязвимость в виде возможности посылать на нас нелегитимный ICMP-трафик. И произойдет это следующим образом:

• Первый вредоносный пакет у которого в качестве источника будет указан адрес из любой сети, в т. ч. и из BOGON, будет обработан на втором правиле, которое разрешает ICMP-трафик. Простым языком: кто-то будет слать якобы ответ на ping-запросы, которые на самом деле не отправлялись.
• Все дальнейшие пакеты будут обработаны самым первым правилом, которое разрешает established & related трафик.
• До правила блокирующего invalid трафик дело уже не дойдет. А именно оно должно было бы остановить атаку не зависимо от того откуда идет атака из BOGON сети или из какой-то другой.

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

Блокировка TCP-соединений по флагам

Эта лженастройка имеет много разных вариаций. В общих чертах она выглядит как попытка заблокировать что-то на основании флага TCP-соединения с помощью опции «tcp-flag». У этой лженастройки файрвола на MikroTik много разных вариаций. Обычно их объединяет то, что есть несколько правил в которых обязательно будет встречаться что-то на подобие:

Полезные материалы по MikroTik

На Telegram-канале Mikrotik сэнсей можно получить доступ к закрытой информации от официального тренера MikroTik. В апреле и мае 2023 будут разбираться темы Wi-Fi и QoS. Подписывайтесь

Базовая настройка защиты роутера MikroTik

В качестве примера будет взят маршрутизатор(роутер) MikroTik hAP ac2 как самое популярное решения для дома и офиса 2019-2020гг.

Обновление прошивки до актуальной версии

Одной из важной задачей при вводе в эксплуатацию нового устройства MikroTik: маршрутизатора(роутера), коммутатора(свчитча) или точки доступа WiFi это обновление прошивки. Чаще всего это имело рекомендованный характер, но недавний инцидент с «back door» в категории long-term указал но то, что актуальность прошивки на устройствах MikroTik имеет критический характер.

Действия в кнопке Download&Install произведут закачку выбранной редакции прошивки и автоматическую перезагрузку устройства. Установка будет произведена в момент загрузки. Не выключайте устройство до полной перезагрузки и обеспечьте стабильное питание электросети при обновлении прошивки.

Редакции прошивок MikroTik

• long term(bug fix only) — самая стабильная версия. Рекомендовано для производственных сред!
• stable(current) — long term плюс поддержка новых функций. Новые технологии это всегда хорошо.

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

Важным дополнением в обновлении прошивки является обновление Current Firmware — это аппаратная прошивка, аналог BIOS в компьютере.

Создание новой учётной записи администратора

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

добавление нового пользователя с полными правами:

деактивация старого пользователя:

Добавление Address List

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface list member
add interface=Bridge-LAN list=LAN
add interface=ether1 list=WAN

Пример базовых правил MikroTik Firewall(Default Rules)

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

/ip firewall filter
add action=accept chain=input comment=»defconf: accept established,related,untracked» connection-state=established,related,untracked
add action=drop chain=input comment=»defconf: drop invalid» connection-state=invalid
add action=accept chain=input comment=»defconf: accept ICMP» protocol=icmp
add action=drop chain=input comment=»defconf: drop all not coming from LAN» in-interface-list=!LAN
add action=accept chain=forward comment=»defconf: accept in ipsec policy» ipsec-policy=in,ipsec
add action=accept chain=forward comment=»defconf: accept out ipsec policy» ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=»defconf: fasttrack» connection-state=established,related
add action=accept chain=forward comment=»defconf: accept established,related, untracked» connection-state=established,related,untracked
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-list=WAN

Деактивация неиспользуемых служб

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes

Ограничение по автообнаружению(Discovery) Neighbors

Если не обратить внимание на эту опцию, то маршрутизатор(роутер) MikroTik будет отображаться как Neighbor на порту провайдера. Используя утилиту Winbox злоумышленник может выявить все устройства MikroTik и подвергнуть их взлому или атаке.

/ip neighbor discovery-settings
set discover-interface-list=LAN

Отключение функций MAC Server

Настройка содержит три опции:

MAC Telnet Server

Рекомендуется активировать только для списка LAN.

MAC WinBox Server

MAC Ping Server

/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool mac-server ping
set enabled=no

Теперь перейдем к практике

Консольный интерфейс преимущественно используют для конфигурирования маршрутизатора и его управления, в том числе для передачи данных по протоколам Telnet и SSH. В нашем случае перед настройками рекомендуется посмотреть действующие правила. Это можно сделать командой:

Flags: X — disabled, I — invalid, D – dynamic

Следующий шаг – переход в раздел настройки фильтрации, для этого есть команда:

Теперь активируем парочку правил:

add action=accept chain=input comment=»default configuration» connection-state=established,related

Рассмотрим составляющие последней команды:

• add action=accept – ставится задача принять пакеты;
• chain=input – будет применяться набор правил, соответствующий входящему трафику Input;
• сomment=«default configuration» – поле для любых комментариев от пользователя, в этом случае внесена информация о том, что конфигурация будет применяться «по умолчанию»;
• connection-state=established,related – устанавливаем полный список статусов, которые будут учитываться при приеме соединений.

Несмотря на довольно длинную строку, приведенный пример команды довольно прост по значению. Ее назначение укладывается во фразу: «Принимать входящие пакеты с подтвержденным статусом Established и Related». Все остальные блоки данных будут отклонены автоматически, пока владелец не изменит настройки фильтров. Теперь рассмотрим следующее правило, рекомендуемое при настройке Mikrotik RouterBoard

Внесите в окне консоли команду:

add action=accept chain=input src-address-list=allowed_to_router

Подобный подход оправдан – операционная система работает только с теми пакетами, которые при настройке были разрешены для приема-отправки. Это снижает нагрузку на аппаратную платформу и риски перегрузки системы за счет отказа от обработки «никому не нужной» информации. Если нет входящих соединений с нужными характеристиками, линия вообще будет свободной. Настройка RouterOS позволяет запретить даже ответ на команду PING.

Команда включения ответа на запрос PING:

Если все-таки понадобится заблокировать режим, значение action нужно заменить на drop. Тогда маршрутизатор прекратит принимать извне и обрабатывать ICMP-пакеты. Выглядеть команда будет следующим образом:

add action=drop chain=input protocol=icmp

Рекомендуется еще отсечь пакеты, оставшиеся после ранее внесенных фильтров. Этодропнуть данные. Процедуру нужно назначать на самый «хвост» правил в цепочке Input, чтобы она не повлияла на разрешительные команды. Выглядит это так:

Теперь рассмотрим подробнее, какие у нас получилось сформировать правила приема и обработки пакетов информации. Если собрать все приведенные примеры команд в единый пакет, они будут выглядеть так:

На «человеческом языке» работа маршрутизатора будет организована следующим образом:

• Извне на сетевое устройство приходит ICMP-пакет. Прибор сначала определяет, было ли соединение активно (пусть это будет правилом 0). Если хост пингуют в первый раз, то его статус будет New. Правило не применится, потому что текущее состояние не соответствует ни Established, ни Related.
• Теперь о правиле 2. Если системный администратор принудительно включил реагирование на PING, маршрутизатор получит сигнал Accept (принять и обработать ICMP-пакет согласно протоколу). После обработки запроса сетевое оборудование отправляет эхо-ответ. На этом процедура реагирования завершается.

Приведем в пример еще один способ обслуживания. Например, когда на сетевое оборудование был отправлен UDP-пакет с неизвестного источника. В таком случае маршрутизатор отреагирует на обращение так:

• Правило 0. Статус коннекта не соответствует Established и Related, поэтому оно работать не будет.
• Правило 1. Перечень IP allowed_to_router еще не заполняли, поэтому оно тоже не сработает из-за невозможности идентификации обратившегося IP.
• Правило 2. Как и предыдущие, оно не применяется, потому что формат не соответствует ICMP.

Все, система подошла к краю цепочки Input. Здесь пакет «поджидает» правило, предназначенное для того, чтобы дропать данные, не соответствующие установленным правилам. В нашем примере из-за отсутствия возможностей для срабатывания правила chain=input action=drop оно работает всегда. И это приводит к отказу приема UDP-пакета независимо от отправителя. Мы разобрали, чтозначит дропнуть

Теперь добавим указанный диапазон:

add address=192.168.88.0-192.168.88.254 list=allowed_to_router

Команда передает маршрутизатору задание на добавление адресов указанного диапазона в список с наименованием allowed_to_router. Это применимо, если перечня не существует, как рассматривается в нашем примере. После ввода команды операционная система его создаст. Но нужно проверить это командой:

Если все нормально, при обработке цепочки Input на этапе отработки правила 1 система уже начнет отрабатывать входящие пакеты. При идентификации адреса отправителя как входящего в «список доверия» правило применится, и пакеты будут передаваться дальше к заданному адресату.

Ошибки

Очень часто неопытные инженеры используют нормально открытый файервол. Например, для цепочки Input правила могут выглядеть так:

В приведенном выше примере для цепочки Input используется нормально открытый файервол и блокируется то, что по мнению администратора представляет риск. Действительно держать 53-ий порт (DNS) открытым для Интернета это очень большой риск попасть на атаку типа «DNS Resolve» и получить загрузку процессора службой DNS под 100%.
Проблема в том, что при использовании нормально открытого файервола администратор устанет запрещать. Даже, если предположить, что администратор на 100% знает все, что надо запретить, то такую схему лучше не использовать потому, что значительно увеличится количество правил, через которые будет проходит пакет. А чем большее количество правил будет пройдено пакетом, тем выше будет нагрузка на процессор устройства.

Сделать файервол нормально закрытым. Т. в нем должно быть запрещено все кроме того, что разрешено и будет небольшой «белый» список доступных сервисов. Например, так:

/ip firewall filter
add action=accept chain=input connection-state=established,related #правило №1 в цепочке input
add action=drop chain=input connection-state=invalid #правило №2 в цепочке input
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=8291 protocol=tcp
add action=accept chain=input port=500,1701,4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=drop chain=input in-interface=WAN #последнее правило в цепочке input

Правила комментариями, которые выделены , должны идти именно в этом порядке.

• Первое правило снижает нагрузку на процессор, т. к. 99% трафика будет проходить через него.
• Второе правило блокирует invalid трафик. Что будет если его поместить хотя бы на одну позицию ниже описано в этой статье выше.
• Последнее правило блокирует все, что явным образом не разрешено правилами, расположенными между вторым и последним правилом.

Неверный порядок правил

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

Пример №1
Пример ситуации, когда блокирующее правило не сработает:

В этой ситуации правило, которое блокирует SSH-трафик (22-ой порт TCP) не сработает потому, что выше есть правило, которое разрешает любой TCP-трафик.

Пример №2
Еще один пример ситуации, когда блокирующее правило не сработает:

Если рассматривать эту конфигурацию в отрыве от остальных настроек, то кажется, что трафик из «Guest» в «LAN» должен быть заблокирован, но если посмотреть конфигурацию целиком, то можно обнаружить, что сеть 192.168.15.0/24 принадлежит интерфейсу LAN:

/ip address
add address=192.168.15.254/24 interface=LAN network=192.168.15.0

Таким образом мы получаем, что у нас есть разрешающее правило выше запрещающего.

Пример №3
Пример ситуации, когда разрешающее правило не сработает потому, что выше есть запрещающее правило.

В этом примере есть правило, которое разрешает TCP-трафик с портом назначения 80 и 443. Если рассматривать правило отдельно от остальных, то можно предположить, что из DMZ можно будет попасть в LAN с таким видом трафика. Но по факту это сделать не получится, т. к. выше есть запрещающее правило, которое блокирует любой трафик из DMZ в LAN.

Некорректное использование FastTrack

Многие читали про то, что с помощью FastTrack можно в разы увеличить производительность маршрутизатора. Как правило эту возможность используют в таком виде:

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related

Но при этом зачастую не учитывают, что при использовании этой возможность игнорируется огромный объем настроек. Какой именно можно оценить посмотрев на то, как проходит FastTrack по схеме прохождения трафика:

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

FastTrack можно и нужно использовать, но не для всего подряд, а точечно выделяя какой-то конкретный вид трафика и пропуская этот выделенный трафик через FastTrack.

Базовая настройка и проброс портов

Решением проблемы является так называемый проброс портов (Port Forwarding). Создавая правило проброса портов мы даем маршрутизатору указания какому устройству перенаправить запрос извне. На логическом уровне подобный запрос может выглядеть как «‎Если на порт XXX придет TCP-запрос, то перенаправь его на локальный адрес 192.168.XXX.XXX на порт YYY»‎. Давайте посмотрим 2 способа как нам настроить NAT на Mikrotik.

где ether1 — интерфейс, смотрящий в интернет. Также можно задать не один выходной интерфейс, а сразу несколько, заранее сформировав список out-interface-list.

Теперь еще один вариант организации NAT. Рассмотрим пример:

Теперь переходим к пробросу портов. Для примера предположим, что у нас в локальной сети 192.168.88.0/24 есть небольшой сервер по адресу 192.168.88.10 с поднятым SSH. Нам нужно подключаться к серверу удаленно, используя номер порта 1122. Для этого выполним проброс портов, созданием правила:

Почему мы взяли такой странный номер порта 1122? Все просто — чтобы затруднить злоумышленникам нахождение номера порта и последующего перебора реквизитов. Таким образом, мы создали правило, однозначно позволяющее маршрутизатору понять, что все TCP-пакеты, пришедшие на порт 1122 следует переадресовывать на локальный адрес 192.168.88.10 на порт 22.

Как защитить MikroTik от DDOS атаки

В первой части статьи, описанные правила Firewall имеют определенно строгий вид и если их описать словами то:

Разрешены(Accept)

• все установленные ранее подключения(было разрешено ранее, значит и сейчас будет разрешено);
• запросы с локальной сети, полное доверие;
• запросы на команду PING с внешней сети, имеет диагностический характер.

Запрещены(Drop)

• пакеты в состоянии invalid;
• все другие пакеты, которые не подошли ни к одному из правил выше.

Как правило DDOS атаки совершаются через ICMP запросы и этой единственный возможный запрос, на который ответит роутер MikroTik по цепочке Input. Все остальные пакеты он будет напросто отклонять.

В качестве метода по борьбе с DDoS атакой будет рассмотрен сценарий, в котором будет применяться фильтр на количество новых подключений в цепочках Input и Forward.

/ip firewall filter
add action=jump chain=forward connection-state=new in-interface=pppoe-out jump-target=Pre-DDoS
add action=jump chain=input connection-state=new in-interface=pppoe-out jump-target=Pre-DDoS
add action=drop chain=forward connection-state=new src-address-list=BAN-DDoS
add action=drop chain=input connection-state=new src-address-list=BAN-DDoS
add action=return chain=Pre-DDoS dst-limit=32,32,src-address/10s
add action=add-src-to-address-list address-list=BAN-DDoS address-list-timeout=14d chain=Pre-DDoS

Теория настройки файрвола

Сразу уточним, что в здесь мы рассмотрим настройку облачного варианта RouterOS CHR при помощи командной строки (CLI). При работе с WinBox и WebFig алгоритм будет таким же.

Итак, начнем рассмотрение базовых понятий по настройке Mikrotik. Одно из основных здесь – «цепочка». На новых устройствах установлено 3 единицы, но пользователю доступны функции создания собственных.

• INPUT – входящий трафик, поступающий на устройство через Mikrotik Firewall
• OUTPUT – исходящий трафик, передаваемый внешним клиентам из памяти оборудования.
• FORWARD – сквозной трафик, который передается от клиента клиенту, но через Mikrotik

Файрвол – это решение для фильтрации пакетов данных по определенным правилам. Первый вид цепочки предназначен для обработки поступающей информации, например, из интернета, страниц сайтов, которые открывает пользователь, из облачных хранилищ, откуда тот скачивает файлы. Все, что передается обратно, будет обработано по правилам, заданным цепочкой Output (это позволяет применить разные настройки на оба вида трафика).

На случай, когда маршрутизатор Mikrotik выполняет роль промежуточного узла между отдельными сегментами сети, используют условия Forward. Термин «цепочка» принят не просто так. Firewall – это система, последовательно применяющая заданные правила и постепенно отсеивающая данные, что не соответствуют условиям. Такой подход снижает нагрузку на аппаратную платформу сетевого оборудования, исключают зависание пакетов при «одновременном обращении».

настройке Микротика также придется столкнуться со статусами соединения. Каждое из них можно разделить на 4 условные категории:

• New – это только что созданное соединение, исходящее, входящее или сквозное.
• Established – коннект установлен, оборудование готово к передаче пакетов информации.
• Related – обращение осуществляется к одному из ранее созданных соединений, когда нужно изменить его назначение в служебных целях.
• Invalid – ошибочное обращение, когда маршрутизатор «не может понять» формат или иные критерии входящего соединения.

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

И сразу к практике

Открываем консольный интерфейс и посмотрим на существующие правила:

Пока что правил нет, отображается только «‎легенда»‎ про флаги. Переходим в раздел настройки фильтров:

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

Теперь создадим несколько правил и расскажем для чего они нужны:

Эту команду можно читать прямо дословно. Разберем прямо по пунктам:

• add action=accept — принимать пакеты.
• chain=input — правило будет работать в цепочке входящего трафика.
• connection-state=established,related — указываем какие статусы соединения будем принимать.

Таким образом эта длинная команда всего лишь превращается во вполне логичную фразу «‎Принимать извне все пакеты со статусом соединения Established и Related»‎. Это правило позволяет четко указать маршрутизатору что если из внешней сети прилетают соединения с указанными статусами, то их следует принять.

Теперь переходим к следующему правилу, рекомендуемому Mikrotik:

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

Тут все просто — эта команда разрешает принимать извне и обрабатывать ICMP-пакеты. И завершающая команда:

Этим в финале цепочки INPUT мы будем отбрасывать (дропать) все оставшиеся пакеты, не подпадающие под правила выше. Посмотрим как у нас сформировались правила:

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

• Прилетел снаружи ICMP-пакет. Машрутизатор смотрит в правило номер 0 — есть ли уже установившееся соединение. Если нас пингуют впервые, то статус соединение будет New, а не Established или Related. Так что правило не срабатывает.
• Наконец доходим до правила 2, которое однозначно говорит маршрутизатору, что следует принять (Accept) и обработать по протоколу ICMP данный пакет. Маршрутизатор отвечает на ICMP-пакет соответствующим эхо-ответом. До четвертого правила пакет уже не добирается, т.к. процедура обработки фактически завершена.

Рассмотрим еще один случай. На этот раз к нам на маршрутизатор извне прилетел некий неизвестный UDP-пакет с данными. Как будет действовать маршрутизатор:

• Смотрим правило 0. Существующего Established или Related соединения у нас нет, поэтому правило не срабатывает.
• Правило 1 — смотрим в список разрешенных адресов allowed_to_router, но там пусто. Еще одно правило не сработало.
• Дошли до правила 2 — является ли пришедший пакет ICMP-пакетом. Нет, не является, так что правило не срабатывает.
• И вот мы дошли до конца цепочки INPUT, где нас поджидает «‎правило-вышибала”. Поскольку у правила chain=input action=drop нет условий для срабатывания, то оно по умолчанию срабатывает всегда и наш неизвестный UDP-пакет дропается и перестает существовать.

Надеемся, что столь подробный разбор логики немного прояснил как именно работает файервол в Mikrotik RouterOS, поэтому приступим к дальнейшей настройке. Сформируем список разрешенных адресов. Для этого вернемся в главное меню, нажав символ / и подтвердив нажатием клавиши Enter. Теперь перейдем в раздел консольного интерфейса Mikrotik – ip firewall и посмотрим какие адресные списки у нас существуют:

Как видим, список пока пустой. Добавим туда адреса из стандартной локальной подсети 192.168.88.0/24 за исключением 192.168.88.1 (адрес маршрутизатора). Эта подсеть обычно используется по умолчанию на устройствах Mikrotik и именно ее чаще всего используют для раздачи адресов в локальной сети. Выполним добавление:

add address=192.168.88.2-192.168.88.254 list=allowed_to_router

Команда максимально проста для понимания мы говорим, что нам нужно добавить адреса 192.168.88.2-192.168.88.254 в список с именем allowed_to_router. Подразумевается то, что если списка с таким именем не существует, то при выполнении команды он будет создан. Проверим:

Защита от атак перебором

Брутфорс-атаки давно стали повседневностью. Десятки тысяч ботов регулярно сканируют весь интернет в поисках открытых портов SSH и затем начинают весьма активно «‎стучаться»‎ на внешний интерфейс и перебирать пароли в попытке захватить контроль над подключенным устройством. У тех, кто контролирует эти сети есть весьма обширные словари паролей, использующие как дефолтные реквизиты доступа большинства устройств.

Но даже если вы задали сложный пароль — это еще не гарантирует безопасности. Длительная атака перебором способна сломать этот барьер защиты, поэтому проще всего пресекать попытки злоумышленников сразу, как только замечен процесс перебора. Настройка правил firewall у устройств Mikrotik достаточно тривиальна:

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

Третья ошибочная попытка приводит к копированию IP из списка ssh_stage3 в список ssh_blacklist и все входящие соединения с этого IP будут заблокированы сроком на 10 дней.

Для разблокировки адреса будет достаточно его удалить из черного списка.

Стандартные настройки для разных случаев

Материал из MikroTik Wiki

В статье рассматриваются настройки файрвола на операционной системе MikroTik RouterOS. Разбираются самые распространенные ситуации.

Нет подключения к MikroTik, роутер не отвечает

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

Через графический интерфейс

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

• Цепочка (Chain:)
• Протокол (Protocol:)
• Порт (Dst. Port:)

Цепочку, порт и протокол можно посмотреть в настройках через консоль.

Через консоль

Разрешить весь VPN-трафик через VPN-соединение
Надо учитывать, что некоторые виды подключение, например GRE не являются PPP.

/ip firewall filteradd chain=forward comment=»Permit all PPP» in-interface=all-ppp

Разрешить PPTP-подключение/ip firewall filteradd chain=input dst-port=1723 protocol=tcp comment=»Permit PPTP»add action=accept chain=input protocol=gre comment=»Permit GRE»

Разрешить L2TP-подключение/ip firewall filteradd chain=input dst-port=1701 protocol=udp comment=»Permit L2TP»

Разрешить IPSec-подключение/ip firewall filteradd chain=input port=500,4500 protocol=udp comment=»Permit IPSec ports 500 and 4500″add chain=input protocol=ipsec-esp comment=»Permit IPSec protocol ipsec-esp»

Разрешить OpenVPN-подключение/ip firewall filteradd action=accept chain=input dst-port=1194 protocol=tcp comment=»Permit OpenVPN»

Разрешить SSTP-подключение/ip firewall filteradd action=accept chain=input dst-port=443 protocol=tcp comment=»Permit SSTP»

Разрешить GRE-подключение/ip firewall filteradd action=accept chain=input protocol=gre comment=»Permit GRE»

Разрешить IPIP-подключение/ip firewall filteradd action=accept chain=input protocol=ipip comment=»Permit IPIP»

Прохождение IPSec при использовании Fast Track

Fast Track это опция представленная в RouterOS 6.29. С помощью этой опции можно передавать пакеты в обход ядра Linux. За счет этого существенно повышается производительность маршрутизатора.

Включить Fast Track можно следующим образом:/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related
Это позволит пакетам у которых состояние «Established» или «Related» обходить ядро Linux и быть сразу перенаправленным к цели. Такие пакеты не будут проходить ни через одно правило файервола или другое правило обработки пакетов. Of course – a connection gains the state of established or related once it went through the firewall so it will still be secure.

Как результат появляется недостаток: соединения IPsec так же не будут обработаны. Решить эту проблему можно следующим образом.

Вначале надо пометить соединения IPsec:/ip firewall mangle add action=mark-connection chain=forward comment=»Mark IPsec» ipsec-policy=out,ipsec new-connection-mark=ipsecadd action=mark-connection chain=forward comment=»Mark IPsec» ipsec-policy=in,ipsec new-connection-mark=ipsec

Далее изменить стандартное правило Fast Track так, что бы оно не обрабатывало пакеты IPsec. Изменения внесенные в стандартное правило выделены красным./ip firewall filter add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related

Правила пустышки

В основной своей массе эти правила сводятся к одному: разрешению того, что и так не запрещено.

Эта категория лженастроек не делает ничего кроме бессмысленного потребления ресурсов маршрутизатора.
Выглядит это все примерно так:

С пакетом, который попадает в файервол с таким набором правил происходит одно из двух:

• Пакет попадает под действие одного из правил и оказывается разрешенным.
• Пакет не попадает под действие ни одного из правил и так как нет запрещающего правила, то пакет оказывается разрешенным.

Т. е. в любом случае пакет оказывается разрешенным.

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