Настройки firewall в mikrotik

Нам достаточно настроить файервол в нормально закрытом режиме и заблокировать invalid-трафик.

/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=drop chain=input #последнее правило в цепочке input
# для последнего правила часто дополнительно указывают входящим WAN-интерфейс, но это зависит от конкретных настроек, которые хочет задать администратор сети

Правило, блокирующее 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-трафик. И произойдет это следующим образом:

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

Резюме

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

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

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

... protocol=tcp tcp-flags=fin,syn
... protocol=tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack
... protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg

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

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

Описание

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

/ip firewall filter
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=161 protocol=udp src-address-list=zabbix
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
...
Далее нет ни одного запрещающего правила

Развенчание мифа

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

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

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

Резюме

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

Ошибки

Использование нормально открытого файервола

Описание

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

/ip firewall filter
add action=drop chain=input dst-port=53 protocol=tcp
add action=drop chain=input dst-port=53 protocol=udp
add action=drop chain=input dst-port=22 protocol=tcp
add action=drop chain=input dst-port=80 protocol=tcp
add action=drop chain=input ...
add action=drop chain=input ...
add action=drop chain=input ...
add action=drop chain=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

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

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

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

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

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

/ip firewall filter
...
add action=accept chain=input protocol=tcp
...
add action=drop chain=input dst-port=22
...

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


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

/ip firewall filter
...
add action=accept chain=forward dst-address=192.168.15.0/24
...
add action=drop chain=forward in-interface=Guest out-interface=LAN
...

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

/ip firewall filter
...
 add action=drop chain=forward in-interface=DMZ out-interface=LAN
...
add action=accept chain=forward dst-port=80,443 protocol=tcp

В этом примере есть правило, которое разрешает 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.

 

 

источник: https://mikrotik.wiki/wiki/%D0%9C%D0%B5%D0%B6%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B9_%D1%8D%D0%BA%D1%80%D0%B0%D0%BD:%D0%9B%D0%B6%D0%B5%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B8_%D0%B8_%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D0%BF%D1%80%D0%B8_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B5_%D1%84%D0%B0%D0%B9%D1%80%D0%B2%D0%BE%D0%BB%D0%B0?utm_source=interface31&utm_medium=cpm&utm_campaign=mrakobesie

 

 

 

Яндекс.Метрика