Как дудосить: Как организовать DDoS в благих целях? / Хабр

Как организовать DDoS в благих целях? / Хабр

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

А как этот сервис отреагирует, если против него будет организована распределенная DoS-атака? Защищен ли ресурс от потенциальных действий злоумышленников?

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

В этой статье мы расскажем про опыт организации нагрузочного тестирования для DNS- и HTTP-сервисов.

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

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

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

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

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. И в обязательном порядке всеми силами стараемся заверить, что будем вести себя хорошо, внимательно наблюдать за ходом тестирования и остановим его по первому требованию в случае необходимости.

   
   

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

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

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

• включать инстанс;

• запускать тестовую атаку;

• собирать статистику о ходе проведения;

• останавливать тестовую атаку;

• менять IP-адрес;

• выключать инстанс.

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

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

Сначала соберем 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 довольно строгая. Даже согласованный стресс-тест отнимает минимум несколько дней на общение с техподдержкой, а при первых «вредоносных» действиях получаем бан порта, с которого выходил трафик, и требование немедленно объясниться. (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

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

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

Для этих целей можно использовать механизм 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-адрес). Необходимо дождаться завершения запуска (обычно для этого достаточно минуты).

Затем можно подключиться по SSH, если нам известен IP-адрес. Просто запрашиваем список машин, которые сейчас запущены. Среди их параметров находим PublicDnsName или PublicIpAddress.

aws ec2 describe-instances --region

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

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

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

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

AWS присваивает новый IP-адрес каждый раз, когда машина запускается. Поэтому для смены IP потребуется выключить и включить машину заново (не нужно ее удалять!).

Разница между выключением и удалением заключается в том, что мы посылаем разные сигналы. 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

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

Создаем и запускаем простейший «пинг»-скрипт, который отслеживает доступность целевых портов (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

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

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

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

Стоит обсудить еще один вопрос, связанный с организацией тестирования, — стоимость всего этого мероприятия.

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

Поэтому стоимость атаки рассчитывается в каждом случае отдельно в зависимости от [масштаба боевых действий] максимальной мощности атаки и числа планируемых запусков.

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

Для того чтобы проиллюстрировать подсчет стоимости проведения нагрузочного тестирования, допустим, что хотим проверить устойчивость DNS-сервера к нагрузке в 10 Гб/c.

Нам известно, что используемые инструменты и возможности инстанса t3. small, запущенного в Мумбаи, позволяют выдать 500 Мб/c с одного запущенного инстанса. Цена за аренду сущности – 0,0224 $ в час, за трафик – 0,01093 $ за 1 Гб. То есть пик атаки означает одновременную работу 20 сущностей.

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

Формула расчета стоимости принимает вид:

60 с * (стоимость аренды в секунду) + 60 с * 0,5 Гб/c * (стоимость Гб трафика) = стоимость атаки с одной сущности за 60 с.
1 * (стоимость атаки с одной сущности) + 2 * (стоимость атаки с одной сущности) + ... + 20 * (стоимость атаки с одной сущности) = стоимость всей атаки

Получается, что стоимость одной атаки мощностью в 10 Гб/c на DNS-сервер – примерно 70 $. Отметим, что это приблизительная оценка, так как объем трафика нельзя абсолютно точно спрогнозировать. Подробнее про цены можно почитать здесь. Более того, правильный подход – выполнить проверку несколько раз, чтобы откалибровать настройки тестируемого сервера.

На этом все про организацию нагрузочного тестирования. Желаем не убить ваши серверы в процессе проб и ошибок.

Автогол. Как я сделал DDoS атаку на наш сервер

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

• План действий
• Настройка приложения и защиты
  • Подключение услуги по защите от DDoS
• Стресс-тест без защиты
• Атака на защищенный IP
• Статистика атак
• Выводы

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

В этой статье мы рассмотрим случай атаки, нацеленной на перегрузку полосы пропускания, а конкретно используем метод DrDOS (Distributed Reflection Denial of Service), использующий технику отражения запросов. Подобный метод интересен тем, что позволяет многократно усиливать объем атаки по сравнению с пропускной способностью зараженной машины, и был выбран нами поскольку наглядно показывает масштаб возможной атаки.

План действий

Демонстрацию услуги по защите от DDoS-атак мы проведем с помощью эксперимента, целью которого будет сравнение работоспособности веб-сервера, находящегося под DDoS-атакой, с подключенной услугой и без неё. Для этого мы организуем два стресс-теста с одинаковыми параметрами атаки на заранее подготовленный веб-сервер в VPC через защищенный и прямой IP-адрес. Степень влияния услуги по защите от DDoS-атак на фильтрацию нежелательного трафика мы оценим с помощью метрик загрузки процессора и сетевого устройства. Кроме того, используем инструмент мониторинга сервисов для определения доступности веб-сервера в разных локациях.

Веб-сервер:

• Простой сайт на WordPress, развернутый с помощью стандартного LAMP-стека;
• Виртуальный сервер в VPC с 1 vCPU и 1 GB оперативной памяти на Ubuntu.

Инструменты мониторинга:

• Утилита Netdata для просмотра сведений о системе в реальном времени;
• Мониторинг доступности сервисов, в котором мы используем простой GET-запрос для проведения теста.

Инструмент для стресс-теста:

• IP Stresser, предоставляющий возможность создания теста с объемом атаки до 3 Гбит/c.

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

Настройка приложения и подключение услуги по защите от DDoS

В качестве среды для размещения веб-сервера мы выбрали виртуальное приватное облако за возможность быстрого создания виртуальной машины и подключения публичной подсети:

В состав выделенных ресурсов мы также включили публичную подсеть — для работы с услугой по защите от DDoS плавающий IP-адрес не подходит:

Далее создадим сервер внутри проекта, используя в качестве источника для установки системы готовый образ Ubuntu 16.04. В разделе настройки сети необходимо выбрать подключение через зарезервированную ранее публичную подсеть, а также выбрать и записать публичный IP-адрес: он понадобится нам позже.

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

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

Подключение услуги Базовая защита от DDoS

Заказ услуги осуществляется в разделе Сети и услуги в личном кабинете Selectel:

Выберем пункт Базовая защита от DDoS 10 Мбит/с и произведем оплату услуги:

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

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

Настройка алиасов немного различается в различных системах, в нашем примере мы используем Ubuntu, где это осуществляется следующей командой:

$ sudo ifconfig eth0:0 95.213.255.18 up

Для многих компаний техподдержка не является главным приоритетом и поэтому время ответа на запросы может стремиться к бесконечности, а качество предлагаемых решений оставляет желать лучшего. Однако, в Selectel круглосуточная поддержка, которая отвечает даже в вечер воскресенья (у автора статьи возникла проблема с доступом к сервису статистики):

На данном этапе остается протестировать работу и доступность сервиса через защищенный IP-адрес:

Стресс-тест на незащищенный IP-адрес

Перейдем к стресс-тесту системы на незащищенный IP-адрес со следующими настройками атаки:

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

Начнём первый стресс-тест:

Видно, что почти мгновенно происходит перегрузка процессора и объем принимаемого трафика стремится к 3Гбит/с:

Теперь оценим доступность и время отклика сервиса в разных географических точках:

Большая часть точек проверок показала недоступность указанного сервиса и большое время отклика, что говорит об успешном проведении стресс-теста и уязвимости текущей конфигурации перед DDoS-атаками транспортного уровня.

Резюмируя полученные результаты, очевидно, что веб-сервер полностью принял на себя весь объем тестовой атаки, а в случае увеличения нагрузки произошел бы отказ работоспособности приложения. Далее мы протестируем доступность веб-сервера с подключенной <a href=»https://selectel.ru/services/additional/ddos-protection/» услугой по защите от DDoS атак, однако в реальных системах крайне желательно провести дополнительные мероприятия по обеспечению безопасности приложения на программном уровне.

Стресс-тест на защищенный IP-адрес

Используя полностью аналогичные параметры для атаки кроме IP-адреса, запустим стресс-тест:

Видно, что регистрируемый объем входящего трафика составляет около 120 Мбит/с, а нагрузка на процессор составляет около 20%:

Теперь перейдем к тестированию доступности и времени отклика веб-сервера через инструмент мониторинга:

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

Мониторинг атак и статистика

Как только начинается атака на защищенный адрес, служба Servicepipe уведомляет клиента об этом по email:

Для просмотра информации об атаках в реальном времени доступен веб-интерфейс:

В нем содержится более подробная информация о поступающем трафике:

А также можно увидеть источники трафика по странам:

Вывод

Проведенный опыт показал сохранение работоспособности веб-сервера под тестовой DDoS-атакой при подключенной услуге по защите от DDoS. Кроме того, использование сервиса Servicepipe позволяет отслеживать в реальном времени поступающие DDoS-атак без дополнительных настроек рабочих систем и оперативно реагировать на них.

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

Ознакомиться с типами защит и успешным опытом наших клиентов можно на странице услуги.