Как кинуть ддос атаку на айпи
DDoS атака по IP-адресу. Какая программа нужна и как защититься?
Zip File, мамкины хацкеры. В данном выпуске, я, как и обещал, покажу вам один из способов проведения DDoS атаки по IP-адресу. Темка эта не новая. И чтобы она прокатила, вам должно очень-очень, прямо-таки невероятно сильно повезти. Ибо, что такое DDoS по своей сути. Админы, под данным термином обычно подразумевают большое количество запросов, отправляемых на определённый порт из разных источников.
Т.к. запросов много, оборудование не успевает их все обработать и соответственно уходит в защиту. Тем самым отказывая другим подключающимся пользователям в корректном предоставлении сервиса. Последствия атаки не всегда могут быть очевидны. Например, жертва может банально подумать, что проблемы с возросшим пингом исходят со стороны провайдера.
Начать звонить в тех. поддержку, ругаться, выяснять в чём причина такой безобразный работы. И по итогу докопаться до истины. Но, как правило, мало кто заходит настолько уж далеко. Ведь сами атаки длятся считанные минуты, однако последствия от их проведения при определённом стечении обстоятельств, могут быть действительно ужасающими.
Злоумышленник может поставить под угрозу работу сайта крупной корпорации. Или элементарно сильно замедлить Интернет своему обидчику Пете из девятого Б. Правда у этого Пети при этом, должен быть зачем-то прокинут какой-нибудь популярный порт на роутере во внешку. Ну например, для того же WEB-сайта, который он делает в качестве дополнения к реферату по информатике.
Сам, я, частенько давал такие задания должникам. Поднять сайт на Apache и закинуть туда мордочку вордпресса или джумлы это прям святое. И проверять это дело очень удобно, порт открыли, я чекнул по IPшнику, чел оценочку получил и все довольны. Ладненько, опять меня не в ту степь понесло. Давайте уже приступ непосредственно к практике и проведём-таки небольшую атаку в обучающих целях на мой IP-адрес. Погнали.
Шаг 1. Запускаем Kali Linux и обновляем текущий список пакетов введя в терминале apt update.
Шаг 2. Далее скачиваем с гитхаба скрипт Ксеркс.
Шаг 3. И перейдя во вновь созданный каталог.
Шаг 4. Компилируем файл «xerxes.c» используя GNU компилятор.
Шаг 5. Пока файл запуска создаётся, переходим по нужному белому IP-адресу. У меня на этот, без заморочек прокинута web-морда админки от роутера прямо на 80 порту.
Шаг 6. Возвращаемся в Kali и пробуем запустить наш скрипт указывая соответствующий адрес и порт. Запросы пошли.
Шаг 7. Давайте снова попробуем обновить индексную страничку. Результат, что называется, на лицо.
Атака работает. Но согласитесь назвать этот способ рабочим и классным можно только с большой натяжкой. Ведь для того, чтобы узнать IP-адрес, придётся приложить некоторые усилия. Которые, даже при лучшем раскладе, могут оказаться бесполезны, если ИПы раздаются провайдером динамически и постоянно меняются. К тому же вероятность того, что кто-то из домашних пользователей откроет один из портов – крайне мала.
Обычно, такими вещами занимаются знающие люди, которые уж точно не станут покупать роутер за 1500-2000 в DNS’е. Да и одна работая станция при 100 метровом канале в среднем досит 500-600 мегов за минуту. Для современного оборудования – такая нагрузка в принципе не о чём. Чтоб записать данный ролик мне пришлось искать по всем конторам самую старую D-Link’овскую рухлять.
Ибо никакой DOS не берёт обновлённые железяки. Тут уже нужно напрягать товарищей по оружию и объединившись творить настоящий DDoS. Но и здесь, что называется, палка о двух концах. Провайдеры ведь тоже не дураки, и вычислить вас за такую шалость можно на раз. Поэтому нужно заблаговременно озаботиться вопросом своей анонимности.
Но это уже совершенно другая тема. Мы же сегодня говорим исключительно о принципах DoSи DDoS атак совершаемых по IP’адресам. Кстати, этот метод прекрасно работает в том числе и на слабеньких сайтах. Просто вместо IP’шника вводите DNS-имя, порт и тестируете ресурс на отказоустойчивость. Нормальные сайты, конечно, проверку пройдут. А вот самопальная шляпа, ляжет на раз.
Что ж, на этом у меня всё. Если впервые заглянул на канал, то не теряй время, клацай на колокол и в твоей ленте будут регулярно появляться бодрейшие ролики на тему этичных взломов, пентестингу и практической стороны информационной безопасности. С олдов по традиции жду царские лайки. Соберёте 500 и я расскажу вам, чем ещё может быть чревато неграмотные открытие портов и использование устаревшего сетевого оборудования для повседневных задач.
А с вами, как обычно, был Денчик. Желаю удачи, успехов и самое главное отличного настроения. Берегите себя и свои роутеры, не открывайте порты почём зря и никогда не используйте знания, полученные из моих роликов в противоправных целях. Это может плохо закончиться. Лучше устройтесь на работу сисадмином или на худой конец безопасником и зарабатывайте, не напрягаясь штукарь, другой баксов в месяц. А я вам в этом обязательно помогу. До новых встреч, камрады. Всем пока.
Как сделать Ддос-атаку и сесть на семь лет
Заказать Ддос-атаку много ума не надо. Заплатил хакерам и думай о панике конкурентов. Сначала с кресла директора, а потом с тюремной койки.
Объясняем, почему обращаться к хакерам — последнее дело честного предпринимателя и чем это грозит.
Как сделать Ддос-атаку знает даже школьник
Сегодня инструменты для организации Ддос-атаки доступны для всех желающих. Порог вхождения для начинающих хакеров низкий. Поэтому доля коротких, но сильных атак на российские сайты выросла. Похоже, что хакерские группы просто отрабатывают навыки.
Показательный случай. В 2014 году Образовательный портал Республики Татарстан подвергся Ддос-атакам. На первый взгляд, в нападении нет смысла: это не коммерческая организация и спросить с неё нечего. На портале выставляют оценки, расписание занятий и так далее. Не более. Эксперты «Лаборатория Касперского» нашли группу «Вконтакте», где студенты и школьники Татарстана обсуждали как сделать Ддос-атаку.
Производные запросы от «как сделать Ддос-атаку Татарстан» привели специалистов по кибербезопасности к интересному объявлению. Исполнителей быстро нашли и им пришлось возместить ущерб.
Из-за простоты Ддос-атак за них берутся новички без моральных принципов и пониманий своих возможностей. Такие могут и перепродать данные о заказчике. Омоложение исполнителей Ддос-атак — мировая тенденция.
Весной 2017 года тюремный срок получил британский студент. Когда ему было 16 лет, он создал программу для Ддос-атак Titanium Stresser. На её продаже британец заработал 400 тысяч фунтов стерлингов (29 миллионов рублей). С помощью этой Ддос-программы провели 2 миллиона атак на 650 тысяч пользователей во всём мире.
Подростками оказались участники крупных Ддос-группировок Lizard Squad и PoodleCorp. Юные американцы придумали собственные Ддос-программы, но использовали их для атаки на игровые серверы, чтобы получить преимущества в онлайн-играх. Так их и нашли.
Доверять ли репутацию компании вчерашним школьникам, каждый решит сам.
Наказание за Ддос-программы в России
Как сделать Ддос-атаку интересуются предприниматели, не желающие играть по правилам конкуренции. Такими занимаются сотрудники Управления «К» МВД России. Они же ловят исполнителей.
Российское законодательство предусматривает наказание за кибер-преступления. Исходя из сложившейся практики, участники Ддос-атаки могут попасть под следующие статьи.
Заказчики. Их действия обычно подпадают под статью 272 УК РФ — неправомерный доступ к охраняемой законом компьютерной информации.
Наказание: лишение свободы до семи лет или штраф до 500 тысяч рублей.
Пример. По этой статье осудили сотрудника отдела технической защиты информации администрации города Курган. Он разработал многофункциональную программу Мета. С её помощью злоумышленник собрал персональные данные на 1,3 миллиона жителей области. После — продавал банкам и коллекторским агентствам. Хакер получил два года лишения свободы.
Исполнители. Как правило, наказываются по статье 273 УК РФ — создание, использование и распространение вредоносных компьютерных программ.
Наказание. Лишение свободы до семи лет со штрафом до 200 тысяч рублей.
Пример. 19-летний студент из Тольятти получил получил 2,5 года условного срока и штраф 12 млн рублей. С помощью программы для Ддос-атак он пытался обрушить информационные ресурсы и сайты банков. После атаки студент вымогал деньги.
Неосторожные пользователи. Несоблюдение правил безопасности при хранении данных карается по статье 274 УК РФ — нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей.
Наказание: лишение свободы до пяти лет или штрафом до 500 тысяч рублей.
Пример. Если в ходе доступа к информации каким-либо образом были похищены деньги, статью переквалифицируют в мошенничестве в сфере компьютерной информации ( статья 159.6 УК РФ). Так два года в колонии-поселении получили уральские хакеры, получившие доступ к серверам банков.
Нападки на СМИ. Если Ддос-атаки направлены на нарушение журналистских прав, действия подпадают под статью 144 УК РФ — воспрепятствование законной профессиональной деятельности журналиста.
Наказание: лишение свободы до шести лет или штрафом до 800 тысяч рублей.
Пример. Эту статью часто переквалифицируют в более тяжёлые. Как сделать Ддос-атаку знали напавшие на «Новую газету», «Эхо Москвы» и «Большой город». Жертвами хакеров становятся и региональные издания.
Программы для Ддос-атак
По информации экспертов, для атаки на средний сайт достаточно 2000 ботов. Стоимость Ддос-атаки начинается от 20 долларов (1 100 рублей). Количество атакующих каналов и время работы обсуждаются индивидуально. Встречаются и вымогательства.
Приличный хакер перед атакой проведёт пентест. Военные назвали бы этот метод «разведка боем». Суть пентеста в небольшой контролируемой атаке, чтобы узнать ресурсы защиты сайта.
Интересный факт. Как сделать Ддос-атаку знают многие, но сила хакера определяется ботнетом. Часто злоумышленники крадут у друг друга ключи доступа к «армиям», а потом перепродают. Известный приём — «положить» wi-fi, чтобы тот принудительно перезагрузился и вернулся к базовым настройкам. В таком состоянии пароль стоит стандартный. Далее злоумышленники получают доступ ко всему трафику организации.
Хакеры проведут Ддос-атаку на конкурента. Потом могут получить доступ к его вычислительной мощности и замайнить биткоин-другой. Только эти доходы заказчику не достанутся.
Риски заказа Ддос-атаки
Подведём итог, взвесив достоинства и недостатки заказа Ддос-атаки на конкурентов.
Если конкуренты насолили бизнесу, хакеры не помогут. Они сделают только хуже. Агентство «Digital Sharks» удалит нежелательную информацию законными способами.
В России раньше «фурами» взламывали email-адреса, страницы соц сетей у миллионов, хакали пачками и тысячами номера icq и еще много-много ОЧень много всего. И что вы думаете много кого сажали? ответ — почти никого. Да и сейчас, если подойти к заказу той же ddos-атаки с «мозгами» и позаботиться о своей анонимности… все будет гуд.
Андрей, вы правы, в прошлом происходило огромное количество взломов, однако хочется подчеркнуть, что это было по ряду причин:
1) Слабые технологии защиты;
2) Отсутствие компьютерной грамотности у людей;
Иметь пароль в виде даты рождения считалось нормой, и взломщикам не приходилось выдумывать сложные алгоритмы для подбора символов. Сейчас же большинство уже на автомате подключает двухфакторную авторизацию, не говоря о паролях с абсолютно рандомными символами.
Время меняется, в компетентные органы приходят молодые сотрудники со знаниями и пониманием. К примеру, в мае 2017 года был осужден житель Забайкальского края за взлом страницы знакомой, его приговорили к исправительным работам. В 2019 году осудили 21-летнего хакера из Воронежа, взламывающего личные страницы ВКонтакте. Его приговорили к году исправительных работ с удержанием заработной платы в размере 10% ежемесячно в пользу государства.
Таких историй достаточно, но не так много, как хотелось бы. Все-таки раньше все взломы происходили через технику, а сейчас «взламывают» людей, но это совсем другая история.
Ошибки нет. Некорректно описали процесс. Там мужчина валил сервера, а потом собирал данные. Перепислаи в статье этот блок, чтобы всем читателям было понятно. Спасибо!
Как организовать DDoS в благих целях?
Перед релизом нового сервиса неплохо бы убедиться в том, что он работает в соответствии с нашими ожиданиями и доступен вне зависимости от того, сколько клиентов одновременно им пользуются.
А как этот сервис отреагирует, если против него будет организована распределенная DoS-атака? Защищен ли ресурс от потенциальных действий злоумышленников?
Для того чтобы оценить возможные риски и повысить защищенность, имеет смысл самостоятельно провести действия, имитирующие DDoS-атаку, пока ресурс еще не запущен для массового использования.
В этой статье мы расскажем про опыт организации нагрузочного тестирования для DNS- и HTTP-сервисов.
Подготовка
Для того чтобы спровоцировать генерацию огромного количества сетевого трафика на проверяемом ресурсе, нужно задействовать много виртуальных машин, каждая из которых будет посылать максимальное число запросов к сервису. Если вы не располагаете мощным вычислительным центром, то есть смысл временно арендовать виртуальные машины в каком-либо облаке. Эта затея имеет одну особенность: нужно убедиться в том, что облако не сфолзит, приняв вашу активность за действия злоумышленника.
Сравнив политику различных облачных сервисов (кто-то безжалостно банит учетную запись, с которой, предположительно, были выполнены действия, приводящие к отказу ресурса) в отношении проведения нагрузочного тестирования с использованием их функционала, мы решили остановиться на Amazon Web Services (AWS). В их документах указано, что AWS допускает проведение нагрузочного тестирования, но просит согласовать его, отправив письмо на определенный адрес.
Согласование нагрузочного тестирования
Отправляем сообщение, где коротко рассказываем о своих намерениях, и получаем форму, которую должны заполнить:
Есть несколько нюансов:
У нас спрашивают, кого будем «дубасить». Имеем ли мы на это право? Говорим, что это наш ресурс (по всей видимости, никто не проверяет, так ли это) и что тестирование полностью согласовано.
Нам нужно обозначить, сколько трафика создадим в каждом из регионов. В ходе переписки выясняем, что каждый регион имеет свой лимит на количество сетевого трафика. В общей сложности разрешают запросить 645 Гб/c. Считаем, сколько нужно для атаки, и набираем регионы таким образом, чтобы получилось необходимое значение.
Требуется описать, в какое время будет проводиться атака, как долго будет длиться и как будет расти ее мощность. В свободной форме, но достаточно подробно рассказываем о своих планах. Атака проводится с постепенным увеличением мощности, поэтому расписываем, какие этапы будут у тестирования и какая максимальная мощность предполагается на каждом из них. Дату атаки можно не указывать с точностью до дня, вполне можно обозначить диапазон в две-три недели.
И в обязательном порядке всеми силами стараемся заверить, что будем вести себя хорошо, внимательно наблюдать за ходом тестирования и остановим его по первому требованию в случае необходимости.
Скорее всего, в ответ на заполненную форму попросят какие-то разъяснения, поэтому переписываемся и отвечаем на вопросы до тех пор, пока не получим разрешение на тестирование.
На все согласование уходит примерно три рабочих дня, если отвечать оперативно.
Подготовка инфраструктуры
После согласований сталкиваемся с необходимостью подготовить инфраструктуру для тестирования. Дело в том, что во время проверки нам нужно будет оперативно:
• запускать тестовую атаку;
• собирать статистику о ходе проведения;
• останавливать тестовую атаку;
Создание образа инстанса
Выбор типа инстанса
Характеристики инстансов можно посмотреть вот тут. Также выбирать и сравнивать инстансы можно здесь.
Запрос на увеличение лимита
Нужно заранее подумать о том, сколько инстансов будет участвовать в тестировании. Дело в том, что Amazon предоставляет для каждого региона свои ограничения на число инстансов. Если у вас есть ощущение, что понадобится больше инстансов, чем доступно по умолчанию, то стоит как можно раньше запросить увеличение лимита. Для этого переходим в раздел Support, создаем обращение типа Service limit increase. Время обработки обращения может быть разным: кто-то отвечает уже на следующий день, предоставляя столько сущностей, сколько было запрошено, кто-то говорит, что не даст запустить больше, чем N инстансов. Были и такие регионы, которые отвечали на запрос около месяца.
Тюнинг производительности
Далее нужно создать образ инстанса, который будет запускаться во время тестирования. Для этого включаем инстанс выбранного типа, производим на нем все настройки, затем сохраняем то, что получилось, в качестве образа (в том же меню Actions, где есть возможность включения инстанса, а также функциональность по созданию образа Image Create Image).
Нам нужно получить максимальный исходящий трафик с каждого инстанса, поэтому для начала оптимизируем настройки сети и памяти под нашу задачу на инстансе.
Для этого внесем настройки в файл /etc/sysctl.conf :
• Повысим диапазон локальных портов и уменьшим время нахождения сокетов в состоянии FIN_WAIT:
Диапазон локальных портов определяет максимальное количество исходящих сокетов, которое хост может создать из определенного 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, когда заканчиваются свободные:
Установка вышеуказанной опции (которая по умолчанию отключена) помогает минимизировать потери на «простаивание» уже отработавших соединений.
Очень подробно о TIME_WAIT рассказано в этой статье.
• Включим опцию tcp_timestamps для работы вышеуказанной опции tcp_tw_reuse :
Сценарии тестовых атак
1. Атака на DNS
Одна из основных задач тестирования – оценка производительности DNS-серверов. Именно DNS-серверы могут стать узким местом отказоустойчивости сайта, так как при возникновении проблем с DNS даже самый устойчивый сервис окажется недоступным. Для создания нагрузки на DNS-серверы будем генерировать много разнообразных DNS-запросов. Запросы должны быть валидными и требовать от DNS-сервера как можно большего и длительного ответа.
Для генерации подобного трафика подходит утилита DNSPerf.
DNSPerf – это простой, гибкий и бесплатный инструмент тестирования производительности DNS-серверов. В первую очередь он рассчитан на authoritative DNS-сервера, но может также использоваться для измерения производительности кеширующих серверов.
В нашем случае нагружаются authoritative DNS-сервера, обслуживающие одну зону – example.com.
Для DNSPerf предварительно подготовим файл с запросами dns_queries.txt (преимущественно ANY для увеличения времени и размера ответа от DNS-сервера):
Пример запуска утилиты:
2. Атака на ICMP
Пример запуска утилиты:
3. Атака на HTTP
Теперь проверяем на стрессоустойчивость основной функционал сервиса – обработку HTTP(S)-трафика. Одним из самых гибких и простых инструментов для генерации HTTP-трафика является siege. Siege – это многопоточная утилита с открытым исходным кодом, предназначенная для тестирования производительности веб-ресурса.
Как и DNSPerf, siege позволяет нагрузить сервер запросами от заданного числа виртуальных пользователей (эмуляция пользователя реализуется c помощью отдельного порта), а также использовать подготовленный заранее набор запросов. Это очень удобно, так как можно включить в тест наиболее ресурсоемкие запросы.
Пример запуска утилиты:
Формат содержимого test_urls.txt :
Как видите, тесты проводились с использованием преимущественно POST-запросов, требующих обработки на стороне сервера и занимающих наибольшее количество ресурсов по сравнению с другими типами запросов.
Ни в одном из вариантов не используется подмена IP, так как Amazon не позволяет это реализовать. Какой бы src_IP ни был указан в пакете, на выходе с инстанса он будет изменен на правильный.
Все создаваемые запросы должны быть легитимными – никакой волны исходящего трафика без ответа, – так как политика Amazon в отношении DDoS довольно строгая. Даже согласованный стресс-тест отнимает минимум несколько дней на общение с техподдержкой, а при первых «вредоносных» действиях получаем бан порта, с которого выходил трафик, и требование немедленно объясниться.
Скрипты для запуска атак
Для удаленного управления тестами подготовим bash-скрипты (dns.sh, ping.sh, http.sh), запускающие нужный вид атаки, и файлы с пейлоадами (test_urls.txt, valid_dns_queries.txt).
Когда мы загрузим все это на AWS-образ (из которого и будут создаваться все инстансы), каждый тест можно будет запускать удаленно командой следующего формата:
В качестве stress-script.sh указывается скрипт нужного типа, а params — соответствующие параметры. В файле stress.log мы будем отслеживать вывод запущенной утилиты. Для удобства будем использовать разные логи для разных утилит: dns.log, ping.log, http.log.
Пример скрипта dns.sh :
Как видно из кода, скрипт можно будет запускать и останавливать, а также проверять статус (запущен/не запущен).
Аналогичным образом построены скрипты для ICMP- и HTTP-тестов, запускающие соответственно hping3 и siege с переданной через аргумент строкой параметров.
Скрипты мониторинга
Для оценки исходящего трафика и состояния инфраструктуры тестирования нам понадобится средство мониторинга. Из соображений простоты и экономии ресурсов используем iptables. Для этого напишем скрипт, подсчитывающий количество отправленных Мб, и положим его на AWS-образ:
Скрипт создает новую цепочку TRAFFIC_OUT и добавляет в нее фильтры для нужных протоколов: tcp, udp, icmp.
В цепочку OUTPUT добавляется перенаправление пакетов в TRAFFIC_OUT.
Количество переданных данных можно узнать командой:
Установим скрипт в качестве сервиса. Для этого создадим файл monitoring.service и переместим его в директорию /etc/systemd/system нашего образа:
Теперь можно добавить сервис в автозагрузку:
Управление инстансами
Теперь разберемся с удаленным (максимально автоматизированным) управлением инстансами.
Для этих целей можно использовать механизм AWS CLI – управление с помощью консоли.
Создаем Secret Key (Access keys (access key ID and secret access key)) и настраиваем консоль.
Теперь у нас есть доступ ко всем возможностям учетной записи.
Особенность работы с AWS состоит в том, что все действия выполняются для конкретного региона и их приходится повторять, если привлечено несколько регионов.
Для создания нового инстанса из образа, который мы выше смастерили (подразумеваем, что есть публичный ami-ID, который используем в скрипте), выполним следующие действия:
Затем можно подключиться по SSH, если нам известен IP-адрес. Просто запрашиваем список машин, которые сейчас запущены. Среди их параметров находим PublicDnsName или PublicIpAddress.
Далее выполняем SSH-команды, указав SSH-ключ, созданный выше:
SSH-команды позволяют управлять атакой и получать всю информацию о состоянии атаки, так как мы снабдили инстансы всеми необходимыми скриптами и инструментами.
Нужно понимать, что большинство средств защиты от атак, направленных на отказ в обслуживании, блокируют IP-адрес, с которого поступает аномально много запросов. Поэтому IP-адреса виртуальных машин должны постоянно меняться для поддержания мощности атаки.
AWS присваивает новый IP-адрес каждый раз, когда машина запускается. Поэтому для смены IP потребуется выключить и включить машину заново (не нужно ее удалять!).
Разница между выключением и удалением заключается в том, что мы посылаем разные сигналы. Stop – чтобы выключить, terminate – чтобы выключить и сразу же удалить.
В целях мониторинга входящего трафика инстанса используем следующую команду с указанием ID инстанса: когда начинается замер трафика, когда заканчивается, за какой период значения суммируются:
Мониторинг доступности сервиса
Дополнительно для проведения атаки потребуется наблюдать, жив ли тот сервис, который мы тестируем.
Создаем и запускаем простейший «пинг»-скрипт, который отслеживает доступность целевых портов (53 и 80 в нашем случае).
Пример кода на Python, который позволяет автоматизировать проверку доступности:
Полученную информацию сохраняем в лог-файле, на основе которого по итогам атаки можно будет построить график доступности ресурса.
Если замедление работы несущественное, а мощность атаки достигла установленного максимума, то есть смысл подождать минуту или две, и если сервис продолжает работать без перебоев, то проверка считается успешной.
Финансовый вопрос
Стоит обсудить еще один вопрос, связанный с организацией тестирования, — стоимость всего этого мероприятия.
Amazon предоставляет подробную информацию о тарифах, но нужно понимать, что приходится платить практически за все. Тем не менее многими расчетами можно пренебречь. В первую очередь стоит посчитать стоимость трафика (зависит от региона и от того, какой итоговый объем информации будет передан) и стоимость аренды инстансов (оплата поминутная). Эти пункты образуют примерно 99 % от стоимости всей атаки.
Поэтому стоимость атаки рассчитывается в каждом случае отдельно в зависимости от [масштаба боевых действий] максимальной мощности атаки и числа планируемых запусков.
С точки зрения упрощения расчетов лучше использовать учетную запись Amazon, которая зарегистрирована не больше года назад. Тогда часть операций будет бесплатна. Подробнее про лимиты бесплатного использования можно почитать здесь.
Для того чтобы проиллюстрировать подсчет стоимости проведения нагрузочного тестирования, допустим, что хотим проверить устойчивость DNS-сервера к нагрузке в 10 Гб/c.
Мы будем увеличивать мощность атаки постепенно, для этого сначала запустим одну сущность, затем добавим еще по одной каждые 60 с.
Формула расчета стоимости принимает вид: