Правила брэндмауэра для обеспечения внешней безопасности сети с помощью маршрутизатора Mikrotik (Router OS)

[Erik_U]

Все не так.

Вместо 3-х правил можно (и нужно) сделать одно.

add action=drop chain=forward in-interface=WAN connection-state=!established,!related

[podarok66]

Все не так.

Вместо 3-х правил можно (и нужно) сделать одно.

add action=drop chain=forward in-interface=WAN connection-state=!established,!related

Каким образом вы в одном правиле хотите описать и инпут и форвард? Да ещё учитывая пожелание вынести пакеты из цепочки форвард ( не знаю зачем, но указано же). ТЗ есть, и если плясать, то именно в рамках этого ТЗ. Не путайте начинающего, он сам без вас ещё не раз этот фаервол в узел завяжет и будет голову ломать, за какой кончик тянуть.
Ну и ещё один момент. Не стоит пытаться придумать универсальное правило. Часто случаются ситуации, когда нужно что-то дописать в фаервол на лету. И вот тут многоуровневые правила могут сыграть с вами злую шутку.
Например, пишете правило, но оно не отрабатывает. Ага, чтобы понять, работает оно вообще или нет, отключаете общий запрет (то самое правило дропа)_. А ваш запрет включал ещё какие-то оговорки и они теперь не учитываются. И новое устройство или программа, для которых вы и пытаетесь написать правило, как-то зависит от этих оговорок. Но вы-то их исключили из фаервола, отключая дроп. И в итоге то, что вроде бы должно работать, капризничает. А вы будете копать землю, и не факт, что сообразите, чего там у вас не так.
Да и вообще, я established и related стараюсь разрешить в самом верху фаервола, потом уже можно оговорить, что и куда там идёт, и только потом дроп. Правила-то выполняются по порядку. Пусть уж созданные соединения в первом же правиле разрешаются, и не проходят через всю цепочку правил.

[Erik_U]

Все не так.

Вместо 3-х правил можно (и нужно) сделать одно.

add action=drop chain=forward in-interface=WAN connection-state=!established,!related

Каким образом вы в одном правиле хотите описать и инпут и форвард? Да ещё учитывая пожелание вынести пакеты из цепочки форвард ( не знаю зачем, но указано же). ТЗ есть, и если плясать, то именно в рамках этого ТЗ. Не путайте начинающего, он сам без вас ещё не раз этот фаервол в узел завяжет и будет голову ломать, за какой кончик тянуть.
Ну и ещё один момент. Не стоит пытаться придумать универсальное правило. Часто случаются ситуации, когда нужно что-то дописать в фаервол на лету. И вот тут многоуровневые правила могут сыграть с вами злую шутку.
Например, пишете правило, но оно не отрабатывает. Ага, чтобы понять, работает оно вообще или нет, отключаете общий запрет (то самое правило дропа)_. А ваш запрет включал ещё какие-то оговорки и они теперь не учитываются. И новое устройство или программа, для которых вы и пытаетесь написать правило, как-то зависит от этих оговорок. Но вы-то их исключили из фаервола, отключая дроп. И в итоге то, что вроде бы должно работать, капризничает. А вы будете копать землю, и не факт, что сообразите, чего там у вас не так.
Да и вообще, я established и related стараюсь разрешить в самом верху фаервола, потом уже можно оговорить, что и куда там идёт, и только потом дроп. Правила-то выполняются по порядку. Пусть уж созданные соединения в первом же правиле разрешаются, и не проходят через всю цепочку правил.

Даже и не собираюсь в одном правиле и инпут и форвард описывать.

В "простой гениальности" jump сделан только на форвард, поэтому 3 правила "customer" обрабатывают только форвард. Инпут они не обрабатывают.

add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established in-interface=WAN
add action=accept chain=input connection-state=related in-interface=WAN
add action=drop chain=input in-interface=WAN
add action=jump chain=forward in-interface=WAN jump-target=customer
add action=accept chain=customer connection-state=established
add action=accept chain=customer connection-state=related
add action=drop chain=customer

Jump на следующую строку делать бессмысленно. Разбивать connection-state=established и connection-state=related на 2 правила - бессмысленно. И вообще,для них достаточно сделать исключение в одном запрещающем правиле (в той конструкции, которая приведена).

add action=drop chain=forward in-interface=WAN connection-state=!established,!related

Получится 1 строка вместо 4-х.

Я бы еще понял, если бы после Jump стояло правило, которое например дропает все остальнае пакеты, а цепочка customer написана после него, чтобы туда доходили только пакеты chain=forward in-interface=WAN.
А так, как написано - все равно будут все пакеты проверяться. Как минимум на соответствие chain=customer.

[Erik_U]

те 8 строк можно уложить в 3

add action=accept chain=input protocol=icmp
add action=drop chain=input in-interface=WAN connection-state=!established,!related
add action=drop chain=forward in-interface=WAN connection-state=!established,!related

[podarok66]

Да мы же с вами не "гениальность" джампа обсуждаем
Да три ваших правила описывают ситуацию полностью. Но! я бы дроп с акцептом на столь глобальном правиле не объединял.