+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Атака TCP SYN Flood вызывает высокую нагрузку на CPU

Атака TCP SYN Flood вызывает высокую нагрузку на CPU, RouterOS

Cha0s

Guest

04.10.2017 15:35:00

Сегодня на одного из моих клиентов попала атака TCP SYN Flood. Атака была не особо сильной (~150-200kpps и пару сотен Мбит/с), но умудрилась почти всё положить. У меня аплинк на 10 гбит, так что физического перегруза канала не было, и я проверил — у моего провайдера тоже никаких проблем с перегрузками не наблюдалось (то есть, атака была не объёмной). Пока FastNetMon не сработал и не заблэкхолил IP жертвы, роутер был фактически недоступен, а всё, что за ним, либо сильно тормозило, либо теряло пакеты. Winbox и SSH вообще не подключались.

Я использую сырые фильтры для no-track всего транзитного трафика. При UDP-атаках даже с 1 млн pps и 7-8 Gbps роутер не морщился — no-track работает как часы! Но вот при TCP SYN Flood роутер просто начал ломаться.

Я не включаю TCP SYN Cookies и не использую трекинг соединений. На короткое время мне удалось зайти в Winbox и я увидел, что основная нагрузка на CPU приходится на модуль «networking». Роутер — CCR1036-8G-2S+ с ROS v6.38.5 и прошивкой FW v3.33.

Кто-то ещё сталкивался с таким? Это нормально? Разве роутер не должен просто пропускать этот трафик? Почему именно SYN Flood вызвала такую нагрузку на CPU? Есть ли советы, как избежать высокого CPU при будущих SYN Flood атаках?

Anumrak Guest	#2 0 26.10.2017 08:58:00 Почему ты не использовал tcp syn cookie? /ip settings set tcp-syncookies=yes

berlo

Guest

26.10.2017 10:09:00

С помощью syncookie вы просите RouterOS выступать в роли прокси, и это немного помогает при SYN-флуд атаках. Еще один трюк, который мы добавили — это поставить в mangle несколько проверок TCP, чтобы помечать и заносить IP в черный список.

/ip firewall> mangle print
Flags: X - отключено, I - недействительно, D - динамически
0 chain=prerouting action=add-src-to-address-list tcp-flags=syn,rst protocol=tcp address-list=ddos-source address-list-timeout=6h in-interface=NETIX log=no log-prefix=""

1 X chain=prerouting action=add-src-to-address-list tcp-flags=!fin,!syn,!rst,!ack protocol=tcp address-list=ddos-source address-list-timeout=6h in-interface=NETIX log=no log-prefix=""

Можно поставить любое правило маркировки, чтобы добавить IP в список адресов. С этим можно просто сбрасывать пакеты с исходящего IP или отправлять его в черную дыру.

texmeshtexas

Guest

12.08.2018 05:25:00

то правило mangle изначально /ip firewall> mangle print
Флаги: X - отключено, I - недействительно, D - динамическое
0 цепочка=prerouting действие=add-src-to-address-list tcp-flags=syn,rst протокол=tcp address-list=ddos-source address-list-timeout=6h входной-интерфейс=NETIX лог=нет префикс_лога=“”
очень похоже, что оно тут же добавляет в список кучу адресов.
Для срабатывания нужно, чтобы оба флага syn И rst были установлены или достаточно syn ИЛИ rst?

sindy

Guest

12.08.2018 09:02:00

Правда в том, что логическая операция между элементами списка не очевидна, но ответ на вопрос «какая логическая операция между значениями списка используется для этого конкретного поля?» — «та, которая полезнее». То есть, пока для dst-port=a,b (и большинства других условий совпадения) единственная логичная операция — «или» (то есть условие разворачивается в dst-port=a или dst-port=b), в случае tcp-flags=a,b полезной в большинстве случаев является операция «и» (то есть условие разворачивается в tcp-flags.a = true и tcp-flags.b = true). Если бы вы (теоретически) хотели совершить одно и то же действие для tcp-flags.syn=true или tcp-flags.rst=true, пришлось бы использовать два правила: одно с tcp-flags=syn, другое — с tcp-flags=rst. Также имейте в виду, что просто tcp-flags=syn не учитывает другие флаги, поэтому если хотите поймать пакеты, где установлен только флаг SYN, нужно использовать tcp-flags=syn,!ack,!cwr,!ece,!fin,!psh,!rst,!urg.

Cha0s Guest	#6 0 16.07.2019 14:10:00 Прошло почти два года, а ничего не изменилось. CCR по-прежнему не могут пропускать (а не отбрасывать) умеренный поток SYN-пакетов.

edwinlai33 Guest	#7 0 19.10.2019 10:04:00 Полностью согласен, много раз страдал.

edwinlai33 Guest	#8 0 31.10.2019 07:39:00 Ты включил FastPath? Если да, то он не должен грузить процессор.

Cha0s Guest	#9 0 01.11.2019 00:36:00 FastPath требует включения кеша маршрутов. При включённом кеше маршрутов роутер становится почти полностью неотзывчивым во время любой средней по мощности SYN-флуд атаки.

edwinlai33 Guest	#10 0 01.11.2019 03:10:00 Если в CCR нет fastpath, производительность хуже, чем у X86 при схожей атаке.

Cha0s Guest	#11 0 01.11.2019 06:12:00 Спасибо за ваше мнение.

rpingar Guest	#12 0 02.11.2019 17:37:00 Мы столкнулись с такой же высокой загрузкой ЦП на CCR и умеренным syn-флудом. В некоторых случаях нам удавалось поймать злоумышленников и отфильтровать их на уровне raw. Но в одном случае поймать их не получается: когда атакующий использует все IP из какого-то /22 для всех наших IP, при этом у каждого исходного IP низкая частота SYN-пакетов. Есть идеи, как их отловить? С уважением, Ros

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры