Настройка фильтрации трафика на MikroTik. Часть 3

В прошлых частях статьи мы ознакомились с базовыми настройками файрволла, из которых мы, в том числе, узнали, что межсетевой экран маршрутизатора последовательно проверяет пакет на соответствие правилам фильтрации сверху-вниз. Проверка прекращается в тот момент, когда пакет будет либо пропущен на следующий этап обработки трафика (Action=Accept), либо прохождение пакета будет запрещено (Action=reject,drop,tarpit).

Таким образом, если мы представим себе файрволл, состоящий из 25 правил, то выглядеть это будет следующим образом:

При этом, если пакет соответствует только правилу номер 25, он все равно будет проверен на соответствие правилам с номера 1 по номер 24, на что будут потрачены ресурсы маршрутизатора.

Ситуация осложняется тем, что есть «очень дорогие», с точки зрения процессорного времени, правила фильтрации. В этих случаях приходит на выручку возможность писать собственные цепочки (Chain) обработки правила.

Если вы когда-либо занимались программированием, то собственная цепочка очень похожа на процедуру, вызов которой осуществляется указанием в поле Action команды Jump с именем цепочки, возврат же происходит на следующее правило за вызовом цепочки, по окончании обработки трафика в цепочке, либо если в каком-либо правиле собственной цепочки было использовано Action=Return, что прервало дальнейшую обработку цепочки.

При этом надо обратить внимание, что пакет попадет в цепочку Custom-Chain-1, только если он будет соответствовать условиям, обозначенным в правиле 3a, а в цепочку Custom-Chain-2, только если он соответствует правилу 15a.

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

Так же хочется обратить внимание что одну и ту же цепочку можно вызывать из разных цепочек (в том числе и своих) фильтрации трафика. Например, вы можете написать цепочку с защитой ssh-сервера от подбора пароля и обращаться к ней как из цепочки input (подбор пароля на маршрутизатор), так и из цепочки forward, защищая один или несколько внутренних серверов.

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

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

• WAN (Выход в интернет);
• DMZ (Демилитаризованная зона);
• LAN (Локальная сеть).

Разделим их по уровню доверия.

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

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

WAN – самая небезопасная сеть. С нее по умолчанию закрыт доступ как в LAN, так и в DMZ.

Графически это можно представить так:

Так же предположим, что в DMZ у нас есть www-сервер с адресом 10.10.10.100, который должен быть доступен из WAN (Вопросы настройки NAT в этой статье не рассматриваются). Так же из DMZ разрешено обращение на порт 22(ssh) хоста 192.168.88.200 расположенного в LAN.

Так как в этой части статьи мы работаем с трафиком, идущим через маршрутизатор, основной цепочкой (Chain) для такого трафика является forward.

Сначала разрешим все соединения с состояниями соединения равными established и related, и запретим с состоянием соединения равным invalid, независимо от интерфейсов. Так как мы уже знаем, что фильтровать трафик логично только на новых соединениях (connection-state=new).

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

Теперь создадим необходимые нам цепочки правил.

В этой цепочке мы разрешаем любой трафик от LAN интерфейса к WAN-интерфейсу. При необходимости можно добавить запрещающие правила. (Обратите внимание, что мы не указываем интерфейсы. Они будут указаны в цепочке forward, при переходе на свои цепочки).

А здесь мы, наоборот, запрещаем весь трафик идущий из интерфейса WAN в локальную сеть. Ранее установленные соединения обрабатывается правилом, их разрешающим, заданным ранее.

Здесь нужно пропустить 22 порт на хост 192.168.88.200

Здесь нам нужно разрешить обращение на хост 10.10.10.100 на порт 80 (www).

На этом создание собственных цепочек закончено. Осталось к ним обратиться.

Создаем группу правил в основной цепочке forward. В ней мы, в зависимости от интерфейсов, будем отправлять пакет в подходящую цепочку:

Для удобства, я поднял эти правила в файрволле повыше, сразу за первыми созданными правилами.

Должно получиться следующее:

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

Обратите внимание, что фильтрацию трафика теперь логично проводить в соответствующей цепочке, что значительно упрощает конфигурирование, особенно в случае большого количества правил.

Общий код файрволла:

Таким образом, мы выполнили базовую настройку Firewall MikroTik и научились работать с собственными цепочками фильтрации трафика.

Технический директор Илья Князев (MTCNA, MTCWE, MTCTCE, MTCRE, MTCINE)