Сам себе РКН или родительский контроль с MikroTik (ч.2)
▍ 1. Firewall Mangle
Рассмотрим имеющиеся возможности по маркировке трафика в контексте родительского контроля. Firewall Mangle подробно изучается на курсе MikroTik Certified Traffic Control Engineer (MTCTCE), тема требует внимательности и сосредоточенности. Разметим проходящий через маршрутизатор трафик:
В текстовом варианте они плохо представляются, поэтому объясним их по скриншоту. Как видно, трафик пользователей размечается на входящий (WAN => LAN) и исходящий (LAN => WAN).
На самом деле, так делать не нужно, ведь достаточно маркировать только исходящий трафик, потому что входящий – это всегда ответ на исходящий, в контексте домашнего устройства. TCP соединение устанавливается по инициативе пользователя, так же как и UDP пакеты к нам идут в ответ на наши запросы.
Итого нам нужно пометить весь исходящий трафик. Сразу будем выделять только детские соединения. Весь трафик разделим на четыре категории: DNS, HTTPS, QUIC и остальные соединения. DNS будем отлавливать в цепочки prerouting, сначала помечая соединения, затем пакеты в этих соединениях:
Чтобы понять, почему это нужно делать именно в prerouting, следует обратиться к схеме прохождения трафика внутри маршрутизатора MikroTik. Например, можно воспользоваться рисунком от этой компании.
Если первичным DNS сервером (/ip dhcp-server network add address=10.0.0.0/24 dns-server=10.0.0.1 gateway=10.0.0.1 netmask=24) будет выступать ваш роутер, то запросы от клиентов пойдут именно к нему, т. е. в Input Interface. Далее уже будем работать с цепочкой Forward. Помечаем все детские соединения. Среди них выделяем соединения HTTPS и QUIC:
Одинаково помечаем пакеты в HTTPS и QUIC соединениях, так как к ним будет применена одинаковая логика обработки:
Для самоконтроля, рекомендую на каждом этапе проводить зеркалирование пакетов и их ручную обработку в Wireshark (как настроить прием трафика, рассмотрено ранее):
Трафик размечен, теперь прикрутим сюда параметры блокировки. В Firewall Mangle во вкладке Advanced имеются следующие интересующие нас возможности: Content и TLS Hosts.
Параметр Content позволяет задать текст, который будет искаться во всех проходящих через маршрутизатор пакетах. В первую очередь, это подойдет для HTTP соединений по понятным причинам. Для HTTPS и QUIC это тоже работает. В качестве примера рассмотрим соединение с одним из сайтов, о которых нельзя говорить вслух:
Видно, что его доменное имя несколько раз проходит в устанавливаемом соединении. Используем его в качестве фильтра, для всех типов размеченных пакетов: DNS и остального трафика Именно поэтому нужна была перемаркеровка пакетов, выполненная ранее в цепочке Forward:
Конечно, такой анализ сильно грузит процессор роутера. Как видно, при срабатывании хотя бы одно из правил ставится запрет на дальнейшую перемаркировку трафика, что разгрузит маршрутизатор (passthrough=no).
Параметр TLS Hosts позволяет задать SNI или Server Name Indication – расширение популярного широко используемого криптографического протокола TLS. Смысл SNI в том, что если в настройках web сервера включена поддержка технологии, то на одном IP адресе может размещаться неограниченное количество сайтов, работающих по HTTPS. Изначально HTTPS можно было использовать только при наличии выделенного IP адреса. Если возникала необходимость разместить на сервере второй сайт, работа с которым была бы возможна по защищенному соединению, нужно было использовать другой белый IP. В современном мире, конечно, на одном сервере хостится огромное количество сайтов.
Рассмотрим как проверить SNI на сервере:
Наличие в выводе строки TLS server extension «server name» (id=0), len=0 будет означать, что SNI используется, и на сервере с одним IP адресом можно разместить любое количество сайтов. Таким образом, можно помечать пакеты на основании параметра TLS Hosts:
Запретим дальнейшую перемаркеровку пакетов (passthrough=no) и поставим эти правила перед правилами с параметром Content. Говорят, таким же образом работает великий китайский firewall, но при этом он умеет лезть еще глубже. Жалко пока нет технических подробностей.
Во вкладке Mangle Extra для решения поставленной задачи нам ничего не подойдет, увы…
Теперь соберем все правила Mangle воедино по следующей схеме:
Пакеты, помеченные как Children Filter, будем дропать в Firewall Filter. Иллюстрация ниже, взятая опять же у этих ребят, объясняет почему это нужно делать именно там, а не в результате, например, роутинга:
Блокирующее правило придется поставить самым первым в цепочке Forward, иначе пакеты, подлежащие фильтрации, перескочат через Firewall:
В результате ограничиваемые соединения будут просто прибиваться, браузер ребенка не сможет загрузить ничего из запрещенного контента.
Упомяну еще про /ip firewall layer7-protocol. Данный фильтр позволяет искать совпадения в первых 2 KB трафика (или 10 первых пакетах) по регулярным выражениям в ICMP, TCP и UDP потоках. Не рекомендую его использовать, слишком вероятностно все там работает и очень сильно загружает процессор роутера.
▍ 2. Заключение
RouterOS обладает различными возможностями по организации родительского контроля. В статьях представлены различные подходы: работа с DNS протоколом, Firewall Filter, Firewall Mangle и Kid-Control. Последний является средством автоматизации от MikroTik и не несет самостоятельных инженерных решений. Что же лучше использовать: работу с DNS, Firewall Filter или Firewall Mangle?
Работа DNS протокола неизбежна связана с кешированием, как на промежуточных серверах, так и на вашем роутере и даже в операционной системе. Нельзя сказать, чтобы это прямо-таки был минус, но нужно учитывать. Чтобы вы, как родитель, не подставили в DNS ответ, но до него дело может даже не дойти. Устройство ребенка извлечет IP адрес запрашиваемого ресурса из своего собственного хранилища. А вот то, что рано или поздно шифрованный DNS прочно войдет в нашу жизнь, нужно понимать уже сейчас. Поэтому в будущем актуальность эксплуатации собственных DNS серверов или коммерческих аналогов, по моему мнению, сохранится. Для данного подхода придется задействовать дополнительные технические ресурсы и, самое главное, поддерживать всю эту инфраструктуру в исправном и актуальном состоянии, что, скорее всего ляжет на ваши сисадминские плечи.
Дропать пакеты по IP адресу в Firewall Filter – достаточно топорное решение. Автоматический резолвинг доменных имен работает хорошо. Однако поле TLS Hosts в Firewall Mangle имеет перед ним сильное преимущество, так как позволяет фильтровать и субдомены. Ведь забивать их все в address-list совсем не хочется. А если на одном IP адресе окажется несколько сайтов, что было достаточно частой проблемой в период известных блокировок Роскомнадзора, то ничего хорошего из подобного подхода не выйдет. Грамотно разметить трафик в Firewall Mangle – это хороший навык, который позволяет решать много инженерных задач, в том числе таких как, приоритезация трафика и балансировка. Поэтому он мне нравится больше других.
Параметр Content может показаться исключительно хорошим решением, однако прогон толстого трафика через не достаточно сильный MikroTik по множеству фильтров может перегрузить центральный процессор роутера. Поэтому это остается последней мерой качественной фильтрации трафика.
В статье не рассмотрены подходы к блокировкам различных VPN, которые позволят перепрыгнуть через все описанные фильтры, потому как, считаю, это не относится к родительскому контролю.
Получается, что все описанные технические возможности хороши с определенными оговорками. Выбираем, что нравится больше и используем, а лучше все сразу. И потолще и побольше. Если вы действительно хотите организовать родительский контроль за трафиком ребенка. Но это уже не тема нашей статьи.
Mangle
Mangle is a kind of ‘marker’ that marks packets for future processing with special marks. Many other facilities in RouterOS make use of these marks, e.g. queue trees, NAT, routing. They identify a packet based on its mark and process it accordingly. The mangle marks exist only within the router, they are not transmitted across the network.
Additionally, the mangle facility is used to modify some fields in the IP header, like TOS (DSCP) and TTL fields.
Firewall mangle rules consist of five predefined chains that cannot be deleted:
Properties
For example, if a router receives an IPsec encapsulated Gre packet, then rule ipsec-policy=in,ipsec will match Gre packet, but a rule ipsec-policy=in,none will match the ESP packet.
Sets a new MSS for a packet.
Matches source address type:
Stats
To show additional read-only properties:
| Property | Description |
|---|---|
| bytes (integer) | The total amount of bytes matched by the rule |
| packets (integer) | The total amount of packets matched by the rule |
To print out stats:
Configuration example
Change MSS
It is a known fact that VPN links have a smaller packet size due to encapsulation overhead. A large packet with MSS that exceeds the MSS of the VPN link should be fragmented prior to sending it via that kind of connection. However, if the packet has a Don’t Fragment flag set, it cannot be fragmented and should be discarded. On links that have broken path MTU discovery (PMTUD), it may lead to a number of problems, including problems with FTP and HTTP data transfer and e-mail services.
In the case of a link with broken PMTUD, a decrease of the MSS of the packets coming through the VPN link resolves the problem. The following example demonstrates how to decrease the MSS value via mangle:
Стена огня. Учимся настраивать файрвол на примере MikroTik
Содержание статьи
Файрвол, как и многое другое в RouterOS, пришел из Linux и представляет собой доработанный iptables. Поэтому многие мануалы по настройке iptables легко можно сконвертировать в формат RouterOS. Файрвол состоит из следующих таблиц:
Таблицы состоят из цепочек. Цепочки в разных таблицах могут отличаться. Чуть позже станет ясно почему. В нашей таблице Filter три цепочки:
Два важных момента, о которых нужно помнить.
Момент первый. У трафика в forward всегда есть входящий и исходящий интерфейсы — трафик влетел в input, обработался процессом маршрутизации и должен вылететь в output. У входного трафика не может быть исходящего интерфейса — он обработается внутри роутера и никуда дальше не полетит. Также у выходного трафика не может быть входящего интерфейса — этот трафик генерируется самим роутером (это либо новый трафик, либо созданный роутером ответ на трафик, пришедший в input).
Момент второй. У трафика не существует «внешнего» или «внутреннего» интерфейсов. Роутеру плевать, что ты считаешь внешним, — для него есть интерфейс, в который трафик вошел, и интерфейс, с которого трафик уйдет.
Правила образуют цепочки. У каждого правила может быть только одна цепочка. По умолчанию политика у всех цепочек — все разрешено. Правила срабатывают в таблицах в зависимости от их порядка: сначала пакет обработается первым правилом, затем вторым и так далее. Хорошим тоном считается упорядочивать правила внутри таблиц по цепочкам: сначала — пачка правил input, затем — forward, в конце — output.
Трафик будет проходить по правилам только в пределах своей цепочки. И если сначала идет input, потом forward, затем снова input, то трафик input все равно никогда не попадет в forward, то есть такое расположение правил не повлияет на прохождение трафика, а только запутает админа. В пределах одной таблицы пакет не перепрыгнет из одной цепочки в другую, пока админ это явно не укажет.
Xakep #253. Сканеры уязвимостей
Connection Tracking
Еще одна важная вещь для понимания работы файрвола — механизм определения состояния соединений — Connection Tracking (или просто ConnTrack). У RouterOS есть специальная таблица, в которой хранятся данные о состоянии соединений. Благодаря ей работает NAT и многие другие части файрвола.
Механизмы ConnTrack проверяют, принадлежит ли пришедший на роутер пакет какому-либо из потоков, чтобы применить к нему политики всего потока или как-то упорядочить пакеты в пределах одного или нескольких потоков (например, для нарезки скорости).
Для ConnTrack существуют четыре состояния пакетов:
Состояние потока не связано с флагами TCP: SYN, ACK, FIN. Для UDP и других stateless-протоколов в таблице ConnTrack тоже содержатся все возможные состояния.
Работа ConnTrack требует ресурсов процессора и при больших объемах трафика может существенно нагрузить CPU. Но ConnTrack нужен не везде, и его можно отключить. Например, у провайдеров на стыке с вышестоящим провайдером стоят роутеры, которые молотят десятки гигабит трафика. На этих роутерах, как правило, нет NAT (прямая маршрутизация), а трафик фильтруется уровнем ниже, чтобы не перегружать и без того нагруженный бордер. То есть в этом случае ни к чему проверять каждый пакет на принадлежность какому-либо потоку.
WARNING
Выключенный ConnTrack ломает NAT и фичи файрвола, основанные на трекинге потоков: connection-bytes, connection-mark, connection-type, connection-state, connection-limit, connection-rate, layer7-protocol, new-connection-mark, tarpit.
Рекомендации по настройке
Переходим к практике настройки. В этой статье я расскажу о таблице Filter — той, что занимается фильтрацией трафика. Как мы выяснили чуть выше, за трафик к самому роутеру отвечает цепочка input, а за трафик, который проходит через роутер, — forward. Займемся защитой самого роутера.
Первое и самое главное, что нужно помнить при работе с файрволом, было описано еще в утерянной главе «Слова о полку Игореве»: «удаленная настройка файрвола — к дальней дороге». Так что уважай предков — чти их заветы и используй Safe Mode.
Работает этот режим так: ты нажимаешь кнопку Safe Mode в интерфейсе, и она остается нажатой. Дальше ты делаешь все, что собирался, но применятся эти изменения, только когда ты снова кликнешь по кнопке. Если они приведут к обрыву взаимодействия роутера и конфигуратора WinBox (например, если ты зафильтровал свои же пакеты или отключил интерфейс), то роутер вернется в состояние, которое было до входа в Safe Mode.
Запоминается только 100 действий, но этого хватит на большинство случаев. Перезагрузки не будет — откат мгновенный. Из консоли этот режим активируется по Ctrl-X.
Есть два подхода к настройке файрвола:
Ни один из них нельзя назвать однозначно правильным. Я приверженец второго подхода, но в незнакомых сетях применяю первый.
Чтобы разрешить нужный трафик, нужно определиться с этим самым трафиком. В случае с input это сделать довольно просто. Вот что нужно для корректной работы роутера.
Определились? Открываем нужное и закрываем все остальное.
Файрвол работает по принципу «если [условие], то [действие]». Если выполняются условия, заданные во вкладках General, Advanced, Extra, то к пакету применяется действие из вкладки Action. На сегодня нам будет достаточно условий src/dst address, protocol, src/dst port, in/out interface, connection-state. Их значения понятны по названию, но если вдруг неясно — вперед, читать про основы TCP/IP. Самые распространенные действия: accept — разрешено, drop — запрещено (пакет просто уничтожится), reject — запрещено, но отправитель получит информацию, что пакет был уничтожен по причине, указанной в reject-with.
Каждое правило на пути пакета отнимает процессорное время. И если в небольших сетях это некритично, то при серьезных объемах трафика нужно учитывать этот момент. Рассмотрим на примере.
В этом случае при попытке подключиться к роутеру по SSH с адреса 10.11.0.11 файрвол будет шесть раз обращаться к CPU с вопросом, пропустить ли этот трафик. Выглядит это примерно так: «8291 — не наш порт — пропускаем дальше. 10.0.0.0/24 — не наша подсеть, пропускаем дальше. То же для 10.10.0.0/24, и только шестое правило подходит». На шестом шаге файрвол поймет, что трафик легитимный и его можно пропустить.
Пакеты FTP и весь другой неразрешенный трафик будет дергать CPU семь раз — первые шесть и последний дроп. И это в выдуманном примере из семи правил. В реальной жизни правил на порядок или два больше.
Первое, что мы можем сделать, — объединить два порта в одном правиле:
Немного снизили нагрузку. Но осталось три идентичных правила с разницей лишь в адресах. С помощью списка адресов (Address List) мы можем объединить их в одно.
Address List — фича RouterOS, которая позволяет объединять IP-адреса, подсети и DNS-имена в одну запись.
Создаем три записи в одном Address List.
И применяем его к нашему правилу.
Так из семи правил мы получили два и избавились от лишней нагрузки. По аналогии со списками адресов работают списки интерфейсов (я рассматривал их в предыдущей статье — «Защищаем MikroTik»): объединяем в один interface list интерфейсы разных провайдеров и вешаем правила уже не на сами интерфейсы, а на списки. Так мы не только уменьшим нагрузку, но и упростим жизнь админа: чем меньше правил, тем удобнее обслуживать систему.
Еще один способ облегчить работу файрволу — использовать ConnTrack. Понятно, что established-пакетов будет намного больше, чем new, related и invalid, вместе взятых. А раз мы разрешили первый пакет из потока, то все остальные пакеты в этом потоке можно считать легитимными. Поэтому просто создаем правило «разрешить established» и помещаем его в самом верху.
Выбирай нужные тебе протоколы и порты, создай соответствующие списки адресов и интерфейсов. Открой все, что нужно, и поставь последним правилом drop all. На этом основную настройку цепочки input можно считать завершенной.
К слову, по умолчанию файрвол снабжен достаточно крепкой настройкой — ее вполне хватит, чтобы нормально работала сеть практически любых размеров. Но всегда есть какие-то особенности и любой конфиг можно улучшить с учетом своих условий.
Для примера конфигурации можешь взять мой шаблон.
Траблшутинг
Когда файрвол не работает или работает не так, как подразумевалось при настройке, виноват админ. Магии не бывает. Первое, на что стоит обратить внимание при траблшутинге, — счетчики пакетов. Если счетчик не увеличивается, значит, трафик в него не попадает. А если трафик не попадает, значит, либо этого трафика просто нет, либо он был обработан стоящим выше правилом.
Ты же помнишь, что правила файрвола работают по принципу «кто первый встал — того и тапки»? Если пакет попал под действие правила, то дальше он уже не пойдет. Значит, нужно искать проблему выше. Просто копируем наше правило, action ставим accept (для траблшутинга не делай дроп — так при проверке можно сломать себе доступ или нарушить работу сети) и постепенно двигаем его наверх до первого увеличения счетчиков в этом правиле. Если через это правило уже проходил трафик, то счетчики будут ненулевые и можно пропустить нужные нам пакеты, — просто сбрось счетчики в этом правиле или во всех кнопками Reset Counters.
Предположим, мы нашли правило, в которое попадает наш трафик, а попадать не должен. Нужно понять, почему так происходит. В этом нам поможет опция Log. Во вкладке Action ставим галочку Log (можно написать префикс для правила, чтобы было проще отлавливать его в логах) и смотрим логи, где написаны все характеристики пакетов, попадающих под правило. Среди характеристик: цепочка, входящий и исходящий интерфейсы, адреса и порты источника и получателя, протокол, флаги, размер пакета, действия NAT.
Если даже в самом верху в правиле не будут увеличиваться счетчики, убирай правила из условия по одному. Начинай с интерфейсов — админы часто путаются в своих представлениях о том, откуда или куда должен идти трафик (например, при коннекте к провайдеру через PPPoE или в туннелях между филиалами или сложном роутинге). Счетчики пошли? Включаем лог и смотрим интерфейсы и другие параметры.
Если и это не помогает — пришло время тяжелой артиллерии. Идем в Tools → Torch и изучаем трафик на роутере. Может, ожидаемого трафика вовсе нет. Еще один крутой инструмент — аналог tcpdump — Tools → Packet Sniffer. Разбор работы этих инструментов тянет на отдельную статью (если она тебе интересна — сообщи об этом в комментариях к статье).
Чтобы упростить траблшутинг, можно использовать функцию комментирования. Если из-за комментов окно становится слишком большим и это мешает смотреть на правила, воспользуйся инлайновыми комментариями (Inline Comments). Так комменты встанут с правилом в одну строку и в окно будет умещаться больше правил.
Также рекомендую распределять правила по порядку, следуя какой-то определенной логике. И старайся ее поддерживать на всех роутерах.
Итоги
В этой статье приведены только основы настройки файрвола и главные методы диагностики. Кроме RouterOS, эти принципы применимы и для Linux. В следующей статье разберем более сложные правила, которые позволяют защититься от не самых простых атак, и разберем цепочку Forward, а также создадим свои цепочки.
Mangle mikrotik что это
Кроме того, функция mangle используется для изменения некоторых полей в заголовке IP, таких как поля TOS (DSCP) и TTL.
Свойства
action
по умолчанию: accept)
address-list
( строка ; По умолчанию:)
address-list-timeout
( строка ; По умолчанию:)
( целое-целое ; по умолчанию:)
( целое число, сетевая маска ;
( целое число 0..4294967295 ;
tftp ; по умолчанию 🙂
content
dst-address-type
dst-limit
dst-port
( целое [-integer]: 0..65535 ;
( да | нет ; по умолчанию:)
icmp-options
in-bridge-port
ipsec-policy
( in | out, ipsec | none;
Например, если маршрутизатор получает пакет Gre, инкапсулированный в Ipsec, то правило ipsec-policy=in,ipsecбудет соответствовать пакету Gre, но правило ipsec-policy=in,noneбудет соответствовать пакету ESP.
ipv4-options
маршрут без записи |
предупреждение об отсутствии маршрутизатора |
маршрутизация без источника |
без отметки времени |
нет | маршрут записи | предупреждение маршрутизатора |
строгая маршрутизация от источника |
Layer7-protocol
limit
( строка ; По умолчанию:)
new-dscp
new-mss
( целое ; по умолчанию 🙂
( строка ; По умолчанию:)
new-priority
new-routing-mark
( строка ; По умолчанию:)
new-ttl
out-bridge-port
( целое [-integer]: 0..65535 ;
( да | нет ; по умолчанию: да )
per-connection-classifier ( ValuesToHash: знаменатель /
остаток ; по умолчанию 🙂
port
( integer [-integer]: 0..65535 ; по умолчанию 🙂
( имя или идентификатор протокола ; по умолчанию: tcp )
( строка ; По умолчанию:)
src-ardess
( IP / маска сети, диапазон IP ;
src-address-list
src-address-type
( unicast | local | broadcast | multicast ; По умолчанию:)
Соответствует типу адреса источника:
src-port
( integer [-integer]: 0..65535 ; по умолчанию 🙂
src-mac-address
( MAC-адрес ; по умолчанию:)
tcp-flags
( ack | cwr | ece | fin | psh | rst | syn | urg ; по умолчанию 🙂
tcp-mss
( integer [-integer]: 0..65535 ; по умолчанию 🙂
time
( время-время, сб | пт | чт | ср | вт | пн | вс ; по умолчанию:)
