[Mikrotik] Шаманизм в RouterOS или как я сделал нормально закрытый Firewall в RAW
С чего бы начать. RAW по сути своей сильно урезан по функционалу, из-за того что он идёт до Conntrack и теряет много полезных ништяков, но это не критично.
Небольшое предисловие
Я не претендую на 100% достоверность, по той простой причине, что не являюсь сертифицированным специалистом Mikrotik. И не имею никаких сертификатов, дипломов. Я лишь монтажник сетей, и пишу сюда свой опыт с этими устройствами.
В чем проблема стандартных (QuickSet) правил Filter?
При стандартных параметрах маршрутизатора, мы видим что пакеты приходящие через интерфейс WAN проходят до цепочки Input. То есть маршрутизатор их обрабатывает полноценно через Routing Decision, заносит их в Conntrack с соответствующими данными, и в конце этот пакет либо встречает свою погибель в лице стандартного правила Drop, либо пройдет как новое подключение с локальным процессом, если порт роутера открыт. Либо в уйдет в Forward цепочку, если настроен проброс портов через сетевую трансляцию адресов, но это уже скорее исключение.
Посмотрите на схему цепочек RouterOS:
Задача:
Разгрузить маршрутизатор для работы хотя бы с локальной сетью, если из внешней сети гадят большим количеством пустого трафика. Закрыть полностью все порты управления RouterOS для WAN одним правилом и попытаться если не полностью предотвратить, то хотя бы ослабить переполнение Conntrack.
Условия:
Что потребуется?
Как реализовать и куда тыкать?
Потребуется создать 3 правила NAT для TCP, UDP и ICMP подключений локальной сети, чтобы исходящий трафик машин из LAN менял свои SRC порты на наш диапазон, который мы укажем. Рекомендуется выбирать диапазон и количество портов исходя из количества клиентов, и того, сколько подключений делается в самое пиковое время, (не обязательно, но желательно). Можно взять за пример
Недостаток такого метода: Если клиентов к роутеру подключено слишком много, то в таком случае, реализовать эту систему правил необходимо без NAT. Но должны быть заблокированы все порты служб маршрутизатора из WAN, что не является нашей задачей.
Разумеется, от меня существует две версии. При динамическом адресе, и при статическом.
Сначала рассмотрим правила NAT при динамическом адресе.
Диапазон 12000-18000 указан как пример собственной конфигурации;
Masquerade NAT Rule
Правила в текстовом режиме для терминала:
/ip firewall nat
add action=masquerade chain=srcnat comment=»SRC RAW NAT TCP» out-interface-list=WAN protocol=tcp to-ports=42000-50000
add action=masquerade chain=srcnat comment=»SRC RAW NAT UDP»
out-interface-list=WAN protocol=udp to-ports=42000-50000
add action=masquerade chain=srcnat comment=»SRC RAW NAT ICMP»
out-interface-list=WAN protocol=icmp
Как вы можете заметить, используется Masquerade. Это сделано для совместимости с динамической выдачей адресов от провайдера (DHCP) и как более совместимый/универсальный вариант. Однако, он же является менее безопасным, поскольку в сеть провайдера могут улететь ваши локальные IP адреса при внезапном разрыве, но беспокоиться не о чем. Это явление крайне редкое.
Если у вас статический IP адрес, есть другой вариант. Он чуть безопаснее, и надежнее, поскольку при внезапном разрыве локальные адреса не улетят в публичную сеть и немного разгрузится маршрутизатор.
Правила в текстовом режиме для терминала:
/ip firewall nat add action=src-nat chain=srcnat comment=»SRC NAT TCP RAW»
out-interface-list=WAN protocol=tcp to-addresses=INSERTYOURIP to-ports=
42000-50000
add action=src-nat chain=srcnat comment=»SRC NAT UDP RAW»
out-interface-list=WAN protocol=udp to-addresses=INSERTYOURIP to-ports=
42000-50000
add action=src-nat chain=srcnat comment=»SRC NAT ICMP RAW»
out-interface-list=WAN protocol=icmp to-addresses=INSERTYOURIP
Не забудьте отредактировать «INSERTYOURIP», впишите туда свой статический адрес, чтобы правило начало работать 🙂
Firewall RAW, великий и ужасный
Здесь нам необходимо почесать репу, сделать 5 базовых правил RAW. Оперируем мы всегда цепочкой Prerouting, и никогда Output. Это сделано для того, чтобы работали исходящие подключения от системы роутера к службам обновлений, внешним DNS.
/ip firewall raw add action=drop chain=prerouting comment= «Security Rule: Block IP Fragment» fragment=yes
IP Fragment Delete Rule
Текстовый формат правила:
/ip firewall raw
add action=accept chain=prerouting comment=»Src NAT TCP» dst-port=12000-18000 in-interface-list=WAN limit=200,200:packet protocol=tcp
add action=accept chain=prerouting comment=»Src NAT UDP» dst-port=12000-18000 in-interface-list=WAN limit=200,200:packet protocol=udp
add action=accept chain=prerouting comment=»Src NAT: RAW ICMP» limit=
10,10:packet protocol=icmp
ICMP принимаем как есть, ограничение ставим на 10 пакетов в секунду по стандарту.
Accept connections in our NAT ports
Block all Rule
Достоинства данной системы правил:
Высокая производительность Drop-а пустого трафика. (Да, она может спасти от DDoS с IP Spoofing-ом, если службы ваших LAN-машин экранированы через NAT и ограничены в RAW, поскольку учтены таймеры соединений Conntrack внешних служб для защиты последнего).
Гибкость, вы спокойно можете опубликовать ваши службы.
Вы можете сделать подобие Conntrack через Address List и Mangle, если потребуется обслуживать клиентов вашей службы в первую очередь, и устроить мониторинг IP подключенных клиентов к вашим службам для диагностики.
Она не влияет на LAN подключения, поскольку все правила проработаны только для WAN.
Полностью закрывает все порты маршрутизатора извне, при верном выборе диапазона SRC портов. Это происходит поскольку пакеты не доходят до Input цепочки без соответствующего разрешающего правила, а даже если и доходят, то отлавливаются стандартным правилом Drop all from WAN. Либо принимаются, исходя из вашей конфигурации.
Таким образом мы исключаем атаки на DNS порт, порт SSH, порты FTP, Bandwitch Server, а также атаки на Winbox-порты одним правилом.
Также комплекс правил не исключает и не мешает технике ICMP Port Knocking для доступа извне.
Есть возможность прикрутить систему, которая обнаруживает IP сканеры, хецкеров и удалять такие пакеты не в Input цепочке, а в Prerounting, выполняя тем самым разгрузку CPU.
Ограничение количества пользовательских портов.
Возможно не совместим с VPN. (Поправьте, если это не так).
Требуется более детальная настройка портов, которые смотрят наружу. Требуется добавлять в Raw дополнительные правила с ограничениями.
Mikrotik firewall raw что это
Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов
Фильтрация входящего трафика FILTER и RAW
Правила форума
Как правильно оформить вопрос.
Прежде чем начать настройку роутера, представьте, как это работает. Попробуйте почитать статьи об устройстве интернет-сетей. Убедитесь, что всё, что Вы задумали выполнимо вообще и на данном оборудовании в частности.
Не нужно изначально строить Наполеоновских планов. Попробуйте настроить простейшую конфигурацию, а усложнения добавлять в случае успеха постепенно.
Пожалуйста, не игнорируйте правила русского языка. Отсутствие знаков препинания и неграмотность автора топика для многих гуру достаточный повод проигнорировать топик вообще.
1. Назовите технологию подключения (динамический DHCP, L2TP, PPTP или что-то иное)
2. Изучите темку «Действия до настройки роутера».
viewtopic.php?f=15&t=2083
3. Настройте согласно выбранного Вами мануала
4. Дочитайте мануал до конца и без пропусков, в 70% случаев люди просто не до конца читают статью и пропускают важные моменты.
5. Если не получается, в Winbox открываем терминал и вбиваем там /export hide-sensitive. Результат в топик под кат, интимные подробности типа личных IP изменить на другие, пароль забить звездочками.
6. Нарисуйте Вашу сеть, рисунок (схему) сюда. На словах может быть одно, в действительности другое.
Добрый день, специалисты
/ip firewall filter
add action=accept chain=input comment=\
«allow related & esteblished connections» connection-state=\
established,related
add action=accept chain=input comment=»alllow eoip to twonky» disabled=yes \
dst-address=172.16.1.1 protocol=gre src-address=172.16.1.0/24
add action=drop chain=input comment=»drop black list connections» \
connection-state=»» disabled=yes in-interface-list=WAN src-address-list=\
blacklist
add action=drop chain=input comment=»drop invalid connections» \
connection-state=invalid
add action=accept chain=input comment=»allow local connections» \
in-interface-list=!WAN log-prefix=allow
add action=drop chain=input comment=»drop everything else» log-prefix=\
«firewall input drop:»
add action=accept chain=forward comment=\
«allow related & esteblished connections» connection-state=\
established,related
add action=drop chain=forward comment=»drop invalid connections» \
connection-state=invalid
add action=accept chain=forward comment=»allow from local to internet» \
in-interface-list=!WAN out-interface-list=WAN src-address-list=\
«allow to internet»
add action=accept chain=forward comment=»allow echo reply» icmp-options=8:0 \
in-interface-list=!WAN protocol=icmp
add action=drop chain=forward comment=»drop everything else» log=yes \
log-prefix=»firewall forward drop:»
add action=accept chain=output comment=»accept everything»
/ip firewall nat
add action=masquerade chain=srcnat comment=»allow local to internet» \
out-interface-list=WAN src-address-list=»allow to internet»
/ip firewall raw
add action=drop chain=prerouting comment=»\?\?\? drop black list connections» \
disabled=yes in-interface-list=WAN src-address-list=blacklist
НО Вы свои правила задаёте слишком обобщённо, и вот что получается (я от себя говорю и слегка обобщённо и поверхностно).
Рассмотрим пример:
компьютер запросил скажем сайт ya.ru и пройдя всё, на роутере формируется исходящее
соединение, от внешнего адреса и скажем порт исходящий 55384, и данные ушли на Яндекс, с Яндекса ответ
прилетает, вот тут, Ваши правила слишком общие, прилетает ответ с неизвестного IP (у яндекса их тьма) и с порта
тоже фанарного, но в пакете есть заголовок (в котором указан Ваш реальный айпи и порт 55384).
И повторюсь, в этом моменте Вы и режете и формируете отказ роутера. То есть формально роутер роет яму сам себе,
и со временем проваливается в ней (набивается много ответов которые попадают в ловушку Вашу).
Если бы можно было так просто закрывать всё, так бы давно делали.
Поэтому в RAW надо описать условия более конкретные, что откуда или хотя бы куда, на какой протокол,
и на какой порт, и уже получив атаки по портам этим, это всё сразу дропать.
А вот уже в таблице Filter Rules там можно более тактично и правильно гибко резать/запрещать.
Стена огня. Учимся настраивать файрвол на примере 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, а также создадим свои цепочки.
Предисловие
Для кого эта статья
Если вы умеете работать с iptables, то дерзайте и настраивайте firewall, для вас в этой статье не будет ничего нового (ну разве что в таблице NAT используются цепочки с другими именами). Если вы впервые видите firewall в RouterOS и хотите получить готовый скрипт для конфигурации, то вы его здесь не найдете. Материал нацелен на тех, кто хочет получить базовое представление о том как работает firewall и что происходит с ip пакетом на разных этапах его обработки. Более глубокое понимание прейдет с опытом и решением повседневных и необычных задач с использованием пакетного фильтра.
Теоретическая часть
Что такое Layer3 Firewall
Предположим, что у вас есть роутер с выходом в интернет и двумя bridge интерфейсами: bridge-lan(ether2-ether5) и bridge-dmz(ether6-ether10).
В пределах Bridge интерфейса устройства самостоятельно находят соседей из свой подсети и обмениваются пакетами, роутер выполняет функции свича и не отслеживает такой трафик на сетевом уровне (конечно можно принудительно заставить его это делать, но про Layer2 Firewall поговорим в другой раз).
При необходимости связаться с устройством подключенного к другому bridge интерфейсу или находящемуся в глобальной сети устройства передают пакеты маршрутизатору, который определяет маршрут следования и обрабатывает их на сетевом(Layer 3) уровне.
Packet Flow Diagram
Полный путь трафика описан в Packet Flow Diagram, есть несколько официальных(v5, v6) версий, их необходимо знать и использовать в повседневной работе, но для понимания работы пакетного фильтра они перегружены, поэтому я буду объяснять на облегченном варианте.
Особенности терминологии
Изучая packet flow для iptables, можно встретить описания через «цепочки в таблицах» либо «таблицы в цепочках». На схеме представлены таблицы в цепочках, при добавлении правил в firewall все будет наоборот.
Но на самом деле пакет перемещается между блоками [цепочка+таблицы], например если вы сделайте accept в блоке [prerouting+mangle] транзитный пакет все-равно будет обработан в [forward+mangle]. Это важно помнить в сложных конфигурациях с pbr и queues.
В документации iptables есть более точные определения, но простыми словами:
Цепочки отвечают за место обработки пакета и последовательность правил.
Таблицы определяют действия, которые можно произвести над пакетом.
Базовые варианты следования пакета
Транзитный
Входящий
Исходящий
Connection Tracker
Для начала необходимо понять, что представляет из себя stateful и stateless пакетные фильтры.
Пример. Компьютер 192.168.100.10 открывает tcp соединение с сервером 192.0.2.10. На стороне клиента используется динамический порт 49149, на стороне сервера 80. Еще до получения контента клиент и сервер должны обменяться пакетами для установки tcp сессии.
В stateless потребуется открыть трафик из локальной сети в интернет и из интернета в локальную сеть (как минимум для диапазона динамических портов). Что в целом является дырой.
В stateful маршрутизатор анализирует пакеты и получив tcp syn от 192.168.100.10:49149 для 192.0.2.10:80 считает это началом нового (new) соединения. Все дальнейшие пакеты (в любом направлении) между 192.168.100.10:49149 и 192.0.2.10:80 будут считаться частью установленного (established) соединения, до закрытия tcp сессии или истечения таймеров.
Для UDP/ICMP и других видов трафика, где нельзя четко выделить начало и конец соединения, новым пакетом является первый, остальные считаются частью установленного соединения и обновляют таймеры, маршрутизатор забывает про подобные соединения по истечению таймеров.
Connection tracker делит пакеты на несколько типов:
Конфигурация Connection tracker
enabled=yes — включен.
enabled=no — отключен.
enabed=auto — отключен, пока в firewall не появится правило использующее возможности conntrack. Используется по умолчанию.
Остальные параметры являются различными таймерами и обычно не требуют тюнинга.
Администратор может просматривать и удалять соединения, например так выглядит соединение с NAT:
Использование conntrack сказывается на производительности и потреблении ресурсов (особенно при большом числе соединений), но отключить его в большинстве конфигураций не получится, т.к. у вас останется stateless firewall без NAT.
Список функций зависящих от connection tracker:
Time To Live — поле в заголовке IP пакета определяющее число маршрутизаторов через которые может пройти пакет прежде чем будет уничтожен, защищает от бесконечной пересылки пакетов при петлях маршрутизации.
При пересылке (forwarding) роутер уменьшает значение TTL на 1 отбрасывает, если TTL=0. При этом пакет с TTL=1 попадет локальному процессу роутера.
Некторые операторы связи используют трюки с TTL для пресечения использования роутеров. Все эти ограничения прекрасно обходятся увеличением значения ttl в таблице mangle.
Network Address Translation — технология изменения адресов в заголовке ip пакета. Как и в linux, NAT является частью пакетного фильтра. NAT работает на основе connection tracker.
Изначально NAT был разработан как быстрое решение проблемы исчерпания IPv4 адресов, для локальных сетей было предложено использовать подсеть из диапазонов: 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16 и транслировать их в один(или несколько) маршрутизируемых адресов. На самом деле есть еще несколько служебных подсетей, которые можно использовать в частных сетях и роутеру в принципе все-равно что и как NAT’ить, но рекомендуется следовать стандартам.
NAT обрабатывает только: tcp, udp, icmp и некоторых мультипротоколов из [IP]->[Firewall]->[Service Port]. Обрабатывается только первый (connection-state=new) пакет в соединении, оставшиеся обрабатываются автоматически без участия таблицы NAT. Это можно отследить по изменению счетчиков в правилах.
В заголовке пакета присутствует Source и Destenation address, соответственно и NAT делится на Source и Destenation NAT.
Source NAT — подмена адреса отправителя, присутствует на подавляющем большинстве домашних и корпоративных роутеров в мире.
Позволяет множеству устройств с «серыми» адресами в локальной сети общаться с интернетом используя один (или несколько) реальных адресов.
Возвращаясь к Packet Flow смотрим, что SRC-NAT находится в Postrouting, после принятия решения о маршрутизации пакета.
Ответный пакет проходит неявный DST-NAT в котором адрес получателя меняется на локальный.
Destenation NAT — подмена адреса получателя.
Применяется при необходимости переслать пакет на другой адрес, обычно используется для «проброса портов» из внешней сети в локальную.
По Packet Flow работа DST-NAT происходит до принятия решения о маршрутизации в Prerouting, присутствует неявный SRC-NAT для ответного трафика.
NAT является довольно мощным инструментом управления трафиком, но применять его стоит в последнюю очередь (когда остальные инструменты не могут помочь).
Цепочки(chains) базовые и пользовательские
Цепочки состоят из правил и форсируют логику обработки пакета.
Есть несколько базовых цепочек, отображенных на packet flow:
Prerouting(dstnat) — обработка пакета до принятия решения о маршрутизации
Input — обработка пакетов предназначеных локальным процессам маршрутизатора
Output — обработка пакетов пакетов сгенерированных локальными процессами маршрутизатора
Forward — Обработка проходящего трафика
Postrouting(srcnat) — Обработка трафика готового к передаче на интерфейс
Все как в iptables, но цепочки в nat переименованы. С чем это связано (скорее всего с hotspot или аппаратной разгрузкой nat) мне неизвестно, но в корне ничего не меняет.
Пакет проходит правила в цепочке последовательно, если он подходим по всем условиям, то к пакету применяется действие. Если действие является терминирующим и не отбрасывает пакет, то он передается в следующий блок packet flow.
У всех цепочек базовых есть действие по умолчанию (если пакет не подошел ни под одно из правил) — accept.
Пользовательские цепочки необходимы для уменьшения количества правил которые проходит каждый пакет и для построения сложных правил обработки трафика. У всех пользовательских цепочек есть действие по умолчанию — return.
В пределах таблицы можно пересылать правила из нескольких различных базовых (и пользовательских) цепочек в пользовательскую, но вернется пакет в ту цепочку из которой пришел.
Условия в правилах
Цепочки состоят из правил, каждое правило состоит из условий и действия. Условий достаточно много, но далеко не все вы будете использовать в реальных конфигурациях. Большинству условий можно поставить префикс «не» (знак «!»). Для совпадением с правилом, пакет должен подходить под все указанные условия.
Некоторые из условий:
| Условие | Описание |
|---|---|
| src-address | Адрес источника |
| dst-address | Адрес получателя |
| src-address-list | Адрес источника присутствует в списке |
| dst-address-list | Адрес получателя присутствует в списке |
| protocol | Протокол транспортного уровня |
| src-port | Порт источника |
| dst-port | Порт получателя |
| port | Порт источника или получателя |
| in-interface | Интерфес на который пришел пакет |
| out-interface | Интерфейс с которого пакет будет отправлен в сеть |
| in-interface-list | Интерфес на который пришел пакет присутствует в списке |
| out-interface-list | Интерфейс с которого пакет будет отправлен в сеть присутствует в списке |
| layer7-protocol | Анализ содержимого первых 10 пакетов в соединениий |
| content | Поиск заданной строки в пакете |
| tls-host | Поиск хоста в заголовке tls |
| ipsec-policy | Проверить подпадает пакет под политику ipsec или нет |
| packet-size | размер пакета в байтах |
| src-mac-address | mac адрес источника пакета |
| connection-mark | Метка соединения |
| packet-mark | Метка пакета |
| routing-mark | Маршрутная метка пакета |
| connection-state | Состояние пакета в соединении |
| tcp-flags | Флаги tcp пакета |
| icmp-options | Опции icmp пакета |
| random | Правило срабатывает(при совпадении остальных условий) с заданной вероятностью |
| time | Можно указать рабочее время правила, к сожалению без конктеризации даты |
| ttl | Значение поля ttl в пакете |
| dscp | Значение поля DSCP(ToS) в пакете |
| —//— | —//— |
| place-before | Консольная опция(не условие), позволяет добавить правило перед указанным |
| disabled | Консольная опция(не условие), позволяет отключить правило |
Примечания
В качестве src.(dst.) address можно указывать: одиночный ip, диапазон адресов через дефис, либо подсеть.
Списки адресов необходимы для объединения под одним именем нескольких несвязанных ip. В отличии от ipset в netfilter, записи в списках MikroTik могут удаляться через заданный промежуток времени. Просмотреть списки и внести изменения можно в [IP]->[Firewall]->[Address Lists].
В качестве номера порта(port, src-port, dst-port) можно указывать одиночный порт, несколько портов через запятую, либо диапазон портов через дефис.
На последнем MUM в МСК была неплохая презентация на тему влияния различных условий на скорость обработки пакетов (там же вы узнаете как использовать таблицу raw для снижения нагрузки на роутер), кому интересно: запись и презентация.
Действия в таблицах
Набор доступных действий над пакетом, зависит от таблицы в которой он обрабатывается.
Filter — таблица фильтрации трафика, одно из двух мест, где можно отбросить пакет.
NAT — таблица модификации ip адресов и портов(tpc, udp) в заголовке ip пакета.
Mangle — таблица для модификации других полей ip пакета и установки различных меток.
Существует три типа внутренних меток пакетов: connection, packet, route. Сетки существуют только в пределах роутера и не уходят в сеть. Пакет может иметь по одной метке каждого типа, при последовательном прохождении нескольких mark-* правил метки перезаписываются.
Маршрутные метки можно ставить только в цепочках prerouting и output, остальные в любых цепочках.
Хорошей практикой считается сначала маркировать соединение (connection), а потом пакет (packet) либо маршрут (route). Проверка наличия метки происходит быстрее чем полей пакета. На практике, это не всегда так и в сложных очередях или pbr дополнительная маркировка соединения не приносит пользы.
RAW — таблица позволяющая пакетам обходить механизм трекинга соединений (connection tracker). Используется для противодействия DoS и снижения нагрузки на cpu (например исключением multicast трафика). Позволяет отбросить пакет.
Терминирующие действия завершают обработку пакета в цепочке и передают следующему блоку в packet flow, либо отбрасывают.
| Таблица | Действие | Описание | Терминирующее? |
|---|---|---|---|
| Все | accept | Прекратить обработку пакета и передать в следующий блок Pakcet flow | Да |
| Все | log | Записать в log информацию о пакете.В современных версиях можно добавить log к любому другому действию | Нет |
| Все | passtrough | Посчитать число пакетов. Используется для отладки | Нет |
| Все | add src to address list и add dst to address list | Добавить source (destenation) адрес из пакета в заданный список | Нет |
| Все | jump | Перейти в пользовательскую цепочку | Да |
| Все | return | Вернуться в родительскую цепочку. В базовых цепочках работает как accept | Да |
| Filter и Raw | drop | Остановить движение пакета по packet flow и отбросить | Да |
| Filter и Prerouting | fasttrack | Пометить пакет для быстрого прохождения packet flow | Да |
| Filter | reject | Аналогично drop, но отправителю пакетов отправляется уведомление(tcp или icmp) о отброшенном пакете | Да |
| Filter | trapit | Эмулировать наличие открытого порта. Используется для защиты от DoS, ввода в заблуждение и(иногда) отладке | Да |
| NAT | src-nat | Подмена адреса отправителя на указанный | Да |
| NAT | masquerade | Частный случай src-nat, подменяет адрес отправителя на один из адресов с интерфейса, используется на динамических(dhcp, vpn) интерфейсах. Не рекомендуется использовать при наличии нескольких ip на интерфейсе | Да |
| NAT | same | Частный случай src-nat. Подменяет адрес отправителя на адрес из заданного диапазона | Да |
| NAT | dst-nat | Подменяет адрес получателя на указанный | Да |
| NAT | redirect | Частный случай dst-nat, подменяет адрес получателя на адрес интерфейса роутера на который пришел пакет | Да |
| NAT | netmap | Не замена dst-nat. Применяется при трансляции сеть-в-сеть, смотрите примеры | Да |
| Mangle | mark connection | Метка соединения | Нет |
| Mangle | mark packet | Метка пакета, применяется в очередях | Нет |
| Mangle | mark routing | Метка маршрута, применяется в Policy base routing | Нет |
| Mangle | change ttl | Изменить ttl | Нет |
| Mangle | change dcsp(tos) | Изменить dcsp, в десятичном виде | Нет |
| Mangle | change mss | Изменить mss в tcp syn | Нет |
| Mangle | clear df | Очистить флаг do not fragmet | Нет |
| Mangle | strip ipv4 options | Очистить дополнительные опции ipv4 | Нет |
| Mangle | set priority | Установить приоритет для CoS | Нет |
| Mangle | route | Задать gateway для пакета. Простая версия PBR | Нет |
| Mangle | sniff tzsp | Инкапсулировать пакеты в udp и отправить на указанный ip | Нет |
| Mangle | sniff pc | Аналог tzsp, но с другим типом инкапсуляции. В wiki если примеры использования с calea | Нет |
| Mangle | passtrough | По умолчанию большинство правил в mangle не останавливает прохождение пакета, можно изменить это поведение установить passtrough=no | Нет |
| Raw | notrack | Не отслеживать пакет в connection tracker | Да |
Если найдутся желающие, могу написать подробнее про FastTrack и FastPath, но чудес от этих технологий ждать не стоит.
Пара слов про DPI
Существует несколько возможностей заглядывать в пакет чуть глубже заголовка транспортного уровня:
content — производит поиск заданной строки в пакете.
layer7-protocol — буферезирует первые 10 пакетов (или 2KiB) из соединения и производит поиск по regexp в буферезированных данных. Большое число layer7 правил существенно влияют на производительность.
tls-host — адрес имени хоста в заголовке TLS/SNI соединения HTTPS.
Примеры
Не копируйте примеры бездумно, лучше возбмите устройство и постарайтесь написать конфигурацию самостоятельно (или переписать примеры, но вникнуть что делает каждое из правил). Если не знаете как дополнить правила: в дефолтной и минимальной домашней конфигурациях нет доступа на роутер с wan интерфейса, добавьте его с фильтрацией по списку адресов.
Дефолтный Firewall RouterOS
Достаточно защищенная конфигурация, но местами сильно замороченая:
Никогда не использовал дефолтный конфиг, но раньше дефолтный firewall был значительно хуже.
Минимальный «домашний» firewall
Самый простой, что удалось придумать. Да в нем не разрешен untracked трафик (но на этапе базового изучения firewall он вам всеравно не нужен) и будут проблемы с туннельным ipsec (опять-же, если вы умеете настраивать ipsec, то сами знаете что необходимо сделать).
Пример с DMZ
На «домашних» роутерах аббревиатурой DMZ любят обзывать компьютер в локальной подсети для которого проброшены все порты из внешней сети.
На самом деле это не так и один из вариантов DMZ — отделение ресурса на который необходимо предоставить доступ из сети интернет и может быть проведена успешная атака (web server с cms в которых постоянно находят дыры — хорошая цель для взломщика). В случае взлома, злоумышленник не сможет повлиять на участников локальной сети.
HairPin NAT
Типичная ситуация, когда вы делайте проброс порта на сервер в локальной сети и извне все работает, а вот внутри локальной сети сервер не доступен по внешнему адресу.
Давайте разберем что происходит:
Решение — добавить дополнительное правило изменяющее адрес источника на адрес роутера, таким образом сервер вернет пакет на роутер, который отправит его на компьютер инициализатор.
На практике такую схему используют не часто, но как пример отладки firewall мне очень нравится.
Правильное использование netmap
Netmap — технология трансляции адресов из одной подсети в адреса другой подсети.
IP адрес (в записи с маской) состоит из двух частей: сетевой (число бит указанных в маске подсети) и хостовой (оставшиеся биты). Netmap изменяет сетевую часть адреса, но не трогает хостовую.
Есть два роутера соединенные VPN каналом. Роутеры обслуживают подсети с одинаковой адресацией. Необходимо сделать доступ между подсетями.
Без дополнительной адресации тут не обойтись.
Пользователи из левой подсети будут стучаться в правую через подсеть 192.168.102.0/24
Пользователи из правой подсети будут стучаться в левую через подсеть 192.168.101.0/24
Конфигурация на MikroTik 1.
Конфигурация MikroTik2 практически аналогична:
Есть более сложные конфигурации с использованием netmap, например если у вас множество подключений к удаленным точкам с пересекающимеся подсетями и нет возможности изменить настройки на удаленном оборудовании, но это уже advanced routing.
Если вы ничего не поняли (про netmap), значит оно вам не нужно и просто не используйте данное действие при пробросе портов.
