[Mikrotik] Шаманизм в RouterOS или как я защитил LAN и разгрузил CPU/RAM маршрутизатора через...

[Lappland_Saluzzo]

Эта тема является основным обсуждением к статье [Mikrotik] Шаманизм в RouterOS или как я сделал нормально закрытый Firewall в RAW, разгрузив маршрутизатор при школо-DDoS-ах..

Принимаю критику в мягкой форме. Если возникли проблемы - перечитайте статью полностью. Имейте ввиду, что этот комплекс правил работает с нуля, и только знающий RouterOS может встроить её без последствий для его сети.

Если что - NAT-PT это моя аббревиатура механизма NAT Overload с трансляцией под наш диапазон пользовательских исходящих портов.

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

Недостаток используемой системы также заключается в том, что если злоумышленник внезапно нашел пользовательские порты (а это невозможно, если Input цепочка настроена по стандарту на простой DROP и выбран правильный диапазон пользовательских портов), и знает пример вашей конфигурации - он может убить интернет в локальной сети, если будет атаковать мульти-DDoS-ом через TCP и UDP подключения на всё порты. Имейте ввиду. С другой стороны, если вы общаетесь с DDoS-ером, вы спокойно можете заявить что работаете за NAT-ом поставщика услуг связи, и подтверждение вашим словам будет - подключения от вашего глобального адреса имеют нестандартные порты NAT.
И ещё, чаще всего, DDoS-еры спамят UDP трафиком, поскольку это проще, а значит TCP подключения будут спокойно проходить и интернет в LAN будет работать, но без UDP на время атаки.

Подобную систему возможно реализовать не применяя правила NAT, описанные в статье. Однако имейте в виду, что небольшие сканы и атаки, которые будут превышать ваше ограничение в RAW - будут убивать ваш интернет, поэтому рассчитывайте количество подключений для всех портов с умом. Разумеется, чтобы такое изобрести - вам необходимо полностью отключить все службы управления для интерфейса WAN, и перенаправить их в LAN. Если всё равно потребуется подключение к службе RouterOS - выполните технику Port Knocking. Подробно она написана на тематических сисадминских форумах.

Если возникли вопросы, или вы хотите что-либо реализовать/спросить как сделать - спрашивайте здесь, постараюсь ответить максимально развернуто.

 

[Lappland_Saluzzo]

Статья [Mikrotik] Шаманизм в RouterOS или как я защитил LAN и разгрузил CPU/RAM маршрутизатора через механизмы NAT-PT и Firewall RAW была обновлена:

Прошло два года с момента первой публикации. За это время схема была неоднократно проверена на разных конфигурациях — от домашних роутеров до небольших офисных шлюзов. Выявились некоторые нюансы, которые в первоначальной версии были упущены или описаны не совсем точно.

Что изменилось и почему я переписал часть материала:

Согласование диапазонов портов.
В первых версиях статьи диапазоны в NAT и RAW иногда «разъезжались», что делало схему неработоспособной. Теперь везде используется единый рекомендованный диапазон 12000-18000 со сноской - "используйте 60000-65535" в начале статьи.

Уточнение работы FastTrack и RAW.
Изначально я не до конца понимал, как FastTrack взаимодействует с RAW и почему лимиты не обрезают уже установленные соединения. Дополнительные тесты на RB941-2ND показали, что в RAW попадают только «сигнальные» пакеты, а основной поток их обходит. Это позволило более точно описать принцип работы и дать рекомендации по настройке лимитов.

Блокировка фрагментированных пакетов.
В первоначальной версии правило блокировало фрагментированные пакеты на всех интерфейсах, что могло нарушать работу локальных сервисов (RDP, NFS). Теперь блокировка применяется только к интерфейсу WAN.

Уточнение про Input и Filter.
Я более чётко описал, как RAW отсекает трафик до цепочек Input/Filter, и какую роль играет дополнительное правило Drop в Filter.

Дополнение про проброс портов и FastTrack.
Главное добавление, которое появилось благодаря реальной эксплуатации. Выяснилось, что при включённом FastTrack проброшенные порты могут работать некорректно (лагать, рваться, не открываться у части клиентов). Решение — добавить правило Mangle с действием Route для проброшенных портов. Это «вытаскивает» их из-под некорректного Routing Decision и не жертвует производительностью остального трафика.

Исправление мифов и неточностей.
Убрал утверждение про «утечку LAN-адресов» при masquerade, уточнил терминологию (Tail Drop, Conntrack), добавил пояснения про безопасность через неочевидность (security through obscurity).

 

[Lappland_Saluzzo]

Статья [Mikrotik] Шаманизм в RouterOS или как я защитил LAN и разгрузил CPU/RAM маршрутизатора через механизмы NAT-PT и Firewall RAW была обновлена:

Удалил повторы.

 

[Lappland_Saluzzo]

Статья [Mikrotik] Шаманизм в RouterOS или как я защитил LAN и разгрузил CPU/RAM маршрутизатора через механизмы NAT-PT и Firewall RAW была обновлена:

Запутался в портах, поправил.

 

[Lappland_Saluzzo]

Статья [Mikrotik] Шаманизм в RouterOS или как я защитил LAN и разгрузил CPU/RAM маршрутизатора через механизмы NAT-PT и Firewall RAW была обновлена:

Добавил 4 пункт недостатков. Ручная работа с NAT...

Сообщения автоматически склеены: 27 Мар 2026

Адаптация схемы под Linux (nf_tables)​

Система, описанная в статье, работает не только на RouterOS. Та же логика, адаптированная под nf_tables на Linux-серверах, даёт впечатляющие результаты.
Сухие факты (на железе AMD Epyc 7763):

• Стандартный firewall на Filter(без оптимизации):
  • 2.5 млн пакетов/сек → нагрузка 40–50% на 8 ядрах (по факту 4 ядра в утиль).
  • Conntrack забивается, начинаются потери.
• Фильтрация в RAW(по аналогии со схемой из статьи):
  • 2.5 млн пакетов/сек → нагрузка всего 20% на одном ядре.
  • Conntrack почти не задействован, мусор отсекается на раннем этапе + NOTRACK корректно работает, а не убого как на Mikrotik.

Почему такая разница?
На Linux многие льют правила в filter, не задумываясь, что conntrack — это ресурсоёмкий механизм. Если перенести логику отсева в raw (prerouting) с ранним дропом, лимитами и разрешением только нужных портов — нагрузка падает кратно.

При этом:

• FastPath (или XDP при желании) работает аналогично FastTrack на RouterOS.
• Conntrack используется только для установленных соединений, а не для всего мусора.
• Filter остаётся для тонкой настройки легитимного трафика.

Вывод: схема масштабируется. Родившись на говно-роутере за косарь (на то время) каким-то любителем - она прекрасно работает на мощных серверах, снижая нагрузку в разы и освобождая ресурсы для полезной нагрузки. Она не спасёт от армагеддона и забива порта сервера флудом (хотя это спорно, по тестам - соединения не рвались), но как минимум - запретит серверу или вашим службам умирать под атакой. Но точно спасёт от мамкиных DoS-еров, у которых канал связи - 100 мбит в секунду.

 

[ykpon]

 

[Lappland_Saluzzo]

*** Скрытый текст не может быть процитирован. ***

Вообще да - он щас нынче крайне мощный. Можно - но я ограничиваюсь портом. Был бы он 10-100 гбитный - начал бы смотреть в ту сторону :)
Мне в принципе норм что 1 ядро уничтожает 10 миллионов пакетов стандартными решениями - так что это избыточно уже.
И тем более я держу не хостинг, а VDS сервер обычный где-то в центре Сибири. И всё. - решение избыточное, но работает. Потому что могу.