• XSS.stack #1 – первый литературный журнал от юзеров форума

DDoS TORа и бан дескриптора на нодах

Отслеживать
gliderexpert

gliderexpert

CPU register
Забанен
Регистрация
17.02.2021
Сообщения
1 440
Решения
1
Реакции
2 336
Пожалуйста, обратите внимание, что пользователь заблокирован
Всем привет!
История следующая. Запустили файлообменник для форума.
Пришел c0d3x , включил свой stresse.io и все положил ))
Лег nginx с php, лег демон тора, в общем "сайт не найден", все в лучших традициях.
Само не восстановилось, пришлось принудительно перезагружать VM на которых работал тор-прокси и сам LEMP.

Потом я изменил конфиг - подробное описание тут - https://xss.pro/threads/105520/page-2#post-738337
Пришел c0d3x и снова все положил )
Логи - тут https://xss.pro/threads/105520/page-3#post-738375
На этот раз - connection timeout.
В кратце - со стороны бекенда все ок, канал загружен на смешные 40...50мбит/с, сервера ну может процентов на 10% по CPU. Но через тор соединение не устанавливается.

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

После гадания на кактусах, кошачьих хвостах, кофейной гуще и пузырьковой камере Вильсона (с) - появилась мысль что дескриптор именно этого ключа, на который был направлен ддос -забанен где-то внутри самих нод тора.
Дальше я сгенерировал новую пару закрытый ключ-публичный ключ, перезапустил тор демон и попробовал зайти на новый адрес - сразу открылся.
Возвращаю старый закрытый ключ - опять timeout. Т.е. проблема не на моем сервере, а что-то происходит в момент ддоса и после него в самой сети тора.
А значит - решение использовать onionbalance и PoW - простое, очевидное, и неправильное. И EndGame капча соответственно тоже работать не будет, т.к. дохнет что-то внутри цепочки нод тора, а не на самом хостинге где находится ресурс.

Примерно через час все восстановилось само, сайт стал доступен по старому адресу.

Внимание вопрос - кто сталкивался с подобным, в какую сторону копать? Поднимать свои ноды?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Продолжаем смотреть логи. Приблизительно до 1000 запросов в минуту все живет нормально.
balancer2.png


Распределение посетителей по нодам балансёра более-менее равномерное. Последняя цифра IP адреса - это номер ноды.

balancer1.png


Забавно что нагрузка по трафику не так хорошо балансируется - например на 8 ноде траф минимален, но при этом обращений к ней достаточно много.
balancer3.png


После превышения порога в 1300 успешных запросов (а сколько там было на входе - я не знаю) - 3 ноды балансировщика перестали работать, видимо ip улетел в бан. Из списка исчезла 1, 2, 5 ноды. Никакой взаимосвязи с их нагруженностью не наблюдается - судя по предыдущим графиком, они где-то в середине были по кол-ву запросов.

balancer4.png


Кол-во запросов упало с 80к в час до 35к в час, т.е. получается в момент отказа эти ноды держали 80-35=45к обращений в час, по 15 тыс обращений на каждую. В минуту - 250 запросов.
balancer5.png



Получаем примерно что одна нода балансера держит скорость запросов до 250 посетителей в минуту, после чего дескриптор улетает в бан.
Это хорошо согласуется с общей картиной - 250(запросов в мин)*8 (нод) = 2000, где-то около того и была скорость ддоса в момент когда ресурс полностью лег.

После отваливания нод произошло довольно серьезное перераспределение нагрузки по трафику - основную нагрузку взяла на себя 6 нода.
balancer6.png
 
Последнее редактирование:
gliderexpert сказал(а):
DDOS-защита + её тестирование при помощи https://stresse.io/
ты л4 или л7 тестировал ? может кто нибудь объяснить как л7 настраивать ? с л4 все понятно +\- ,а вот с л7 ничего не понятно. запускаю стрессер, но сайт не падает, на л4 падает. подписка кастомная с 2 потоками.
PS: c0d3x твой промокод уже не работает,дня 4 назад воркал еще.
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Desconocido сказал(а):
оффтоп, ты л4 или л7 тестировал ? может кто нибудь объяснить как л7 настраивать ? с л4 все понятно +\- ,а вот с л7 ничего не понятно. запускаю стрессер, но сайт не падает, на л4 падает. подписка кастомная с 2 потоками.
PS: c0d3x твой промокод уже не работает,дня 4 назад воркал еще.

Настраивал c0d3x , я не знаю. Судя по логам, похоже что по l7 была атака.

Код: 
10.152.152.14 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 12; SAMSUNG SM-N435F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.$
10.152.152.13 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 12.0; Pixel 2 Build/OPD3.170816.012) AppleWebKit/537.36 (KHTML, like Gec$
10.152.152.13 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 11.0.89; S109 Build/LMY13I; wv) AppleWebKit/537.36 (KHTML, like Gecko) C$
10.152.152.13 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 11.0.89; S109 Build/LMY13I; wv) AppleWebKit/537.36 (KHTML, like Gecko) C$
10.152.152.14 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 12; SAMSUNG SM-N435F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.$
10.152.152.10 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 12; SAMSUNG SM-A912B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0$
10.152.152.13 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 11.0.89; S109 Build/LMY13I; wv) AppleWebKit/537.36 (KHTML, like Gecko) C$
10.152.152.18 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPad; U; CPU OS 4_1_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.$
10.152.152.10 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 12; SAMSUNG SM-A912B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0$
10.152.152.10 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 12; SAMSUNG SM-A912B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0$
10.152.152.18 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPad; U; CPU OS 4_1_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.$
10.152.152.18 - - [16/Jan/2024:13:44:26 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (Linux; Android 11; SAMSUNG SM-N135F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0$
10.152.152.18 - - [16/Jan/2024:13:44:27 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPad; U; CPU OS 4_1_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.$
10.152.152.18 - - [16/Jan/2024:13:44:27 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPad; U; CPU OS 4_1_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.$
10.152.152.10 - - [16/Jan/2024:13:44:27 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Ch$
10.152.152.18 - - [16/Jan/2024:13:44:27 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPad; U; CPU OS 4_1_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.$
10.152.152.10 - - [16/Jan/2024:13:44:27 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Ch$
10.152.152.18 - - [16/Jan/2024:13:44:27 +0300] "GET / HTTP/1.1" 200 2674 "-" "Mozilla/5.0 (iPad; U; CPU OS 4_1_1 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.$
 
gliderexpert а нет логов запросов из тора в твои ноды? Может быть можно ограничить количество запросов обслуживаемых одной тор-нодой в минуту? Тогда, в случае атаки, сервис останется частично рабочий и блокировка, возможно, не произойдет?

Посмотри еще это и это
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Ar3s сказал(а):
gliderexpert а нет логов запросов из тора в твои ноды? Может быть можно ограничить количество запросов обслуживаемых одной тор-нодой в минуту? Тогда, в случае атаки, сервис останется частично рабочий и блокировка, возможно, не произойдет?

Проблема в том что блокировка происходит где-то внутри guard relay , это самая ближайшая к "посетителю" точка - а к ней у меня доступа естественно нет, т.к. таков механизм тора. Вот этот Guard Relay при определенной мощности ддоса + комбинации настроек Hidden Service блокирует дескриптор моего HS и не дает сформироваться цепочке + создать rendezvou point.
А дальше начинает действовать таймаут на обновления хеша дескриптора в HS, но вроде бы есть возможность это обойти, 60*60сек тупо захардкодили в исходники тора .
В общем потихоньку занимаюсь исследованиями.

1 шаг - "маломощный" L-7 стрессер для тестов. Количество запросов подобрал так, чтобы xss... .onion ложился )) Оказалось что для этого нужно не очень много ресурсов. admin, сорри за ночные испытания - все ради науки! )) Все последующие испытания DamageLiB'а проводились именно на этой скорости запросов, в течении одного и того же интервала времени.

Дальше проверяю как работает PoW. Для этого выключил онионбаланс, оставил 1 ноду с TORом.
Настройки PoW - ВКЛЮЧЕН,
#HiddenServicePoWQueueRate 150
#HiddenServicePoWQueueBurst 1500
Включаю стрессер.
Изменяю на
#HiddenServicePoWQueueRate 15
#HiddenServicePoWQueueBurst 150
Включаю.
Изменяю на
#HiddenServicePoWQueueRate 450
#HiddenServicePoWQueueBurst 4500
Загрузка сервера - на скриншотах ниже (пики слева направо - pow 150, 15, 450)

cpu and mem.png
diskio.png


На значениях 450/4500 произошло интересное - сайт перестал открываться, лег по "таймаутам" - "время ожидания истекло". После завершения атаки - восстановился спустя 15 минут. Попадание дескриптора в бан - это не дело. Поэтому следующий тест - с полностью выключенным PoW.
Смотрим на 4 (самый правый) пик
without pow.png
without pow-disk io.png


Параллельно пишу лог запросов с NGINX'а.
Больше запросов - лучше работа тор-прокси.
150/1500 - получено 21250 запросов, 51 Мб данных.
15/1500 - 24727 запросов, 59Мб данных
450/4500 - 23896 запросов, 57Мб данных
PoW выключен - 28043 запросов, 67Мб данных

Как видно, для PoW отсутствует линейная зависимость между значениями коэффициентов, и фактической нагрузкой на сервер. Очевидно одно, что при повышении числа - увеличивается время открытия страницы, и при значениях порядка 450/4500 соединение начинает рваться по таймаутам и дескриптор попадает в бан на guard-relays.


Следующий этап - снес с основного сервера тор, перешел на онионбаланс. PoW включен, коэффициент 150/1500.
balancerwithpow.png


Пролезло 28600 запросов и 68мб трафа.

Выключаем PoW, ждем пока разбанят дескриптор. Повторяем атаку.
53 000 запросов и 129 мб трафа. При этом загрузка cpu на LEMP-сервере достигла 55 процентов.
onionb_without_pow.png
balance_without_pow_disk.png

При этом дескриптор тором забанен не был.

Похоже что правильное решение - это Onionbalance с выключенным PoW, но фронтенд его должен работать на быстром канале и отдавать дудосеру какой-нибудь очень "легкий" ответ, чтобы не загружать основной сервер по трафику и запросам. Т.к. фронтенд онионбаланса однопоточный - имеет смысл его хостить на проце с тактовой частотой 5...6Ггц ну или сделать тор-фронтенд на FPGA :)

Максимальную нагрузку кстати создает php-fpm и mysql
phpfpm.png

Это было ожидаемо. На "welcome-page" который отдает фронтенд онионбаланса, mysql запросов должно быть минимальное количество, это все понятно и будет сделано.

Но вот неожиданным стал тот факт, что в стандартном LEMP имеет место быть memleak - постоянное, неконтролируемое увеличение объема занятой ОЗУ
memleak.png

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

На сегодня экспериментов - пожалуй достаточно, продолжу завтра )
Главное что я получил технологию как загнать со 100% вероятностью tor дескриптор Hidden сервиса в бан на guard-ноде, ну а дальше уже можно экспериментировать с методиками обновления хеша дескриптора в DHT и т.п. методиками его разблокировки.
 
Последнее редактирование:
gliderexpert сказал(а):
Проблема в том что блокировка происходит где-то внутри guard relay , это самая ближайшая к "посетителю" точка - а к ней у меня доступа естественно нет, т.к. таков механизм тора. Вот этот Guard Relay при определенной мощности ддоса + комбинации настроек Hidden Service блокирует дескриптор моего HS и не дает сформироваться цепочке + создать rendezvou point.
А дальше начинает действовать таймаут на обновления хеша дескриптора в HS, но вроде бы есть возможность это обойти, 60*60сек тупо захардкодили в исходники тора .
В общем потихоньку занимаюсь исследованиями.

1 шаг - "маломощный" L-7 стрессер для тестов. Количество запросов подобрал так, чтобы xss... .onion ложился )) Оказалось что для этого нужно не очень много ресурсов. admin, сорри за ночные испытания - все ради науки! )) Все последующие испытания DamageLiB'а проводились именно на этой скорости запросов, в течении одного и того же интервала времени.

Дальше проверяю как работает PoW. Для этого выключил онионбаланс, оставил 1 ноду с TORом.
Настройки PoW - ВКЛЮЧЕН,
#HiddenServicePoWQueueRate 150
#HiddenServicePoWQueueBurst 1500
Включаю стрессер.
Изменяю на
#HiddenServicePoWQueueRate 15
#HiddenServicePoWQueueBurst 150
Включаю.
Изменяю на
#HiddenServicePoWQueueRate 450
#HiddenServicePoWQueueBurst 4500
Загрузка сервера - на скриншотах ниже (пики слева направо - pow 150, 15, 450)

Посмотреть вложение 73948Посмотреть вложение 73949

На значениях 450/4500 произошло интересное - сайт перестал открываться, лег по "таймаутам" - "время ожидания истекло". После завершения атаки - восстановился спустя 15 минут. Попадание дескриптора в бан - это не дело. Поэтому следующий тест - с полностью выключенным PoW.
Смотрим на 4 (самый правый) пик
Посмотреть вложение 73952Посмотреть вложение 73953

Параллельно пишу лог запросов с NGINX'а.
Больше запросов - лучше работа тор-прокси.
150/1500 - получено 21250 запросов, 51 Мб данных.
15/1500 - 24727 запросов, 59Мб данных
450/4500 - 23896 запросов, 57Мб данных
PoW выключен - 28043 запросов, 67Мб данных

Как видно, для PoW отсутствует линейная зависимость между значениями коэффициентов, и фактической нагрузкой на сервер. Очевидно одно, что при повышении числа - увеличивается время открытия страницы, и при значениях порядка 450/4500 соединение начинает рваться по таймаутам и дескриптор попадает в бан на guard-relays.


Следующий этап - снес с основного сервера тор, перешел на онионбаланс. PoW включен, коэффициент 150/1500.
Посмотреть вложение 73956

Пролезло 28600 запросов и 68мб трафа.

Выключаем PoW, ждем пока разбанят дескриптор. Повторяем атаку.
53 000 запросов и 129 мб трафа. При этом загрузка cpu на LEMP-сервере достигла 55 процентов.
Посмотреть вложение 73958Посмотреть вложение 73959
При этом дескриптор тором забанен не был.

Похоже что правильное решение - это Onionbalance с выключенным PoW, но фронтенд его должен работать на быстром канале и отдавать дудосеру какой-нибудь очень "легкий" ответ, чтобы не загружать основной сервер по трафику и запросам. Т.к. фронтенд онионбаланса однопоточный - имеет смысл его хостить на проце с тактовой частотой 5...6Ггц ну или сделать тор-фронтенд на FPGA :)

Максимальную нагрузку кстати создает php-fpm и mysql
Посмотреть вложение 73960
Это было ожидаемо. На "welcome-page" который отдает фронтенд онионбаланса, mysql запросов должно быть минимальное количество, это все понятно и будет сделано.

Но вот неожиданным стал тот факт, что в стандартном LEMP имеет место быть memleak - постоянное, неконтролируемое увеличение объема занятой ОЗУ
Посмотреть вложение 73961
С утечкой памяти придется разбираться, это совершенно отдельная проблема.

На сегодня экспериментов - пожалуй достаточно, продолжу завтра )
Главное что я получил технологию как загнать со 100% вероятностью tor дескриптор Hidden сервиса в бан на guard-ноде, ну а дальше уже можно экспериментировать с методиками обновления хеша дескриптора в DHT и т.п. методиками его разблокировки.
А можно было сделать просто L7 защиту например от меня и работать без тора и не парить голову
 
7teen сказал(а):
А можно было сделать просто L7 защиту например от меня и работать без тора и не парить голову
Клирнет домены под эту задачу/проект (которую ТС реализовывает) не подходят, так как будут отлетать от абуз по 100 раз за неделю.
 
c0d3x сказал(а):
Клирнет домены под эту задачу/проект (которую ТС реализовывает) не подходят, так как будут отлетать от абуз по 100 раз за неделю.
Не уверен, надо проверять
 
Пожалуйста, обратите внимание, что пользователь заблокирован
7teen сказал(а):
А можно было сделать просто L7 защиту например от меня и работать без тора и не парить голову
Вы называете это "парить голову", я называю - самообразование.
Мне интересно разобраться с телеком. технологиями, их особенностями и нюансами использования. Надеюсь, я не одинок в своих суждениях.
А впрочем, пофигу )
 
gliderexpert сказал(а):
Вы называете это "парить голову", я называю - самообразование.
Мне интересно разобраться с телеком. технологиями, их особенностями и нюансами использования. Надеюсь, я не одинок в своих суждениях.
А впрочем, пофигу )
Дело в том что на торе никак ты не запилишь защиту, банально потому что все запросы идут с ограниченного пула адресов.

Вопрос ддоса будет стоять в том сколько ддосер вольет в это сил.
Если у тебя там 10 балансеров, ну значит на балансер три машины с которых будет флудить. Тор тем и плох .что в нем нет инструмента для борьбы с атаками
 
gliderexpert сказал(а):
Вы называете это "парить голову", я называю - самообразование.
Мне интересно разобраться с телеком. технологиями, их особенностями и нюансами использования. Надеюсь, я не одинок в своих суждениях.
А впрочем, пофигу )
У самурая нету цели, есть только путь.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
7teen сказал(а):
Вопрос ддоса будет стоять в том сколько ддосер вольет в это сил.

Как и в клирнете. При определенной мощности ддоса на клирнет домен/ip - Вас пошлёт в блэкхол (/dev/null, попрошу не путать с anus) маршрутизатор датацентра.
Я понимаю, что дальше будут разговоры про flux-dns и прочие round-robin балансировщики - но, позвольте - а чем это в таком случае будет отличаться от тора с его DHT ?


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

Инструментарий есть, документация - слабая. Приходится изучать исходники чтобы понять как работает та или иная функция.
PoW, rate лимиты на guard нодах управляемые с HiddenService, rendguard внутри vanguards, бан цепочек через control-socket тор демона и т.д.
 
gliderexpert сказал(а):
Как и в клирнете. При определенной мощности ддоса на клирнет домен/ip - Вас пошлёт в блэкхол (/dev/null, попрошу не путать с anus) маршрутизатор датацентра.
Да, но кодекс в клирнете не смог меня положить, а в торе может. Вот в чем разница, понимаешь?
 
Пожалуйста, обратите внимание, что пользователь заблокирован
7teen сказал(а):
Да, но кодекс в клирнете не смог меня положить, а в торе может. Вот в чем разница, понимаешь?
Плохо разобрались с TORом, бывает...

Идея онион-роутера на fpga оказалось не нова - уже пытались сделать https://ee533usc.weebly.com/about-netfpga.html
Не понятно, смогли ли довести проект до ума. Вообще это было бы хорошим решением, учитывая однопоточность тор демона.
 
Последнее редактирование:
7teen сказал(а):
но кодекс в клирнете не смог меня положить
Да, но у меня нет например 5 терабит в секунду, от которых загнется любой IP в любой AS (в клирнете), а у некоторых есть. С тобой это обсуждалось, но многие здесь не знают в чем соль. Поясняю:

1. Челик предлагает защиту на базе кастомных JS, под которые нет обходов ни у кого вообще, поскольку это малоизвестный скажем так сервис по защите от дудоса, который ни кто нихуя не знает.
2. По его же заявлению он может менять JS челленджи хоть каждые пол часа, соответственно даже если написать обход для одного челледжа - он выкатит тут же другой, и так по кругу. Такие маневры возможны когда у тебя небольшая база клиентов, а когда у тебя будут тысячи и десятки тысяч клиентов - такие маневры будут нереальны, по многим причинам, одна из которых - хуевая конверсия, из-за чего можно потерять огромное количество клиентов. Поэтому у многих антидудосилок популярных - один челлендж который они обновляют/меняют дай бог раз в год.
3. Если у него будет стабильно 1-3 челленджа которые не меняются и будет высокий спрос на ддос сайтов находящихся у него под защитой - этим челленджам пизда, напишут хуеву тучу методов байпасса, как под CloudFlare, ddos-guard.net и прочие.
4. Сейчас его антидудос держится на двух столпах: первый - он малоизвестен и нет спроса на атаки сайтов которые у него защищаются, второй (прямо коррелирует с первым) - он быстро меняет челленджи, пока ты напишешь обход под один из них - он выкатит еще 5 заготовок. Оба этих столпа будут постепенно разрушены как только у него начнется сильный рост клиентуры.
5. Новый рекорд атаки по L4 - 5 TBPS, и это не амп, это ботнет. По L4 если такая хуевина заглянет к тебе - ничего кроме нуллрута тебя не ждет, где бы ты не хостился, попросту ни одной антидудос конторе нерентабельно тебя защищать за условные $500 в месяц, когда им выливают такой объем трафика который стоит в сотни раз дороже твоего тарифа.

7teen сказал(а):
Дело в том что на торе никак ты не запилишь защиту
Это не так. Весь 23 год были запросы на атаку меги, соляриса, рутора. Деньги большие, до $30k в сутки предлагали например за мегу, за солярис до $1m за месяц даунтайма, разумеется не только мне. Ну и хули? Ни кто их так и не ебнул. Если было бы все так просто то этих всех нарко-площадок не существовало бы, потому что их заебали бы атаками с вымогательствами все кому не лень, поскольку бабки там крутятся такие, что любой рансом курит в сторонке, торчки со всего СНГ ежеденевно миллионы баксов загоняют на эти площадки.
 
Последнее редактирование:
gliderexpert сказал(а):
Вы называете это "парить голову", я называю - самообразование.
Мне интересно разобраться с телеком. технологиями, их особенностями и нюансами использования. Надеюсь, я не одинок в своих суждениях.
А впрочем, пофигу )
Таких как ты я стараюсь брать на работу. Даже если знаний не хватает, но человек сам находит себе занятие и это занятие не просмотр мемов или ютуба, а техническое самообразование - я это называю профессиональным взрослением. Так что я морально и по-мере сил буду помогать тебе в этом топе, думать над каждым вопросом и тратить свое время на поиски в интернете. Потому что считаю правильным и само начинание и поддержку комьюнити таких аматоров.
 
когда блек кэт тор домен угнали показывало то их сайт, то фбр.
может есть вариант запустить на нескольких серверах сайтик с одним P KEY
так сделать распределение нагрузки некое?
 
А может просто ТОР поменять на другую сеть, где DDOS просто невозможен?
Торовский POW , побрякушка для лохов, толку с него ноль, а вот AntiBot Cloud,
запросто справился с легеньким ддосом.
c0d3x сказал(а):
Весь 23 год были запросы на атаку меги, соляриса, рутора. Деньги большие
Ну и к какой защите они пришли? К частой смене доменов?
Мне кажется, в сети I2P, ддосер сольется на этапе построения маршрута, просто он завалит
ближайший узел и дальше роутинг не пойдет. Поправьте меня, если я не прав.
 
Последнее редактирование:
c0d3x сказал(а):
Поэтому у многих антидудосилок популярных - один челлендж который они обновляют/меняют дай бог раз в год.
3. Если у него будет стабильно 1-3 челленджа которые не меняются и будет высокий спрос на ддос сайтов находящихся у него под защитой - этим челленджам пизда, напишут хуеву тучу методов байпасса, как под CloudFlare
ставь лойс если помнишь "s,t,o,p,b,r,e,a,k,i,n,g" и стучи в пм если это написали для тебя
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх