- Специальный корреспондент
По роду деятельности, я столкнулся с большим количеством вопросов о том, что такое DDoS-атаки, нужно ли с ними бороться (WTF??? конечно, не нужно, пусть все лежит нужно). Зрелым матерым спецам здесь вряд ли будет интересно.
Хочу сразу отметить, что некоторым читателям, погруженным в банковскую тематику, текст может показаться знакомым. И да, он в каком-то виде был выпущен для узкого круга лиц, но поскольку уже прошло достаточно времени, а данные в целом не устарели и автор этого поста был, в основном, автором этого текста, то я решил выложить его на хабр в несколько сокращенном и подредактированном варианте, дабы давать ссылку на этот пост, когда опять начнут задавать вопросы, либо для своих студентов.
Часть 1: То, что вы читаете сейчас. Самый-самый базис: что такое DDoS-атака и основные типы атак, с примерами
Часть 2: Защита от DDoS-атак (WAF и все-все). Пока в процессе.
DDoS (Distributed DoS: распределённый DoS) – разновидность DoS-атаки, реализующая отказ системы в обслуживании посредством исчерпания тех или иных вычислительных ресурсов самой атакуемой системы или внешних сервисов, от функционирования которых зависит работа атакуемой системы (транзитные операторы связи, источники данных и т. д.).
Целью DoS/DDoS-атак является блокировка возможности сервиса адекватно и своевременно реагировать на запросы настоящих, легитимных клиентов, вплоть до полной невозможности работы с сервисом. Причинами атаки могут быть: недобросовестная конкуренция; хактивизм - когда атакующий в большей степени мотивирован идеологическими разногласиями; вымогательство; шпионаж; политические мотивы в качестве самовыражения и т.д., а также маскировка работ по проникновению в инфраструктуру (отвлечение внимания на факт атаки, чтобы скрыть какие-то иные шумные "работы" по проникновению).
1. Атаки на сетевые ресурсы (Network floods, L3), целью которых является исчерпание канальной ёмкости как самой атакуемой системы, так и её поставщиков доступа в сеть Интернет, а также транзитных операторов связи. Исторически, это самый простой для атакующего вариант, поскольку обычно не требовалась установка TCP-соединения с компьютером жертвы. Примерами таких атак являются ICMP- и UDP- flood. В отдельный подкласс обычно выделяют, так называемые, Amplification-атаки. Их отличительной особенностью является использование промежуточных уязвимых компьютеров для увеличения «плеча» атаки в 2-3 раза. Amplification-атаки классифицируются в зависимости от протокола, используемого для усиления мощности атаки: NTP Amplification, DNS Amplification, SSDP Amplification и подобное.
2. Атаки на инфраструктуру, целью которых является нарушение нормального (штатного) функционирования промежуточного и служебного оборудования: маршрутизаторов, межсетевых экранов и т.д. В качестве таких атак могут выступать SYN flood, Route Loop DDoS и пр. Кривые анонсы BGP, которые были на слуху, тоже можно отнести к такого типа атакам. Хотя и не всегда они были вызваны злонамеренными действиями, а объяснялись банальной криворукостью.
3. Атаки на транспортный уровень (L4), в частности, с использованием различных этапов TCP-соединения. Это связано с тем, что протокол TCP достаточно сложен с вычислительной точки зрения и допускает эксплуатацию атакующим ряда узких мест, например, алгоритмов установления и закрытия TCP-соединения. В качестве примеров такой атаки могут выступать SYN Flood, ACK Flood, TCP Connection Flood и подобные. Ну, в целом это наиболее распространенная атака в силу простоты ее реализации.
4. Атаки на встроенные механизмы протоколов SSL/TLS. Эти протоколы ещё более сложны, чем TCP, поэтому атакующий может ставить своей целью воздействие на них. Например, можно говорить об атаках на сам процесс установки SSL/TLS взаимодействия (TLS handshake), отправке «мусорных» пакетов серверу или злоупотреблении функциями согласования ключевой информации и подобное.
5. Атаки на сервис прикладного уровня (L7-атаки). Эти атаки взаимодействуют непосредственно с приложением, причём надо отметить, что в последние годы это воздействие распространяется не только на «классический» HTTP, но и на HTTPS, DNS, VoIP, SMTP, FTP и другие прикладные протоколы. В случае c протоколом HTTP, атакующий может дополнительно маскировать свои деструктивные действия внутри SSL/TLS-трафика, что значительно усложняет противодействие. Такие атаки могут подразделяться на следующие виды:
a. Медленные атаки малого объема, так называемые «Low and Slow». Этот вариант представляет опасность в силу малой заметности и продолжительного времени нарастания зловредного воздействия. Обычно здесь речь идет о воздействии на приложения и иногда на серверные ресурсы;
b. Атаки, основанные на значительном числе произвольных «мусорных» запросов. Целью таких атак обычно является мощный «кумулятивный» удар по системе, вследствие которого она долгое время не сможет обрабатывать запросы от легитимных пользователей. Характерным примером является атака типа Wordpress Pingback DDoS. Хотя эта атака однозначно обнаруживается и фильтруется по типовым HTTP-заголовкам, тем не менее, она может составлять серьёзную проблему для атакуемого ресурса, поскольку полоса такой атаки может достигать десятков Гбит/с и в состоянии превысить показатели по доступности канальной ёмкости и производительности HTTP-сервера;
c. Атаки, имитирующие поведение легитимного пользователя. В отличие от предыдущей разновидности, такие атаки используют большое количество неагрессивных ботов, что затрудняет анализ в режиме реального времени. Зачастую эти механизмы используют «узкие места» или уязвимости в web-приложениях и остальной инфраструктуре. Это может привести к несанкционированному доступу к системе, потерям и несанкционированным изменениям данных. Для обнаружения «узких мест» атакующий может использовать сканирование сети – действие, которое, на первый взгляд, представляется безвредным, поскольку само по себе не приносит урона, но на самом деле позволяет получить информацию, которая поможет в дальнейшем атаковать систему.
Что такое L3/L4/L7, про которые часто упоминается в тексте?
L3 / L4 / L7 - названия уровней представления по сетевой модели ISO/OSI. Не вдаваясь в дискуссии, нужна/не нужна эта модель, жива она или мертва - в данном случае это не суть - опишу кратко:
Что есть ошибки 5хх?
Ошибки 5хх - серия кодов ошибок состояния HTTP, которые отдает сервер, когда не может обработать запрос пользователя. Чаще всего отдает 500 - "внутренняя ошибка сервера" или 502 "Bad Gateway" / 503 "Сервер недоступен". Для интересующихся, полный список можно прочитать в Википедии:
Принцип работы ICMP flood достаточно прост. На узел жертвы отправляется простой эхо-запрос (ICMP Echo Request), который требуется обработать и отправить эхо-ответ; при ответе потребуется задействовать больше ресурсов по сравнению с обычным пакетом, хотя сам запрос по объему небольшой.
В результате, при относительно небольшом трафике, можно добиться перегрузки по количеству пакетов. Атакуемый узел начинает работать нестабильно, терять пакеты.
При этом генерация большого числа корректных эхо-запросов (в т.ч. с поддельным IP-адресом источника) – алгоритмически тривиальная задача. Таким образом, в ходе атаки может быть сгенерирован весьма значительный объём трафика, что позволит атакующему исчерпать канальную ёмкость атакуемого узла.
Усиление атаки достигается использованием бот-сети («ботнета»), когда запросы приходят с тысяч узлов. Кроме этого, можно отправить запрос по широковещательному адресу с поддельным адресом-источника пакета (так называемые Smurf-атаки). Отправка эхо-запроса ICMP на широковещательный адрес заставляет все узлы в этой сети отправить эхо-ответы на подмененный адрес, который и является адресом жертвы, то есть происходит усиление атаки (Amplification). Схема на рисунке ниже.
UDP flood
Принципы атаки схожи с предыдущим вариантом и заключаются в отправке множества UDP-пакетов на определённые номера портов атакуемого узла, который для каждого полученного пакета должен идентифицировать соответствующее приложение, отправив ответное ICMP-сообщение «адресат недоступен» или, в худшем случае, передать данные UDP-пакета пользовательскому приложению и оттранслировать полученный ответ.
В итоге, атакуемая система окажется перегруженной, поэтому после начала атаки зловредный трафик может быстро захватить всю доступную полосу пропускания, не оставив ничего легитимному трафику, что и является целью атакующего – не дать работать легитимным пользователям. Подменив IP‑адреса источников в UDP-пакетах, атакующий может перенаправить поток ICMP-ответов и тем самым сохранить работоспособность атакующих узлов, а также обеспечить их маскировку.
Следует отметить, что ни ICMP flood, ни UDP flood не используют уязвимостей системы, то есть мы имеем дело со стандартными принципами работы стека протокола TCP/IP.
Кроме того, существуют методы, позволяющих значительно (в 10-1000 раз) усилить атаку, например, направив исходный трафик атаки не непосредственно на атакуемый узел, а на уязвимый промежуточный сервер, обеспечивающий усиление (Amplification).
Атаки на транспортный уровень
Атаки на транспортном уровне сети обычно эксплуатируют основные «узкие места» в реализации протокола TCP при установке сессии. Обычно это либо этап установления сессии, либо атака на таблицу соединений протокола TCP. Ниже разберем основные типы атак.
SYN flood
Атака типа SYN flood эксплуатирует особенность стека протоколов TCP/IP – потребность установки TCP-сессии. В отличие от UDP, где это не требуется, при TCP-взаимодействии необходимо, чтобы отправитель «договорился» с получателем перед тем, как что-то будет отправлено. Для этого используется механизм three-way handshake – «тройного рукопожатия», или трехэтапного подтверждения. Принцип его работы выглядит следующим образом:
1. Клиент посылает пакет с TCP-сегментом SYN (Synchronize);
2. Сервер отвечает пакетом с сегментом SYN-ACK (Synchronize-Acknowledge);
3. Клиент подтверждает прием пакета SYN-ACK пакетом ACK (Acknowledge).
На этом процедура установления соединения завершается. Но, что существенно, сервер обязан выделить все необходимые ресурсы в момент получения SYN-сегмента от клиента, до отсылки ответного пакета SYN-ACK.
Установив фальшивый IP-адрес отправителя и отправив серверу большое количество SYN-пакетов. Генерация корректного SYN-сегмента – алгоритмически тривиальная задача. Получая пакет SYN, сервер должен выделить часть своих ресурсов для установления нового соединения. В конце концов все ресурсы сервера будут исчерпаны, что приведет к невозможности обслуживания новых запросов. Цель атакующего достигнута.
Для борьбы с атакой типа SYN flood обычно используются механизмы SYN Cookies и/или SYN Proxy. Суть их в том, что в момент получения SYN‑сегмента сервер не выделяет ресурсы, а кодирует всю необходимую информацию вместе с секретным токеном и отправляет её в ответном сегменте SYN-ACK. Легитимный клиент, устанавливающий соединение со своего реального IP-адреса, получит этот сегмент и перешлет эту информацию обратно в сегменте ACK, после чего сервер действительно выделит ресурсы и установит соединение. Атакующий, подделывая IP-адреса, закодированные данные не получит и корректное подтверждение отправить не сможет, таким образом, соединение не установится.
Сложность использования этих методов состоит в том, что для генерации SYN Cookies необходимы адекватные текущему уровню атак вычислительные мощности и сетевые ресурсы с пропускной способностью от 100 Гбит/с и более. Защищённая инфраструктура должна обладать этими ресурсами в обязательном порядке.
TCP Connection Flood
Другое «узкое место» протокола TCP – таблица соединений. Используя бот-сеть, атакующий может генерировать с реальных IP-адресов бот-сети TCP-соединения (каждое из которых фактически будет стоить ему двух тривиальных TCP-пакетов), заполняя таблицу TCP-соединений атакуемого сервера, а также расходуя ресурсы на заполнение нижестоящих таблиц (например, таблица отслеживания соединений – connection tracking – при NAT) и вышестоящие (как число файловых дескрипторов HTTP-сервера) ресурсы.
Для более успешного противодействия такой атаке обычно ограничивают таймауты на установление и поддержание (в состоянии бездействия, idle time) TCP-соединений. Как правило, оптимальное значение – около 60 секунд, но оно может варьироваться в зависимости от задач, возложенных на сервер.
В общем случае, если TCP-соединение клиента с сервером действительно установлено и тем самым IP-адрес клиента аутентифицирован, для борьбы с подобного рода атаками на автомат (тут под словом "автомат" подразумевается математическая модель функционирования протокола ТСР, представленная в виде конечного автомата - для желающих изучить подробнее - ссылка ) TCP и таблицу соединений используются эвристические методы применительно к данному конкретному ресурсу и его типовым параметрам взаимодействия по протоколу TCP. В случае обнаружения клиентов, чьё поведение значительно отличается от типичного, например, числом открываемых в единицу времени соединений, медленными запросами и/или ответами, нестандартными переходами по автомату TCP-соединения и пр. – такой IP-адрес заносится в «чёрный список» и в дальнейшем – или, по крайней мере, в течение некоторого промежутка времени – соединения с этого IP-адреса не обрабатываются.
Необходимо при этом учитывать, что на сегодняшний день массовое установление большого числа TCP-соединений с поддельного IP-адреса в общем случае практически сложнореализуемо, однако установление одного spoofed-соединения с определённого IP-адреса – за продолжительный промежуток времени – в ряде случаев технически реализуемо. Таким образом, «чёрные списки» являются удобным механизмом для фильтрации DDoS-атак, основанных на протоколе TCP (или на протоколах верхнего уровня, использующих TCP на транспортном уровне). Однако к «чёрным» и «белым» спискам как методам авторизации пользователей на ресурсе следует относиться с определенной долей осторожности.
В то же время, категорически нельзя использовать «чёрные списки» для фильтрации любых атак, не задействующих открытые TCP-соединения, например, для борьбы с SYN flood или ICMP flood. Использование «чёрных списков» для этой цели может привести к недоступности сервиса для легитимных пользователей, а в дальнейшем – к исчерпанию памяти и других вычислительных ресурсов средства фильтрации трафика.
Атаки, основанные на протоколе SSL/TLS
HTTPS Flood – атака на Secure Socket Layer (SSL): с ростом популярности этого метода шифрования, используемого в различных сетевых протоколах, он также стал мишенью для атакующих. Концептуально SSL или его современная версия – TLS – используется поверх TCP/IP, обеспечивая безопасность соединений путем шифрования и аутентификации сторон.
DDoS-атаки, связанные с протоколом SSL/TLS, принимают различные формы: они могут быть нацелены на механизм взаимодействия при установлении SSL/TLS-сессии и выражаться в отправке «мусорных» данных на сервер SSL/TLS или эксплуатации определенных функций, связанных с процессом согласования ключей шифрования SSL/TLS. Такого рода атаки обычно считаются «асимметричными», так как сервер расходует на обработку атаки с использованием SSL/TLS гораздо больше ресурсов, чем требуется для ее запуска.
Например, атака THC-SSL-DoS использует малое количество пакетов для приведения в состояние «отказ в обслуживании» даже достаточно мощного сервера. В ходе этой атаки сначала инициируется SSL взаимодействие для установки сессии, а затем немедленно запрашивается процедура повторного согласования ключа шифрования.
Этот инструмент постоянно повторяет запрос на повторное согласование до тех пор, пока все ресурсы сервера не будут исчерпаны. Атакующие предпочитают запускать атаки с использованием SSL, потому что установка каждой сессии SSL требует примерно в 15 раз больше ресурсов на стороне сервера, чем на стороне клиента. Фактически, один обыкновенный домашний персональный компьютер при определенных условиях может вывести из строя целый web‑сервер, использующий SSL, а несколько компьютеров могут вывести из строя всю серверную часть (даже целую ферму) защищенных онлайн сервисов.
Атаки на web-приложения
Наиболее распространенными DDoS-атаками, нацеленными на приложения, являются разновидности атак на протокол HTTP. В литературе для обозначения таких атак обычно используется обобщенный термин HTTP flood. Обычно для их осуществления используется бот-сеть из зараженных устройств, но в ряде случаев в состав атакующих вполне могут входить и добровольцы, например, когда речь идет о целенаправленной хактивистской деятельности.
В атаке могут использоваться любые HTTP-запросы, но обычно используют GET и POST. Атака также может осуществляться с использованием шифрованных TLS-сессий. Конечной целью атаки является исчерпание ресурсов web‑приложения. Тут надо понимать, что "железных" ресурсов сервера еще может оставаться много - и незабитого канала тоже может (но не обязательно) остаться много. Но узким местом станет именно само веб-приложение: из-за особенностей конфигурации или в силу других причин оно либо просто перестанет обслуживать легальные запросы, либо просто упадет.
Атака осуществляется следующим образом: отправляется небольшой по объему HTTP-запрос, в ответ на который сервер должен прислать куда больший объем информации. Несомненно, канал сервера во много раз «шире» канала, который использует атакующий, но ведь и отдавать информации приходится намного больше; кроме того, не составит труда подменить IP-адрес источника.
Следовательно, ответные пакеты сервера не вызовут эффекта отказа в обслуживании атакующего узла, более того, таких узлов может быть огромное количество.
Угрозы от этой атаки - исчерпание канальной емкости и отказ на уровне обработки запросов, так как у любого HTTP-сервера, а тем более – web-приложения или ресурсов, обеспечивающих его работу (система авторизации, СУБД и др.), есть свой предел производительности. В результате, легальный запрос не будет обработан, а пользователь не получит своей порции цифрового контента.
HTTP-атаки с использованием шифрования (HTTPS Flood)
В настоящее время практически все разработчики используют в своих приложениях SSL/TLS для шифрования трафика и обеспечения сквозной безопасности при передаче данных. Любая DDoS-атака на приложение, допускающее шифрование, может быть запущена поверх трафика, зашифрованного SSL/TLS, что создает определенные трудности в ее идентификации. Большинство технологий противодействия DoS атакам не производят реальной проверки трафика SSL, так как это требует расшифровки зашифрованных данных.
Wordpress Pingback DDoS
Определенная популярность есть у Reflection DDoS-атак уровня L7 (приложений). Наиболее характерным примером такой атаки является Wordpress Pingback DDoS, которую и рассмотрим.
Основной её принцип заключается в следующем. Чрезвычайно распространённый web-фреймворк Wordpress до определенных версий предоставлял публичное API, позволяющее запросить любую web-страницу с любого удалённого HTTP-сервера без авторизации. Таким образом, отправив небольшой (до 400 байт) запрос на уязвимый Wordpress-сервер, можно было инициировать загрузку любой крупной страницы (или файла, если это возможно без авторизации) с атакуемого сервера на уязвимый сервер.
В ходе такой атаки определённая нагрузка ложится и на уязвимый Wordpress-сервер, однако, в силу того, что в нападении участвует несколько тысяч Wordpress-серверов и атака разделяется между ними примерно равномерно, нагрузка на каждый отдельный сервер обычно не является критичной и может быть даже не замечена системным администратором на фоне ежедневной средней загрузки. Основная же доля нагрузки приходится именно на атакуемый ресурс.
Интересно, что эта атака, несмотря на то, что Wordpress давно исправил уязвимость была популярна и в 2021, и 2022 г, поскольку в Интернете находилось порядка нескольких миллионов Wordpress-серверов, пригодных для эксплуатации в атаке типа Wordpress Pingback DDoS, и, как минимум, в ряде инцидентов принимало участие одновременно до 350 тыс. уязвимых серверов. Так как в большинстве случаев фреймворк Wordpress развёрнут не на рабочей станции (как обычный модуль бот-сети), а на сервере с неплохой производительностью и канальной ёмкостью, то атаки типа Pingback DDoS на канальном уровне достигали уровня в 10 Гбит/с и более.
В тоже время, атака типа Wordpress Pingback DDoS, организуемая на HTTP-ресурс без шифрования, достаточно легко идентифицируется и несложно фильтруется при наличии достаточной производительности и канальной ёмкости (от 20 Гбит/с).
Важной особенностью Pingback-атаки является то, что уязвимый сервер в состоянии запрашивать произвольные крупные web-страницы как по HTTP, так и по HTTPS, то есть внутри зашифрованной SSL/TLS-сессии. Это приводит к невозможности фильтрации такой Reflection-атаки при отсутствии адекватных механизмов анализа зашифрованного трафика. Для борьбы с Pingback DDoS в общем случае требуется раскрытие текстовой информации, содержащейся внутри TLS-сессий.
В целом, не надо думать, что Pingback-атаки характерны только для Wordpress. Они могут вылезти на любом приложении, которое позволяет перенаправить запрос (в силу своей архитектурной особенности или ошибок конфигурации). Поэтому, очень важно, при настройке веб-приложений максимально минимизировать возможности запросов для неавторизованных пользователей - особенно это касается той части, которая отвечает за обработку API.
Full Browser Stack-атаки и имитация поведения пользователя
Одной из самых сложной для идентификации и фильтрации разновидностью атаки уровня приложения являются, так называемые, FBS‑атаки (от англ. «Full Browser Stack» – полноценная среда браузера). В этом случае для генерации паразитных запросов используются не обычные легковесные библиотеки, имитирующие браузер, а полноценный экземпляр браузера, способный корректно формировать запросы (либо качественный эмулятор), загружать с атакуемого web-сервера изображения и CSS-стили, выполнять HTTP-переадресацию и JavaScript-код. Такую атаку очень сложно отследить и классифицировать, анализируя каждый пакет или каждый запрос в отдельности, поскольку каждый отдельный запрос полностью легитимен и идентичен пользовательскому.
Для борьбы с такими атаками недостаточно тривиальных проверок наподобие HTTP-редиректов и JavaScript-проверок. Используются, как правило, нестрогие статистические алгоритмы, анализ истории поведения пользователей, поиск закономерностей и мониторинг состояния защищаемого сервера. Подобный анализ, как правило, чрезвычайно вычислительно сложен и подразумевает хранение больших объёмов данных с возможностью быстрого поиска по ним. Таким образом, решение по фильтрации атак уровня приложения (L7-атак) должно быть в состоянии работать с большими объёмами данных в реальном времени.
Следует отметить, что подобные атаки необязательно будут организованы именно посредством бот-сети. В ряде случаев они проводятся хактивистами, т.е. живыми людьми. В этом случае распространённое решение с демонстрацией изображений или решения головоломок типа CAPTCHA также может быть неэффективным, хотя, безусловно, создающее дополнительные трудности атакующему.
Медленные атаки малого объема (Slow and Low)
DDoS атаки не всегда подразумевают большой объем трафика и бот-сети из сотен узлов. Иногда вполне достаточно даже одного компьютера, чтобы остановить работу сервиса. Существует целый класс атак, направленных на приложения, то есть работающих на L7 (прикладном) уровне модели ISO/OSI, использующих минимум ресурсов. Зачастую бывает вполне достаточно и одного компьютера, используются стандартные принципы работы прикладных протоколов. Но их негативное воздействие оказывается весьма значительным, вплоть до полной остановки работы сервисов.
Речь идет о медленных атаках небольшого объема («Slow and Low»). Ниже приведены некоторые представители подобного рода атак.
Are You Dead Yet / RUDY
Принцип этой атаки базируется на стандартном поведении протокола HTTP при обработке запросов POST.
Предположим, имеется web-сайт, на котором находится форма для ввода данных, которую необходимо заполнить пользователю. Например, это характерно для финансовых учреждений, банков, интернет-магазинов, систем бронирования билетов, любого сайта, на котором требуется аутентификация и т.д.
Когда легитимный пользователь заполняет web-форму, на сайт отправляется всего несколько пакетов, после чего сессия с web-сервером закрывается, ресурсы освобождаются. Сервер готов обслуживать запросы других пользователей. Атакующий, использующий специальный инструмент, например, RUDY (сам инструмент достаточно древний и стал именем нарицательным для подобных инструментов, которые разрабатываются и в 2022), действует иначе. Отправляемые на web-сервер данные разбиваются на множество мелких пакетов, каждый из которых содержит лишь небольшой объем данных, например, один байт. Запросы на сервер отправляются со случайным интервалом, что не дает возможность серверу сразу закрыть сессию, поскольку передача данных еще не завершена.
Несколько тысяч таких запросов в течение нескольких минут приводят к тому, что сервер не может отвечать на запросы легитимных пользователей.
Но в данном случае не требуется большой объем трафика или значительное количество пакетов, чтобы вывести ресурс из строя. Все запросы абсолютно легитимны, здесь имитируется поведение системы с медленным каналом связи. Цель атакующего достигнута – работать с сайтом невозможно. Подобная уязвимость характерна практически для любого сайта. Поэтому для отсечки таких атак целесообразно использовать очистку трафика.
SlowLoris
Если этот раздел читают "старички в ИБ", то тут наверное они усмехнутся: LOIC, HOIC, HULK, SLOWLORIS - это набор скрипткиддисов, не так ли?
И зачем раскапывать стюардессу. Но как бы ни так - и инструменты, и методы внезапно ожили в 2021 / 2022 - пруф, к примеру, отчет Radware (
). Поэтому желательно знать принципы таких атак.
Атака SlowLoris, также как и предыдущая, базируется на стандартном поведении протокола HTTP при обработке запросов. Для закрытия HTTP сессии необходимо прислать соответствующую последовательность.
Собственно говоря, так и поступает легитимный пользователь. Правильный запрос на получение данных с web-сервера (Get Request) обычно состоит из одного пакета и завершается специальной последовательностью в конце для разрыва сессии.
Суть атаки заключается в следующем: используя специальный инструмент SlowLoris или подобные, атакующий генерирует множественные подключения к целевому web-серверу, при этом соединения не закрываются, поскольку в запросе будет отсутствовать соответствующая последовательность символов. В результате, ресурсы сервера будут исчерпаны и легитимные пользователи не смогут подключиться. Цель атакующего достигнута – работать с сайтом невозможно. Большой объем трафика или значительное количество пакетов не требуется, чтобы вывести ресурс из строя.
В целом, не сказать, что атака является достаточно серьезной проблемой, если вы озаботились защитой от DDoS-атак. Но для слабо защищенных веб-серверов она может стать проблемой, несмотря на хорошую детектируемость.
DNS flood
Другим характерным примером атаки на приложения, не связанным напрямую с протоколом HTTP, является DNS flood. Организация его не составляет большого труда, что, собственно, и послужило залогом его большого распространения.
Как известно, серверы DNS служат для разрешения имен в IP-адреса. Основная задача DNS сервера – найти требуемый адрес, чтобы компьютер смог обратиться на искомый сайт. Атака построена на принципах взаимодействия клиента и сервера DNS. Атакующий, используя бот-сеть, посылает множество запросов на сервер жертвы. Сервер перегружен и не сможет разрешать имена по запросам легитимных пользователей, и следовательно, они не смогут обратиться на требуемый им ресурс, поскольку не смогли разрешить его имя в адрес (при этом, в подавляющем большинстве случаев можно обратиться на сервер по его IP-адресу).
Усиление атаки достигается за счет того, что DNS использует в качестве транспортного протокол UDP, который не требует установки соединения, то есть без использования «троекратного рукопожатия» (three-way handshake), не аутентифицирует удалённую сторону и работает без сохранения состояния соединения. Это дает возможность атакующему свободно подменять IP-адрес отправителя в запросе к DNS-серверу на поддельный адрес, а также направлять ответы других DNS-серверов в адрес его жертвы (DNS Reflection).
Наверное, на этом стоит закончить длинное описание атак, но нужно упомянуть OWASP (Open Web Application Security Project) - это сообщество ведет периодически обновляемый список , в котором перечислены наиболее опасные уязвимости в системе безопасности web-приложений. Использование уязвимостей из этого списка зачастую приводит к различным нарушениям в работе web-приложения либо к его полной остановке, что по сути является DoS.
В чем опасность сканирования применительно к DDoS?
Сканирование сети - и использование сетевых сканеров - означает разведку сети. Обычно стараются достичь следующих целей (одной или нескольких):
Сканирование бывает активным и пассивным. Активному сканированию вы можете противостоять, но пассивному противостоять сложнее, т.к. в этом сценарии атакующий не проводит непосредственно сканирование вашей инфраструктуры, а получает информацию о ней из других источников, например, Shodan.
К сожалению, некоторые компании, специализирующиеся на защите от DDoS-атак, не рассматривают сканирование в качестве атаки и не считают нужным ему противостоять. Действительно, на первый взгляд, никакого вреда системе нет. Тем не менее, с таким подходом трудно согласиться: как уже говорилось выше, практически всегда сканирование предваряет атаку, позволяя атакующему выяснить, какие сервисы работают в целевой системе, версию сервисов, версию операционных систем, назначение систем и сервисов и впоследствии подготовить и провести целенаправленную атаку.
В тоже время, само по себе сканирование не всегда является злонамеренным действием, все зависит от его целей. Службы информационной безопасности или сотрудники ИТ вполне могут прибегнуть к сканированию для выявления уязвимостей инфраструктуры и выполнения иных задач.
Возможны сочетания нескольких способов злонамеренного воздействия одновременно. Достаточно нескольких минут для изменения воздействия на атакуемые ресурсы, а одного вида атаки, который успешно осуществлен – для остановки работы целевой системы. На рисунке ниже сделана попытка показать, на какую цель направлен какой вектор:
Хочу сразу отметить, что некоторым читателям, погруженным в банковскую тематику, текст может показаться знакомым. И да, он в каком-то виде был выпущен для узкого круга лиц, но поскольку уже прошло достаточно времени, а данные в целом не устарели и автор этого поста был, в основном, автором этого текста, то я решил выложить его на хабр в несколько сокращенном и подредактированном варианте, дабы давать ссылку на этот пост, когда опять начнут задавать вопросы, либо для своих студентов.
Краткий пересказ всех частей
Поскольку материала набралось достаточное количество, решил разнести в несколько постов, чтобы проще было читать.Часть 1: То, что вы читаете сейчас. Самый-самый базис: что такое DDoS-атака и основные типы атак, с примерами
Часть 2: Защита от DDoS-атак (WAF и все-все). Пока в процессе.
DDoS - и что это?
DoS (от англ. Denial of Service: отказ в обслуживании) – атака на вычислительную систему, целью которой является отказ системы в обслуживании, то есть создание таких условий, при которых легальные пользователи системы не могут получить доступ к системным ресурсам либо этот доступ существенно затруднен.
DDoS (Distributed DoS: распределённый DoS) – разновидность DoS-атаки, реализующая отказ системы в обслуживании посредством исчерпания тех или иных вычислительных ресурсов самой атакуемой системы или внешних сервисов, от функционирования которых зависит работа атакуемой системы (транзитные операторы связи, источники данных и т. д.).
Целью DoS/DDoS-атак является блокировка возможности сервиса адекватно и своевременно реагировать на запросы настоящих, легитимных клиентов, вплоть до полной невозможности работы с сервисом. Причинами атаки могут быть: недобросовестная конкуренция; хактивизм - когда атакующий в большей степени мотивирован идеологическими разногласиями; вымогательство; шпионаж; политические мотивы в качестве самовыражения и т.д., а также маскировка работ по проникновению в инфраструктуру (отвлечение внимания на факт атаки, чтобы скрыть какие-то иные шумные "работы" по проникновению).
Какой он вообще бывает, дедос
DDoS - он такой, разный. Но все ж особой фантастики тут нет, достаточно прозаичные вещи. От L3 (сетевой уровень) до L7 (прикладной). Обычно классифицируют так:1. Атаки на сетевые ресурсы (Network floods, L3), целью которых является исчерпание канальной ёмкости как самой атакуемой системы, так и её поставщиков доступа в сеть Интернет, а также транзитных операторов связи. Исторически, это самый простой для атакующего вариант, поскольку обычно не требовалась установка TCP-соединения с компьютером жертвы. Примерами таких атак являются ICMP- и UDP- flood. В отдельный подкласс обычно выделяют, так называемые, Amplification-атаки. Их отличительной особенностью является использование промежуточных уязвимых компьютеров для увеличения «плеча» атаки в 2-3 раза. Amplification-атаки классифицируются в зависимости от протокола, используемого для усиления мощности атаки: NTP Amplification, DNS Amplification, SSDP Amplification и подобное.
2. Атаки на инфраструктуру, целью которых является нарушение нормального (штатного) функционирования промежуточного и служебного оборудования: маршрутизаторов, межсетевых экранов и т.д. В качестве таких атак могут выступать SYN flood, Route Loop DDoS и пр. Кривые анонсы BGP, которые были на слуху, тоже можно отнести к такого типа атакам. Хотя и не всегда они были вызваны злонамеренными действиями, а объяснялись банальной криворукостью.
3. Атаки на транспортный уровень (L4), в частности, с использованием различных этапов TCP-соединения. Это связано с тем, что протокол TCP достаточно сложен с вычислительной точки зрения и допускает эксплуатацию атакующим ряда узких мест, например, алгоритмов установления и закрытия TCP-соединения. В качестве примеров такой атаки могут выступать SYN Flood, ACK Flood, TCP Connection Flood и подобные. Ну, в целом это наиболее распространенная атака в силу простоты ее реализации.
4. Атаки на встроенные механизмы протоколов SSL/TLS. Эти протоколы ещё более сложны, чем TCP, поэтому атакующий может ставить своей целью воздействие на них. Например, можно говорить об атаках на сам процесс установки SSL/TLS взаимодействия (TLS handshake), отправке «мусорных» пакетов серверу или злоупотреблении функциями согласования ключевой информации и подобное.
5. Атаки на сервис прикладного уровня (L7-атаки). Эти атаки взаимодействуют непосредственно с приложением, причём надо отметить, что в последние годы это воздействие распространяется не только на «классический» HTTP, но и на HTTPS, DNS, VoIP, SMTP, FTP и другие прикладные протоколы. В случае c протоколом HTTP, атакующий может дополнительно маскировать свои деструктивные действия внутри SSL/TLS-трафика, что значительно усложняет противодействие. Такие атаки могут подразделяться на следующие виды:
a. Медленные атаки малого объема, так называемые «Low and Slow». Этот вариант представляет опасность в силу малой заметности и продолжительного времени нарастания зловредного воздействия. Обычно здесь речь идет о воздействии на приложения и иногда на серверные ресурсы;
b. Атаки, основанные на значительном числе произвольных «мусорных» запросов. Целью таких атак обычно является мощный «кумулятивный» удар по системе, вследствие которого она долгое время не сможет обрабатывать запросы от легитимных пользователей. Характерным примером является атака типа Wordpress Pingback DDoS. Хотя эта атака однозначно обнаруживается и фильтруется по типовым HTTP-заголовкам, тем не менее, она может составлять серьёзную проблему для атакуемого ресурса, поскольку полоса такой атаки может достигать десятков Гбит/с и в состоянии превысить показатели по доступности канальной ёмкости и производительности HTTP-сервера;
c. Атаки, имитирующие поведение легитимного пользователя. В отличие от предыдущей разновидности, такие атаки используют большое количество неагрессивных ботов, что затрудняет анализ в режиме реального времени. Зачастую эти механизмы используют «узкие места» или уязвимости в web-приложениях и остальной инфраструктуре. Это может привести к несанкционированному доступу к системе, потерям и несанкционированным изменениям данных. Для обнаружения «узких мест» атакующий может использовать сканирование сети – действие, которое, на первый взгляд, представляется безвредным, поскольку само по себе не приносит урона, но на самом деле позволяет получить информацию, которая поможет в дальнейшем атаковать систему.
Примеры DDoS-атак разных уровней
Ниже я попробовал описать основные DDoS-атаки, которые часто встречаются для L3, L4, L7. Наиболее интересные, конечно, атаки на уровне приложения: они, по моему мнению, более разрушительные (поскольку нарушают логику работы веб-приложения, что приводит к неправильным результатам работы веб-приложения либо вообще упущению прибыли организации) и с ними тяжелей бороться (стандартные "чистилки" трафика L3, L4 тут выручат далеко не всегда, нужно ставить Web Application Firewall (WAF) и настраивать правила детекта и блокировки запросов уже на нем). Атаки L3, L4 обычно приводят просто к недоступности сервиса (он не отвечает вообще либо отвечает ошибками 5хх). Атаки L7 не всегда приводят к появлению таких ошибок.Что такое L3/L4/L7, про которые часто упоминается в тексте?
L3 / L4 / L7 - названия уровней представления по сетевой модели ISO/OSI. Не вдаваясь в дискуссии, нужна/не нужна эта модель, жива она или мертва - в данном случае это не суть - опишу кратко:
- L3 - сетевой уровень. Это где происходит трансляция сетевых адресов в физические адреса, на нем работает ряд протоколов маршрутизации и прочих служебных
- L4 - транспортный уровень. Тут живут протоколы UDP и TCP, уровень отвечает за передачу данных от отправителя к получателю
- L7 - прикладной уровень. Тут уже живут протоколы HTTP, HTTPS и работают веб-приложения - то, что видите в браузере
Что есть ошибки 5хх?
Ошибки 5хх - серия кодов ошибок состояния HTTP, которые отдает сервер, когда не может обработать запрос пользователя. Чаще всего отдает 500 - "внутренняя ошибка сервера" или 502 "Bad Gateway" / 503 "Сервер недоступен". Для интересующихся, полный список можно прочитать в Википедии:
Атаки сетевого уровня (L3)
ICMP floodПринцип работы ICMP flood достаточно прост. На узел жертвы отправляется простой эхо-запрос (ICMP Echo Request), который требуется обработать и отправить эхо-ответ; при ответе потребуется задействовать больше ресурсов по сравнению с обычным пакетом, хотя сам запрос по объему небольшой.
В результате, при относительно небольшом трафике, можно добиться перегрузки по количеству пакетов. Атакуемый узел начинает работать нестабильно, терять пакеты.
При этом генерация большого числа корректных эхо-запросов (в т.ч. с поддельным IP-адресом источника) – алгоритмически тривиальная задача. Таким образом, в ходе атаки может быть сгенерирован весьма значительный объём трафика, что позволит атакующему исчерпать канальную ёмкость атакуемого узла.
Усиление атаки достигается использованием бот-сети («ботнета»), когда запросы приходят с тысяч узлов. Кроме этого, можно отправить запрос по широковещательному адресу с поддельным адресом-источника пакета (так называемые Smurf-атаки). Отправка эхо-запроса ICMP на широковещательный адрес заставляет все узлы в этой сети отправить эхо-ответы на подмененный адрес, который и является адресом жертвы, то есть происходит усиление атаки (Amplification). Схема на рисунке ниже.
UDP flood
Принципы атаки схожи с предыдущим вариантом и заключаются в отправке множества UDP-пакетов на определённые номера портов атакуемого узла, который для каждого полученного пакета должен идентифицировать соответствующее приложение, отправив ответное ICMP-сообщение «адресат недоступен» или, в худшем случае, передать данные UDP-пакета пользовательскому приложению и оттранслировать полученный ответ.
В итоге, атакуемая система окажется перегруженной, поэтому после начала атаки зловредный трафик может быстро захватить всю доступную полосу пропускания, не оставив ничего легитимному трафику, что и является целью атакующего – не дать работать легитимным пользователям. Подменив IP‑адреса источников в UDP-пакетах, атакующий может перенаправить поток ICMP-ответов и тем самым сохранить работоспособность атакующих узлов, а также обеспечить их маскировку.
Следует отметить, что ни ICMP flood, ни UDP flood не используют уязвимостей системы, то есть мы имеем дело со стандартными принципами работы стека протокола TCP/IP.
Кроме того, существуют методы, позволяющих значительно (в 10-1000 раз) усилить атаку, например, направив исходный трафик атаки не непосредственно на атакуемый узел, а на уязвимый промежуточный сервер, обеспечивающий усиление (Amplification).
Атаки на транспортный уровень
Атаки на транспортном уровне сети обычно эксплуатируют основные «узкие места» в реализации протокола TCP при установке сессии. Обычно это либо этап установления сессии, либо атака на таблицу соединений протокола TCP. Ниже разберем основные типы атак.
SYN flood
Атака типа SYN flood эксплуатирует особенность стека протоколов TCP/IP – потребность установки TCP-сессии. В отличие от UDP, где это не требуется, при TCP-взаимодействии необходимо, чтобы отправитель «договорился» с получателем перед тем, как что-то будет отправлено. Для этого используется механизм three-way handshake – «тройного рукопожатия», или трехэтапного подтверждения. Принцип его работы выглядит следующим образом:
1. Клиент посылает пакет с TCP-сегментом SYN (Synchronize);
2. Сервер отвечает пакетом с сегментом SYN-ACK (Synchronize-Acknowledge);
3. Клиент подтверждает прием пакета SYN-ACK пакетом ACK (Acknowledge).
На этом процедура установления соединения завершается. Но, что существенно, сервер обязан выделить все необходимые ресурсы в момент получения SYN-сегмента от клиента, до отсылки ответного пакета SYN-ACK.
Установив фальшивый IP-адрес отправителя и отправив серверу большое количество SYN-пакетов. Генерация корректного SYN-сегмента – алгоритмически тривиальная задача. Получая пакет SYN, сервер должен выделить часть своих ресурсов для установления нового соединения. В конце концов все ресурсы сервера будут исчерпаны, что приведет к невозможности обслуживания новых запросов. Цель атакующего достигнута.
Для борьбы с атакой типа SYN flood обычно используются механизмы SYN Cookies и/или SYN Proxy. Суть их в том, что в момент получения SYN‑сегмента сервер не выделяет ресурсы, а кодирует всю необходимую информацию вместе с секретным токеном и отправляет её в ответном сегменте SYN-ACK. Легитимный клиент, устанавливающий соединение со своего реального IP-адреса, получит этот сегмент и перешлет эту информацию обратно в сегменте ACK, после чего сервер действительно выделит ресурсы и установит соединение. Атакующий, подделывая IP-адреса, закодированные данные не получит и корректное подтверждение отправить не сможет, таким образом, соединение не установится.
Сложность использования этих методов состоит в том, что для генерации SYN Cookies необходимы адекватные текущему уровню атак вычислительные мощности и сетевые ресурсы с пропускной способностью от 100 Гбит/с и более. Защищённая инфраструктура должна обладать этими ресурсами в обязательном порядке.
TCP Connection Flood
Другое «узкое место» протокола TCP – таблица соединений. Используя бот-сеть, атакующий может генерировать с реальных IP-адресов бот-сети TCP-соединения (каждое из которых фактически будет стоить ему двух тривиальных TCP-пакетов), заполняя таблицу TCP-соединений атакуемого сервера, а также расходуя ресурсы на заполнение нижестоящих таблиц (например, таблица отслеживания соединений – connection tracking – при NAT) и вышестоящие (как число файловых дескрипторов HTTP-сервера) ресурсы.
Для более успешного противодействия такой атаке обычно ограничивают таймауты на установление и поддержание (в состоянии бездействия, idle time) TCP-соединений. Как правило, оптимальное значение – около 60 секунд, но оно может варьироваться в зависимости от задач, возложенных на сервер.
В общем случае, если TCP-соединение клиента с сервером действительно установлено и тем самым IP-адрес клиента аутентифицирован, для борьбы с подобного рода атаками на автомат (тут под словом "автомат" подразумевается математическая модель функционирования протокола ТСР, представленная в виде конечного автомата - для желающих изучить подробнее - ссылка ) TCP и таблицу соединений используются эвристические методы применительно к данному конкретному ресурсу и его типовым параметрам взаимодействия по протоколу TCP. В случае обнаружения клиентов, чьё поведение значительно отличается от типичного, например, числом открываемых в единицу времени соединений, медленными запросами и/или ответами, нестандартными переходами по автомату TCP-соединения и пр. – такой IP-адрес заносится в «чёрный список» и в дальнейшем – или, по крайней мере, в течение некоторого промежутка времени – соединения с этого IP-адреса не обрабатываются.
Необходимо при этом учитывать, что на сегодняшний день массовое установление большого числа TCP-соединений с поддельного IP-адреса в общем случае практически сложнореализуемо, однако установление одного spoofed-соединения с определённого IP-адреса – за продолжительный промежуток времени – в ряде случаев технически реализуемо. Таким образом, «чёрные списки» являются удобным механизмом для фильтрации DDoS-атак, основанных на протоколе TCP (или на протоколах верхнего уровня, использующих TCP на транспортном уровне). Однако к «чёрным» и «белым» спискам как методам авторизации пользователей на ресурсе следует относиться с определенной долей осторожности.
В то же время, категорически нельзя использовать «чёрные списки» для фильтрации любых атак, не задействующих открытые TCP-соединения, например, для борьбы с SYN flood или ICMP flood. Использование «чёрных списков» для этой цели может привести к недоступности сервиса для легитимных пользователей, а в дальнейшем – к исчерпанию памяти и других вычислительных ресурсов средства фильтрации трафика.
Атаки, основанные на протоколе SSL/TLS
HTTPS Flood – атака на Secure Socket Layer (SSL): с ростом популярности этого метода шифрования, используемого в различных сетевых протоколах, он также стал мишенью для атакующих. Концептуально SSL или его современная версия – TLS – используется поверх TCP/IP, обеспечивая безопасность соединений путем шифрования и аутентификации сторон.
DDoS-атаки, связанные с протоколом SSL/TLS, принимают различные формы: они могут быть нацелены на механизм взаимодействия при установлении SSL/TLS-сессии и выражаться в отправке «мусорных» данных на сервер SSL/TLS или эксплуатации определенных функций, связанных с процессом согласования ключей шифрования SSL/TLS. Такого рода атаки обычно считаются «асимметричными», так как сервер расходует на обработку атаки с использованием SSL/TLS гораздо больше ресурсов, чем требуется для ее запуска.
Например, атака THC-SSL-DoS использует малое количество пакетов для приведения в состояние «отказ в обслуживании» даже достаточно мощного сервера. В ходе этой атаки сначала инициируется SSL взаимодействие для установки сессии, а затем немедленно запрашивается процедура повторного согласования ключа шифрования.
Этот инструмент постоянно повторяет запрос на повторное согласование до тех пор, пока все ресурсы сервера не будут исчерпаны. Атакующие предпочитают запускать атаки с использованием SSL, потому что установка каждой сессии SSL требует примерно в 15 раз больше ресурсов на стороне сервера, чем на стороне клиента. Фактически, один обыкновенный домашний персональный компьютер при определенных условиях может вывести из строя целый web‑сервер, использующий SSL, а несколько компьютеров могут вывести из строя всю серверную часть (даже целую ферму) защищенных онлайн сервисов.
Атаки на web-приложения
Наиболее распространенными DDoS-атаками, нацеленными на приложения, являются разновидности атак на протокол HTTP. В литературе для обозначения таких атак обычно используется обобщенный термин HTTP flood. Обычно для их осуществления используется бот-сеть из зараженных устройств, но в ряде случаев в состав атакующих вполне могут входить и добровольцы, например, когда речь идет о целенаправленной хактивистской деятельности.
В атаке могут использоваться любые HTTP-запросы, но обычно используют GET и POST. Атака также может осуществляться с использованием шифрованных TLS-сессий. Конечной целью атаки является исчерпание ресурсов web‑приложения. Тут надо понимать, что "железных" ресурсов сервера еще может оставаться много - и незабитого канала тоже может (но не обязательно) остаться много. Но узким местом станет именно само веб-приложение: из-за особенностей конфигурации или в силу других причин оно либо просто перестанет обслуживать легальные запросы, либо просто упадет.
Атака осуществляется следующим образом: отправляется небольшой по объему HTTP-запрос, в ответ на который сервер должен прислать куда больший объем информации. Несомненно, канал сервера во много раз «шире» канала, который использует атакующий, но ведь и отдавать информации приходится намного больше; кроме того, не составит труда подменить IP-адрес источника.
Следовательно, ответные пакеты сервера не вызовут эффекта отказа в обслуживании атакующего узла, более того, таких узлов может быть огромное количество.
Угрозы от этой атаки - исчерпание канальной емкости и отказ на уровне обработки запросов, так как у любого HTTP-сервера, а тем более – web-приложения или ресурсов, обеспечивающих его работу (система авторизации, СУБД и др.), есть свой предел производительности. В результате, легальный запрос не будет обработан, а пользователь не получит своей порции цифрового контента.
HTTP-атаки с использованием шифрования (HTTPS Flood)
В настоящее время практически все разработчики используют в своих приложениях SSL/TLS для шифрования трафика и обеспечения сквозной безопасности при передаче данных. Любая DDoS-атака на приложение, допускающее шифрование, может быть запущена поверх трафика, зашифрованного SSL/TLS, что создает определенные трудности в ее идентификации. Большинство технологий противодействия DoS атакам не производят реальной проверки трафика SSL, так как это требует расшифровки зашифрованных данных.
Wordpress Pingback DDoS
Определенная популярность есть у Reflection DDoS-атак уровня L7 (приложений). Наиболее характерным примером такой атаки является Wordpress Pingback DDoS, которую и рассмотрим.
Основной её принцип заключается в следующем. Чрезвычайно распространённый web-фреймворк Wordpress до определенных версий предоставлял публичное API, позволяющее запросить любую web-страницу с любого удалённого HTTP-сервера без авторизации. Таким образом, отправив небольшой (до 400 байт) запрос на уязвимый Wordpress-сервер, можно было инициировать загрузку любой крупной страницы (или файла, если это возможно без авторизации) с атакуемого сервера на уязвимый сервер.
В ходе такой атаки определённая нагрузка ложится и на уязвимый Wordpress-сервер, однако, в силу того, что в нападении участвует несколько тысяч Wordpress-серверов и атака разделяется между ними примерно равномерно, нагрузка на каждый отдельный сервер обычно не является критичной и может быть даже не замечена системным администратором на фоне ежедневной средней загрузки. Основная же доля нагрузки приходится именно на атакуемый ресурс.
Интересно, что эта атака, несмотря на то, что Wordpress давно исправил уязвимость была популярна и в 2021, и 2022 г, поскольку в Интернете находилось порядка нескольких миллионов Wordpress-серверов, пригодных для эксплуатации в атаке типа Wordpress Pingback DDoS, и, как минимум, в ряде инцидентов принимало участие одновременно до 350 тыс. уязвимых серверов. Так как в большинстве случаев фреймворк Wordpress развёрнут не на рабочей станции (как обычный модуль бот-сети), а на сервере с неплохой производительностью и канальной ёмкостью, то атаки типа Pingback DDoS на канальном уровне достигали уровня в 10 Гбит/с и более.
В тоже время, атака типа Wordpress Pingback DDoS, организуемая на HTTP-ресурс без шифрования, достаточно легко идентифицируется и несложно фильтруется при наличии достаточной производительности и канальной ёмкости (от 20 Гбит/с).
Важной особенностью Pingback-атаки является то, что уязвимый сервер в состоянии запрашивать произвольные крупные web-страницы как по HTTP, так и по HTTPS, то есть внутри зашифрованной SSL/TLS-сессии. Это приводит к невозможности фильтрации такой Reflection-атаки при отсутствии адекватных механизмов анализа зашифрованного трафика. Для борьбы с Pingback DDoS в общем случае требуется раскрытие текстовой информации, содержащейся внутри TLS-сессий.
В целом, не надо думать, что Pingback-атаки характерны только для Wordpress. Они могут вылезти на любом приложении, которое позволяет перенаправить запрос (в силу своей архитектурной особенности или ошибок конфигурации). Поэтому, очень важно, при настройке веб-приложений максимально минимизировать возможности запросов для неавторизованных пользователей - особенно это касается той части, которая отвечает за обработку API.
Full Browser Stack-атаки и имитация поведения пользователя
Одной из самых сложной для идентификации и фильтрации разновидностью атаки уровня приложения являются, так называемые, FBS‑атаки (от англ. «Full Browser Stack» – полноценная среда браузера). В этом случае для генерации паразитных запросов используются не обычные легковесные библиотеки, имитирующие браузер, а полноценный экземпляр браузера, способный корректно формировать запросы (либо качественный эмулятор), загружать с атакуемого web-сервера изображения и CSS-стили, выполнять HTTP-переадресацию и JavaScript-код. Такую атаку очень сложно отследить и классифицировать, анализируя каждый пакет или каждый запрос в отдельности, поскольку каждый отдельный запрос полностью легитимен и идентичен пользовательскому.
Для борьбы с такими атаками недостаточно тривиальных проверок наподобие HTTP-редиректов и JavaScript-проверок. Используются, как правило, нестрогие статистические алгоритмы, анализ истории поведения пользователей, поиск закономерностей и мониторинг состояния защищаемого сервера. Подобный анализ, как правило, чрезвычайно вычислительно сложен и подразумевает хранение больших объёмов данных с возможностью быстрого поиска по ним. Таким образом, решение по фильтрации атак уровня приложения (L7-атак) должно быть в состоянии работать с большими объёмами данных в реальном времени.
Следует отметить, что подобные атаки необязательно будут организованы именно посредством бот-сети. В ряде случаев они проводятся хактивистами, т.е. живыми людьми. В этом случае распространённое решение с демонстрацией изображений или решения головоломок типа CAPTCHA также может быть неэффективным, хотя, безусловно, создающее дополнительные трудности атакующему.
Медленные атаки малого объема (Slow and Low)
DDoS атаки не всегда подразумевают большой объем трафика и бот-сети из сотен узлов. Иногда вполне достаточно даже одного компьютера, чтобы остановить работу сервиса. Существует целый класс атак, направленных на приложения, то есть работающих на L7 (прикладном) уровне модели ISO/OSI, использующих минимум ресурсов. Зачастую бывает вполне достаточно и одного компьютера, используются стандартные принципы работы прикладных протоколов. Но их негативное воздействие оказывается весьма значительным, вплоть до полной остановки работы сервисов.
Речь идет о медленных атаках небольшого объема («Slow and Low»). Ниже приведены некоторые представители подобного рода атак.
Are You Dead Yet / RUDY
Принцип этой атаки базируется на стандартном поведении протокола HTTP при обработке запросов POST.
Предположим, имеется web-сайт, на котором находится форма для ввода данных, которую необходимо заполнить пользователю. Например, это характерно для финансовых учреждений, банков, интернет-магазинов, систем бронирования билетов, любого сайта, на котором требуется аутентификация и т.д.
Когда легитимный пользователь заполняет web-форму, на сайт отправляется всего несколько пакетов, после чего сессия с web-сервером закрывается, ресурсы освобождаются. Сервер готов обслуживать запросы других пользователей. Атакующий, использующий специальный инструмент, например, RUDY (сам инструмент достаточно древний и стал именем нарицательным для подобных инструментов, которые разрабатываются и в 2022), действует иначе. Отправляемые на web-сервер данные разбиваются на множество мелких пакетов, каждый из которых содержит лишь небольшой объем данных, например, один байт. Запросы на сервер отправляются со случайным интервалом, что не дает возможность серверу сразу закрыть сессию, поскольку передача данных еще не завершена.
Несколько тысяч таких запросов в течение нескольких минут приводят к тому, что сервер не может отвечать на запросы легитимных пользователей.
Но в данном случае не требуется большой объем трафика или значительное количество пакетов, чтобы вывести ресурс из строя. Все запросы абсолютно легитимны, здесь имитируется поведение системы с медленным каналом связи. Цель атакующего достигнута – работать с сайтом невозможно. Подобная уязвимость характерна практически для любого сайта. Поэтому для отсечки таких атак целесообразно использовать очистку трафика.
SlowLoris
Если этот раздел читают "старички в ИБ", то тут наверное они усмехнутся: LOIC, HOIC, HULK, SLOWLORIS - это набор скрипткиддисов, не так ли?
И зачем раскапывать стюардессу. Но как бы ни так - и инструменты, и методы внезапно ожили в 2021 / 2022 - пруф, к примеру, отчет Radware (
). Поэтому желательно знать принципы таких атак.Атака SlowLoris, также как и предыдущая, базируется на стандартном поведении протокола HTTP при обработке запросов. Для закрытия HTTP сессии необходимо прислать соответствующую последовательность.
Собственно говоря, так и поступает легитимный пользователь. Правильный запрос на получение данных с web-сервера (Get Request) обычно состоит из одного пакета и завершается специальной последовательностью в конце для разрыва сессии.
Суть атаки заключается в следующем: используя специальный инструмент SlowLoris или подобные, атакующий генерирует множественные подключения к целевому web-серверу, при этом соединения не закрываются, поскольку в запросе будет отсутствовать соответствующая последовательность символов. В результате, ресурсы сервера будут исчерпаны и легитимные пользователи не смогут подключиться. Цель атакующего достигнута – работать с сайтом невозможно. Большой объем трафика или значительное количество пакетов не требуется, чтобы вывести ресурс из строя.
В целом, не сказать, что атака является достаточно серьезной проблемой, если вы озаботились защитой от DDoS-атак. Но для слабо защищенных веб-серверов она может стать проблемой, несмотря на хорошую детектируемость.
DNS flood
Другим характерным примером атаки на приложения, не связанным напрямую с протоколом HTTP, является DNS flood. Организация его не составляет большого труда, что, собственно, и послужило залогом его большого распространения.
Как известно, серверы DNS служат для разрешения имен в IP-адреса. Основная задача DNS сервера – найти требуемый адрес, чтобы компьютер смог обратиться на искомый сайт. Атака построена на принципах взаимодействия клиента и сервера DNS. Атакующий, используя бот-сеть, посылает множество запросов на сервер жертвы. Сервер перегружен и не сможет разрешать имена по запросам легитимных пользователей, и следовательно, они не смогут обратиться на требуемый им ресурс, поскольку не смогли разрешить его имя в адрес (при этом, в подавляющем большинстве случаев можно обратиться на сервер по его IP-адресу).
Усиление атаки достигается за счет того, что DNS использует в качестве транспортного протокол UDP, который не требует установки соединения, то есть без использования «троекратного рукопожатия» (three-way handshake), не аутентифицирует удалённую сторону и работает без сохранения состояния соединения. Это дает возможность атакующему свободно подменять IP-адрес отправителя в запросе к DNS-серверу на поддельный адрес, а также направлять ответы других DNS-серверов в адрес его жертвы (DNS Reflection).
Наверное, на этом стоит закончить длинное описание атак, но нужно упомянуть OWASP (Open Web Application Security Project) - это сообщество ведет периодически обновляемый список , в котором перечислены наиболее опасные уязвимости в системе безопасности web-приложений. Использование уязвимостей из этого списка зачастую приводит к различным нарушениям в работе web-приложения либо к его полной остановке, что по сути является DoS.
Пара слов о векторах атак
В реальной жизни, атакующие могут использовать комбинацию различных видов атак на инфраструктуру (в т.ч. осуществлять сканирование сети). Такое действо можно описать как изменение вектора атаки, которое зачастую не требует от атакующего каких-либо значительных затрат.В чем опасность сканирования применительно к DDoS?
Сканирование сети - и использование сетевых сканеров - означает разведку сети. Обычно стараются достичь следующих целей (одной или нескольких):
- Определение находящихся в сети узлов (сетевое сканирование)
- Выявление открытых портов и функционирующих сервисов (сканирование портов)
- Выявление известных уязвимостей веб-приложений (сканирование безопасности)
Сканирование бывает активным и пассивным. Активному сканированию вы можете противостоять, но пассивному противостоять сложнее, т.к. в этом сценарии атакующий не проводит непосредственно сканирование вашей инфраструктуры, а получает информацию о ней из других источников, например, Shodan.
К сожалению, некоторые компании, специализирующиеся на защите от DDoS-атак, не рассматривают сканирование в качестве атаки и не считают нужным ему противостоять. Действительно, на первый взгляд, никакого вреда системе нет. Тем не менее, с таким подходом трудно согласиться: как уже говорилось выше, практически всегда сканирование предваряет атаку, позволяя атакующему выяснить, какие сервисы работают в целевой системе, версию сервисов, версию операционных систем, назначение систем и сервисов и впоследствии подготовить и провести целенаправленную атаку.
В тоже время, само по себе сканирование не всегда является злонамеренным действием, все зависит от его целей. Службы информационной безопасности или сотрудники ИТ вполне могут прибегнуть к сканированию для выявления уязвимостей инфраструктуры и выполнения иных задач.
Возможны сочетания нескольких способов злонамеренного воздействия одновременно. Достаточно нескольких минут для изменения воздействия на атакуемые ресурсы, а одного вида атаки, который успешно осуществлен – для остановки работы целевой системы. На рисунке ниже сделана попытка показать, на какую цель направлен какой вектор:
