[Trueno]

Нужны комментарии по поводу настройки фаервола.

Настраиваю очередной интернет-шлюз под заказчика, пользователей около 100, включение/выключение руками (через ip - firewall - address list).

Пробовал разные варианты, и придумал вот что:

 

/ip firewall filter

add action=drop chain=input connection-state=invalid
#блокирует некорректные соединения на вход

add action=drop chain=forward connection-state=invalid
#блокирует некорректные соединения на транзит

add action=accept chain=input src-address-list=Client
#разрешает входящие соединения для пользователей, если ip активен в адрес-листе

add action=accept chain=forward src-address-list=Client
#разрешает транзитные соединения для пользователей, если ip активен в адрес-листе

add action=accept chain=input protocol=icmp
#разрешает входящий ICMP для всех

add action=drop chain=input connection-state=new
#запрет для всех входяших новых соединений, которые не попадают в вышестоящие правила

add action=drop chain=forward connection-state=new
#запрет для всех транзитных новых соединений, которые не попадают в вышестоящие правила

 

И вроде бы всё работает. Из интернета пинг на шлюз есть, доступа на порты нет, инет для активных ай-пи в адрес-листе работает.

Однако, поразмыслив с коллегами, пришли к сомнениям.

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

2. Моя логика с чередованием input/forward кривая, мол, нужно сначала прописать все intup, потом все forward. Я так пробовал. Визуально начинают дольше грузиться странички. Или же это из-за перестройки и нужно сначала ребутнуть роутер?

3. Нужно в разрешающих правилах разрешать не всё, а только established и related, а в нижних правилах рубить всё, а не только new.

Вот я и задумался.

 

Как бы посоветовали вы?

[McSea]

1. Вам тут точно нужны, т.к. в конце дропаются только new.

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

 

2. Вообще не имеет значения, один пакет за раз проходит только либо input, либо forward. Важен порядок правил только внутри цепочки.

 

3. Если будете внизу дропать все, какое правило будет пропускать пакеты с src-address="из инета" ?

Если разрешать только est&rel, какое правило будет пропускать new ?

 

А открыть доступ к управлению микротиком всем из Client - так нужно было по ТЗ ? 

Стандартный конфиг кстати чем не нравится, там все вполне логично для варианта с connection tracking-ом ?

Изменено 13 апреля, 2019 пользователем McSea

[Trueno]

2 часа назад, McSea сказал:

А открыть доступ к управлению микротиком всем из Client - так нужно было по ТЗ ? 

На управление (ссш) доступ только для двух ай-пи (админских), прописано в ip - services.

2 часа назад, McSea сказал:

Стандартный конфиг кстати чем не нравится, там все вполне логично для варианта с connection tracking-ом ?

 

Дык, там ещё больше правил.

Чем мой вариант уступает дефолтному?

[Chexov]

В 13.04.2019 в 10:32, Trueno сказал:

Настраиваю очередной интернет-шлюз под заказчика

и придумал вот что:

Однако, поразмыслив с коллегами, пришли к сомнениям.

Вот я и задумался.

Как бы посоветовали вы?

Хватит дурью маяться, есть стандартный (дефолт) конфиг, которые более чем правильный, нет ничего лишнего!

Надо только отключить и настроить сервис порты, ненужные закрыть, а нужные по списку.

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

Руководство по iptables (Iptables Tutorial 1.1.19)

TCP/IP. Сетевое администрирование (Крейг Хант)

linux администрирование сетей tcp/ip  (Скотт Манн, Митчел Крелл)

И на курсы по микротику походить, а не фантазировать своими кривыми конфигами.

Сначала разумите зачем нужны эти правила, а не наоборот.

 

 

Изменено 15 апреля, 2019 пользователем Chexov

[Trueno]

9 часов назад, Chexov сказал:

Хватит дурью маяться, есть стандартный конфиг, которые более чем правильный!

 

Вы имеете в виду конфиг из дефолтной конфигурации?

[Saab95]

19 часов назад, Chexov сказал:

Хватит дурью маяться, есть стандартный конфиг, которые более чем правильный!

Если в конце стандартного конфига написать system reset-configuration no-defaults=yes, после чего отключить все не нужные службы, установить на них ограничения с IP для доступа, в настройках учеток админов так же поставить ограничения, и для пущей уверенности в файрволе заблокировать доступ на порт винбокса (только дроп), то микротик никто уже не сломает и доступ не получит.

 

Все остальное не нужно вообще, ни дропать некие невалидные соединения - ведь если они до микротика дошли, то и канал уже заняли, что толку от дропа? Только вот производительность с выше указанным списком правил у него раза в 2 меньше станет.

[alibek]

15 минут назад, Saab95 сказал:

то микротик никто уже не сломает и доступ не получит.

Ха-ха.

[McSea]

On 4/13/2019 at 9:04 PM, Trueno said:

Дык, там ещё больше правил.

При схеме

 

allow  established, related

..

разрешающие правила

..

drop all 

 

бОльшая часть пакетов не проходит дальше первого правила, так что общее число правил не так важно.

 

 

[sherwood]

34 минуты назад, McSea сказал:

так что общее число правил не так важно.

Вы не правы, программа отрабатывает все правила, даже те которые - Disable.

[McSea]

@sherwood 

Вы видимо не совсем поняли, о чем я говорю. 

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

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

 

Ну и на всякий случай цитата с wiki.mikrotik.com --

Quote

When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action). If a packet has not matched any rule within the built-in chain, then it is accepted.

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

 

 

Изменено 15 апреля, 2019 пользователем McSea

[sherwood]

1 минуту назад, McSea сказал:

Вы видимо не совсем поняли, о чем я говорю.

Я все правильно понял. Ответ был не на то, что пакет попавший под первое правило должен пойти дальше по правилам, нет он не пойдет, потому, что он выбрасывается из этой цепочки. Ответ был на то, что количество правил не имеет значение. Значение имеет для ОС и ее производительности, потому что правила обрабатываются все, даже те которые в - Disable. Например у Вас 1000 правил в rules и все они отключены, а последние работает, так вот пакет попавший в цыпочку rules будет проверятся в каждом правиле на соответствии но сработает только последнее. Не забывайте про это.

[McSea]

9 minutes ago, sherwood said:

Значение имеет для ОС и ее производительности, потому что правила обрабатываются все, даже те которые в - Disable.

А откуда такая информация ? Как-то не логично проверять пакеты на соотвествие условиям отключенных правил, не находите ?

 

Также выше я написал "не так важно", а не "вообще не важно".

На приведенном выше скриншоте только менее 0.5% пакетов прошло дальше первого правила цепочки.

 

Изменено 15 апреля, 2019 пользователем McSea

[sherwood]

1 минуту назад, McSea сказал:

не находите ?

Цитата

Мир такой какой он есть, он не обязан быть понятным тебе.

Ну как же, есть пакет есть правило, система должна проверить, понятно что она не проверяет все условия правила которое disable, но пакет пробегает по всем правилам. Попадает под первое правило, правило disable, идет дальше.

На примере с DDoS атакой, пакет уже прилетел на интерфейс и системе надо его обработать.

[poisons]

@sherwood зачем? Если правило в конфиге явно выключено, то зачем это правило тащить в iptables или чего там внутри прибалты прикрутили.

[sherwood]

Ну, значит еще не время.

[sherwood]

12 часов назад, poisons сказал:

зачем? Если правило в конфиге явно выключено, то зачем это правило тащить в iptables

Поясню, написан код на любом языке, который выполняется сверху вниз по строчно (ни чего не напоминает?), доходит до строчки с # что она делает, правильно игнорирует. Но ей надо с чем то сравнить и проверить, что строчку начинающую с символа # надо пропускать (потому что это комментарии). А например строка с <!-- ее тоже надо игнорировать, и мало того нужно еще дойти до конца до ответного символа --> что бы понять что это комментарий и выполнять его не надо. Что это оставил пометку для себя человек с его слабеньким умишком, не способный запомнить для чего он это навоял и считающий себя пупом земли, мать его :) (шутка про комметрарии).

[alibek]

59 минут назад, sherwood сказал:

Поясню, написан код на любом языке, который выполняется сверху вниз по строчно (ни чего не напоминает?), доходит до строчки с # что она делает, правильно игнорирует. Но ей надо с чем то сравнить и проверить, что строчку начинающую с символа # надо пропускать (потому что это комментарии).

К чему эти детские фантазии?

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

Неужели кто-то всерьез может думать, что каждое правило обрабатывается парсером, прежде чем будет применено к пакету?

[sherwood]

15 минут назад, alibek сказал:

Правила, задаваемые через GUI

Извините, но научитесь смотреть дальше обложки.

[alibek]

Симметрично.

[Saab95]

На микротике отключенные правила никак не участвуют в прохождении трафика. Данные передаются по цепочкам, где каждая состоит из данных правила и адреса (или ссылки, указателя и т.п.) на следующее правило. Когда производятся какие-то действия по добавлению, удалению или перемещения правил, в этот момент перестраивается цепочка.