Стена огня. Учимся настраивать файрвол на примере Микротика - «Новости»

Файрвол, как и многое другое в RouterOS, пришел из Linux и представляет собой доработанный iptables. Поэтому многие мануалы по настройке iptables легко можно сконвертировать в формат RouterOS. Файрвол состоит из следующих таблиц:

• Filter — занимается фильтрацией трафика — определяет, пропустить пакет в сеть или отбросить его. Мы будем рассматривать работу только этой таблицы;


• NAT — Network Address Translation. Изменяет проходящие пакеты. Поменять адрес источника или порт назначения — дело именно этой таблицы. В основном она используется для обеспечения доступа в интернет из локалки и обратно. Иногда без NAT невозможно работать в плохо спроектированных сетях, а еще его, бывает, используют в качестве «костыля»;


• Mangle — классифицирует и маркирует трафик и может менять некоторые поля в заголовке (TTL, ToS, DF). Применяется для построения сложных путей трафика (например, когда подключено два провайдера или нужны разные пути трафика для RDP и VoIP);


• Raw — обрабатывает пакеты до их попадания в Connection Tracking. Пригодится для защиты от DoS или при работе с большими объемами трафика.

Таблицы состоят из цепочек. Цепочки в разных таблицах могут отличаться. Чуть позже станет ясно почему. В нашей таблице Filter три цепочки:

• input — трафик к самому роутеру. Обязательное условие попадания в input — адресом назначения пакета должен быть один из адресов роутера, широковещательный адрес сети или широковещательный адрес работающей на роутере службы. Сюда попадает WinBox, SSH, WebFig, ping, VPN и другой трафик, предназначенный роутеру. Полный список можешь посмотреть в вики. В этой цепочке мы должны защищать сам роутер;


• output — трафик от роутера. Ответы на прилетевшее в input или новые пакеты от роутера (пинг, VPN, SSH-сессия с самого роутера). Эта цепочка редко используется, так как часто роутер считается доверенным звеном и пакеты, генерируемые им, по умолчанию легитимны. Но, как показывает история взломов, контроль исходящего трафика может выявить заражение на начальных этапах;


• forward — трафик, проходящий через роутер (когда пакет прилетел в один интерфейс и вылетел с другого или того же самого). Трафик из локалки в интернет, из интернета в локалку, из одного VLAN локалки в другой;


• user chains — пользовательские цепочки. Админ может создавать цепочки правил по своему усмотрению. Это бывает полезно для декомпозиции больших конфигураций. К примеру, можно весь трафик на порты 80 и 443 завернуть в отдельную цепочку WEB и в ней уже делать десятки правил для фильтрации — это визуально упростит настройку, хотя качественно на прохождение трафика не повлияет.

Два важных момента, о которых нужно помнить.

Момент первый. У трафика в forward всегда есть входящий и исходящий интерфейсы — трафик влетел в input, обработался процессом маршрутизации и должен вылететь в output. У входного трафика не может быть исходящего интерфейса — он обработается внутри роутера и никуда дальше не полетит. Также у выходного трафика не может быть входящего интерфейса — этот трафик генерируется самим роутером (это либо новый трафик, либо созданный роутером ответ на трафик, пришедший в input).

Момент второй. У трафика не существует «внешнего» или «внутреннего» интерфейсов. Роутеру плевать, что ты считаешь внешним, — для него есть интерфейс, в который трафик вошел, и интерфейс, с которого трафик уйдет.

Правила образуют цепочки. У каждого правила может быть только одна цепочка. По умолчанию политика у всех цепочек — все разрешено. Правила срабатывают в таблицах в зависимости от их порядка: сначала пакет обработается первым правилом, затем вторым и так далее. Хорошим тоном считается упорядочивать правила внутри таблиц по цепочкам: сначала — пачка правил input, затем — forward, в конце — output.

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

Connection Tracking

Еще одна важная вещь для понимания работы файрвола — механизм определения состояния соединений — Connection Tracking (или просто ConnTrack). У RouterOS есть специальная таблица, в которой хранятся данные о состоянии соединений. Благодаря ей работает NAT и многие другие части файрвола.

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

Для ConnTrack существуют четыре состояния пакетов:

• new — новый пакет, не принадлежащий ни одному из известных потоков. Это может быть первый пакет для коннекта к серверу RDP, или первый пакет в потоке WinBox, или запрос к DNS. Система запоминает Source IP, Source Port, Destination IP, Destination Port и некоторые другие параметры и записывает эти данные в таблицу. Следующий пакет с такими же данными будет относиться к записанному потоку;


• established — пакет, принадлежащий существующему потоку. То есть пакет, у которого Source IP, Source Port, Destination IP, Destination Port подходят под одну из записей таблицы ConnTrack (или обратный пакет).


• related — пакет, порожденный другим потоком. Некоторые протоколы, такие как FTP, SIP, PPTP, используют для работы несколько потоков. Например, управляющие команды FTP ходят по порту TCP 21, но данные передаются с порта TCP 20. При попытке получения или отправки данных на FTP в потоке на порт 21 сервер сообщает: «А сейчас я открою 20-й порт, и ты забирай данные с него», после этого клиент посылает пакет на 20-й порт сервера. Этот пакет будет считаться related, так как он порожден потоком 21-го порта.


• invalid — все, что не относится к перечисленным выше состояниям. Пример: сессия корректно закрылась, но из-за ошибок маршрутизации часть пакетов из середины сессии улетела другим путем. Когда они пришли, их сессия уже закрыта и роутер о них ничего не знает. Они не new и не относятся к существующим соединениям, поэтому считаем их invalid.

Состояние потока не связано с флагами TCP: SYN, ACK, FIN. Для UDP и других stateless-протоколов в таблице ConnTrack тоже содержатся все возможные состояния.

Работа ConnTrack требует ресурсов процессора и при больших объемах трафика может существенно нагрузить CPU. Но ConnTrack нужен не везде, и его можно отключить. Например, у провайдеров на стыке с вышестоящим провайдером стоят роутеры, которые молотят десятки гигабит трафика. На этих роутерах, как правило, нет NAT (прямая маршрутизация), а трафик фильтруется уровнем ниже, чтобы не перегружать и без того нагруженный бордер. То есть в этом случае ни к чему проверять каждый пакет на принадлежность какому-либо потоку.

Нажав кнопку Tracking, можно отключить механизм ConnTrack или подкрутить таймеры. В большинстве случаев тебе не понадобится заходить в эти настройки, но знать о них нужно. Режима ConnTrack три: что такое yes Рё no, думаю, понятно, а в режиме auto ConnTrack выключен до тех пор, пока хотя бы один пакет не попадет в существующие правила таблицы NAT или Filter.