Від стрес-тесту до DDoS — менше, ніж здається. Як змусити сервери стресувати

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Мене звуть Сергій, я General QA. До нещодавна жив собі звичайнісіньким життям, усіляко тестував функціонал свого продукту, займався улюбленими справами. Аж раптом зіткнувся з тою ж самою проблемою, що і вся країна. Назва проблеми — повномасштабна війна.

В статті я хотів би розповісти про свій досвід використання різноманітних інструментів навантажувального тестування, за допомогою яких можна відносно легко та ефективно робити стрес-тест, а за бажанням й DDoS-атаку (або DoS-атаку).

І тут постає питання: а чим, власне, стрес-тестування відрізняється від DoS-атаки? На мою думку — різниця, перш за все, формальна. Тобто чисто технічно сценарій проведення може бути однаковим, тільки стрес-тест — це зазвичай санкціонована процедура, погоджена.

Мій улюблений інструмент для цього — це Apache Jmeter, який є класикою жанру та швейцарським ножем в цій галузі. Функціоналу «з коробки» — вистачає з головою.

Але наразі з’явився ще один нюанс — не хотілося перевантажувати й без того перевантажену українську мережу. Тож специфіка полягала в максимізації ефективності при оптимальному навантаженні.

Крім того, довелося відкрити для себе віртуальні сервери (раніше якось не доводилося використовувати). А ще відкрив чимало різноманітних нюансів, про існування яких не знав і не парився.

Розглянемо:

  • Використання Apache Jmeter на локальному хості.
  • Розгортання Docker-контейнерів на віртуальному сервері.
  • Інструменти та різновиди атак.
  • Трошки теорії (як же без неї).

Отже, спершу про теорію

Види навантаження зазвичай розподіляється на навантаження на рівні L7 і L3&4.

L7 — навантаження сьомого рівня моделі OSI. Це навантаження на рівні додатків, частіше всього під ним розуміють тільки HTTP, однак не буде перебільшенням розуміти будь-яке завантаження на рівні протоколу TCP.

У L7 атак є певні відмінні риси. По-перше, вони приходять безпосередньо в додаток, відобразити їх мережевими засобами вийде навряд чи. Такі атаки задіюють логіку, і через це дуже ефективні, і навіть при невеликому трафіку споживають процесор, пам’ять, диск, базу даних та інші ресурси.

HTTP-flood

Звісно, навантаження простіше створити, ніж обробити, і в разі з L7- атаками теж. Трафік таких атак не просто відрізнити від легітимних запитів, і частіше його відрізняють за частотністю, але якщо все сплановано як слід, то відрізнити атаку від легітимних запитів досить складно.

HTTP-flood — це найпростіший спосіб створити навантаження. Зазвичай, для цього підійдуть такі інструменти як Apache Jmeter або ApacheBench та формування запиту. При такому простому підході є велика ймовірність нарватися на кешування сервера, але його легко оминути. Наприклад, додавши випадкові рядки в запит, що змусить сервер постійно віддавати свіжу сторінку.

При всій простоті атаки HTTP Flood мають свої недоліки. По-перше, для створення навантаження потрібні більші потужності. По-друге, такі атаки досить легко виявляються, особливо якщо йдуть з однієї адреси. У результаті запити відразу ж починають фільтруватися або системними адміністраторами, або навіть на рівні провайдера.

Для того щоб знизити кількість запитів на секунду і при цьому не втратити в ефективності, потрібно витратити час на дослідження сайту. Адже навантажувати можна як канал чи сервер, так і окремі частини архітектури, наприклад, бази даних чи файлові системи. Також можна пошукати місця на сайті, які роблять великі обчислення: пошуковики, калькулятори, сторінки з підбором продуктів та інше. Нарешті, часто буває, що на сайті є якийсь PHP-скрипт, який генерує сторінку з декількох сотень тисяч рядків. Такий скрипт також значною мірою навантажує сервер і може стати мішенню для атаки.

Також не варто забувати про піддомени. Наприклад, є якийсь онлайн-магазин, example.com, і він має піддомен admin.example.com. Швидше за все, це адмінка з авторизацією, але якщо в неї пустити навантаження, то вона може створити проблеми для основного ресурсу. Крім того, головна сторінка сайту може бути захищена від дідосів, а от на адмінку частіше заплющують очі. Також у вебсайту може бути піддомен api.abc.com. Ймовірно, це ресурс для мобільних додатків.

Не варто забувати про такий популярний нині REST API. Захистити REST API набагато складніше, ніж звичайний сайт. Для REST API не працюють навіть банальні засоби захисту від перебору паролів та іншої нелегітимної активності.

REST API досить просто зламати, тому що він звертається безпосередньо до бази даних. При цьому виведення такого сервісу з ладу спричиняє досить тяжкі наслідки. Справа в тому, що з REST API зазвичай зав’язаний не лише головний сайт, а й мобільний додаток, якісь внутрішні бізнес-ресурси. І якщо це все падає, то ефект набагато сильніший, ніж у випадку з виходом з ладу простого сайту.

Робити випадкові запити до бази даних теж завжди ефективно. Набагато краще створити список ключових слів, які стосуються пошуку. Крім того, варто використовувати пагінацію: пошуку набагато складніше віддати передостанню сторінку видачі, ніж першу. Тобто за допомогою пагінації можна трохи урізноманітнити навантаження.

Важкий контент

Наприклад, великі картинки, які віддає сервер, бінарні файли, pdf-файли.Це добре вантажить файлову систему та забиває канали, тому так ефективно. Тобто навіть якщо сервер не ляже, все одно під час завантаження великих файлів на невеликих швидкостях це забиває канал цільового сервера та призводить до відмови в обслуговуванні.

Атаки L3&4

Окрім протоколу HTTP на рівні L7, можна експлуатувати інші протоколи. Як правило, у звичайного вебсайту, тим більше у звичайного хостингу, назовні стирчать поштові протоколи та база даних. Поштові протоколи схильні до навантажень меншою мірою, ніж бази даних, але їх теж можна навантажувати досить ефективно і на виході отримувати перевантажений процесор на сервері.

Атаки на рівнях L3&4 — це атаки канального рівня. Таке навантаження майже завжди відрізняється від легітимного, якщо це не атака SYN-flood. Проблема SYN-flood атак для засобів захисту полягає у великому обсязі.

SYN-flood (або TCP-flood)

SYN-атака — атака транспортного рівня моделі OSI. Полягає у відправці у відкритий порт сервера маси SYN-пакетів, що не призводять до встановлення реального з’єднання з тих чи інших причин, що спричиняє створення «напіввідкритих з’єднань», які переповнюють чергу підключень, змушуючи сервер відмовляти в обслуговуванні черговим клієнтам. Плюс до цього TCP RFC зобов’язує сервер відповідати на кожен вхідний SYN, що додатково б’є як по ресурсах сервера, так і по каналу передачі даних.

SYN та SYN-ACK — це пакети, які використовуються під час встановлення з’єднання. Тому SYN-flood і складно відрізнити від легітимного навантаження: незрозуміло, це SYN, який прийшов на встановлення з’єднання або частину флуду.

SYN-flood є дуже цікавим видом атаки. Справа в тому, що найчастіше для захисту використовують блокування IP, і це роблять як люди, так і автоматизовані системи захисту. Використовуючи ампліфікацію через SYN та SYN-ACK, коли на відправку одного SYN система відповідає двома-трьома SYN-ACK, зрештою атака множиться у два-три рази.

UDP-flood

UDP — це протокол, який працює без встановлення з’єднання. Перед використанням протоколу UDP передачі даних з’єднання між клієнтом і сервером не встановлюється. Якщо дані губляться під час передачі від клієнта до сервера, сам протокол не може це виявити. Тому часто називають протокол UDP ненадійним протоколом передачі.

Оскільки UDP — ненадійний мережевий протокол, яка корисна цінність чи необхідність? Це не той випадок, у деяких випадках протокол UDP може стати дуже корисним. Тому що UDP має перевагу в швидкості, що не має аналогів TCP. Незважаючи на те, що в TCP вбудовані різні функції безпеки, під час фактичного виконання буде задіяна велика кількість системних витрат, що, безсумнівно, серйозно впливає на швидкість передачі.

Навпаки, UDP, оскільки він виключає надійний механізм передачі інформації, передає функції, такі як безпеку та сортування додатків верхнього рівня для завершення, значно скорочуючи час виконання та забезпечуючи швидкість передачі.

UDP-flood — це атака пропускної спроможності. Ініціюється величезна кількість пакетів UDP до цільового сервер. Такі пакети UDP зазвичай є великими пакетами, і їхня швидкість дуже висока. Це навантажує ресурси смуги пропускання мережі та може навіть викликати перевантаження каналу, а велика кількість UDP-потоків з різними джерелами та портами може призвести до того, що мережеві пристрої, які використовують переадресацію сеансів, погіршать продуктивність і навіть вичерпують сеанси, що може призвести до паралічу мережі. UDP-flood не встановлює з’єднання, на відміну від SYN Flood, тому й захиститися від них важче. І відрізнити від легітимного трафіку теж.

ICMP-flood

Нелегітимні ICMP-пакети складно відрізнити від легітимних, адже Internet Control Message Protocol не має вимоги підтвердження про отримання. Атака може використовуватися ще для отримання інформації про сервер для майбутнього точкового нападу. Окремий вид: з великими фрагментованими пакетами ICMP для вичерпання ресурсів сервера. Нині такі атаки досить рідкісні, оскільки пропускна спроможність мереж за останні роки підвищилася.

Примітка: Атаки рiвня L7 краще робити коли відомо доменне ім’я цілі. Атаки рівня L3/L4 краще проводити на IP-адресу, тобто безпосередньо на сервак. Ще трохи теорії буде надано впродовж опису роботи інструментів, тож це не все.

Тепер — інструменти.

Apache Jmeter

Як вже було написано, це класика жанру, а класика не старіє. Кросплатформений інструмент, для якого потрібна тільки Java-машина, досить приємний інтерфейс, можливість дуже гнучко та комплексно формувати запити і репрезентативні метрики. Якщо чогось нема на базі — плагіни допоможуть. Також, можливо формувати розподільну мережу, роблячи з DoS-атаки вже повноцінну DDoS-атаку.

З недоліків: це переважно GUI інструмент. Так, він досить оптимізований під використання без графічної оболонки, але все ж його сила — це GUI mode.

В принципі, туториалів та мануалів для цього інструменту безліч, то можна пробігтися «взагалі по загалям»

Кількість навантаження задається в блоку Thread Group.

Примітка: Кількість ітерацій (Loop Count) краще не ставити в режим нескінченності, бо якщо почне жерти багато ресурсів — складно буде зупинити виконання.

Блок HTTP Header Manager краще ставити не в кожен запит, а над всіма. Перший заголовок, який слід прописати, це user-agent.

Багато user-agent популярних інструментів тестування фільтруються системними адміністраторами, і в такому разі навантаження може просто не дійти до бекенда. Значно покращити результат можна, вставляючи в запит більш менш валідний заголовок з браузера (а точніше, скопіпастити з девтулзів).

Те саме стосується й блоку HTTP Request Default: в ньому можна написати домен, протокол та порт цільового ресурсу, а вже в зразках запиту — тільки кінцевий шлях та параметри.

А вже в полях запиту можна писати конкретний шлях (Add -> Sampler -> HTTP Request).

Для моніторингу успішності процесу можно додати до сценарію якість «слухач». Особисто я рекомендую View Results Tree, щоб бачити результат кожного зразку.

Власне, загальний сценарій виглядає так. Цей зразок можна зберегти як шаблон для подальшого використання.

А тепер — декілька важливих тюнингів.

Використання проксі-серверів

Якщо є вірогідність, що IP може бути заблокований, а під рукою нема VPN, то доцільно використовувати проксі-сервери.

Поставити адресу проксі-серверу можливо в кожному окремому запиті HTTP Request або у головному запиті — HTTP Request Default. Робиться все у вкладці Advanced.

Використання CSV-файлів

У наведеному прикладі всі дані зазначені в статичному режимі. Але краще, якщо деякі дані будуть змінюватися в кожним новим запитом. Саме для цього всі необхідні дані зберігаються в файлі в форматі CSV і додаються до запитів через змінну.

До сценарію додається та налаштовується відповідний блок: Add -> Config Element -> Data Set Config. А оголошені змінні додати куди слід.

Таким же чином можна буде зробити вибірку будь-чого: айпішників, портів, юзер-агентів, параметрів для запиту. Дуже класна річ.

Використання рандомної генерації

Варто зазначити один нюанс: чим різноманітніше буде кількість потоків, тим краще буде навантаження на сервер(и). Отже, однаковий шлях в кожному запиті — це не діло. Краще за все — запит на окрему сторінку. А ще краще — запит в пошуковик, який присутній в переважній більшості сучасних вебсайтів. Це створює навантаження на базу даних та на бізнес-логіку. А крім того, що особливо приємно — таким чином можна уникнути кешування.

Робити це можна вже вищевказаним способом або завдяки рандомній генерації тексту. Доступно просто «з коробки»: Tools -> Function Helper -> RandomString

А згенеровану змінну додати як параметр запиту.

Використання POST-запитів

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

Скопіпастити форму запиту в браузерних девтулзів або улюбленого проксі (на кшталт Charles) — і нехай сервак захлинається, веріфікуючі потік надісланих запитів.

Повільний HTTP POST

У цього методу є значна перевага — це дуже ефективно. Але також є і значний недолік — цей ефект діє в обидві сторони, тобто своя мережа теж буде сильно гальмувати.

Повільна POST HTTP-атака передбачає надсилання великого POST-запиту невеликими фрагментами на сервер. Справа в тому, що за стандартом HTTP-сервер повинен чекати повної передачі даних і може закрити з’єднання лише за тайм-аутом. Таким чином атакований сервер відкриває величезну кількість з’єднань, катастрофічно витрачаючи свої ресурси.

Щоб провести цю атаку, вам потрібно відредагувати файл users.properties, який знаходиться в папці /bin, а саме: відкрити цей файл і додати рядки:

httpclient.socket.http.cps=1

httpclient.socket.https.cps=1

Це необхідно для емуляції повільного інтернет-з’єднання. Це означає, що буде надсилатися один символ в секунду, а це дуже повільно.

Закінчивши, не забути видалити їх з файлу.

Використання інструментів навантаження в Docker-контейнері на віртуальному сервері

Перш за все, потрібен віртуальний сервер: VPS (Virtual Private Server) або VDS (Virtual Dedicated Server).

Вибір немалий: можна підняти віртуалку на Azure, Amazon, Google Cloud Platform, Vultr. Але я продемонструю приклад на досить популярному Digital Ocean.

Отже, перш за все, треба зареэструватися на DO.

Примітка: Якщо є пошта на gmail, то можна зробити наступним чином: після назви скриньки та перед символом «@» написати символ «+» та рандомну кількість символів — то для DO це буде унікальна назва скриньки, а от Gmail це ігнорує. Таким чином, на одну гуглову скриньку можна зробити декілька акаунтів.

Ще одна примітка: Оплату акаунту краще прив’язати до віртуальної картки, яку за декілька хвилин можна зробити у більшості банків.

Яку віртуалку обирати, якої потужності — залишається на розсуд кожного, але розглянуто буде мінімальний сервак, якого для більшості інструментів має вистачити.

Розташування серверу: чим ближче географічно, тим краще.

Не забути обрати також автоматичне встановлення Docker, в іншому разі доведеться встановлювати в ручному режимі.

Авторизація: надійніше, звісно, генерування SSH-ключа, але можна й одразу написати пароль.

Це все загальні пункти. Інші деталі — опціонально, на власний розсуд.

Коли все буде готово — натиснути кнопку Create Droplet та дочекатися створення інстансу.

Власне, сервак готовий.

До нього треба підключитися, це робиться за протоколом SSH. Якщо підключатися з макбуку чи з компа на базі ОС Linux — достатньо використовувати термінал.

Якщо підключення буде відбуватися з Windows — треба користуватися SSH-клієнтами. Класика цього жанру — утиліта PuTTy, але утиліта SmarTTY не гірше.

Щоб перевірити наявність Docker на сервері, достатньо ввести в терміналі сервака:

docker -v

Вітаю, все готово.

Інструменти для навантаження

Тепер — інструменти. Вдалося застосувати декілька інструментів, на жаль, досвіду їхнього використання не так багато, як хотілося б, але всі працюють досить результативно.

Bombardier

Простий та лаконічний кросплатформний інструмент для тестування HTTP, написаний на Go. Використовує чудовий fasthttp замість стандартної http бібліотеки Go через його продуктивність

В терміналі сервака виконати команду:

docker run -ti --rm alpine/bombardier -c 1000 -d 3600s -l ip:port/hostname

run — створення контейнера з образу та виконання контейнера

-t — запуск терміналу для взаємодії з контейнером (опціонально)

-i — запуск інтерактивного режиму (опціонально)

—rm — видалити після завершення роботи (обов’язково, суб’єктивна думка)

alpine — легкий дистрибутив Linux, на основі якого створюється контейнер

bombardier — назва образу (docker image)

 — кількість потоків, що запускаються

-d — час виконання (у цьому прикладі: 3600s = 1 год)

ip:port/hostname — IP-адреса та порт цільового сервера АБО доменне ім’я цільового ресурсу.

Параметри запуску можна змінювати на власний розсуд.

Відстежувати кількість контейнерів: команда

> docker ps

Відстежувати споживання ресурсів сервера:

> htop

Apache Bench

ab — досить повільний та однопотоковий, втім не потребує багато ресурсів, написаний на мові C і постачається в комплекті зі стандартним вихідним кодом Apache, оскільки від самого початку створювалася саме для тестування вебсервера Apache.

До речі, якщо хтось сидить на вінді та користується пакетом утиліт Open Server — там ab теж є (не забуваємо про використання VPN).

Виконати команду:

> docker run —rm jordi/ab -c 10 -n 1000 -l hostname

АБО

> docker run —rm devth/aipine-bench -t 7 -c 1000 -n 3000 -l hostname

 — кількість запитів для одночасного виконання. За замовчуванням — один запит за раз.

-l — не повідомляти про помилки, якщо довжина відповідей непостійна. Це може бути корисно для динамічних сторінок.

-n — кількість запитів для виконання. За замовчуванням виконується лише один запит.

-t (timelimit) — максимальна кількість секунд, яку потрібно витратити на порівняльний аналіз (раптом треба буде).

-s (timeout) — секунди до максимального очікування кожної відповіді (раптом треба буде).

Важлива примітка: Apache Bench працює тільки з доменним ім’ям, який наприкінці має прямий слеш («/»). Інакше впаде.

hping3

Утиліта HPING дозволяє генерувати спеціальні ICMP/UDP/TCP пакети та переглядати відповіді хоста, що пінгується, за допомогою звичайної утиліти ping.

Підтримує фрагментацію, дозволяє визначати розмір і вміст тіла пакета і може використовуватися для передачі файлів за протоколами, що підтримуються.

Відповідно, образ інструменту один, а от команд може бути декілька.

Атака SYN-flood

Атака на перевищення максимальної кількості напіввідкритих сесій

> docker run —rm sflow/hping3 —flood -S -p 80 hostname/ip

—flood — надсилати стільки пакетів, скільки можливо.

-S — використовувати SYN пакети (протокол TCP)

-p 80 — пакети надсилаються на порт 80 (HTTP)

Атака ICMP-flood

Краще використовувати разом з великим розміром пакетів, щоб спробувати вичерпати вхідний канал сервера, якій атакується.

> docker run —rm sflow/hping3 —flood —icmp -d 1000 hostname/ip

—icmp — використовуємо пакети ICMP

-d 1000 — вказуємо розмір пакету

UDP-flood

Ця атака також насичує смугу пропускання.

> docker run —rm sflow/hping3 —flood —udp -s 53 —keep -p 68 hostname/ip

—udp — використовуємо UDP

-s 53 — відправляємо з порту 53

—keep — фіксуємо порт відправлення, інакше він збільшуватиметься на 1 для кожного наступного пакета

-p 68 — надсилаємо пакети на порт 68

Ще один образ тої ж самої утіліти

> docker run utkudarilmaz/hping3 —flood —icmp -d 1000 hostname/ip

SlowHTTPTest

Атака на повільне підключення (дуже цікава річ).

Сенс цієї атаки в тому, що у будь-якого Web-сервера є ліміт на кількість одночасних підключень, але коли при підключенні дуже повільно запитується сторінка — з’єднання не скидається, а кількість паралельних підключень сервера обмежена.

Ця програма реалізує найбільш загальні уповільнюючі роботу мережі атаки рівня додатків, такі як Slowloris, атака slow body, атака Slow Read (на основі експлойту постійного таймера TCP), вона займає весь доступний пул підключень, а також атака Apache Range Header, яка стає причиною значного використання пам’яті та процесора на сервері.

Slowloris і Slow HTTP POST атаки покладаються на факт, що HTTP навмисно вимагає від запитів бути отриманими сервером повністю до того, як вони будуть оброблені. Якщо запит HTTP неповний або швидкість його пересилання дуже повільна, сервер зберігає свої ресурси зайнятими, чекаючи даних, що залишилися. Якщо сервер підтримує занадто багато зайнятих ресурсів, це тягне за собою відмову в обслуговуванні. Цей інструмент надсилає часткові запити HTTP, намагаючись домогтися відмови від обслуговування цільового HTTP сервера.

Атака Slow Read орієнтована на ті ж ресурси, що й slowloris зі slow body, але замість продовження запиту, вона надсилає легітимні HTTP-запити, але відповіді читає повільно.

Запуск SlowHTTPTest:

> docker run frapsoft/slowhttptest -c 1000 -H -i 20 -r 200 -t GET -u domainname

-c — загальна сумарна кількість підключень

-i — пауза між сесіями для завантаження частини сторінки (в рамках одного підключення)

-r — кількість підключень за секунду

-t GET — використовувати GET запити (так само можна POST)

-u — URL. Підтримує HTTP та HTTPS посилання

-x — кількість байт, що завантажуються, з частини сторінки за одну сесію (в рамках одного підключення)

-p — час очікування під час перевірки підключення. Якщо відповідь від сервера не отримана за цей час, сервер вважається недоступним

-H — атака slow headers a.k.a. Slowloris

Також доступні типи атак:

-B — атака slow body a.k.a R-U-Dead-Yet

-R — атака range attack a.k.a Apache killer

-X — атака Slow Read

Зразок результату роботи програми:

Siege

Утиліта siege (англ. «облога»), яка просто запитує сторінки сайту у безліч потоків, після чого відбувається вичерпання або ресурсів сервера (якщо запитуємо важкі сторінки), або ресурсів вихідного каналу (якщо запитуємо важкі файли).

Також Siege може імітувати звернення до сайту одразу кількох користувачів. Це дозволяє довго тримати сервер ніби під облогою.

Кількість запитів, зроблених під час «облоги», розраховується із загальної кількості користувачів та кількості їх звернень до сервера.

Наприклад, 20 користувачів, звернувшись по 50 разів, створюють загалом 1000 запитів.

Результат, що виводиться програмою після тестування, включає час, витрачений на перевірку, загальну кількість переданої інформації (в тому числі — заголовки), середній час відповіді сервера, його пропускну здатність і кількість запитів, на які прийшла відповідь з кодом 200.

Ці дані формуються та надаються при кожній перевірці. Докладно вони описані нижче.

Siege має 3 основні моделі роботи:

  • режим регресійного тестування — зчитує порцію посилань конфігураційного файлу і звертається до них по черзі;
  • режим імітації Інтернету — зчитує порцію посилань конфігураційного файлу і звертається до них рандомно;
  • режим грубої сили — користувач може вказати одну єдину адресу, до якої будуть проводитися всі звернення.

Запустити:

> docker run —rm -t yokogawa/siege -d1 -r15 -c100 domainname

АБО

> docker run —rm -t yokogawa/siege -t25s -d1 -r15 -c100 domainname

-d — це рандомна затримка у секундах між запитами;

-r — це кількість запитів на користувача;

-c — це кількість користувачів (потоків);

-t — це час (в секундах).

Примітка: Більшість команд можна завершити, натиснувши разом: Ctrl+C. Але працюємо все ж з Docker-контейнерами, їх тушити командою: docker stop <container_id>

Примітка: Не буде зайвим дивитися звіти виконання навантаження, які формуються після завершення роботи програм з метою коригування параметрів.

Ще трошки про Docker

Адмін-панель користувача надає ряд інструментів контролю показників роботи віртуальних серверів (дроплетів).

Наприклад, візуалізація задіяності ресурсів:

У разі некоректного налаштування або втрати актуальності дроплета, або у разі, коли запуск зазначеної команди став неактуальним через блокування IP-адреси сервера — доцільно знищити дроплет і створити новий.

Наче все.

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному10
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

С помощью Apache Jmeter можно положить самый какой-то нубовский сайт. Обычно это используется QA для тестировки нагрузки в сыром виде. Если стоит тот же CloudFire не сможет положить. Я рекомендую использовать mhddos(на гите есть).И там же есть образ для докера. С возможностью использовать разные опции. А если вы просто найдете сайт увидите айпи, а там стоит WAF и ваши пакеты просто будут отбрасываться. Для этого нужна хорошая разведка. Так что рекомендую канал t.me/ukrainian_reaper_ddos

Вы правы только отчасти.
Если хорошо провести разведку, как следует выявить горизонт атаки, и грамотно составить образец запроса, то в ряде случаев достаточно и Apache Jmeter (в ряде случаев). То есть, на эффективное использование почти любого инструмента в немалой степени влияет опыт и компетенция его пользователя.
Да, канал что вы рекомендуете — годный. Тоже рекомендую.

Тогда извиняюсь) У меня был частичный опыт с Apache Jmeter и может чего-то не заметил.

практика показывает, что 50% ресурсов складываются от обычного slowhttptest
достаточно 2х инстансов по 5$, в цикле запущенный slow и ресурс уходит в аут (если между ним и вами не стоит WAF)

о, да.
поэтому я и указал что slowhttptest это «дуже цікава річ».

Не потрібно панікувати, потрібно бути як Сергій!

Підписатись на коментарі