Здравствуй! Пишу эту статью для того, чтобы чуть-чуть прояснить практическое использование Raw и обобщить свой опыт. Сколько бы не искал информации о настройке Raw - нашел лишь крупицы. Проблема настройки оного осложняется тем, что рабочих конфигураций или адекватных применений, сколько бы я не искал - их попросту нет. И его "потанцевал" оказался не раскрыт, а администраторы игровых серверов запрашивают у меня примеры разгрузки, и это значит что пора пилить статью...
С чего бы начать?.. RAW по сути своей сильно урезан по функционалу, из-за того что он идёт до Conntrack и теряет много полезных инструментов, вроде маркировки соединения, и прочих. И это вызывает некоторые проблемы фильтрации, однако - мы получаем крайне высокую производительность. Сегодня мы не будем обходить ограничения костылями, а подстроим это всё под себя. Подобная система правил описанная в статье -может быть и очень грубая, и лишена некоторых полезных примочков, но крайне эффективна при отражении атак.
Когда я создавал эти правила, я смотрел в сторону фильтрации трафика как у поставщика связи - Ростелекома. Если быть точнее, они используют NAT с Port Translation, вперемешку с маскировкой Input цепочки на сторонних или таких же мощных маршрутизаторах. То есть схема примерно такая:
- Клиент => Городской узел связи => Ядро сети => Гейт (IP).
Небольшое предисловие: Я не претендую на 100% достоверность, по той простой причине, что не являюсь сертифицированным специалистом Mikrotik. И не имею никаких сертификатов, дипломов. Я лишь монтажник сетей, и владелец своего сервера и пишу сюда свой опыт с этими устройствами.
Для примера своей разработки я взял довольно распространённую модель RB941-2ND со 100 мбит-ными портами для наглядности, версия RouterOS - 6.47.9 | 32Мб RAM и 650 МГц CPU на архитектуре MIPS.
(Возможно это звучит как издевательство, но я действительно DDoS-ил эту конфигурацию через специальные сервисы, и оно спокойно молотило все 100Мбит нагружаясь лишь на 25%, когда при стандартных правилах Filter уходило в 100% при 60 мбит. А при DDoS-е мелкими пакетами - CPU уходило гулять в 100% только при DROP-е 240 тысяч пакетов в секунду по 40-60 байт, TCP Mixed атакой);
В чем проблема стандартных (QuickSet) правил Firewall Filter?
Посмотрите на схему цепочек RouterOS:
При стандартных параметрах маршрутизатора через QuickSet настройку в режим Home AP, мы можем наблюдать через Winbox что пакеты приходящие через интерфейс WAN проходят до цепочки Input. То есть маршрутизатор их обрабатывает полноценно через Routing Decision, заносит их в Conntrack с соответствующими данными, и в конце этот пакет либо встречает свою погибель в лице стандартного правила Drop all from WAN, либо пройдет как новое подключение с локальным процессом, если порт роутера открыт. Ну конечно же есть и 3 вариант - уйдет в Forward цепочку, если настроен проброс портов через NAT, но это уже скорее исключение.
То, что не-легимтимный трафик проходит до Input со всеми вытекающими - это максимально бесполезная трата ресурсов процессора и оперативной памяти маршрутизатора. Таким образом, при довольно больших объемах бесполезного трафика при DoS и DDoS атаках CPU уйдет в 100% или Conntrack переполнится новыми TCP/UDP подключениями рано или поздно и вызовет TAIL DROP - то есть удаление ВСЕГО трафика из-за перегрузки устройства. Всё потому что у нашего подопытного - аппаратное обеспечение по сути минимальное. И хотя это довольно спорный момент - даже мощный маршрутизатор может загнуться от несильной DoS атаки - проверял и такие вещи.
Задача:
Разгрузить маршрутизатор для работы хотя бы с локальной сетью, чтобы ядро операционной системы RouterOS не выдало Kernel Panic/зависания и не возникало переполнения буфера UDP, если из внешней сети гадят большим количеством пустого трафика. Закрыть полностью все порты управления RouterOS для WAN одним правилом, и попытаться если и не полностью предотвратить, то хотя бы ослабить переполнение таблицы Conntrack.
Условия:
Маршрутизатор полностью настроен через QuickSet в качестве домашней точки доступа (Home AP, если точнее), что может вам, возможно, показаться кощунством. Все службы управления RouterOS включены и успешно видны и в LAN, так и в интернете по IP. Включен FastTrack, и это очень важная деталь. Запомните её.
Сценарий пользования: Домашний/Офисный, с динамическим/статическим адресом; Эти случаи объединяет одно - открытый доступ извне. Я конечно же предоставлю оба варианта в графическом, и в текстовом для SSH или терминала формате.
Что потребуется?
Нам потребуется Winbox или терминал SSH - выбирайте по вкусу, GUI, или SSH. Знания - как работает NAT, прямые руки, и подключение к RouterOS, только из LAN.
Процесс реализации комплекса правил NAT-PT и RAW:
Нам необходимо создать 3 базовых правила NAT для TCP, UDP и ICMP подключений для LAN, чтобы исходящий трафик машин из LAN менял свои SRC порты на наш диапазон, который мы укажем. Грубо говоря, реализовать NAT-Port Translation. Будем использовать систему фильтрации наподобие Ростелекомовской. (Последних не уважаю совершенно, но за реализацию такой системы — это + им в карму).
Рекомендуется выбирать диапазон и количество портов исходя из количества клиентов и того, сколько подключений делается в пиковое время. Вообще, это крайне рекомендуется, поскольку могут возникнуть проблемы, они описаны ниже. Можно взять за пример ~384 подключений с одного устройства. Предположим, что в сети около 8 проводных устройств, итого 3072 порта требуется зарезервировать под нашу затею.
Также необходимо учесть, что этот диапазон должен быть нестандартным, чтобы не сканировали извне боты, и NAT правила не накладывались на открытые порты маршрутизатора из диапазона 1-10000.
Я рекомендую использовать диапазон 60000-65535, поскольку:
Для беспроводных клиентов Wi-Fi, если есть радиомодуль в маршрутизаторе - добавляем по 256 портов к общей сумме, и при обнаружении каких-либо проблем с доступом в интернет.
Недостаток такого метода заключается в том, что если клиентов к LAN подключено слишком много (я не назову точную цифру), то в таком случае, реализовать эту систему правил, возможно, не получится из-за того что ситуации разные. Если все клиенты - начнут лезть по интернету - есть немаленький шанс того что эфемерных портов просто не хватит - это будет сопровождаться тупняком интернета, или недоступностью некоторых ресурсов.
Достоинство этого метода:
Сначала рассмотрим правила NAT при динамическом адресе.
Диапазон 12000-18000 указан как пример собственной альтернативной конфигурации;
Правила в текстовом режиме для терминала:
Как вы можете заметить, используется Masquerade. Это сделано для совместимости с динамической выдачей адресов от провайдера (DHCP) и как более совместимый/универсальный вариант со всеми возможными физическими вариантами подключений (DHCP, IPoE, PPPoE, PPTP и т.д). Masquerade автоматически подставляет в качестве исходного адреса адрес интерфейса, через который выходит трафик. Если интерфейс неактивен (разрыв связи), пакеты не отправляются. Утечки приватных адресов в публичную сеть не происходит. Тем не менее, при статическом WAN-адресе использование src-nat с явным указанием адреса даёт чуть больше контроля и может считаться предпочтительным с точки зрения предсказуемости.
Правила в текстовом режиме для терминала:
Не забудьте отредактировать "INSERTYOURIP". Впишите туда свой ГЛОБАЛЬНЫЙ WAN адрес, чтобы правила начали работать.
Как это сделать:
Назовём правило хоть как. Я из глупости назвал его Security Rule.
Почему ограничение?
Если легитимный трафик прошёл и соединение попало в FastTrack — дальнейшие пакеты обходят RAW. В RAW попадают только «сигнальные» пакеты (инициализация, подтверждения, keepalive). Ограничение в 200–300 пакетов в секунду для TCP/UDP на линии 100 Мбит обычно достаточно. Если клиентов много или используются приложения с интенсивным потоком мелких сигнальных пакетов — увеличивайте лимит вручную. Недостаточный лимит приведёт к тому, что TCP-соединения начнут застревать или рваться (алгоритм Cubic при обнаружении потери пакетов снижает окно передачи).
Формула «1 Мбит ≈ 2 пакета в секунду» — это эмпирическое приближение, от которого можно отталкиваться, но окончательно лимит подбирается под конкретную сеть.
Почему такой расчёт?
Если легитимный пакет обрабатывается роутером как легитимное соединение — 90% этого соединения уходит в FastTrack, и очень редко подтверждающие пакеты могут зайти в RAW — они же «сигнальные» для Conntrack пакеты.
Пример работы FastTrack:
Когда соединение успешно установлено и попадает в FastTrack, оно начинает обрабатываться по сокращённому пути. Пакеты такого соединения уже не проходят через фильтры, NAT, mangle и даже через RAW (за исключением небольшого числа «сигнальных» пакетов, которые нужны для поддержания таблицы соединений).
Именно поэтому в моей схеме ограничения в RAW (limit=200,200:packet) не обрезают уже установленный трафик — они успевают пропустить управляющие пакеты инициализации соединения, а дальнейший поток данных FastTrack минует RAW и не попадает под лимиты.
Практическая проверка на RB941-2ND подтверждает: при активной передаче данных через FastTrack счётчики принятых пакетов в RAW-правилах растут очень медленно (только «сигнальные»), в то время как общая пропускная способность остаётся высокой. Это позволяет эффективно защищать устройство без ущерба для производительности. Однако, если клиентов LAN шибко много и испытываются проблемы с потолком ограничителя разрешающего правила (падение скорости, недоступность ресурсов) — подбирайте количество сигнальных пакетов на своей конфигурации вручную. Если идёт активная передача данных с огромным Flow — необходимо разрешить куда больше сигнальных пакетов, иначе соединения будут банально застревать или рваться. Это касается в основном TCP, поскольку на серверах в интернете работает Congestion Protocol — Cubic, а он, в свою очередь, при обнаружении Loss снижает окно передачи TCP (то есть снижает скорость передачи — это банально). Если кто не знает, про что я вообще такое говорю — учим модель OSI и основы алгоритмов TCP.
Текстовый формат правил:
ICMP принимаем как есть, ограничение ставим на 10-50 пакетов в секунду по стандарту, который изначально установлен в RouterOS при конфигурации Home AP во вкладке IP-Settings.
Если посмотреть логи правил Filter в цепочке Input, можно увидеть, что некоторые пакеты проброшенного соединения попадают под DROP (или REJECT, если вы его используете). В результате:
Пример реализации (допустим, вы пробрасываете TCP-порт 25565 для Minecraft-сервера на локальную машину 192.168.1.100):
Правило NAT (проброс порта) — уже должно быть создано:
Правило Mangle — добавляем перед основными правилами (или в начало списка):
Если у вас несколько проброшенных портов — можно создать отдельное правило для каждого, либо объединить по протоколу с указанием нескольких портов через запятую.
Важно: размещайте это правило выше (раньше) любых правил, которые могут отправлять трафик в FastTrack, иначе эффекта не будет.
Достоинства данной системы правил:
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. Полностью закрывает все порты маршрутизатора извне. Поскольку в RAW мы разрешаем только трафик на заданный диапазон портов (и с лимитом) для глобального интерфейса, а всё остальное отбрасываем - пакеты до цепочки Input вообще не доходят (А службы висят на других портах). Дополнительное правило Drop all from WAN в Filter нужно оставить для подстраховки эфемерных портов - если левый пакет попал в эфемерный порт - в Input-цепочке он дропнется.
6. Есть возможность прикрутить систему, которая обнаруживает IP сканеры, хацкеров и удалять их не в Input цепочке, а в Prerounting RAW.
Недостатки:
1. Ограничение диапазона эфемерных портов (Да-да, на Linux - NAT-Port Translation про который написано выше - это по сути велосипед со сменой диапазона эфемерных портов).
2. Лучше всего подходит для сетей, где не так много клиентов - серверы - идеально. 1 cерверу достаточно 1024 эфемерных порта, проверено.
3. Было установлено, что FTP-серверы при таких правилах работают некорректно, и требуется изобретать велосипед с пропуском соединений к порту FTP-сервера и DATA-портам, если на двух маршрутизаторах реализована одна и та же система - ситуация: "Я тебя вижу, но не могу открыть канал передачи данных". Решается просто - в настройках FTP сервера и клиента - банально меняете DATA диапазон портов в соответствии с эфемерными. По идее - FTP сервер кодирует эту информацию и отправляет клиенту, чтобы уже он подконнектился к вам.
4. Если серверов много — растёт ручная работа.
Придётся прописывать NAT‑правила для каждого сервера вручную (а если ещё и RAW‑исключения — то и их). Но с другой стороны, это плата за защиту. Риторический вопрос: надеяться, что тебя не атакуют, и жить с простотой, или знать, что атака может случиться в любой момент, и быть в защите, но мириться с неудобствами настройки? Что важнее?
Ответы на вопросы:
1. Я хочу опубликовать какую-либо службу. Как это сделать с этой схемой правил?
Ответ:
Во-первых, добавить разрешающие правила в RAW, в блок разрешающих правил (правила TCP/UDP/ICMP), ставим ниже нужного протокола - основные правила - всегда выше. Новое правило должно быть с ограничением количества принимаемых пакетов в секунду — это ОБЯЗАТЕЛЬНО. Ограничение нужно, потому что после установки соединения FastTrack берёт его на себя, а в RAW попадают только «сигнальные» пакеты (инициализация, подтверждения, keepalive). Слишком низкий лимит — и соединения начнут рваться, слишком высокий — снижается защита. Подбирается экспериментально под ваш трафик.
Для примера: для SRCDS-сервера я использую 50 UDP p/s и 5 TCP p/s — этого достаточно для стабильной работы при атаке (25 A2S запросов + всплески и 5 SYN сразу же например).
Во-вторых, создать NAT-правила проброса портов.
В-третьих, если это TCP-служба — обязательно добавить правило Mangle с действием route для этого порта (как описано в дополнении к статье). Это «вытащит» соединение из-под некорректной маршрутизации, связанной с FastTrack, иначе часть клиентов не сможет подключиться.
Filter | Forward | Mangle остаются полностью доступны для дальнейшей обработки.
Пакеты, которые прошли RAW (сигнальные и NEW), попадают в цепочки Filter | Forward | Mangle. Там вы можете делать с ними что угодно: логировать, дополнительно фильтровать, ограничивать по адресам, применять reject и т.д. RAW сделал своё дело — отсек мусор и снял нагрузку, а дальше вы управляете легитимным трафиком как обычно.
С чего бы начать?.. RAW по сути своей сильно урезан по функционалу, из-за того что он идёт до Conntrack и теряет много полезных инструментов, вроде маркировки соединения, и прочих. И это вызывает некоторые проблемы фильтрации, однако - мы получаем крайне высокую производительность. Сегодня мы не будем обходить ограничения костылями, а подстроим это всё под себя. Подобная система правил описанная в статье -может быть и очень грубая, и лишена некоторых полезных примочков, но крайне эффективна при отражении атак.
Когда я создавал эти правила, я смотрел в сторону фильтрации трафика как у поставщика связи - Ростелекома. Если быть точнее, они используют NAT с Port Translation, вперемешку с маскировкой Input цепочки на сторонних или таких же мощных маршрутизаторах. То есть схема примерно такая:
- Клиент => Городской узел связи => Ядро сети => Гейт (IP).
Небольшое предисловие: Я не претендую на 100% достоверность, по той простой причине, что не являюсь сертифицированным специалистом Mikrotik. И не имею никаких сертификатов, дипломов. Я лишь монтажник сетей, и владелец своего сервера и пишу сюда свой опыт с этими устройствами.
Для примера своей разработки я взял довольно распространённую модель RB941-2ND со 100 мбит-ными портами для наглядности, версия RouterOS - 6.47.9 | 32Мб RAM и 650 МГц CPU на архитектуре MIPS.
(Возможно это звучит как издевательство, но я действительно DDoS-ил эту конфигурацию через специальные сервисы, и оно спокойно молотило все 100Мбит нагружаясь лишь на 25%, когда при стандартных правилах Filter уходило в 100% при 60 мбит. А при DDoS-е мелкими пакетами - CPU уходило гулять в 100% только при DROP-е 240 тысяч пакетов в секунду по 40-60 байт, TCP Mixed атакой);
В чем проблема стандартных (QuickSet) правил Firewall Filter?
Посмотрите на схему цепочек RouterOS:
При стандартных параметрах маршрутизатора через QuickSet настройку в режим Home AP, мы можем наблюдать через Winbox что пакеты приходящие через интерфейс WAN проходят до цепочки Input. То есть маршрутизатор их обрабатывает полноценно через Routing Decision, заносит их в Conntrack с соответствующими данными, и в конце этот пакет либо встречает свою погибель в лице стандартного правила Drop all from WAN, либо пройдет как новое подключение с локальным процессом, если порт роутера открыт. Ну конечно же есть и 3 вариант - уйдет в Forward цепочку, если настроен проброс портов через NAT, но это уже скорее исключение.
То, что не-легимтимный трафик проходит до Input со всеми вытекающими - это максимально бесполезная трата ресурсов процессора и оперативной памяти маршрутизатора. Таким образом, при довольно больших объемах бесполезного трафика при DoS и DDoS атаках CPU уйдет в 100% или Conntrack переполнится новыми TCP/UDP подключениями рано или поздно и вызовет TAIL DROP - то есть удаление ВСЕГО трафика из-за перегрузки устройства. Всё потому что у нашего подопытного - аппаратное обеспечение по сути минимальное. И хотя это довольно спорный момент - даже мощный маршрутизатор может загнуться от несильной DoS атаки - проверял и такие вещи.
Задача:
Разгрузить маршрутизатор для работы хотя бы с локальной сетью, чтобы ядро операционной системы RouterOS не выдало Kernel Panic/зависания и не возникало переполнения буфера UDP, если из внешней сети гадят большим количеством пустого трафика. Закрыть полностью все порты управления RouterOS для WAN одним правилом, и попытаться если и не полностью предотвратить, то хотя бы ослабить переполнение таблицы Conntrack.
Условия:
Маршрутизатор полностью настроен через QuickSet в качестве домашней точки доступа (Home AP, если точнее), что может вам, возможно, показаться кощунством. Все службы управления RouterOS включены и успешно видны и в LAN, так и в интернете по IP. Включен FastTrack, и это очень важная деталь. Запомните её.
Сценарий пользования: Домашний/Офисный, с динамическим/статическим адресом; Эти случаи объединяет одно - открытый доступ извне. Я конечно же предоставлю оба варианта в графическом, и в текстовом для SSH или терминала формате.
Что потребуется?
Нам потребуется Winbox или терминал SSH - выбирайте по вкусу, GUI, или SSH. Знания - как работает NAT, прямые руки, и подключение к RouterOS, только из LAN.
Процесс реализации комплекса правил NAT-PT и RAW:
Нам необходимо создать 3 базовых правила NAT для TCP, UDP и ICMP подключений для LAN, чтобы исходящий трафик машин из LAN менял свои SRC порты на наш диапазон, который мы укажем. Грубо говоря, реализовать NAT-Port Translation. Будем использовать систему фильтрации наподобие Ростелекомовской. (Последних не уважаю совершенно, но за реализацию такой системы — это + им в карму).
Рекомендуется выбирать диапазон и количество портов исходя из количества клиентов и того, сколько подключений делается в пиковое время. Вообще, это крайне рекомендуется, поскольку могут возникнуть проблемы, они описаны ниже. Можно взять за пример ~384 подключений с одного устройства. Предположим, что в сети около 8 проводных устройств, итого 3072 порта требуется зарезервировать под нашу затею.
Также необходимо учесть, что этот диапазон должен быть нестандартным, чтобы не сканировали извне боты, и NAT правила не накладывались на открытые порты маршрутизатора из диапазона 1-10000.
Я рекомендую использовать диапазон 60000-65535, поскольку:
- Это зарезервированная пользовательская область, которую редко сканируют атакующие;
- Если ботнет всё же начнёт долбить по всему диапазону — стандартные правила Filter цепочки не дадут доступа в LAN;
- По сути, это «дыра», но необходимая — здесь работает принцип security through obscurity: атакующий не знает вашего диапазона эфемерных портов. Ты, читатель — ну не будешь сканировать/бить в этот диапазон, по чесноку. А даже если будешь — ты не увидишь результата — там лимиты далее по статье стоят.
Для беспроводных клиентов Wi-Fi, если есть радиомодуль в маршрутизаторе - добавляем по 256 портов к общей сумме, и при обнаружении каких-либо проблем с доступом в интернет.
Недостаток такого метода заключается в том, что если клиентов к LAN подключено слишком много (я не назову точную цифру), то в таком случае, реализовать эту систему правил, возможно, не получится из-за того что ситуации разные. Если все клиенты - начнут лезть по интернету - есть немаленький шанс того что эфемерных портов просто не хватит - это будет сопровождаться тупняком интернета, или недоступностью некоторых ресурсов.
Достоинство этого метода:
- Гибкость, вы можете спокойно открывать какие-либо порты через NAT и ставить физические серверы, но придется допиливать RAW ограничения наподобие из этой статьи, чтобы не было проблем с переполнением Conntrack в NAT при DDoS.
- Защита цепочки Input. Она будет доступна только на определенном, эфемерном диапазоне портов. Это значит, что если бить DDoS-ом на порт, на котором не висят NAT правила - мы получаем максимальную разгрузку CPU в RAW при удалении пакетов. При DDoS по случайным портам - мы ЗНАЧИТЕЛЬНО снижаем вектор атаки, и большая часть атаки уйдет именно в RAW, а маленькая часть в Filter.
Сначала рассмотрим правила NAT при динамическом адресе.
Диапазон 12000-18000 указан как пример собственной альтернативной конфигурации;
Правила в текстовом режиме для терминала:
PHP:
/ip firewall nat
add action=masquerade chain=srcnat comment="SRC RAW NAT TCP" out-interface-list=WAN protocol=tcp to-ports=12000-18000
add action=masquerade chain=srcnat comment="SRC RAW NAT UDP" out-interface-list=WAN protocol=udp to-ports=12000-18000
add action=masquerade chain=srcnat comment="SRC RAW NAT ICMP" out-interface-list=WAN protocol=icmpКак вы можете заметить, используется Masquerade. Это сделано для совместимости с динамической выдачей адресов от провайдера (DHCP) и как более совместимый/универсальный вариант со всеми возможными физическими вариантами подключений (DHCP, IPoE, PPPoE, PPTP и т.д). Masquerade автоматически подставляет в качестве исходного адреса адрес интерфейса, через который выходит трафик. Если интерфейс неактивен (разрыв связи), пакеты не отправляются. Утечки приватных адресов в публичную сеть не происходит. Тем не менее, при статическом WAN-адресе использование src-nat с явным указанием адреса даёт чуть больше контроля и может считаться предпочтительным с точки зрения предсказуемости.
Правила в текстовом режиме для терминала:
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=12000-18000
add action=src-nat chain=srcnat comment="SRC NAT UDP RAW" out-interface-list=WAN protocol=udp to-addresses=INSERTYOURIP to-ports=12000-18000
add action=src-nat chain=srcnat comment="SRC NAT ICMP RAW" out-interface-list=WAN protocol=icmp to-addresses=INSERTYOURIPFirewall RAW, великий и ужасный
Здесь нам необходимо почесать репу и сделать 6 основных правил RAW. Оперируем мы всегда цепочкой Prerouting, и никогда Output, поскольку работаем с трафиком, приходящим на WAN интерфейс.Правило 0 (опциональное, но важное): Белые списки для DNS и критических сервисов
Иногда DNS-резолвинг самого роутера перестаёт работать, потому что запросы к DNS-серверам провайдера блокируются нашими же правилами. Чтобы этого избежать, добавьте в самый верх RAW-списка разрешающие правила для IP-адресов ваших DNS/NTP-серверов, а также для любых критических внешних сервисов (например, мастер-серверы Steam, IP вашей VDS для RDP и т.д.).Как это сделать:
- Зайдите во вкладку IP → DNS, посмотрите, какие DNS-серверы использует роутер (или пропишите их вручную);
- Добавьте в RAW правила accept для этих IP-адресов, указав интерфейс WAN;
- При необходимости добавьте аналогичные правила для NTP-серверов и других важных внешних ресурсов.
Правило 1: Блокировка фрагментированных пакетов с WAN
Фрагментированные пакеты из глобальной сети — это потенциальная угроза: они могут использоваться для переполнения буфера дефрагментации или для обхода простых фильтров. При этом фрагментированный трафик из локальной сети (например, RDP, NFS) скорее всего легитимен, поэтому ограничиваемся только интерфейсом WAN.Назовём правило хоть как. Я из глупости назвал его Security Rule.
PHP:
/ip firewall raw add action=drop chain=prerouting comment="Security Rule: Block IP Fragment from WAN" fragment=yes in-interface-list=WANПравила 2, 3, 4: Приём легитимного NAT-трафика
Принимаем пакеты на те самые порты, которые мы задали в NAT (у нас это диапазон 12000-18000 из скриншотов), по протоколам TCP, UDP и ICMP. Важно: указываем интерфейс WAN и ставим ограничение на количество пакетов в секунду.Почему ограничение?
Если легитимный трафик прошёл и соединение попало в FastTrack — дальнейшие пакеты обходят RAW. В RAW попадают только «сигнальные» пакеты (инициализация, подтверждения, keepalive). Ограничение в 200–300 пакетов в секунду для TCP/UDP на линии 100 Мбит обычно достаточно. Если клиентов много или используются приложения с интенсивным потоком мелких сигнальных пакетов — увеличивайте лимит вручную. Недостаточный лимит приведёт к тому, что TCP-соединения начнут застревать или рваться (алгоритм Cubic при обнаружении потери пакетов снижает окно передачи).
Формула «1 Мбит ≈ 2 пакета в секунду» — это эмпирическое приближение, от которого можно отталкиваться, но окончательно лимит подбирается под конкретную сеть.
Почему такой расчёт?
Если легитимный пакет обрабатывается роутером как легитимное соединение — 90% этого соединения уходит в FastTrack, и очень редко подтверждающие пакеты могут зайти в RAW — они же «сигнальные» для Conntrack пакеты.
Пример работы FastTrack:
Когда соединение успешно установлено и попадает в FastTrack, оно начинает обрабатываться по сокращённому пути. Пакеты такого соединения уже не проходят через фильтры, NAT, mangle и даже через RAW (за исключением небольшого числа «сигнальных» пакетов, которые нужны для поддержания таблицы соединений).
Именно поэтому в моей схеме ограничения в RAW (limit=200,200:packet) не обрезают уже установленный трафик — они успевают пропустить управляющие пакеты инициализации соединения, а дальнейший поток данных FastTrack минует RAW и не попадает под лимиты.
Практическая проверка на RB941-2ND подтверждает: при активной передаче данных через FastTrack счётчики принятых пакетов в RAW-правилах растут очень медленно (только «сигнальные»), в то время как общая пропускная способность остаётся высокой. Это позволяет эффективно защищать устройство без ущерба для производительности. Однако, если клиентов LAN шибко много и испытываются проблемы с потолком ограничителя разрешающего правила (падение скорости, недоступность ресурсов) — подбирайте количество сигнальных пакетов на своей конфигурации вручную. Если идёт активная передача данных с огромным Flow — необходимо разрешить куда больше сигнальных пакетов, иначе соединения будут банально застревать или рваться. Это касается в основном TCP, поскольку на серверах в интернете работает Congestion Protocol — Cubic, а он, в свою очередь, при обнаружении Loss снижает окно передачи TCP (то есть снижает скорость передачи — это банально). Если кто не знает, про что я вообще такое говорю — учим модель OSI и основы алгоритмов TCP.
Текстовый формат правил:
PHP:
/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" in-interface-list=WAN limit=10,10:packet protocol=icmpICMP принимаем как есть, ограничение ставим на 10-50 пакетов в секунду по стандарту, который изначально установлен в RouterOS при конфигурации Home AP во вкладке IP-Settings.
Правило 5: Блокировка всего остального
Всё, что не попало под белые списки и не было явно разрешено на эфемерном диапазоне, смело отбрасываем. Это самое главное разгружающее правило.
PHP:
/ip firewall raw add action=drop chain=prerouting comment="Security Rule: Block all" in-interface-list=WANДополнение к статье №1 (спустя 2 года использования)
Статья писалась под сценарий «домашний/офисный роутер без проброшенных служб». Однако если вы захотите открыть доступ извне к какому-либо серверу за роутером (например, веб-сервер, игровой сервер, RDP), вы можете столкнуться с проблемой, связанной с FastTrack.В чём проблема?
FastTrack, будучи включённым, «забирает» соединения в ускоренную обработку, минуя стандартные цепочки Filter, NAT и Mangle. Это отлично работает для исходящего трафика клиентов LAN, но при входящем пробросе порта (dst-nat) может возникнуть ситуация, когда часть пакетов соединения «съедается» в цепочке Input, не доходя до вашего сервера.Если посмотреть логи правил Filter в цепочке Input, можно увидеть, что некоторые пакеты проброшенного соединения попадают под DROP (или REJECT, если вы его используете). В результате:
- Соединение может периодически «лагать»;
- При использовании REJECT в Input — TCP-соединение может рваться;
- У некоторых клиентов (примерно 25–30% от общего числа) подключение к серверу за роутером может отсутствовать вовсе.
Решение: Mangle с действием Route
Чтобы исправить это недоразумение, необходимо добавить правило в Mangle (цепочка Prerouting), которое будет помечать входящие соединения на проброшенный порт и направлять их по маршруту, минуя проблемные участки обработки. Действие Route в Mangle позволяет принудительно задать маршрутизацию для помеченных пакетов, что «вытаскивает» их из-под некорректного Routing Decision на критическом этапе.Пример реализации (допустим, вы пробрасываете TCP-порт 25565 для Minecraft-сервера на локальную машину 192.168.1.100):
Правило NAT (проброс порта) — уже должно быть создано:
PHP:
/ip firewall nat add chain=dstnat protocol=tcp dst-port=25565 action=dst-nat to-addresses=192.168.1.100 to-ports=25565
PHP:
/ip firewall mangle add chain=prerouting protocol=tcp dst-port=25565 action=route comment="Fix FastTrack for forwarded port"Как это работает:
Действие route в Mangle заставляет пакеты, подходящие под условие, пройти полный путь обработки (NAT, Filter, маршрутизация) без преждевременного «захвата» Routing Decision в Input. При этом FastTrack для остального трафика остаётся включённым и продолжает давать прирост производительности.Важно: размещайте это правило выше (раньше) любых правил, которые могут отправлять трафик в FastTrack, иначе эффекта не будет.
Достоинства данной системы правил:
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. Полностью закрывает все порты маршрутизатора извне. Поскольку в RAW мы разрешаем только трафик на заданный диапазон портов (и с лимитом) для глобального интерфейса, а всё остальное отбрасываем - пакеты до цепочки Input вообще не доходят (А службы висят на других портах). Дополнительное правило Drop all from WAN в Filter нужно оставить для подстраховки эфемерных портов - если левый пакет попал в эфемерный порт - в Input-цепочке он дропнется.
6. Есть возможность прикрутить систему, которая обнаруживает IP сканеры, хацкеров и удалять их не в Input цепочке, а в Prerounting RAW.
Недостатки:
1. Ограничение диапазона эфемерных портов (Да-да, на Linux - NAT-Port Translation про который написано выше - это по сути велосипед со сменой диапазона эфемерных портов).
2. Лучше всего подходит для сетей, где не так много клиентов - серверы - идеально. 1 cерверу достаточно 1024 эфемерных порта, проверено.
3. Было установлено, что FTP-серверы при таких правилах работают некорректно, и требуется изобретать велосипед с пропуском соединений к порту FTP-сервера и DATA-портам, если на двух маршрутизаторах реализована одна и та же система - ситуация: "Я тебя вижу, но не могу открыть канал передачи данных". Решается просто - в настройках FTP сервера и клиента - банально меняете DATA диапазон портов в соответствии с эфемерными. По идее - FTP сервер кодирует эту информацию и отправляет клиенту, чтобы уже он подконнектился к вам.
4. Если серверов много — растёт ручная работа.
Придётся прописывать NAT‑правила для каждого сервера вручную (а если ещё и RAW‑исключения — то и их). Но с другой стороны, это плата за защиту. Риторический вопрос: надеяться, что тебя не атакуют, и жить с простотой, или знать, что атака может случиться в любой момент, и быть в защите, но мириться с неудобствами настройки? Что важнее?
Ответы на вопросы:
1. Я хочу опубликовать какую-либо службу. Как это сделать с этой схемой правил?
Ответ:
Во-первых, добавить разрешающие правила в RAW, в блок разрешающих правил (правила TCP/UDP/ICMP), ставим ниже нужного протокола - основные правила - всегда выше. Новое правило должно быть с ограничением количества принимаемых пакетов в секунду — это ОБЯЗАТЕЛЬНО. Ограничение нужно, потому что после установки соединения FastTrack берёт его на себя, а в RAW попадают только «сигнальные» пакеты (инициализация, подтверждения, keepalive). Слишком низкий лимит — и соединения начнут рваться, слишком высокий — снижается защита. Подбирается экспериментально под ваш трафик.
Для примера: для SRCDS-сервера я использую 50 UDP p/s и 5 TCP p/s — этого достаточно для стабильной работы при атаке (25 A2S запросов + всплески и 5 SYN сразу же например).
Во-вторых, создать NAT-правила проброса портов.
В-третьих, если это TCP-служба — обязательно добавить правило Mangle с действием route для этого порта (как описано в дополнении к статье). Это «вытащит» соединение из-под некорректной маршрутизации, связанной с FastTrack, иначе часть клиентов не сможет подключиться.
Filter | Forward | Mangle остаются полностью доступны для дальнейшей обработки.
Пакеты, которые прошли RAW (сигнальные и NEW), попадают в цепочки Filter | Forward | Mangle. Там вы можете делать с ними что угодно: логировать, дополнительно фильтровать, ограничивать по адресам, применять reject и т.д. RAW сделал своё дело — отсек мусор и снял нагрузку, а дальше вы управляете легитимным трафиком как обычно.
