Ддос атака по айпи

Создание образа инстанса

Выбор типа инстанса

Сначала соберем AWS-образ, который будет содержать необходимые инструменты и скрипты для управления. Первым делом надо выбрать, какой инстанс арендовать. Изучаем характеристики разных типов инстансов: смотрим на цену, объем максимального трафика, мощность CPU (последнее важно, потому что трафик создается мощностями процессора как-никак), затем тестируем реальную производительность и максимальное число запросов. По нашим оценкам, наиболее удобными для тестирования являются инстансы t3.small
, но тут каждый выбирает на свой вкус.

Характеристики инстансов можно посмотреть вот тут
. Также выбирать и сравнивать инстансы можно здесь
.

Запрос на увеличение лимита

Нужно заранее подумать о том, сколько инстансов будет участвовать в тестировании. Дело в том, что Amazon предоставляет для каждого региона свои ограничения на число инстансов. Если у вас есть ощущение, что понадобится больше инстансов, чем доступно по умолчанию, то стоит как можно раньше запросить увеличение лимита. Для этого переходим в раздел Support
, создаем обращение типа Service limit increase. Время обработки обращения может быть разным: кто-то отвечает уже на следующий день, предоставляя столько сущностей, сколько было запрошено, кто-то говорит, что не даст запустить больше, чем N инстансов. Были и такие регионы, которые отвечали на запрос около месяца.

Тюнинг производительности

Далее нужно создать образ инстанса, который будет запускаться во время тестирования. Для этого включаем инстанс выбранного типа, производим на нем все настройки, затем сохраняем то, что получилось, в качестве образа (в том же меню Actions, где есть возможность включения инстанса, а также функциональность по созданию образа Image Create Image).

Нам нужно получить максимальный исходящий трафик с каждого инстанса, поэтому для начала оптимизируем настройки сети и памяти под нашу задачу на инстансе.

Для этого внесем настройки в файл /etc/sysctl.conf
:

• Повысим диапазон локальных портов и уменьшим время нахождения сокетов в состоянии FIN_WAIT:

 net.ipv4.ip_local_port_range = 1024-65535 (по умолчанию: 32768-61000)
net.ipv4.tcp_fin_timeout = 10 (по умолчанию: 60) 

Диапазон локальных портов определяет максимальное количество исходящих сокетов, которое хост может создать из определенного IP.

С настройкой по умолчанию (61 000–32 768) получается 28 233 сокета. С новыми настройками – 64 500.

Fin_timeout определяет минимальное время, в течение которого исходящие сокеты могут находиться в состоянии FIN_WAIT.

Если указаны значения по умолчанию, система может обеспечить не более (61 000–32 768) / 60 = 470 сокетов в секунду.

Увеличивая port_range и уменьшая fin_timeout, мы можем повлиять на способность системы генерировать большее число исходящих соединений.

• Разрешим повторно использовать сокеты в состоянии TIME_WAIT, когда заканчиваются свободные:

 net.ipv4.tcp_tw_reuse = 1  

Установка вышеуказанной опции (которая по умолчанию отключена) помогает минимизировать потери на «простаивание» уже отработавших соединений.

Очень подробно о TIME_WAIT рассказано в этой статье
.

• Включим опцию tcp_timestamps для работы вышеуказанной опции tcp_tw_reuse
:

 net.ipv4.tcp_timestamps = 1 – включить опцию `tcp_timestamps` для работы вышеуказанной опции tcp_tw_reuse  

• Остальные опции:

 net.ipv4.tcp_max_tw_buckets = 720000 – увеличить возможное количество сокетов в состоянии TIME_WAIT
net.ipv4.tcp_keepalive_time = 600 – уменьшить тайм-аут keepalive-соединений
net.ipv4.tcp_keepalive_probes = 3 – уменьшить количество keepalive-проб
net.ipv4.tcp_keepalive_intvl = 10 – уменьшить временной интервал между keepalive-пробами
net.ipv4.tcp_window_scaling = 1 – разрешить масштабирование TCP-окна
net.ipv4.tcp_mem = 8192 131072 196304 – увеличить размер буферов для TCP-пакетов
net.ipv4.udp_mem = 8192 131072 196304 – увеличить размер буферов для udp-пакетов
net.ipv4.tcp_slow_start_after_idle=0 – отключить Slow-Start Restart
net.core.wmem_default = 31457280 – установить размер буфера по умолчанию для отправки данных
net.core.wmem_max = 33554432 – установить максимальный размер буфера для отправки данных
net.core.somaxconn = 65535 – увеличить размер очереди сокетов в ожидании обработки
net.core.netdev_max_backlog = 65535 – увеличить размер очереди пакетов между сетевой картой и ядром
vm.swappiness = 30 – понизить порог своппинга
vm.dirty_ratio = 50 – очищать буферы по достижении 50 % ОЗУ
vm.pagecache = 90 – ограничить размер файлового кеша 

Сценарии тестовых атак

1. Атака на DNS

Одна из основных задач тестирования – оценка производительности DNS-серверов. Именно DNS-серверы могут стать узким местом отказоустойчивости сайта, так как при возникновении проблем с DNS даже самый устойчивый сервис окажется недоступным. Для создания нагрузки на DNS-серверы будем генерировать много разнообразных DNS-запросов. Запросы должны быть валидными и требовать от DNS-сервера как можно большего и длительного ответа.

Для генерации подобного трафика подходит утилита DNSPerf
.

DNSPerf – это простой, гибкий и бесплатный инструмент тестирования производительности DNS-серверов. В первую очередь он рассчитан на authoritative DNS-сервера, но может также использоваться для измерения производительности кеширующих серверов.

В нашем случае нагружаются authoritative DNS-сервера, обслуживающие одну зону – example.com.

Для DNSPerf предварительно подготовим файл с запросами dns_queries.txt
(преимущественно ANY для увеличения времени и размера ответа от DNS-сервера):

 #dns_queries.txt
example.com ANY
www.example.com ANY
test.example.com ANY
static.example.com ANY
example.com АААА
www.example.com АААА
test.example.com MX 

Пример запуска утилиты:

 dnsperf -s TARGET_IP -d dns_queries.txt -c 100 -n 100
-s = целевой IP-адрес
-d = путь к файлу данных с запросами. По умолчанию – stdin
-c = количество имитируемых клиентов. Для каждого клиента используется уникальный исходящий номер порта
-n = количество «прогонки» файла с запросами. 

2. Атака на ICMP

Следующим этапом тестирования является оценка устойчивости к большому количеству ICMP-трафика. Так как по техническим причинам у серверов часто должна оставаться возможность отвечать на ping-request, существует вероятность DDoS-атаки с использованием ping-запросов. Помимо указания настроек, исключающих возможность ping-to-death
, нужно убедиться в устойчивости серверов к пиковым нагрузкам на ICMP. Для создания таких нагрузок лучше использовать известную утилиту hping3
, которая позволяет регулировать количество запросов, интервал между отправками, а также размер пакетов.

Пример запуска утилиты:

 hping3 -i u1000 -d 1500 -c 100000 -1 TARGET_IP
-i u100 = интервал между отправляемыми пакетами (uX for X microseconds)
-d 1500 = размер каждого пакета
-c 1000000 = количество пакетов для отправки
-1 = режим ICMP 

3. Атака на HTTP

Теперь проверяем на стрессоустойчивость основной функционал сервиса – обработку HTTP(S)-трафика. Одним из самых гибких и простых инструментов для генерации HTTP-трафика является siege
. Siege – это многопоточная утилита с открытым исходным кодом, предназначенная для тестирования производительности веб-ресурса.

Как и DNSPerf, siege позволяет нагрузить сервер запросами от заданного числа виртуальных пользователей (эмуляция пользователя реализуется c помощью отдельного порта), а также использовать подготовленный заранее набор запросов. Это очень удобно, так как можно включить в тест наиболее ресурсоемкие запросы.

Пример запуска утилиты:

 siege -b -c 100 -f test_urls.txt
-b = без задержек (режим benchmark)
-c = количество имитируемых клиентов. Для каждого клиента используется уникальный исходящий номер порта
-f = файл с запросами 

Формат содержимого test_urls.txt
:

 http://example.com/site/login POST login=username&password=test
http://example.com/site/client POST useragent=Mozilla&version=123&date=24May
http://example.com/site/order POST user=username&company=ooo&phone=812345678 

Как видите, тесты проводились с использованием преимущественно POST-запросов, требующих обработки на стороне сервера и занимающих наибольшее количество ресурсов по сравнению с другими типами запросов.

Ни в одном из вариантов не используется подмена IP, так как Amazon не позволяет это реализовать. Какой бы src_IP ни был указан в пакете, на выходе с инстанса он будет изменен на правильный.

Все создаваемые запросы должны быть легитимными – никакой волны исходящего трафика без ответа, – так как политика Amazon в отношении DDoS довольно строгая. Даже согласованный стресс-тест отнимает минимум несколько дней на общение с техподдержкой, а при первых «вредоносных» действиях получаем бан порта, с которого выходил трафик, и требование немедленно объясниться.

Скрипты для запуска атак

Для удаленного управления тестами подготовим bash-скрипты (dns.sh, ping.sh, http.sh), запускающие нужный вид атаки, и файлы с пейлоадами (test_urls.txt, valid_dns_queries.txt).

Когда мы загрузим все это на AWS-образ (из которого и будут создаваться все инстансы), каждый тест можно будет запускать удаленно командой следующего формата:

 ssh instance-amazon 'sudo <stress-script>.sh start <params> &>>stress.log &' 

В качестве stress-script.sh указывается скрипт нужного типа, а params — соответствующие параметры. В файле stress.log мы будем отслеживать вывод запущенной утилиты. Для удобства будем использовать разные логи для разных утилит: dns.log, ping.log, http.log.

Пример скрипта dns.sh
:

 #!/bin/bash
if [[ ! "$1" =~ ^(start|stop|status)$ ]]; then echo "nothing to do: need argument for stop,start or status" exit 1
fi
if [[ "$1" = "start" ]]; then shift dnsperf $@
fi
if [[ "$1" = "stop" ]]; then kill $(pidof dnsperf)
fi
if [[ "$1" = "status" ]]; then if [[ ! "$(pidof dnsperf)" = "" ]]; then echo "dnperf is running with PID $(pidof dnsperf)" ps aux | grep dnsperf else echo "dnsperf is not running" fi
fi 

Как видно из кода, скрипт можно будет запускать и останавливать, а также проверять статус (запущен/не запущен).

Аналогичным образом построены скрипты для ICMP- и HTTP-тестов, запускающие соответственно hping3 и siege с переданной через аргумент строкой параметров.

 ssh instance-amazon 'sudo dns.sh start -s TARGET_IP -d valid_dns_queries.txt -c 1 -n 100 &>>dns.log &'
ssh instance-amazon 'sudo ping.sh start -i u1000 -d 1500 -c 100000 -1 TARGET_IP &>>ping.log &'
ssh instance-amazon 'sudo http.sh start -b -c 100 -f test_urls.txt &>> http.log &' 

Скрипты мониторинга

Для оценки исходящего трафика и состояния инфраструктуры тестирования нам понадобится средство мониторинга. Из соображений простоты и экономии ресурсов используем iptables. Для этого напишем скрипт, подсчитывающий количество отправленных Мб, и положим его на AWS-образ:

 #iptables.sh
sudo iptables -N TRAFFIC_OUT
sudo iptables -A TRAFFIC_OUT -p tcp
sudo iptables -A TRAFFIC_OUT -p udp
sudo iptables -A TRAFFIC_OUT -p icmp
sudo iptables -A OUTPUT -j TRAFFIC_OUT
sudo iptables-save 

Скрипт создает новую цепочку TRAFFIC_OUT и добавляет в нее фильтры для нужных протоколов: tcp, udp, icmp.

В цепочку OUTPUT добавляется перенаправление пакетов в TRAFFIC_OUT.

Количество переданных данных можно узнать командой:

 # iptables -L TRAFFIC_OUT -v -n -x | tail -n 3 | awk '{print $2/1024/1024,"Mb\t\t\t",$3}’ : 2.2 Mb tcp 4.4 Mb udp 3.2 Mb icmp 

Установим скрипт в качестве сервиса. Для этого создадим файл monitoring.service и переместим его в директорию /etc/systemd/system
нашего образа:

 # /etc/systemd/system/monitoring.service
[Unit]
After=network.target
[Service]
ExecStart=/usr/local/bin/monitoring.sh
[Install]
WantedBy=default.target 

Теперь можно добавить сервис в автозагрузку:

 systemctl enable monitoring.service
systemctl start monitoring.service 

Краткий пересказ всех частей

Поскольку материала набралось достаточное количество, решил разнести в несколько постов, чтобы проще было читать.

Часть 1: То, что вы читаете сейчас. Самый-самый базис: что такое DDoS-атака и основные типы атак, с примерами

Часть 2: Защита от DDoS-атак. Почитать тут
.

Подготовка

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

Сравнив политику различных облачных сервисов (кто-то безжалостно банит учетную запись, с которой, предположительно, были выполнены действия, приводящие к отказу ресурса) в отношении проведения нагрузочного тестирования с использованием их функционала, мы решили остановиться на Amazon Web Services
(AWS). В их документах
указано, что AWS допускает проведение нагрузочного тестирования, но просит согласовать его, отправив письмо на определенный адрес.

О чем длиннопост?

Привет читающим этот длиннопост. Давно ничего не писал на Хабре, но 2022 год выдался достаточно непростым в плане DDoS-атак. По роду деятельности, я столкнулся с большим количеством вопросов о том, что такое DDoS-атаки, нужно ли с ними бороться (WTF??? конечно, не нужно, пусть все лежит
нужно). Зрелым матерым спецам здесь вряд ли будет интересно.

Хочу сразу отметить, что некоторым читателям, погруженным в банковскую тематику, текст может показаться знакомым. И да, он в каком-то виде был выпущен для узкого круга лиц, но поскольку уже прошло достаточно времени, а данные в целом не устарели и автор этого поста был, в основном, автором этого текста, то я решил выложить его на хабр в несколько сокращенном и подредактированном варианте, дабы давать ссылку на этот пост, когда опять начнут задавать вопросы, либо для своих студентов.

Пользуясь случаем, хочу поблагодарить Qrator Labs
— они не принимали участие в подготовке этого поста, но внесли очень большой вклад в оригинальный текст, известный в вышеупомянутых узких кругах. Без них он бы не родился 🙂

Управление инстансами

Теперь разберемся с удаленным (максимально автоматизированным) управлением инстансами.

Для этих целей можно использовать механизм AWS CLI
– управление с помощью консоли.

Создаем Secret Key
(Access keys (access key ID and secret access key)) и настраиваем консоль.

Теперь у нас есть доступ ко всем возможностям учетной записи.

Особенность работы с AWS состоит в том, что все действия выполняются для конкретного региона и их приходится повторять, если привлечено несколько регионов.

Для создания нового инстанса из образа, который мы выше смастерили (подразумеваем, что есть публичный ami-ID, который используем в скрипте), выполним следующие действия:

• создаем SSH-ключ и добавляем его в AWS:

 yes n |ssh-keygen -q -t rsa -f $KEYNAME -m pem -N "" > /dev/null
chmod 400 $KEYNAME
aws ec2 import-key-pair --region $REGION --key-name $KEYNAME --public-key-material file:///$(pwd)/$KEYNAME.pub 

• создаем security-group, который разрешает доступ к машине по SSH. В противном случае входящие SSH-соединения будут запрещаться:

 SECURITY="ssh-group"
aws ec2 create-security-group --region $REGION --group-name $SECURITY --description "Just ssh. Nothing more"
IP_RANGE="0.0.0.0/24"
aws ec2 authorize-security-group-ingress --region $REGION --group-name $SECURITY --protocol tcp --port 22 --cidr $IP_RANGE 

• создаем инстанс с созданными ранее ключом и security-group и указываем ID образа. Число инстансов, создаваемых единовременно, может быть произвольным:

 IMG='ami-0d0eaed20348a3389'
NUM=1
aws ec2 run-instances --region $REGION --image-id $IMG --count $NUM --instance-type t2.micro --key-name $KEYNAME --security-groups default $SECURITY > instances.json 

• ждем, пока машина проинициализируется. Это занимает какое-то время: сначала мы получаем ответ об успехе (instances.json), но в это время машина только создана, но еще не запущена (например, ей еще не присвоен IP-адрес). Необходимо дождаться завершения запуска (обычно для этого достаточно минуты).

 aws ec2 describe-instances --region 

Далее выполняем SSH-команды, указав SSH-ключ, созданный выше:

 ssh -I $KEYNAME -oStrictHostKeyChecking=no ubuntu’'+ins_dns echo‘'O’' 

SSH-команды позволяют управлять атакой и получать всю информацию о состоянии атаки, так как мы снабдили инстансы всеми необходимыми скриптами и инструментами.

Разница между выключением и удалением заключается в том, что мы посылаем разные сигналы. Stop – чтобы выключить, terminate – чтобы выключить и сразу же удалить.

В целях мониторинга входящего трафика инстанса используем следующую команду с указанием ID инстанса: когда начинается замер трафика, когда заканчивается, за какой период значения суммируются:

 aws cloudwatch get-metric-statistics --region REGION --namespace AWS/EC2 \ --statistics Sum --metric-name NetworkIn --start-time $STARTTIME --end-time $FINISHTIME --period $PERIOD --dimensions Name=InstanceId,Value=$INCTANCEID 

Атаки сетевого уровня (L3)

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

Усиление атаки достигается использованием бот-сети («ботнета»), когда запросы приходят с тысяч узлов. Кроме этого, можно отправить запрос по широковещательному адресу с поддельным адресом-источника пакета (так называемые Smurf-атаки). Отправка эхо-запроса ICMP на широковещательный адрес заставляет все узлы в этой сети отправить эхо-ответы на подмененный адрес, который и является адресом жертвы, то есть происходит усиление атаки (Amplification). Схема на рисунке ниже.

Принципы атаки схожи с предыдущим вариантом и заключаются в отправке множества UDP-пакетов на определённые номера портов атакуемого узла, который для каждого полученного пакета должен идентифицировать соответствующее приложение, отправив ответное ICMP-сообщение «адресат недоступен» или, в худшем случае, передать данные UDP-пакета пользовательскому приложению и оттранслировать полученный ответ.

В итоге, атакуемая система окажется перегруженной, поэтому после начала атаки зловредный трафик может быстро захватить всю доступную полосу пропускания, не оставив ничего легитимному трафику, что и является целью атакующего – не дать работать легитимным пользователям. Подменив IP‑адреса источников в UDP-пакетах, атакующий может перенаправить поток ICMP-ответов и тем самым сохранить работоспособность атакующих узлов, а также обеспечить их маскировку.

Следует отметить, что ни ICMP flood, ни UDP flood не используют уязвимостей системы, то есть мы имеем дело со стандартными принципами работы стека протокола TCP/IP.

Кроме того, существуют методы, позволяющих значительно (в 10-1000 раз) усилить атаку, например, направив исходный трафик атаки не непосредственно на атакуемый узел, а на уязвимый промежуточный сервер, обеспечивающий усиление (Amplification).

Атаки на транспортный уровень

Атаки на транспортном уровне сети обычно эксплуатируют основные «узкие места» в реализации протокола TCP при установке сессии. Обычно это либо этап установления сессии, либо атака на таблицу соединений протокола TCP. Ниже разберем основные типы атак.

Атака типа 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.

Сложность использования этих методов состоит в том, что для генерации SYN Cookies необходимы адекватные текущему уровню атак вычислительные мощности и сетевые ресурсы с пропускной способностью от 100 Гбит/с и более. Защищённая инфраструктура должна обладать этими ресурсами в обязательном порядке.

TCP Connection Flood

Для более успешного противодействия такой атаке обычно ограничивают таймауты на установление и поддержание (в состоянии бездействия, idle time) TCP-соединений. Как правило, оптимальное значение – около 60 секунд, но оно может варьироваться в зависимости от задач, возложенных на сервер.

В то же время, категорически нельзя использовать «чёрные списки» для фильтрации любых атак, не задействующих открытые 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-сервера, а тем более – 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-атак) должно быть в состоянии работать с большими объёмами данных в реальном времени.

Медленные атаки малого объема (Slow and Low)

DDoS атаки не всегда подразумевают большой объем трафика и бот-сети из сотен узлов. Иногда вполне достаточно даже одного компьютера, чтобы остановить работу сервиса. Существует целый класс атак, направленных на приложения, то есть работающих на L7 (прикладном) уровне модели ISO/OSI, использующих минимум ресурсов. Зачастую бывает вполне достаточно и одного компьютера, используются стандартные принципы работы прикладных протоколов. Но их негативное воздействие оказывается весьма значительным, вплоть до полной остановки работы сервисов.

Речь идет о медленных атаках небольшого объема («Slow and Low»). Ниже приведены некоторые представители подобного рода атак.

Are You Dead Yet / RUDY

Принцип этой атаки базируется на стандартном поведении протокола HTTP при обработке запросов POST.

Предположим, имеется web-сайт, на котором находится форма для ввода данных, которую необходимо заполнить пользователю. Например, это характерно для финансовых учреждений, банков, интернет-магазинов, систем бронирования билетов, любого сайта, на котором требуется аутентификация и т.д.

Когда легитимный пользователь заполняет web-форму, на сайт отправляется всего несколько пакетов, после чего сессия с web-сервером закрывается, ресурсы освобождаются. Сервер готов обслуживать запросы других пользователей. Атакующий, использующий специальный инструмент, например, RUDY (сам инструмент достаточно древний и стал именем нарицательным для подобных инструментов, которые разрабатываются и в 2022), действует иначе. Отправляемые на web-сервер данные разбиваются на множество мелких пакетов, каждый из которых содержит лишь небольшой объем данных, например, один байт. Запросы на сервер отправляются со случайным интервалом, что не дает возможность серверу сразу закрыть сессию, поскольку передача данных еще не завершена.

Несколько тысяч таких запросов в течение нескольких минут приводят к тому, что сервер не может отвечать на запросы легитимных пользователей.

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

Если этот раздел читают «старички в ИБ», то тут наверное они усмехнутся: LOIC, HOIC, HULK, SLOWLORIS — это набор скрипткиддисов, не так ли? 🙂 И зачем раскапывать стюардессу. Но как бы ни так — и инструменты, и методы внезапно ожили в 2021 / 2022 — пруф, к примеру, отчет Radware ( ссылка
). Поэтому желательно знать принципы таких атак.

Атака SlowLoris, также как и предыдущая, базируется на стандартном поведении протокола HTTP при обработке запросов. Для закрытия HTTP сессии необходимо прислать соответствующую последовательность.

Собственно говоря, так и поступает легитимный пользователь. Правильный запрос на получение данных с web-сервера (Get Request) обычно состоит из одного пакета и завершается специальной последовательностью в конце для разрыва сессии.

 Суть атаки заключается в следующем: используя специальный инструмент SlowLoris или подобные, атакующий генерирует множественные подключения к целевому web-серверу, при этом соединения не закрываются, поскольку в запросе будет отсутствовать соответствующая последовательность символов. В результате, ресурсы сервера будут исчерпаны и легитимные пользователи не смогут подключиться. Цель атакующего достигнута – работать с сайтом невозможно. Большой объем трафика или значительное количество пакетов не требуется, чтобы вывести ресурс из строя.

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

Другим характерным примером атаки на приложения, не связанным напрямую с протоколом HTTP, является DNS flood. Организация его не составляет большого труда, что, собственно, и послужило залогом его большого распространения.

Наверное, на этом стоит закончить длинное описание атак

, но нужно упомянуть OWASP
(Open Web Application Security Project) — это сообщество ведет периодически обновляемый список OWASP Top 10
, в котором перечислены наиболее опасные уязвимости в системе безопасности web-приложений. Использование уязвимостей из этого списка зачастую приводит к различным нарушениям в работе web-приложения либо к его полной остановке, что по сути является DoS.

Согласование нагрузочного тестирования

Отправляем сообщение, где коротко рассказываем о своих намерениях, и получаем форму, которую должны заполнить:

 Customer ID: Customer Name: Email Address: AWS Account ID load test will be performed from: Does the customer have an NDA?
Target Data EC2 Resources: Cloudfront Distribution: API Gateway / Lambda ID: ELB Names: Non-AWS Target: Region (please list all regions in scope for testing):
Source Data: IP Addresses: Source Account ID: Regions involved:
Testing Parameters: How much traffic do you plan to generate by region during testing? What is your expected peak load from source by region? (i.e. xx Gbps) What is your expected peak load at destination? (i.e. xx Gbps) Are you testing traffic outbound from EC2, inbound into EC2, or both? Are you testing traffic outbound (egress) from EC2, inbound (ingress) into EC2, or both: Egress. What is your expected peak load from source by region? (i.e. xx Gbps) Ingress. What is your expected peak load from source by region? (i.e. xx Gbps) Start Date: End Date: Finite testing details including timeline of testing: Summary of Test: Testing Timelines by phase including rps, pps, and Gbps: Peak bandwidth for each source IP: Tools Used for each phase of test: Types of testing to be performed for each phase of the request: What criteria/metrics will you monitor to ensure the success of this test? Who is performing the Load Test? (Please provide contact details): Does the tester have an NDA?
Testing Security Do you have a way to monitor the data traffic for the duration of the test to verify
bandwidth limits do not exceed approved rates? Do you have a way to immediately stop the traffic if we/you discover any issue? 2 Emergency contact names and phone numbers: 

Есть несколько нюансов:

1. У нас спрашивают, кого будем «дубасить». Имеем ли мы на это право? Говорим, что это наш ресурс (по всей видимости, никто не проверяет, так ли это) и что тестирование полностью согласовано.

2. Нам нужно обозначить, сколько трафика создадим в каждом из регионов. В ходе переписки выясняем, что каждый регион имеет свой лимит на количество сетевого трафика. В общей сложности разрешают запросить 645 Гб/c. Считаем, сколько нужно для атаки, и набираем регионы таким образом, чтобы получилось необходимое значение.

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

4. И в обязательном порядке всеми силами стараемся заверить, что будем вести себя хорошо, внимательно наблюдать за ходом тестирования и остановим его по первому требованию в случае необходимости.

Скорее всего, в ответ на заполненную форму попросят какие-то разъяснения, поэтому переписываемся и отвечаем на вопросы до тех пор, пока не получим разрешение на тестирование.

На все согласование уходит примерно три рабочих дня, если отвечать оперативно.

Мониторинг доступности сервиса

Дополнительно для проведения атаки потребуется наблюдать, жив ли тот сервис, который мы тестируем.

Создаем и запускаем простейший «пинг»-скрипт, который отслеживает доступность целевых портов (53 и 80 в нашем случае).

Пример кода на Python, который позволяет автоматизировать проверку доступности:

 def http(url): cmd = ['curl', '-w', '"%{time_total}"', '-o', '/dev/null', '-s', url] result = check_output(cmd).decode('utf-8') result = float(json.loads(result)) return result * 1000000
def dns(ip, domain): cmd = ['dig', 'any', '@'+ip, domain ] result = check_output(cmd).decode('utf-8') result = int(result.split('Query time:')[1].split('msec')[0]) return result 

Полученную информацию сохраняем в лог-файле, на основе которого по итогам атаки можно будет построить график доступности ресурса.

В ходе проведения тестирования необходимо постоянно проверять «пинг»-лог, чтобы не убить ресурс окончательно и бесповоротно. Как только появляется существенная деградация и ответ на запрос занимает слишком много времени, атаку нужно прекращать.

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

Примеры DDoS-атак разных уровней

Ниже я попробовал описать основные DDoS-атаки, которые часто встречаются для L3, L4, L7. Наиболее интересные, конечно, атаки на уровне приложения: они, по моему мнению, более разрушительные (поскольку нарушают логику работы веб-приложения, что приводит к неправильным результатам работы веб-приложения либо вообще упущению прибыли организации) и с ними тяжелей бороться (стандартные «чистилки» трафика L3, L4 тут выручат далеко не всегда, нужно ставить Web Application Firewall (WAF) и настраивать правила детекта и блокировки запросов уже на нем). Атаки L3, L4 обычно приводят просто к недоступности сервиса (он не отвечает вообще либо отвечает ошибками 5хх). Атаки L7 не всегда приводят к появлению таких ошибок.

Пара слов о векторах атак

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

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

Какой он вообще бывает, дедос

DDoS — он такой, разный. Но все ж особой фантастики тут нет, достаточно прозаичные вещи. От L3 (сетевой уровень) до L7 (прикладной). Обычно классифицируют так:

В отдельный подкласс обычно выделяют, так называемые, 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-приложениях и остальной инфраструктуре. Это может привести к несанкционированному доступу к системе, потерям и несанкционированным изменениям данных. Для обнаружения «узких мест» атакующий может использовать сканирование сети – действие, которое, на первый взгляд, представляется безвредным, поскольку само по себе не приносит урона, но на самом деле позволяет получить информацию, которая поможет в дальнейшем атаковать систему.