DDoS Как реализовать DDOS-атаку и какие книги и видео стоит прочитать?

[xsTao]

Я бы использовал некоторые инструменты DOS, такие как R.U.D.Y и hping, но не думаю, что какой-либо из них повредит серверу 2023 года. Я хочу знать больше

 

[Dread Pirate Roberts]

какие книги

сначала
google:// "сети для самых маленьких" / "computer networking for dummies"
google:// "какие бывают виды DDOS атак"
google:// "какая разница между layer-4 и layer-7 DDOS атаками"

а потом приходи с более конкретными вопросами, если что-то будет непонятно.

Я бы использовал некоторые инструменты

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

 

[xsTao]

сначала
google:// "сети для самых маленьких" / "computer networking for dummies"
google:// "какие бывают виды DDOS атак"
google:// "какая разница между layer-4 и layer-7 DDOS атаками"

а потом приходи с более конкретными вопросами, если что-то будет непонятно.

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

Я использую RUDY для тестирования сервера Microsoft IIS7 с использованием переадресации портов во внешнюю сеть. Это http.На адресной странице есть окно для ввода аккаунта и пароля, соответствующее стандартам RUDY-атак. После нескольких секунд непрерывных атак сервер вышел из строя. Но я использовал тот же метод для атаки на другой адрес домена (похожий на https://diofsif123.xyz). На странице доменного имени есть окно поиска. Это https, теоретически в случае успешной атаки страница будет недоступна, но RUDY DOS не дает никакого эффекта. Я использовал nslookup+доменное имя и получил неавторитетный ответ. Нужно ли мне знать авторитетный ответ? Или на этом сервере есть дополнительные меры безопасности?

 

[Dread Pirate Roberts]

RUDY DOS не дает никакого эффекта

у сайта может быть настроен anti-ddos.

Я использовал nslookup+доменное имя и получил неавторитетный ответ. Нужно ли мне знать авторитетный ответ?

с вероятностью 99.99% это не имеет значения, неавторитетный ответ даст тот же IP адрес, что и авторитетный.

Или на этом сервере есть дополнительные меры безопасности?

google:// "как работает DNS"
google:// "как работает CDN"
google:// "почему у одного сайта может быть несколько IP адресов"
google:// "что происходит когда я ввожу в браузере адрес сайта и нажимаю Enter"
google:// "как использовать WHOIS"

 

[Мутабор]

Маэстро c0d3x, дай гражданину авторитетный ответ )

А я пока набросаю мини-мануальчик инструментария для самых маленьких. Итак, самый первый инструмент начинающего ддосера - это конечно же GoldenEye. Что мне в нём нравится, так какой ширины канал ему не дай - весь захватывает. Работаем:
git clone https://github.com/jseidl/GoldenEye.git && cd GoldenEye && ./goldeneye.py https://cb.anabolicshops.me/ -w 2 -s 4 -m get -n

Второй известный инструмент доморощенных мамкиных дудосеров - это утилита для стресс тестирования под названием ab
Установка:
apt-get install apache2-utils -y && apt-get install python3-pip -y && pip3 install requests pysocks && apt-get install python3-pip -y
Юзаем:
ulimit -n 10000 && ab -n 10000000 -c 1000 -k -r -l -s 150 -H "User-Agent: Google Bot" https://cb.anabolicshops.me:443/
или так:
ulimit -n 10000 && ab -n 10000000 -c 1000 -k -r -l -s 150 -H "Accept-Encoding: gzip, deflate" https://cb.anabolicshops.me:443/index.html

Вот этот тоже ничего:
git clone https://github.com/ngrock90/xerxes.git && cd xerxes && gcc xerxes.c -o xerxes && ./xerxes cb.anabolicshops.me

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

И где-то вдалеке cнова запел админ АШ Vjlink

 

[xsTao]

Есть ли способ атаковать транспортный уровень? Я могу думать только об использовании hping3 для отправки SYN-флуда на цель, но у меня нет ботнета, поэтому цель не будет серьезно затронута. Что лучше: использовать медленную атаку или усиленную атаку? Я попробовал этот инструмент https://github.com/DrizzleRisk/NTPDoser. Принцип заключается в том, что атакующая машина обманывает сервер синхронизации времени (NTP), и сервер синхронизации времени возвращает большой объем данных на целевой сервер, вызывая целевая система выйдет из строя. Я попробовал это, нашел доменные имена NTP-серверов и использовал их здесь https://support.ntp.org/Servers/NTPPoolServers, но атака, похоже, не работает, может быть, я делаю что-то неправильно? Либо цель не открыла порт 123 udp и не может быть атакована.

该站点可能配置了anti-ddos。


有 99.99% 的可能性，这并不重要，非权威响应将给出与权威响应相同的 IP 地址。




google://“DNS的工作原理”
google://“CDN的工作原理”
google://“为什么一个网站可以有多个IP地址”
google://“当我在浏览器中输入网站地址并按回车时会发生什么”
google://“如何使用 WHOIS”

 

[HostBost]

но атака, похоже, не работает, может быть, я делаю что-то неправильно?

/threads/80972/post-560421

 

[Dread Pirate Roberts]

Есть ли способ атаковать транспортный уровень? Я могу думать только об использовании hping3 для отправки SYN-флуда на цель, но у меня нет ботнета, поэтому цель не будет серьезно затронута.

можно отправлять TCP флуд через бесплатные SOCKS прокси или HTTP флуд через HTTP прокси.

Я попробовал этот инструмент https://github.com/DrizzleRisk/NTPDoser. Принцип заключается в том, что атакующая машина обманывает сервер синхронизации времени (NTP), и сервер синхронизации времени возвращает большой объем данных на целевой сервер, вызывая целевая система выйдет из строя. Я попробовал это, нашел доменные имена NTP-серверов и использовал их здесь https://support.ntp.org/Servers/NTPPoolServers, но атака, похоже, не работает, может быть, я делаю что-то неправильно? Либо цель не открыла порт 123 udp и не может быть атакована.

не все хостинг провайдеры разрешают подмену IP адреса в UDP пакетах. google:// "как работает UDP spoofing"
чтобы найти подходящего провайдера, нужно арендовать самый дешёвый сервер, можно виртуальный, запустить на нём tcpdump -n 'udp port 12345', и отправлять на этот сервер UDP пакеты с подменённым IP адресом. если денег много - можно арендовать сервера у разных провайдеров, если денег мало - можно покупать веб-шеллы с возможностью выполнения команд и отправлять UDP пакеты с этих веб-шеллов.

 

[Мутабор]

Я могу думать только об использовании hping3 для отправки SYN-флуда на цель

hping (hping3) - это не рабочее дерьмо. Забудь и не трать на этот кал время.

у меня нет ботнета

4 года назад юзал вот это. И оно работало, чьёрт пабьери. Проблема с ботами была только, точнее с их количеством. Ебашило даже через StormWall. Потом я забил на это, а сейчас смотрю, проект развивается, добавили новые методы. Советую попробовать, но сначала изучи полностью инструкцию не спеша. Напиши сюда сколько ботов находит.

Что лучше: использовать медленную атаку или усиленную атаку?

Slow атака не на все сервера действует, а только на уязвимые к данной атаке. Можно проверить перед запуском на уязвимость скриптом и nmap´ом. Не помню команду наизусть, но на ютубе было видео на английском, можешь поискать.

но атака, похоже, не работает, может быть, я делаю что-то неправильно?

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

Короче забей член на эту головную боль и лучше займись рансомом )))

 

[Lupin]

Короче забей член на эту головную боль и лучше займись рансомом )))

То чувство когда ддос нужен для рансома P.S не мне конечно)

 

[TROUBLE]

Инструменты с гита, это разве что для общего развития. Смотри в сторону load testing - немного дополнив функционал основных инструментов в этой области, можно получить практически универсальный комбайн для ддоса.

 

[weaver]

Книги и видео.... Нет таких.

Но где черпать информацию ? Самый простой и эффективный способ это смотреть исходники ботнетов. На ум приходит Mirai, посмотри исходники, посмотри как реализованы функции которые вызывают флуд итд

Изучай программирование сырых сокетов под Linux, читай RFC пробуй тестируй.

имхо

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

Например какой нибудь RCE сплойт для http.sys, кривой запрос да и просто PoC может уже BSoD вызывать.
Даже если сервис стартует заново никто не мешает бесконечно отправлять запросы которые крешат сервис\демон. А от кривого rce эксплойта уже анти-ддос не спасет, тут только обновлять ПО. Так, как ты отпраляешь сервер в накаут одним запросом, в сети есть куча кривых rce эксплойтов. Кривые они по той причине, что либо их недоделали, либо невозможно добиться RCE на практике (только в теории), в силу современных защит.

 

[Artnilooog1992]

Классификация DDoS-атак на основе нейросетевой модели
самая актуальная наверное​

 

[c0d3x]

Классификация DDoS-атак на основе нейросетевой модели

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

1. Массовость, чем больше атакующих IP тем лучше. В идеале это десятки и сотни тысяч, которые при этом обновляются постоянно, и заменяют отвалившиеся прокси/ботов.
2. Низкий рейт. Например, когда с каждого атакующего IP идет 1 запрос с интервалом 3~10 секунд.
3. Не долбить в один линк. Парсить сайт и ходить по нему, каждый новый запрос с каждого IP должен быть на новую страницу, которую бот не посещал при предыдущих 15~20 запросах.
4. Полная эмуляция браузера с возможностью детектировать различные JS челленджи и обходить капчу.
5. Боты должны заходить на сайт постепенно, а не сразу всем количеством. Чем больше ботов, тем на бóльший срок надо растягивать их заход на сайт, дабы не триггерить антидудосилку.
6. В идеале найти какой-то уязвимый эндпоинт, который дико тормозит (нагружает) атакуемый сервер при обращении к нему с какими-либо специфичными параметрами/пейлоадом и во время основной атаки поддавать на него слегка, несколько раз в 1~3 минуты. Мой личный рекорд 4 суток, меня не могли отфильтровать при атаке на сайт находящийся на проксировании у ddos-guard.net. Возможно получилось бы и больше, но заказчик зажопил бабки на продолжение банкета. Рекорд поставлен в октябре этого года.

 

[gliderexpert]

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

Т.е. полностью эмулировать создание TLS-сессии? Насколько я знаю простой флуд SYN-пакетами сейчас довольно успешно фильтруют при помощи eBPF и специальных "умных" сетевых карт.

 

[Мальчиш-Плохиш]

1. Массовость, чем больше атакующих IP тем лучше. В идеале это десятки и сотни тысяч, которые при этом обновляются постоянно, и заменяют отвалившиеся прокси/ботов.
2. Низкий рейт. Например, когда с каждого атакующего IP идет 1 запрос с интервалом 3~10 секунд.
3. Не долбить в один линк. Парсить сайт и ходить по нему, каждый новый запрос с каждого IP должен быть на новую страницу, которую бот не посещал при предыдущих 15~20 запросах.
4. Полная эмуляция браузера с возможностью детектировать различные JS челленджи и обходить капчу.
5. Боты должны заходить на сайт постепенно, а не сразу всем количеством. Чем больше ботов, тем на бóльший срок надо растягивать их заход на сайт, дабы не триггерить антидудосилку.
6. В идеале найти какой-то уязвимый эндпоинт, который дико тормозит (нагружает) атакуемый сервер при обращении к нему с какими-либо специфичными параметрами/пейлоадом и во время основной атаки поддавать на него слегка, несколько раз в 1~3 минуты

Теория хороша, безусловно. Но как это осуществить своими силами на практике обычным юзверям?

 

[c0d3x]

Т.е. полностью эмулировать создание TLS-сессии? Насколько я знаю простой флуд SYN-пакетами сейчас довольно успешно фильтруют при помощи eBPF и специальных "умных" сетевых карт.

Подразумевается эмуляция хромиума (пупитер, селениум). SYN/UDP (L4) флуд это отдельная история, гораздо более геморройная чем L7.

Теория хороша, безусловно. Но как это осуществить своими силами на практике обычным юзверям?

Учиться кодить, либо заказывать софт за $, либо покупать готовые решения. Со вторым и третьим вариантом сейчас крайне печальная ситуация на рынке.

 

[c0d3x]

DDoS в коммерческом его варианте умирает постепенно. Смотрите как это работает на практике, когда ты предоставляешь такие услуги.

1. Тебе поступает заказ на сайт который хостится у обычного хостера, без какой-либо защиты. Ты запускаешь атаку, условно говоря за $150 на сутки, такие деньги заказчик готов платить.

2. Через час после начала атаки сайт подключает CloudFlare, включает JS челлендж, капчу, в большинстве случаев и гео-фильтр включают, например блокируют весь мир кроме одной страны. Стоимость атаки для заказчика увеличивается уже через час, например до $300/сутки, а если гео-фильтр включили то вообще до $1000/сутки условно говоря (обычно намного дороже выходит, потому что тебе надо закупать инсталлы/прокси под определенную страну, в ебейших количествах). $300/сутки заказчик еще скрипя зубами готов заплатить, но при $1000 заказчик отвалится (в большинстве случаев), и попросит манибэк уже в первые часы атаки. Иногда можно и гео-фильтр обходить за $300/сутки, в том случае если ты можешь найти бэкенд и уебать туда напрямую. Но в половине случаев на той стороне не дураки, и быстро меняют бэкенд и вместе с этим прячут его.

3. Допустим на $300 заказчик согласился, и вы работаете дальше. На атакуемой стороне видят, что CloudFlare нихуя не помогает, и тупо идут в гугл "подключить защиту от ддос" - а там на первых строчках обычно ddos-guard.net, stormwall.pro, variti.io, qrator.net и прочие "радости жизни". И в течение еще одного часа сайт оказывается под защитой такого сервиса. Если клиент на долгий срок (от нескольких месяцев) подключает проксирование (не полный перенос сайта на их сервера, а именно проксирование) то ему еще и человека выделяют, который грамотно закроет и спрячет бэкенд. И тут все, пиздец, цена для заказчика $5000~10000. У заказчика после таких цифр в 99% случаев падает челюсть на пол, и он говорит "нахой ваш дудос".

В среднем, путь от первого пункта до третьего занимает 3-4 часа. Дальше считаем: $300 за сутки (24 часа) заплатили, пролежал сайт 4 часа, значит вернуть ты должен за 20 часов. 300/24 = $12.5 в час стоимость атаки. $12.5 * 4 = $50 твоя прибыль. Ну и нахуй так жить? У тебя на прокси/инсталлы в несколько раз больше уйдет. Рентабельности - 0.

Кто-то скажет что это не так? Еще как так. Заказчиков с безлимитным бюджетом 1 к 50. Типичный заказчик ддоса это человек который готов максимум $100/сутки платить, и который ахуевает когда ты в процессе повышаешь ему цену до $150. Заказчики которые готовы платить бабки вагонами, это как правило политика, около-политика, казино, фарма, порно. Но таких заказчиков на рынке очень мало, потому что сферы влияния в большинстве своем поделены давно, и каждый себе по куску отрезает, и такие заказчики появляются только когда какой-то залетный влетает с двух ног в их нишу, и его надо убирать в зародыше.

Да что тут говорить, посмотрите на рансом, мне в личку здесь неоднократно писали с просьбами работать на постоянке, ебашить их таргеты (давление таким образом оказывать, чтобы на контакт быстрее выходили и быстрее платили). Скидывают список сайтов, а там дикий пиздец: один сайт на CloudFront висит, с балансировкой трафика на 20 серверов, другой сайт на CloudFlare Enterprise за $5000/месяц с гарантией SLA 2500%. Цена космическая получается, называю им цену - отказываются от атаки на такие защищенные сайты. Дают список попроще, где в основном CloudFlare за $200/месяц и Amazon с балансировкой на 2~4 сервера. Называю цену $300~500/сутки за каждый. Ответ всегда один - "бля, дорого че то, не расчитывали на такое. давай за %?". И зачем мне это надо? А если не заплатят, мне кто мои расходы компенсирует? Ни кто, в минус вся работа. Кароче ебалá это все полнейшая стала.

Работать спокойно, с хорошим доходом можно только имея базу жирных клиентов, из политики, казиков, фармы, порнухи, которым вообще похуй что сколько стоит, им главное результат и чтобы на тебя можно было положиться, чтобы ты не пропал с деньгами и манибэкал в случае неуспеха. Либо со своей командой которая отрабатывает сетки, в которой ты уверен на все 100% что тебя не наебут, которая гарантированно выплатит тебе %, или готова оплачивать твою работу частично + %.

зачем я это все написал - не знаю, может кому нибудь интересно будет.

 

[paulmuller]

c0d3x

Можете обьяснить, как задидосить сайт с CloudFlare? И почему цена именно такая, как вы укaзали.
Если это ваш ноу-хaу, то буду рад хотя бы концептуальному разьяснению. Конечно, чем более детально, тем интереснее. Например, указание тулсов + цены серваков для реквестов + тд.

Заранее спасибо.

 

[c0d3x]

Можете обьяснить, как задидосить сайт с CloudFlare?

1. Массовость, чем больше атакующих IP тем лучше. В идеале это десятки и сотни тысяч, которые при этом обновляются постоянно, и заменяют отвалившиеся прокси/ботов.
2. Низкий рейт. Например, когда с каждого атакующего IP идет 1 запрос с интервалом 3~10 секунд.
3. Не долбить в один линк. Парсить сайт и ходить по нему, каждый новый запрос с каждого IP должен быть на новую страницу, которую бот не посещал при предыдущих 15~20 запросах.
4. Полная эмуляция браузера с возможностью детектировать различные JS челленджи и обходить капчу.
5. Боты должны заходить на сайт постепенно, а не сразу всем количеством. Чем больше ботов, тем на бóльший срок надо растягивать их заход на сайт, дабы не триггерить антидудосилку.
6. В идеале найти какой-то уязвимый эндпоинт, который дико тормозит (нагружает) атакуемый сервер при обращении к нему с какими-либо специфичными параметрами/пейлоадом и во время основной атаки поддавать на него слегка, несколько раз в 1~3 минуты.

Учиться кодить, либо заказывать софт за $, либо покупать готовые решения. Со вторым и третьим вариантом сейчас крайне печальная ситуация на рынке.

Еще можно искать IP бэкенда и бить в него напрямую. Один из методов описывал здесь: https://xss.pro/threads/82843/post-583305 и вот еще неплохая статья: https://infosecwriteups.com/finding-the-origin-ip-behind-cdns-37cd18d5275
Можно стрессеры покупать, только обязательно чекать отзывы и просить тестовые атаки перед покупкой. В хороших стрессерах всегда используются актуальные методы обхода JS челленджей CloudFlare и капчи.

И почему цена именно такая, как вы укaзали.

Цена у всех разная всегда, и складывается она обычно исходя из этого:

1. Суточная стоимость твоих расходников используемых для атаки: сервера, прокси/инсталлы, софт (собственно сам бот), обход капчи через API сервисов по расшифровке (это же платная фича).
2. Статус самого атакуемого сайта. Если это какой-то говно-блог условного дяди Вани с посещаемостью три калеки в сутки, у которого бэкенд это слабенький шаред хостинг падающий с пол тычка, то цена будет одна, не шибко высокая, так как за сутки атаки будет затрачено небольшое количество расходников. Если же это к примеру какое-то крупное СМИ с посещаемостью в десятки и сотни тысяч пользователей в сутки, у которого весь входящий трафик балансится на несколько серверов, у каждого из которых по 256 гб рамы и 128 ядер цпу, то в таком случае цена разумеется будет очень высокой, это может быть и десятки тысяч $.
3. Так называемая сетевая разведка с пентестом. Многие дудосеры ничего подобного не делают, но по хорошему - перед атакой крупного и защищенного ресурса это необходимо делать, поскольку это и тебе облегчит выполнение самой атаки (ведь можно обнаружить, как я ранее писал, какой-либо уязвимый эндпоинт который очень сильно нагружает сервер) и возможно снизит твои расходы на атаку, поскольку ты меньше затратишь на те же сервисы по расшифровке капч, на используемые прокси/инсталлы.

Так называемая сетевая разведка включает в себя:

1. Поиск бэкенда. Ищем через шодан/ценсис и аналогичные сервисы. Не только просто вставив имя домена и нажав кнопку, а можно искать по специфичным хидерам, по хэшу фавикона и так далее, эти методы описаны в статье, ссылку на которую я дал выше. Если успешно нашли - сохраняйте полную информацию по каждому порту и баннеру, со всеми фингерпринтами, потому что бэкенд могут сменить во время атаки и придется его искать заново, сканить все подсети хостера у которого первоначально был обнаружен бэкенд (или подсети другого предполагаемого хостера, куда могли перенести бэкенд) через masscan или httpx и сравнивать с тем что вы сохранили.
2. Поиск бэкенда через сервисы типа dnsdumpster. Возможно у домена есть сабдомены или какие-то MX записи которые резолвятся на IP адреса того же хостера на котором хостится основной домен. Допустим, видишь что есть сабдомен mail.site.com который резолвится на 55.55.55.55, пробуешь отправлять на этот адрес GET запрос с хост-хидером твоего таргета - не открывается или там реально только почта? Тогда берешь все подсети этого хостера и сканишь их через httpx (ссылку на свой пост с этим методом оставил выше). Еще банальный метод проверки, тот бэкенд или не тот - уебать на него L4 (TCP/UDP) на 80/443 порты, и посмотреть лег ли сайт или нет. Палевный вариант, но рабочий. Еще момент, dnsdumpster не всегда находит все существующие поддомены, поэтому иногда стоит и самому просканить любым сканнером сабдоменов, с каким нибудь большим словариком.
3. Ковыряние сайта на наличие каких-либо уязвимостей которые могут помочь при атаке и увеличить downtime. Во первых это может быть SSRF, через который ты быстро без всякого дрочева со сканнерами всегда сможешь узнать новый IP бэкенда в случае его замены. Во вторых, как я уже в сотый раз писал - это эндпоинты сильно нагружающие сервер, или СУБД через SLEEP / BENCHMARK / GET_LOCK запросы например. Это трудоемкий процесс, на который тратится много времени, в том случае если ты ковыряешь руками, который бывает занимает и несколько суток. Можно конечно воспользоваться сканнерами, такими как Acunetix/Netsparker/Burp и прочие, но во первых они могут ничего не найти по итогу, тупо пропустить - не задетектить, а по факту уязвимости там есть, и если ты немного скилловый поцык то сможешь и ручками что-то да наковырять. Во вторых, сканнеры это всегда ебейшее палево, ты засираешь все логи, сканнер генерирует десятки тысяч запросов. В CloudFlare твой сканнер сразу увидят, всплеск трафика на графике, и скорее всего тебя отфильтрует сам CloudFlare, забанит или какой-нибудь BotFight мод включит тебе JS челлендж с капчей, который твой сканнер пройти не сможет. Либо (часто бывает) у многих включен WAF от CloudFlare, поэтому твой сканнер ничего не задетектит. Поэтому, что руками, что сканнером - лучше работать напрямую через бэкенд. Когда бэкенд найден и обнаружена какая-либо уязвимость тормозящая сервер, то можно прибегать к хитрости: основной поток атаки идет прямо в морду, через CloudFlare, и всего несколько раз в минуту несколькими запросами поддавать на уязвимый эндпоинт прямиком на бэкенд.

Если это ваш ноу-хaу

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