1. Атаки на сетевые ресурсы (Network floods на L3 и L4), целью которых является исчерпание канальной ёмкости как самой атакуемой системы, так и её поставщиков доступа в сеть Интернет, а также транзитных операторов связи. Исторически, это самый простой для атакующего вариант, поскольку обычно не требовалась установка TCP-соединения с компьютером жертвы. Примерами таких атак являются ICMP- и UDP- flood. Классический пример L3 атаки - манипуляции с использованием протокола ICMP: Ping of Death, Ping Flood, Smurf Attack. Сюда же можно отнести различные манипуляции с APR: например, при ARP Spoofing или ARP Poisoning вполне можно вызвать отказ в обслуживании (thnx @WhiteChemist за вылавливание ошибки в этом разделе).
В отдельный подкласс обычно выделяют, так называемые, 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, про которые часто упоминается в тексте?
Что есть ошибки 5хх?
Атаки сетевого уровня (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).
