MikroTik Настройка Firewall

MikroTik Firewall Filter

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

/ip firewall filter
add chain=input in-interface-list=ISP action=jump jump-target=ISP-Input
add chain=forward in-interface-list=ISP action=jump jump-target=ISP-Forward

add chain=ISP-Input connection-state=established
add chain=ISP-Input connection-state=related
add chain=ISP-Input connection-state=untracked
add chain=ISP-Input connection-state=invalid action=drop
add chain=ISP-Input jump-target=ISP-Input-Allow action=jump
add chain=ISP-Input action=drop

add chain=ISP-Forward connection-state=established
add chain=ISP-Forward connection-state=related
add chain=ISP-Forward connection-state=untracked
add chain=ISP-Forward connection-state=invalid action=drop
add chain=ISP-Forward connection-nat-state=dstnat
add chain=ISP-Forward action=drop

add chain=ISP-Input-Allow protocol=icmp
add chain=ISP-Input-Allow dst-port=22 protocol=tcp
add chain=ISP-Input-Allow dst-port=1701 protocol=udp

Главной особенностью нашего фаервола заключается в том, что вам нет необходимости
помнить в каком порядке расставлять правила для открытия нужных портов на маршрутизаторе,
вы всегда работает ТОЛЬКО с одной цепочкой ISP-Input-Allow.

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

Стоп!!! Стоп!!! Стоп

А вы не заметили, что мы начали создавать по сути одинаковые правила, для разных
интерфейсов, мне кажется или это “перебор”?! А вам?

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

Собственно на данном этапе мы разрешили пакеты, которые связаны с уже установленными
соединениями и пакеты которые идут мимо connection-tracker, untracked, с ними
мы разберёмся позже.

Так как мы настраиваем цепочку input мы работаем с пакетами которые идут непосредственно
на сам маршрутизатор.

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

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

add chain=Local-Input action=jump jump-target=Local-Input-All

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

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

add chain=Local-Input-All protocol=icmp

Если ваш маршрутизатор выступает в роли dns сервера для всех сетей, то почему бы
и не разрешить его.

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

Нам необходимо более выборочно поступить к настройкам фаервол, допустим нам надо
разрешить управление Mikrotik для его дальнейшей настройки только с интерфейса ether5.3
это наш некий management.

Мы в этой же цепочке, укажем ещё и интерфейс.

add chain=Local-Input-All in-interface=ether5.3 protocol=tcp dst-port=22,8291

Т.е. Мы конкретизировали ещё и интерфейс.

А теперь нам надо заблокировать весь оставшийся трафик, но уже не в цепочке
Local-Input-All, а в Local-Input. Так когда трафик закончится обрабатываться
в цепочке Local-Input-All он вернётся в цепочку Local-Input.

add chain=Local-Input action=drop

Всё, теперь у нас есть конфигурация, которая разрешает с любого локального интерфейса
доступ к dns и icmp, а также с интерфейса ether5.3 соединение непосредственно
с ssh и winbox.

И если вам надо, что-то разрешить, то вы работаете только с цепочкой Local-Input-All,
всё что не будет явно разрешено, будет запрещено.

Firewall Filter Local Forward

А теперь поговорим непосредственно про проходящий трафик, а именно трафик из локальных
сетей. Ещё раз напомню что у нас пять интерфейсов vlan ether5.2, ether5.3, ether5.4,
ether5.5 и ether5.6.

• ether5.2 — сеть, где находятся компьютеры пользователей.
• ether5.3 — management vlan, сеть где находятся различные управляющие IP интерфейсы
  оборудования принадлежащий сетевой инфраструктуре.
• ether5.4 — VoIP здесь находятся телефонные аппараты.
• ether5.6 — гостевой wifi.

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

Конечно всё зависит от задачи и поставленного ТЗ, но так как мы с вами работаем без
ТЗ =), то делать будет по-простому, а именно ориентироваться в наших правилах, на
пакет которые пришёл с определённого интерфейса.

Создадим пять правил

add chain=forward in-interface=ether5.2 action=jump jump-target=Forward-from-ether5.2
add chain=forward in-interface=ether5.3 action=jump jump-target=Forward-from-ether5.3
add chain=forward in-interface=ether5.4 action=jump jump-target=Forward-from-ether5.4
add chain=forward in-interface=ether5.5 action=jump jump-target=Forward-from-ether5.5
add chain=forward in-interface=ether5.6 action=jump jump-target=Forward-from-ether5.6

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

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

add chain=forward action=drop

Теперь у нас фаервол имеет концепцию Нормально закрытый фаервол, всё что не
разрешено то запрещено и надо будет помнить так как при добавлении VPN-ов или новых
интерфейсов у вас будет всё с них запрещено.

Также необходимо добавить ещё два правила, ПЕРЕД нашими forward, а именно:

add chain=forward connection-state=established
add chain=forward connection-state=related
add chain=forward connection-state=invalid action=drop

Эти правила необходимы для того, чтобы уменьшить количество трафика (pps) на правила
в кастомных цепочках, ну и также облегчить удобство настройки. Эти правила должны
быть всегда перед правилами forward/jump

А теперь поколдуем с нашими цепочками.

Начнём с самой простой, гостевой wifi

add chain=Forward-from-ether5.6 out-interface-list=ISP

Продолжим с цепочкой VoIP

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

• 192.168.5.2 — pbxprovision
• 192.168.5.3 — Active DirectoryDNSNTP
• 192.168.5.5 — Active DirectoryDNSNTP
• 192.168.5.4 — SYSLOG

Создадим адрес лист чтобы не плодить сущности

/ip firewall address-list
add address=192.168.5.3 list=ActiveDirectoryServers
add address=192.168.5.5 list=ActiveDirectoryServers

add chain=Forward-from-ether5.4 dst-address=192.168.5.2 protocol=udp dst-port=69 comment=»TFTP»
add chain=Forward-from-ether5.4 dst-address=192.168.5.2 protocol=udp dst-port=5060 comment=»SIP»
add chain=Forward-from-ether5.4 dst-address-list=ActiveDirectoryServers protocol=udp dst-port=53 comment=»DNS»
add chain=Forward-from-ether5.4 dst-address-list=ActiveDirectoryServers protocol=udp dst-port=123 comment=»NTP»
add chain=Forward-from-ether5.4 dst-address-list=ActiveDirectoryServers protocol=tcp dst-port=636 comment=»LDAP BOOK»
add chain=Forward-from-ether5.4 dst-address=192.168.5.4 protocol=udp dst-port=514 comment=»LOG»

Обратите внимание на TFTP и SIP, нам не надо разрешать related порты, например такие,
как RTP 10000-20000 (в большинстве случаев), так как NAT хелперы мы не отключали.
Привет, всем (у кого горит) любителям хелперов =))), а если серьёзно, то вы должны
выбрать для себя, то как будет строиться ваш подход, либо вы отключаете хелпер и
настраиваете “всё и вся” либо вы возлагаете часть работы на хелпер, решать только
вам, оба кейса “имеет место быть”.

Это конечно не входит в данную статью, но помните один важный нюанс, потеря данных
аутентификации к SIP серверу может привести к прямым потерям, в виде счёта от вашего
провайдера, отсюда надо помнить такую вещь! Не пренебрегайте настройками безопасностей
в локальной сети, как показывает практика чаще всего из локальной сети разрешено
всё! Установите на вашу PBX системы как минимум fail2ban и естественно не забудьте
его настроить.

Management vlan

Сеть в которой находить различное оборудование, необходимо минимум настроек

add chain=Forward-from-ether5.3 dst-address-list=ActiveDirectoryServers protocol=udp dst-port=53 comment=»DNS»
add chain=Forward-from-ether5.3 dst-address-list=ActiveDirectoryServers protocol=udp dst-port=123 comment=»NTP»
add chain=Forward-from-ether5.3 dst-address=192.168.5.4 protocol=udp dst-port=514 comment=»LOG»

Локальная сеть

Тут та мы и с вами нагородим

Согласно документации https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts

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

Серверная сеть

Конечно здесь всё индивидуально и под конкретную задачу. Я попробую сделать собирательный
образ

add chain=Forward-from-ether5.5 protocol=icmp
add chain=Forward-from-ether5.5 src-address=192.168.5.2 dst-address-list=voip.provider protocol=udp dst-port=5060
add chain=Forward-from-ether5.5 src-address=192.168.5.2 dst-address-list=voip.provider protocol=tcp dst-port=5060
add chain=Forward-from-ether5.5 src-address-list=ActiveDirectoryServers out-interface=ether5.2
add chain=Forward-from-ether5.5 src-address-list=ActiveDirectoryServers out-interface-list=ISP protocol=udp dst-port=53

Итоговая таблица правил фаервола:

Если что-то забыл, не серчайте, пишите в группу в телеге или в ВК, обязательно поправим.

Разделение адресов локального сегмента и интернета

Названное международное сообщество работает с конца 80-х годов и практикует развитие протоколов и архитектур, используемых внутри глобальной сети. Результаты деятельности IEFT публикуются в виде информационных документов RFC (Request for Comments). В них содержится подробное описание стандартов, спецификаций. На сегодняшний день их принято несколько тысяч (на английском языке). Нас интересует RFC6890.

add address=0.0.0.0/8 comment=RFC6890 list=not_in_internetadd address=172.16.0.0/12 comment=RFC6890 list=not_in_internetadd address=192.168.0.0/16 comment=RFC6890 list=not_in_internetadd address=10.0.0.0/8 comment=RFC6890 list=not_in_internetadd address=169.254.0.0/16 comment=RFC6890 list=not_in_internetadd address=127.0.0.0/8 comment=RFC6890 list=not_in_internetadd address=198.18.0.0/15 comment=RFC6890 list=not_in_internetadd address=192.0.0.0/24 comment=RFC6890 list=not_in_internetadd address=192.0.2.0/24 comment=RFC6890 list=not_in_internetadd address=198.51.100.0/24 comment=RFC6890 list=not_in_internetadd address=203.0.113.0/24 comment=RFC6890 list=not_in_internetadd address=100.64.0.0/10 comment=RFC6890 list=not_in_internetadd address=240.0.0.0/4 comment=RFC6890 list=not_in_internet

Выполнить их нужно поочередно. В большинстве случаев рекомендуется внести в перечень подсеть 224.0.0.0/4. Ее резервируют для многоадресного вещания (мультикаст), подробная информация об этом поддиапазоне содержится в документе RFC2780. Второй диапазон 192.88.99.0/24 рассчитан на передачу трафика IPv6 через сети IPv4 (спецификация согласно документу RFC3068). Вносим такие изменения командой:

add address=224.0.0.0/4 comment=Multicast_RFC2780 list=not_in_internetadd address=192.88.99.0/24 comment=»6to4_RFC 3068″ list=not_in_internet

Теперь нужно проверить, сохранились ли внесенные изменения настроек:

Следующим шагом создадим аналогичные правила, рассчитанные на цепочку Forward. Шаг создаст дополнительный уровень защиты рабочих мест, подключенных к локальной сети, от посягательств извне. Для этого вернемся в раздел с правилами:

Первое, что желательно сделать – чтобы брандмауэр не срабатывал на уже установленные коннекты (это создает бесполезную нагрузку на аппаратную платформу). Выполняется задача командой:

add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related

Следом нужно обработать активные соединения согласно алгоритмам цепочки Forward:

add action=accept chain=forward comment=»Established, Related» connection-state=established,related

Рекомендуется сразу отбросить «битые» соединения:

add action=drop chain=forward comment=»Drop invalid» connection-state=invalid log=yes log-prefix=invalid

add action=drop chain=forward comment=»Drop tries to reach not public addresses from LAN» dst-address-list=not_in_internet in-interface=bridge1 log=yes log-prefix=!public_from_LAN out-interface=!bridge1

add action=drop chain=forward comment=»Drop incoming from internet which is not public IP» in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet

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

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

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

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

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

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

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

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.

Interface List

Создадим отдельный лист, где перечислим все наши локальные интерфейсы, в которых
находятся наши пользователи, только не стоит добавлять все интерфейсы, а только те,
где действительно есть и ходит трафик. В моём случае это 5 интерфейсов
ether5.2 ether5.3 ether5.4 ether5.5, ether5.6 я таким образом именую
vlan интерфейсы, но в вашем случае могут быть разные bridge-ы и просто интерфейсы.

/interface list add name=Local

/interface list member
add list=Local interface=ether5.2
add list=Local interface=ether5.3
add list=Local interface=ether5.4
add list=Local interface=ether5.5
add list=Local interface=ether5.6

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

Отлично теперь у нас есть лист с которым мы будем работать.

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

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

Но даже если вы задали сложный пароль — это еще не гарантирует безопасности. Длительная атака перебором способна сломать этот барьер защиты, поэтому проще всего пресекать попытки злоумышленников сразу, как только замечен процесс перебора. Настройка правил firewall у устройств 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 из первого списка ssh_stage1.

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

Третья ошибочная попытка приводит к копированию IP из списка ssh_stage3 в список ssh_blacklist и все входящие соединения с этого IP будут заблокированы сроком на 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

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

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

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

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

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

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

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

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

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

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

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

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

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

add action=accept chain=input protocol=icmp

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

add action=drop chain=input

Этим в финале цепочки 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. Подразумевается то, что если списка с таким именем не существует, то при выполнении команды он будет создан. Проверим:

И так начнём с простого, займёмся безопасностью.

Firewall Filter Local input

Начнём мы с банального, это перенаправим весь входящий трафик в листе Local в
кастомную цепочку! Поместим это правило в самый верх.

/ip firewall filter
add chain=input in-interface-list=Local action=jump jump-target=Local-Input

Теперь мы в данной цепочке разрешим весь трафик established, related, untracked.

add chain=Local-Input connection-state=established
add chain=Local-Input connection-state=related
add chain=Local-Input connection-state=untracked

Также необходимо отбросить invalid.

add chain=Local-Input connection-state=invalid action=drop

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

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

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

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

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

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

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

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

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

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

Хочу признаться мне не очень нравиться дефолтный конфиг Firewall, но я прекрасно
понимаю, что тем кто его придумал, была задача найти условно общую конфигурацию
которая бы подходила к большинству и покрывала решение зада большинства, но мы
не большинство, и будем “лепить” свой конфиг.

Естественно чистим конфигурацию или просто очищаем полностью Filter Firewall-а.

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

Разделяем и властвуем

Списки адресов — крайне полезная штука при настройке файервола. Тут важно следовать стандартам, разработанным такой крутой организацией, как IETF (Internet Engineering Task Force) — Инженерный совет Интернета. Это международное сообщество с конца 80-х годов занимается развитием протоколов и архитектуры интернета.

Результаты работы IEFT публикуются в виде RFC (Request for Comments) — информационных документов, содержащих в себе детальное описание спецификаций и стандартов. Этих документов уже создано несколько тысяч, все они представлены на английском языке. Один из них поможет нам корректно сформировать списки адресов, а именно RFC6890.

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

Есть еще две важные подсети, которые тоже стоит добавить в этот список. Первая подсеть — это 224.0.0.0/4. Эта подсеть зарезервирована для технологии многоадресного вещания (мультикаст) и это зафиксировано в соответствующем RFC2780. Вторая подсеть специфична для переходного механизма 6to4, позволяющего передавать IPv6 трафик через IPv4 сети. Этот механизм реализован в подсети 192.88.99.0/24, что также зафиксировано в отдельном RFC3068.

Теперь, когда мы все сделали «‎по фен-шую»‎, у нас есть список всех адресов, которые будут опознаваться как локальные, т.е. пришедшие не из интернета. Проверим:

Теперь, используя эти листы, создадим еще правила уже в цепочке FORWARD, которые защитят устройства в локальной сети от различных посягательств. Возвращаемся в раздел с правилами:

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

Обрабатываем установленные соединения в цепочке Forward:

add action=accept chain=forward comment=»Established, Related» connection-state=established,related

Отбрасываем «‎битые»‎ соединения:

Отбрасываем входящие пакеты, которые не подходят для NAT и фиксируем срабатывание:

add action=drop chain=forward comment=»Drop incoming packets that are not NATted» connection-nat-state=!dstnat connection-state=new in-interface=ether1 log=yes log-prefix=!NAT

add action=drop chain=forward comment=»Drop packets from LAN that do not have LAN IP» in-interface=bridge1 log=yes log-prefix=LAN_!LAN src-address=!192.168.88.0/24

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

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

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

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

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

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

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

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

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

Interface List ISP

В моём случае для примера у меня три провайдера ether1, ether2, ether3 и поверх
ether3 запущен PPPoE туннель для получения доступа к интернету.

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

/interface list add name=ISP

Как вы его назовёте, не имеет значения, главное чтобы вам был понятен смысл имени
и наверное очень важно, то чтобы было понятно любому другому человеку который
взглянет на ваши настройки.Ведь согласитесь если вы его назовёте “Bla-bla-bla”
смысл для любого человека будет непонятен, хотя возможно для вас он и будет иметь
сакральный смысл.

Я предпочитаю называть данный лист ISP, что обозначает Internet Service Provider.

Соответственно добавляем в данный лист все интерфейсы провайдеров.

/interface list member
add list=ISP interface=ether1
add list=ISP interface=ether2
add list=ISP interface=ether3
add list=ISP interface=ether3.PPPoE

Обратите вниманию я добавил ether3 и PPPoE интерфейс которые поднят через него же.
По поводу наименование PPPoE туннеля не удивляйтесь у меня есть привычка использовать
в наименовании интерфейсов точку в случае если данные интерфейс является sub интерфейсом
другого интерфейса.К примеру если у меня будет vlan 100 на первом интерфейсе его
имя будет ether1.100.

На данный момент мы закончили с настройкой листа ISP и может приступить непосредственно
к настройке Firewall.