{sape_links}
Быстрая навигация
802.11ac 802.11ac Wave 2 802.11n Android DVB-T2 Google hAP hAP lite Intel IPSec Keenetic LTE Mikrotik MU-MIMO Netis Realtek RouterBOARD RouterOS Rozetka rozetka.com.ua Strong Trimax Ubiquiti UBNT UniFi wAP 60G Wi-Fi Winbox wireless Zyxel безопасность маршрутизатор настройка обзор обновление промо промо-код прошивка роутер скидкиБазовая защита от DoS-атак и SYN-флуда на устройствах Mikrotik RouterBOARD под управлением RouterOS
01 июнь 2018
96 943
16
В процессе повышения навыков работы с Mikrotik и RouterOS в частности, очень важно иметь в своем распоряжении дополнительное устройство RouterBOARD для возможности проведения разнообразных экспериментов. Почему это так важно?
Операционная система RouterOS кардинально отличается от программного обеспечения, использующегося в домашних и SOHO-маршрутизаторах. Функциональные возможности ROS уже из коробки превосходит возможности таких систем как OpenWRT, DD-WRT и NDMS 2 (используется в устройствах Zyxel Keenetic).
Функций RouterOS настолько много, что среднестатистический сетевой администратор попросту не владеет достаточными знаниями и опытом для работы со всеми функциями устройства.
Всего у Mikrotik имеется 3 уровня. На первом уровне находится единственный сертификат – MTCNA (MikroTik Certified Network Associate), это базовый сертификат, подтверждающий базовые навыки настройки RouterOS, чего будет достаточно большинству специалистов и администраторов.
Второй уровень условно можно назвать «Engineer», по сути это инженерная подготовка. На втором уровне насчитывается уже 5 сертификатов (программ подготовки):
Для того, чтобы получить сертификат MTCINE, обязательно требуется иметь сертификаты MTCNA и MTCRE. Курсы MTCINE нацелены на сетевых инженеров, работающих на уровне провайдера. Среди тем, которые изучаются в рамках данных курсов – использование BGP и MPLS.
Как видите, у Mikrotik имеются отдельные курсы по разным направлениям. Базовым сертификатом является MTCNA, который гарантирует наличие базовых знаний по работе с RouterOS.
В реальных условиях далеко не каждый специалист, работающий с Mikrotik, имеет даже базовый сертификат. Чего уже говорить о домашних пользователях и сотрудниках малого и даже среднего бизнеса. Лично у меня сертификата MTCNA нет, желание правда есть, а вот лишние деньги и время отсутствуют.
К чему все это и почему я сделал столь большое лирическое вступление?
Про последствия неправильной настройки Mikrotik я уже писал, причем на реальных примерах. Несмотря на мое уведомление, один из провайдеров по сей день не закрыл уязвимости в своей сети, и таких примеров найдутся тысячи.
Именно поэтому при работе с Mikrotik для продвинутых пользователей важно хранить логи и иметь дополнительное устройство, на котором можно тестировать различные конфигурации.
В отличие от обычных маршрутизаторов, в Mikrotik достаточно легко наделать ошибок в настройках Firewall, если настраивать систему с ноля по чужим инструкциям или же бездумно добавлять/менять правила.
Само собой разумеется, полноценная защита от DDoS требует:
Но сейчас не об этом. В ряде случаев и конфигураций, уложить «микротик» на лопатки очень просто. Банально, многие владельцы данных устройств страдают от внешних запросов на ихний DNS извне, что приводит к ненужной нагрузке на CPU. Как закрыть доступ к DNS, описывалось ранее, кто пропустил – обратите внимание на пункт 3.
Сейчас, опять же, немного не об этом. На официальном Wiki Mikrotik имеется инструкция под названием «DoS attack protection», именно эту публикацию многие берут за основу, многие её адаптировали под себя, некоторые ресурсы и вовсе просто перепубликовали. В любом случае, в результатах поисковой выдачи это один из первых вариантов.
И тут срабатывает человеческий фактор, ведь реализация описана на официальном Wiki, что в ней может быть не так?
DoS является сокращением от английского «Denial of Service», иными словами отказ в обслуживании. DoS возникает тогда, когда ресурсы CPU загружены на 100%, вследствие чего маршрутизатор может стать недоступным (unreachable).
Соответственно термин DDoS является сокращением от Distributed Denial of Service, т.е. распределенных атак. Такие атаки осуществляются с разных IP и даже целых подсетей, способных генерировать огромные объемы траффика. Для примера, не так давно сервис GitHub был атакован ботнетом с суммарной пропускной способностью 1.35 терабит/сек, после чего сервис попросту «упал» на 10 минут. Владельцу ресурса удалось восстановить полную работоспособность уже через 8 минут, но для этого потребовались огромнейшие вычислительные ресурсы ЦОДов. Ваш домашний или корпоративный маршрутизатор, в случае наличия внешнего белого IP также может подвергнуться самым разнообразным атакам.
В RouterOS ресурсы процессора задействуют многие операции по пакетной обработке, в частности это работа Firewall (Filter, NAT, Mangle), логирование событий, очереди (Queues) – в случае большого количества поступающих пакетов, все это может привести к перегрузке маршрутизатора.
На данный момент не существует идеального решения для противодействия DoS-атакам. Запомните, абсолютно любой сервис может быть перегружен чрезмерно большим количеством запросов.
Тем не менее, существуют методы для минимизации воздействия небольших атак подобного типа. Конечно, если у вас подключение 100 Мбит, от атаки 1 Гбит это вас не защитит. А вот если атака меньше, но использует особенности и/или уязвимости конфигурации, согласитесь, иметь загрузку CPU в 30-60% куда лучше, нежели 100% и полный отказ.
Одним из наиболее эффективных методов атаки является SYN-флуд. Суть атаки заключается в отправке большого количества SYN-запросов на установку TCP-соединения, на которые маршрутизатор должен давать ответ SYN+ACK. Все это отнимает у маршрутизатора ресурсы, в то время как атакующий может игнорировать ответы, что в свою очередь привод к большому количеству полу-открытых соединений (half-open connection) без большой загрузки атакующей стороны. Такие соединения «висят» некоторое время «в воздухе», после чего маршрутизатор закрывает их по таймауту. Проблема состоит в том, что пакеты обрабатываются в порядке очередности и при наличии достаточного количества «мусора», маршрутизатор попросту перестанет обрабатывать запросы от обычных клиентов.
Для просмотра текущих соединений в Terminal можно прибегнуть к команде
А также
Если же вы захотите посмотреть статистику по отдельному интерфейсу, используйте следующий синтаксис:
Для просмотра ресурсов, используйте команду:
Собственно, весь этот функционал продублирован в Winbox, я лишь дублирую информацию из публикации на Wiki.
Как бороться с большим числом соединений?
Для этого нам предлагают воспользоваться командой:
Где LIMIT необходимо заменить на число от 100 и выше. Суть правила в том, что при превышении указанного числа соединений, удаленный IP-адрес будет внесен в черный список (blacklist-ddos) на 1 час. Название списка и таймаут можете поменять по своему усмотрению, главное в последующих командах использовать правильный address-list.
Далее для IP из черного списка необходимо произвести обработку пакетов. Однако, вместо стандартного отброса пакетов «action=drop», нам предлагают выполнять «action=tarpit».
Действие «tarpit» приводит к «захвату» и удержанию TCP-соединений, сам маршрутизатор при этом дает ответ SYN/ACK на входящий TCP SYN. На мощных маршрутизаторах это будет приводить к замедлению атакующего (в теории).
Также можно использовать обычный action=drop, чтобы отбрасывать пакеты даже не отвечая на них. Пробуйте экспериментировать с разными настройками. Ни в коем случае не используйте reject, т.к. он предполагает наличие ответа, который будет отнимать ресурсы.
Далее предложен следующий механизм выявления и обработки SYN-флуда
Обратите внимание, все вышеперечисленные правила необходимо переносить в самый верх Firewall, иначе они попросту не будут работать.
У первого правила присутствует атрибут disabled=yes, иными словами правило отключено. Авторы кода предлагают установить желаемый limit и включить правило в цепочку forward для просмотра количества отброшенных пакетов.
Собственно на этом дальнейшие действия не описаны, и многие читатели просто берут и добавляют правила как есть. Но к этому моменту мы еще вернемся.
Последняя рекомендация состоит в использовании SYN cookies.
Что такое SYN cookies и как это работает? При использовании SYN cookie, в случае переполнения очереди, маршрутизатор будет избегать сброса новых соединений, вместо этого клиенту будет отправлять корректный SYN+ACK со специальными номерами последовательности.
При этом маршрутизатор не будет держать соединение открытым. В случае получения корректного ACK и номеров последовательности от клиента, маршрутизатор восстановит сессию. В то же время, маршрутизатор забракует сессию и не будет восстанавливать соединения в случае, когда номер последовательности неверный, чем обеспечивается защита от подмены ACK.
Таким образом, потенциальный злоумышленник не может обойти межсетевые экраны с SYN cookie, путем простой отправки ACK-пакетов с произвольным номером последовательности.
В момент правки правил на втором (тестовом) устройстве меня немного отвлекли и я добавил правила «как есть», не внеся всех изменений.
Чтоб вы правильно понимали, проверку SYN flood необходимо выполнять в первую очередь на цепочке input, т.к. жертвой злоумышленника является именно внешний IP. В то время как цепочка forward отвечает за транзитный траффик, проходящий через маршрутизатор, например, от клиента за NAT в интернет.
Несколькими часами позже я играл в WOT и ощутил фризы, после чего меня и вовсе выкинуло из сервера, а сам тестовый RB951Ui-2HnD ушел в перезагрузку. Собственно о перезагрузке роутера я понял по звуку встроенного бипера, который при запуске у меня дополнительно проигрывает ноты из «Star Wars - The Imperial March».
Но чем были вызваны фризы и автоматическая перезагрузка маршрутизатора? Вариант с перебоями питания исключаем сразу, т.к. устройство подключено через ИБП.
Открываем логи RouterOS и наблюдаем следующую картину:
Это список всех запросов, идущих через webproxy, записи в логах отображаются по той причине, что у меня настроено расширенное логирование в файл.
Установлена актуальная RouterOS 6.42.3, новых users не прибавилось, в files ничего подозрительного.
Заходим в Gparhing и наблюдаем следующую картину:
На графиках просматривается практически 100% загрузка CPU и высокая загрузка RAM при не таком уж и большом траффике на WAN-порту. Впрочем, старенький AR9344 не самый производительный процессор.
В подменю Tools – Profile можно увидеть более детальное распределение ресурсов.
Но как такое возможно, что кто-то получил доступ к webproxy извне?
Все очень просто, на втором маршрутизаторе я не успел внести правки в правила Firewall. Всему виной action=accept для syn-пакетов. В случае с forward это не так страшно, как для input. Действие «Accept» приводит к тому, что Firewall одобряет пакет, и далее к ним уже не применяются остальные правила.
Вышеперечисленные фильтры осуществляют только фильтр по количеству пакетов, не более, поэтому все пакеты, прошедшие фильтр необходимо далее обрабатывать стандартными правилами.
Для этого воспользуемся action=return. Действие return осуществляется возврат пакета в предыдущий chain, для последующей обработки.
В конечном итоге получаем правила следующего вида:
В данном примере на входе установлено ограничение в 100 соединений на IP, в случае превышения лимитов, IP вносится в blacklist с последующим дропом всех последующих пакетов.
Базовая защита от SYN-флуда реализована путем переброса всех SYN-пакетов в дополнительный чейн SYN-Protect с ограничением в 200 пакетов/сек. Пакеты, не попадающие под ограничения, возвращаются в родительский chain, в случае превышения лимитов – пакеты отбрасываются.
Дополнительно задействована надстройка tcp-syncookies, позволяющая не отбрасывать клиентов, находящихся вне очереди.
Собственно на этом все.
Описанная реализация защиты от DoS-атак и SYN-флуда базовая, она поможет защитить ваше устройство и сеть от перегрузок, вызванных примитивными атаками злоумышленников. В то же время повторюсь, для защиты от полноценных DDoS-атак этого будет недостаточно.
Операционная система RouterOS кардинально отличается от программного обеспечения, использующегося в домашних и SOHO-маршрутизаторах. Функциональные возможности ROS уже из коробки превосходит возможности таких систем как OpenWRT, DD-WRT и NDMS 2 (используется в устройствах Zyxel Keenetic).
Функций RouterOS настолько много, что среднестатистический сетевой администратор попросту не владеет достаточными знаниями и опытом для работы со всеми функциями устройства.
Если Вы хотите научиться настраивать MikroTik, предлагаем пройти онлайн обучение. Более подробную информацию Вы можете найти в конце данной публикации.
Для полного понимания, просто взгляните на перечень сертификатов, выдаваемых авторизованным специалистам.Всего у Mikrotik имеется 3 уровня. На первом уровне находится единственный сертификат – MTCNA (MikroTik Certified Network Associate), это базовый сертификат, подтверждающий базовые навыки настройки RouterOS, чего будет достаточно большинству специалистов и администраторов.
Второй уровень условно можно назвать «Engineer», по сути это инженерная подготовка. На втором уровне насчитывается уже 5 сертификатов (программ подготовки):
- MTCWE (MikroTik Certified Wireless Engineer) – расширенный углубленный курс по настройке беспроводных сетей;
- MTCRE (MikroTik Certified Routing Engineer) – расширенный углубленный курс по статической и динамической маршрутизации;
- MTCTCE (MikroTik Certified Traffic Control Engineer) – расширенный углубленный курс по управлению траффиком и QoS;
- MTCUME (MikroTik Certified User Management Engineer) – расширенный углубленный курс по управлению пользователями и авторизацией (VPN, HotSpot, IPsec и т.д.);
- MTCIPv6E (MikroTik Certified IPv6 Engineer) – расширенный углубленный курс по работе с IPv6;
Для того, чтобы получить сертификат MTCINE, обязательно требуется иметь сертификаты MTCNA и MTCRE. Курсы MTCINE нацелены на сетевых инженеров, работающих на уровне провайдера. Среди тем, которые изучаются в рамках данных курсов – использование BGP и MPLS.
Как видите, у Mikrotik имеются отдельные курсы по разным направлениям. Базовым сертификатом является MTCNA, который гарантирует наличие базовых знаний по работе с RouterOS.
В реальных условиях далеко не каждый специалист, работающий с Mikrotik, имеет даже базовый сертификат. Чего уже говорить о домашних пользователях и сотрудниках малого и даже среднего бизнеса. Лично у меня сертификата MTCNA нет, желание правда есть, а вот лишние деньги и время отсутствуют.
К чему все это и почему я сделал столь большое лирическое вступление?
Про последствия неправильной настройки Mikrotik я уже писал, причем на реальных примерах. Несмотря на мое уведомление, один из провайдеров по сей день не закрыл уязвимости в своей сети, и таких примеров найдутся тысячи.
Именно поэтому при работе с Mikrotik для продвинутых пользователей важно хранить логи и иметь дополнительное устройство, на котором можно тестировать различные конфигурации.
В отличие от обычных маршрутизаторов, в Mikrotik достаточно легко наделать ошибок в настройках Firewall, если настраивать систему с ноля по чужим инструкциям или же бездумно добавлять/менять правила.
С чего все началось?
На домашнем тестовом маршрутизаторе RB951Ui-2HnD у меня уже есть гостевая сеть, Queues, HotSpot, WebProxy, Policy Based Routing, IPsec и прочие надстройки. Буквально на днях я решил протестировать дополнительные настройки Firewall с реализацией базовой защиты от DDoS.Само собой разумеется, полноценная защита от DDoS требует:
- жирный интернет-канал, от 10 Гбит и выше
- наличие резервного канала
- высокопроизводительное оборудование
Но сейчас не об этом. В ряде случаев и конфигураций, уложить «микротик» на лопатки очень просто. Банально, многие владельцы данных устройств страдают от внешних запросов на ихний DNS извне, что приводит к ненужной нагрузке на CPU. Как закрыть доступ к DNS, описывалось ранее, кто пропустил – обратите внимание на пункт 3.
Сейчас, опять же, немного не об этом. На официальном Wiki Mikrotik имеется инструкция под названием «DoS attack protection», именно эту публикацию многие берут за основу, многие её адаптировали под себя, некоторые ресурсы и вовсе просто перепубликовали. В любом случае, в результатах поисковой выдачи это один из первых вариантов.
И тут срабатывает человеческий фактор, ведь реализация описана на официальном Wiki, что в ней может быть не так?
«DoS attack protection» с оговоркой…
Существуют такие термины как DoS и DDoS, сразу оговорюсь, первый термин не стоит путать с MS-DOS, это совершенно разные вещи.DoS является сокращением от английского «Denial of Service», иными словами отказ в обслуживании. DoS возникает тогда, когда ресурсы CPU загружены на 100%, вследствие чего маршрутизатор может стать недоступным (unreachable).
Соответственно термин DDoS является сокращением от Distributed Denial of Service, т.е. распределенных атак. Такие атаки осуществляются с разных IP и даже целых подсетей, способных генерировать огромные объемы траффика. Для примера, не так давно сервис GitHub был атакован ботнетом с суммарной пропускной способностью 1.35 терабит/сек, после чего сервис попросту «упал» на 10 минут. Владельцу ресурса удалось восстановить полную работоспособность уже через 8 минут, но для этого потребовались огромнейшие вычислительные ресурсы ЦОДов. Ваш домашний или корпоративный маршрутизатор, в случае наличия внешнего белого IP также может подвергнуться самым разнообразным атакам.
В RouterOS ресурсы процессора задействуют многие операции по пакетной обработке, в частности это работа Firewall (Filter, NAT, Mangle), логирование событий, очереди (Queues) – в случае большого количества поступающих пакетов, все это может привести к перегрузке маршрутизатора.
На данный момент не существует идеального решения для противодействия DoS-атакам. Запомните, абсолютно любой сервис может быть перегружен чрезмерно большим количеством запросов.
Тем не менее, существуют методы для минимизации воздействия небольших атак подобного типа. Конечно, если у вас подключение 100 Мбит, от атаки 1 Гбит это вас не защитит. А вот если атака меньше, но использует особенности и/или уязвимости конфигурации, согласитесь, иметь загрузку CPU в 30-60% куда лучше, нежели 100% и полный отказ.
Одним из наиболее эффективных методов атаки является SYN-флуд. Суть атаки заключается в отправке большого количества SYN-запросов на установку TCP-соединения, на которые маршрутизатор должен давать ответ SYN+ACK. Все это отнимает у маршрутизатора ресурсы, в то время как атакующий может игнорировать ответы, что в свою очередь привод к большому количеству полу-открытых соединений (half-open connection) без большой загрузки атакующей стороны. Такие соединения «висят» некоторое время «в воздухе», после чего маршрутизатор закрывает их по таймауту. Проблема состоит в том, что пакеты обрабатываются в порядке очередности и при наличии достаточного количества «мусора», маршрутизатор попросту перестанет обрабатывать запросы от обычных клиентов.
Для просмотра текущих соединений в Terminal можно прибегнуть к команде
/ip firewall connection printА также
/tool torchЕсли же вы захотите посмотреть статистику по отдельному интерфейсу, используйте следующий синтаксис:
/interface monitor-traffic [название_интерфейса]Для просмотра ресурсов, используйте команду:
/system resource monitorСобственно, весь этот функционал продублирован в Winbox, я лишь дублирую информацию из публикации на Wiki.
Как бороться с большим числом соединений?
Для этого нам предлагают воспользоваться командой:
/ip firewall filter add chain=input protocol=tcp connection-limit=LIMIT,32 \
action=add-src-to-address-list address-list=blacklist-ddos address-list-timeout=1dГде LIMIT необходимо заменить на число от 100 и выше. Суть правила в том, что при превышении указанного числа соединений, удаленный IP-адрес будет внесен в черный список (blacklist-ddos) на 1 час. Название списка и таймаут можете поменять по своему усмотрению, главное в последующих командах использовать правильный address-list.
Далее для IP из черного списка необходимо произвести обработку пакетов. Однако, вместо стандартного отброса пакетов «action=drop», нам предлагают выполнять «action=tarpit».
Действие «tarpit» приводит к «захвату» и удержанию TCP-соединений, сам маршрутизатор при этом дает ответ SYN/ACK на входящий TCP SYN. На мощных маршрутизаторах это будет приводить к замедлению атакующего (в теории).
/ip firewall filter add chain=input protocol=tcp src-address-list= blacklist-ddos \
connection-limit=3,32 action=tarpitТакже можно использовать обычный action=drop, чтобы отбрасывать пакеты даже не отвечая на них. Пробуйте экспериментировать с разными настройками. Ни в коем случае не используйте reject, т.к. он предполагает наличие ответа, который будет отнимать ресурсы.
Далее предложен следующий механизм выявления и обработки SYN-флуда
/ip firewall filter add chain=forward protocol=tcp tcp-flags=syn connection-state=new \
action=jump jump-target=SYN-Protect comment="SYN Flood protect" disabled=yes
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn limit=400,5 connection-state=new \
action=accept comment="" disabled=no
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn connection-state=new \
action=drop comment="" disabled=noОбратите внимание, все вышеперечисленные правила необходимо переносить в самый верх Firewall, иначе они попросту не будут работать.
У первого правила присутствует атрибут disabled=yes, иными словами правило отключено. Авторы кода предлагают установить желаемый limit и включить правило в цепочку forward для просмотра количества отброшенных пакетов.
Собственно на этом дальнейшие действия не описаны, и многие читатели просто берут и добавляют правила как есть. Но к этому моменту мы еще вернемся.
Последняя рекомендация состоит в использовании SYN cookies.
/ip settings set tcp-syncookies=yesЧто такое SYN cookies и как это работает? При использовании SYN cookie, в случае переполнения очереди, маршрутизатор будет избегать сброса новых соединений, вместо этого клиенту будет отправлять корректный SYN+ACK со специальными номерами последовательности.
При этом маршрутизатор не будет держать соединение открытым. В случае получения корректного ACK и номеров последовательности от клиента, маршрутизатор восстановит сессию. В то же время, маршрутизатор забракует сессию и не будет восстанавливать соединения в случае, когда номер последовательности неверный, чем обеспечивается защита от подмены ACK.
Таким образом, потенциальный злоумышленник не может обойти межсетевые экраны с SYN cookie, путем простой отправки ACK-пакетов с произвольным номером последовательности.
Переходим к практике
Данную инструкцию я взял за основу и добавил на 2 маршрутизатора. На первом маршрутизаторе в Firewall были добавлены немного измененные правила.В момент правки правил на втором (тестовом) устройстве меня немного отвлекли и я добавил правила «как есть», не внеся всех изменений.
Чтоб вы правильно понимали, проверку SYN flood необходимо выполнять в первую очередь на цепочке input, т.к. жертвой злоумышленника является именно внешний IP. В то время как цепочка forward отвечает за транзитный траффик, проходящий через маршрутизатор, например, от клиента за NAT в интернет.
Несколькими часами позже я играл в WOT и ощутил фризы, после чего меня и вовсе выкинуло из сервера, а сам тестовый RB951Ui-2HnD ушел в перезагрузку. Собственно о перезагрузке роутера я понял по звуку встроенного бипера, который при запуске у меня дополнительно проигрывает ноты из «Star Wars - The Imperial March».
Но чем были вызваны фризы и автоматическая перезагрузка маршрутизатора? Вариант с перебоями питания исключаем сразу, т.к. устройство подключено через ИБП.
Открываем логи RouterOS и наблюдаем следующую картину:
Это список всех запросов, идущих через webproxy, записи в логах отображаются по той причине, что у меня настроено расширенное логирование в файл.
Установлена актуальная RouterOS 6.42.3, новых users не прибавилось, в files ничего подозрительного.
Заходим в Gparhing и наблюдаем следующую картину:
На графиках просматривается практически 100% загрузка CPU и высокая загрузка RAM при не таком уж и большом траффике на WAN-порту. Впрочем, старенький AR9344 не самый производительный процессор.
В подменю Tools – Profile можно увидеть более детальное распределение ресурсов.
Но как такое возможно, что кто-то получил доступ к webproxy извне?
Все очень просто, на втором маршрутизаторе я не успел внести правки в правила Firewall. Всему виной action=accept для syn-пакетов. В случае с forward это не так страшно, как для input. Действие «Accept» приводит к тому, что Firewall одобряет пакет, и далее к ним уже не применяются остальные правила.
Вышеперечисленные фильтры осуществляют только фильтр по количеству пакетов, не более, поэтому все пакеты, прошедшие фильтр необходимо далее обрабатывать стандартными правилами.
Для этого воспользуемся action=return. Действие return осуществляется возврат пакета в предыдущий chain, для последующей обработки.
В конечном итоге получаем правила следующего вида:
/ip settings
set tcp-syncookies=yes
/ip firewall filter
add action=add-src-to-address-list address-list=ddos-blacklist \
address-list-timeout=30m chain=input comment=\
"DDoS - Limit incoming connections, add IP to Blacklist" \
connection-limit=100,32 in-interface=ether1-gateway protocol=tcp
add action=tarpit chain=input comment=\
"DDoS - capture and hold connections, try to slow the attacker " \
connection-limit=3,32 protocol=tcp src-address-list=ddos-blacklist
add action=jump chain=forward comment="DDoS - SYN Flood protect" \
connection-state=new jump-target=SYN-Protect protocol=tcp tcp-flags=syn
add action=jump chain=input connection-state=new in-interface=ether1-gateway \
jump-target=SYN-Protect protocol=tcp tcp-flags=syn
add action=return chain=SYN-Protect connection-state=new limit=200,5:packet \
protocol=tcp tcp-flags=syn
add action=drop chain=SYN-Protect connection-state=new protocol=tcp \
tcp-flags=synВ данном примере на входе установлено ограничение в 100 соединений на IP, в случае превышения лимитов, IP вносится в blacklist с последующим дропом всех последующих пакетов.
Базовая защита от SYN-флуда реализована путем переброса всех SYN-пакетов в дополнительный чейн SYN-Protect с ограничением в 200 пакетов/сек. Пакеты, не попадающие под ограничения, возвращаются в родительский chain, в случае превышения лимитов – пакеты отбрасываются.
Дополнительно задействована надстройка tcp-syncookies, позволяющая не отбрасывать клиентов, находящихся вне очереди.
Собственно на этом все.
В заключение
На конкретном примере показано насколько важным является понимание всех тех действий, которые вы проводите с конфигурацией маршрутизатора. Никто не застрахован от чужих ошибок, всего 1 ошибка может привести к серьёзным последствиям и нарушить безопасность устройства и сети в целом. После того, как вы убедились в отсутствии ошибок, перепроверьте конфигурацию за собой повторно.Описанная реализация защиты от DoS-атак и SYN-флуда базовая, она поможет защитить ваше устройство и сеть от перегрузок, вызванных примитивными атаками злоумышленников. В то же время повторюсь, для защиты от полноценных DDoS-атак этого будет недостаточно.
Видеокурс «Настройка оборудования MikroTik» (аналог MTCNA)
Учитесь работать с MikroTik? Рекомендую видеокурс «Настройка оборудования MikroTik». В курсе разобраны все темы из официальной учебной программы MTCNA и много дополнительного материала. Курс сочетает теоретическую часть и практику – настройку маршрутизатора по техническому заданию. Консультации по заданиям курса ведет его автор Дмитрий Скоромнов. Подойдет и для первого знакомства с оборудованием MikroTik, и для систематизации знаний опытным специалистам.