Здравствуй! Пишу эту статью для того, чтобы чуть-чуть прояснить практическое использование Raw и обобщить свой опыт. Сколько бы не искал информации о настройке Raw - нашел лишь крупицы. Проблема настройки оного осложняется тем, что рабочих конфигураций или адекватных применений, сколько бы я не искал - их попросту нет. И его "потанцевал" оказался не раскрыт, а администраторы игровых серверов запрашивают у меня примеры разгрузки, и это значит что пора пилить статью...

С чего бы начать?.. RAW по сути своей сильно урезан по функционалу, из-за того что он идёт до Conntrack и теряет много полезных инструментов, вроде маркировки соединения, и прочих. И это вызывает некоторые проблемы фильтрации, но сегодня мы их не будем обходить костылями, а подстроим это всё под себя. Подобная система правил описанная в статье - одна из довольно надежных методов фильтрации, она снимает нагрузку фильтрации трафика при атаках DDoS, и её мало кто использует.

Когда я создавал эти правила, я смотрел в сторону фильтрации трафика как у поставщика связи - Ростелекома. Если быть точнее, они используют NAT-PT вперемешку с маскировкой Input цепочки на сторонних или таких же мощных машрутизаторах.

Небольшое предисловие: Я не претендую на 100% достоверность, по той простой причине, что не являюсь сертифицированным специалистом Mikrotik. И не имею никаких сертификатов, дипломов. Я лишь монтажник сетей, и пишу сюда свой опыт с этими устройствами.

Для примера своей разработки я взял довольно распространённую модель RB941-2ND со 100мбит-ными портами для наглядности, версия RouterOS - 6.47.9 | 32Мб RAM и 650МГц CPU SMIPS.
(Возможно это звучит как издевательство, но я действительно DDoS-ил эту конфигурацию через специальные сервисы, и оно спокойно молотило все 100Мбит нагружаясь лишь на 25%, когда при стандартных правилах Filter уходило в 100% при 60 мбит);

В чем проблема стандартных (QuickSet) правил Firewall Filter?

Посмотрите на схему цепочек RouterOS:

980624f60d2a31275892fd1e87e2a47c.png

При стандартных параметрах маршрутизатора через QuickSet настройку в режим Home AP, мы можем наблюдать через Winbox что пакеты приходящие через интерфейс WAN проходят до цепочки Input. То есть маршрутизатор их обрабатывает полноценно через Routing Decision, заносит их в Conntrack с соответствующими данными, и в конце этот пакет либо встречает свою погибель в лице стандартного правила Drop all from WAN, либо пройдет как новое подключение с локальным процессом, если порт роутера открыт. Либо в уйдет в Forward цепочку, если настроен проброс портов через сетевую трансляцию адресов, но это уже скорее исключение.

То, что нелегимтимный трафик проходит до Input со всеми вытекающими это максимально бесполезная трата ресурсов процессора и оперативной памяти маршрутизатора. Таким образом, при довольно больших объемах бесполезного трафика при DoS и DDoS атаках CPU уйдет в 100% или Conntrack переполнится новыми TCP/UDP подключениями рано или поздно. Всё потому что у нашего подопытного - аппаратное обеспечение оставляет желать лучшего. И хотя это довольно спорный момент - даже мощный маршрутизатор может загнуться от несильной DoS атаки.

Задача:
Разгрузить маршрутизатор для работы хотя бы с локальной сетью, чтобы ядро операционной системы RouterOS не выдало Kernel Panic и не возникало переполнения буфера UDP, если из внешней сети гадят большим количеством пустого трафика. Закрыть полностью все порты управления RouterOS для WAN одним правилом, и попытаться если не полностью предотвратить, то хотя бы ослабить переполнение Conntrack.

Условия:
Маршрутизатор полностью настроен через QuickSet в качестве домашней точки доступа (Home AP, если точнее), что может вам, возможно, показаться кощунством. Все службы управления RouterOS включены и успешно видны и в локальной сети, так и в интернете по IP. Включен FastTrack, и это очень важная деталь. Запомните её.
Сценарий пользования:
Домашний/Офисный, с динамическим/статическим адресом; По большому счету, это роли не играет. При необходимости потребуется чуть-чуть поменять правила для каждого случая, но эти случаи объединяет одно - открытый доступ извне. Я конечно же предоставлю оба варианта в графическом, и в текстовом для терминала формате.

Что потребуется?
Нам потребуется Winbox или терминал SSH - выбирайте по вкусу. Знания - как работает NAT, прямые руки и подключение к RouterOS, очень желательно из локальной сети, поскольку соблюсти истину "Удаленной настройки Firewall - это к дальнему выезду" ни мне, ни вам не хочется, верно? А если пришлось - ВКЛЮЧАЕМ SAFE MODE!! И ОБЯЗАТЕЛЬНО ПРОПИСЫВАЕМ СЕБЕ РАЗРЕШАЮЩЕЕ ПРАВИЛО В RAW С ОГРАНИЧЕНИЕМ КОЛИЧЕСТВА ПАКЕТОВ 25 P/s НА ПОРТ 8291 (TCP).

Процесс реализации комплекса правил NAT-PT и RAW:

Нам необходимо создать 3 базовых правила NAT для TCP, UDP и ICMP подключений для локальной сети, чтобы исходящий трафик машин из LAN менял свои SRC порты на наш диапазон, который мы укажем. Грубо говоря, реализовать NAT-PT. Будем использовать систему фильтрации наподобие Ростелекомовской. (Последних не уважаю совершенно, но за реализацию такой системы - это + им в карму). Рекомендуется выбирать диапазон и количество портов исходя из количества клиентов, и того, сколько подключений делается в самое пиковое время, (Вообще, это не обязательно, но рекомендуется, поскольку могут возникнуть проблемы, они описаны ниже). Можно взять за пример ~2 тысячи подключений с одного устройства как Example. Предположим, что в сети около 4 проводных устройств, итого ~8 тысячи портов требуется зарезервировать под нашу затею. Также необходимо учесть, что этот диапазон должен быть нестандартным, чтобы не сканировали извне боты, и NAT правила не накладывались на открытые порты маршрутизатора из диапазона 1-10000. Правильнее будет указать... допустим - 42000-50000 (Max - 65535). Этот диапазон как раз является зарезервированным, пользовательским диапазоном, и мало кто додумается бить именно туда. А даже если и будут бить туда - лишь слегка заполнится оперативная память устройства, но интернет не погаснет. (Учитывайте свою линию связи. Если на вас пало 5Гбит на 1Гбит канал - вам ничего не поможет, но локальная сеть будет работать исправно и CPU не уйдет гулять в 100%).

Для беспроводных клиентов Wi-Fi, если есть радиомодуль в маршрутизаторе - добавляем по 250 портов к общей сумме, и при обнаружении каких-либо проблем с доступом в интернет.

Недостаток такого метода заключается в том, что если клиентов к роутеру и локальной сети подключено слишком много, например более 28 проводных, то в таком случае, реализовать эту систему правил, возможно, не получится. Это в итоге получится что нам надо зарезервировать все порты кроме диапазона 0-10000, которые использовать нельзя из-за открытых там служб Mikrotik. Банально кто хочет - тот и подключится к роутеру, или просканирует его.

Достоинство этого метода:
> Гибкость, вы можете спокойно открывать какие-либо порты через NAT и ставить серверные машины, но придется допиливать RAW ограничение наподобие из этой статьи, чтобы не было проблем с переполнением Conntrack в NAT при DDoS.
> Маскировка цепочки Input. Она будет доступна только на определенном диапазоне портов. Это значит, что если бить DDoS-ом на порт, на котором не висят NAT правила - мы получаем максимальную разгрузку CPU в RAW при удалении пакетов.

Разумеется, от меня существует две версии системы правил. При динамическом адресе, и при статическом.
Сначала рассмотрим правила NAT при динамическом адресе.
Диапазон 12000-18000 указан как пример собственной конфигурации;
1e17f37e02ca3c36f0a96f6f0c376e06.png

PHP:
Правила в текстовом режиме для терминала:

/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) и как более совместимый/универсальный вариант со всеми возможными физическими вариантами подключений (DHCP, IPoE, PPPoE, PPTP и т.д). Однако, он же является менее безопасным, поскольку при внезапном разрыве связи - в сеть поставщика услуг связи могут улететь ваши локальные адреса. (Случается довольно редко, и иногда не выходит за рамки сети поставщика услуг связи).

Если у вас глобальный статический IP адрес, есть другой вариант. Он чуть безопаснее, и надежнее, поскольку при внезапном разрыве локальные адреса не улетят в публичную сеть + незначительно снижается нагрузка на CPU роутера.
90096f0d3e616f06c60b949f7bff5c3b.png

PHP:
Правила в текстовом режиме для терминала:

/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, великий и ужасный.

Рекомендую здесь включить здесь Safe Mode и выйти из него, если соединение с RouterOS не упало при настройке удаленно. Сначала обязательно добавьте разрешающее правило на порт 8291/TCP/WAN/25 пакетов в секунду.

Здесь нам необходимо почесать репу, сделать 5 правил RAW. Оперируем мы всегда цепочкой Prerouting, и никогда Output. Это сделано для того, чтобы любые соединения от роутера работали корректно, например DNS-Resolve, или обновление системы.

Первое фундаментальное правило - блокировать фрагментированные пакеты со всех интерфейсов Ethernet. Зачем? Такие пакеты не сулят ничего хорошего, если они исходят из глобальной сети. Часто этим пользуются бот-сканеры, и DDoS-стрессеры. Принцип атаки заключается в том, что пока маршрутизатор ждёт остальную часть пакета, которая никогда не приходит - переполняется буфер оперативной памяти устройства.

Обзываем правило хоть как. Я из глупости назвал его Security Rule.
Пример правила в терминале:
PHP:
/ip firewall raw add action=drop chain=prerouting comment= "Security Rule: Block IP Fragment" fragment=yes
af55164d05363444ac3229341fc23681.png

2-3-4 правило - Принимать пакеты на указанные в NAT порты, по протоколам из начала статьи, TCP/UDP/ICMP. Но в зависимости от скорости сети указывать ограничение количества пакетов в секунду. (Каждый 1 мбит = 2 пакета). Во всех правилах далее - указываем интерфейс WAN.

Почему расчёт ограничения - 1 мбит = 2 пакета? Если легимтимный пакет обрабатывается роутером как легимтимное соединение - 98% этого соединения уходит в FastTrack, и очень редко подтверждающие пакеты могут зайти в RAW.
Пример работы: Установлено подключение через FastTrack - всего приходит 41 пакет - 1 контрольный пакет может с вероятностью в ~10% уйти в RAW, остальные 40 в FastTrack. Если клиентов LAN шибко много и испытываются проблемы с потолком ограничителя разрешающего правила - берите расчет 1 мбит - 3 пакета на крайний случай.
C-подобный:
Текстовый формат правил:
/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

Опытным путем было установлено, что ограничения в 200 входящих пакетов в секунду для TCP/UDP протоколов по линии 100Мбит - достаточно при включенном FastTrack. Неверный пакет уходит в Input и там удаляется, остальное считается как Related-соединения и приходит на компьютеры юзвергов как обычно.

ICMP принимаем как есть, ограничение ставим на 10 пакетов в секунду по стандарту, который изначально установлен в RouterOS при конфигурации Home AP во вкладке IP-Settings.
8e61b2887c03ef26fc77f70dd4ef0f63.png

Пятое правило - блокировать всё, что явно не разрешено с интерфейса WAN.
174761025be1bafcd88bfabc93ddb629.png


Правило в текстовом формате:
/ip firewall raw add action=drop chain=prerouting comment="Security Rule: Block all" in-interface-list=WAN

Достоинства данной системы правил:
1. Высокая производительность. (Да, комплекс правил может спасти от DDoS с IP Spoofing-ом, если службы ваших LAN-машин правильно прописаны через NAT и ограничены в RAW, поскольку учтены таймеры соединений для защиты таблицы Conntrack).
2. Гибкость. Вы спокойно можете опубликовать ваши службы на локальных машинах, и прописать NAT правила + правила RAW ограничивающие поток фреймов установки соединения. (Рекомендуется ставить ограничение в 50 P/sec). А также ставить системы обнаружения Hecker-ов, и автоматических сканеров IP адресов.
3. Вы можете сделать подобие Conntrack через Address List и Mangle, если потребуется мониторинг IP подключенных клиентов к вашим службам.
4. Система правил не влияет на LAN подключения, поскольку всё проработано исключительно только для WAN.
5. Полностью закрывает все порты маршрутизатора извне, при верном выборе диапазона трансляции локальных портов. Это происходит, поскольку пакеты не доходят до Input цепочки без соответствующего разрешающего правила, а даже если и доходят, то отлавливаются стандартным правилом Drop all from WAN.
6. Есть возможность прикрутить систему, которая обнаруживает IP сканеры, хацкеров и удалять их не в Input цепочке, а в Prerounting RAW.

Недостатки:
1. Ограничение количества пользовательских портов.
2. Лучше всего подходит для сетей, где меньше 24 клиентов.


Ответы на вопросы:
1. Я хочу опубликовать какую-либо службу. Как это сделать с этим комплексом?
Ответ: Во первых - добавить разрешающие правила в RAW, в блок разрешающих правил, Новое правило должно быть с ограничением количества принимаемых пакетов в секунду, это ОБЯЗАТЕЛЬНО. (Для SRCDS допустим 50 UDP P/s и 5 TCP P/s). Создать NAT правила проброса.
2. У меня не-систематически растет счетчик удаленных фрагментированных пакетов в правиле RAW (Часто от 1-250), в чем причина?
Ответ: Если вас не атакуют (в случае атаки - количество удаленных пакетов более 2к в секунду), и не сканируют - в вашей сети существует проблема, она может быть как физической, так и вирусной. Проверьте, с какого адреса идут такие пакеты из локальной сети включив логгирование правила. Обязательно отключите его, как только произошло обнаружение, и записались логи. В противном случае случится переполнение оперативной памяти/перегрузка CPU при атаке.
Проверяйте физическое соединение машины, на которую RouterOS выдал обнаружение и её программное обеспечение на наличие вирусного ПО.