seocore

seocore
Рейтинг
143
Регистрация
25.09.2006
Romka_Kharkov:
Есть теоритическая возможность получить контроль над несколькими зараженными машинами из этого ботнета (домо-провайдер может посодействовать) есть ли в этом смысл?

это для правоохранительных органов смысл должен быть, а так - даже проснифить на уровне провайдера весь трафик зомби машины без согласия владельца нельзя 🍿

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

Mikanoshi:
Железом?) Ибо софтом нельзя отбить грамотный ддос/брут

совершенно верно, когда на айпишник летит пара десятков гигабит UDP флуда, или миллионы спуфленных SYN-пакетов, то тут никакие конфиги не помогут 😂

кстати, устроить подобное "надругательство" над любым сервером могли эти ребята легко, с их многотысячной армией ботов, 50к ботов по 1Мбиту вот вам и "закрытие хостинга" 🍿

Dimanych:
Не знаю как у других, у нас боты отступают постепенно, активных IP в блоке не более 1к на каждом сервере :)

может провайдеры наконец-то проснулись и начали реагировать

Silva:
Возможно этого из-за того, что хосты рубит у меня движок, при 3-х неверных авторизациях ip блокируется на 20 минут…
параметры сервера хуже чум у вас…

да уж, красивое объяснение только оторвано от реальности

что на самом деле:

1) если сайтов на Joomla/WP/DLE на сервере немного, скажем так - до 10-30 штучек, то такому серверу никак не мешает брутфорс, так как брутфорсят плавно и не более Н-ного числа запросов к 1 сайту за промежуток времени

2) если сайтов на сервере тысячи (типично для шаред-хостинга), то по 100 запросов\минуту на каждый уже гарантированно ложит типичный сервер "из коробки"

3) когда правил в iptables уже под 50к, тогда начинает уже подтупливать (т.е. уже видна визуально деградация производительности)

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

zzzit:
Да. Потому решение с кукой работает только для тупых ботов и потому сами использовали раньше такие костыли на nginx, теперь у нас все по взрослому :)

правильно, возможно "повзрослеть" в плане защиты придется всем (недавние UDP атаки на шаред хостинги тоже показатель), так как то, что сейчас происходит это явно начало, никто не мешал атакующим не только перебирать пароли, но еще и проверять сайты на уязвимости

Mikanoshi:
seocore, ну если 404 отдавать вордпрессом, завернув в шаблон сайта, то конечно)

так это и будет у тех, кто просто переименует страничку-скрипт авторизации

zzzit:
Там еще ньюансы были, например - как узнать, бот это или нет, если это его первый запрос, т.е. куки еще нет?

а есть боты, которые и куки ставят и JavaScript выполняют :)

Mikanoshi:
И на сколько там будет нагружать ответ 200 размером в пару сотен байт от нгинкса? 100 в минуту, 2 ответа в секунду разве не может нгинкс обслуживать? Да хоть 10.

ваш вариант с 200-кой в одну строку вообще не будет никак нагружать, даже если будет 2-3к подключений одновременно, а вот 404/403 на уровне Apache/.htaccess при 2-3к с большой долей вероятности положит дедик

zzzit:
Кто еще из хостеров не справился с атакой? Давайте помогу настроить nginx перед апачем, мы так пользовались раньше, всех тупых ботов отбивает незаметно и безвредно для посетителей. Потом выложим для всех готовый конфиг.

выше уже приводили решения

WapGraf:
seocore, поставьте спереди freebsd, легко переварит много тысяч айпишек.

или аппаратный фильтр, только не всем подходят такие решения 🍿

admin1s:
Вроде уже на DLE пошла атака

изначально шла на DLE/Joomla/WP, если в начале перебирали какие-то примитивные пароли по словарю (типичные школо-пароли), то сейчас ситуация уже иная - пароли идут уже весьма логичные (подозреваю, что у них есть база "краденых" паролей из каких-то взломанных сервисов и т.п.)

блокировать на уровне Apache бесполезно в случае, если у вас шаред хостинг и тысячи сайтов, так как число запросов "эпическое", при .htaccess блокировке нагрузка уже выходит за "рабочие" пределы, а блокировать полсотни тысяч ботов на уровне iptables приводит к своим проблемам (нагрузка на проц растет), причем ботнет - это обычные люди (а не прокси, как тут пишут некоторые), и забанив такое число ip адресов вы просто срежете реальных посетителей (которые не в курсе, что они "зомбированы")

те же, кто советует повесить "каптчу" на wp-login.php видимо не в курсе, что генерация картинки посредством ПХП это весьма трудоемкий процесс для сервера 🤪

вот тут приводил решение - /ru/forum/comment/12019919, протестировано на масс-хостинге (в разы экономнее по ресурсам, чем блокировка через .htaccess)

Mikanoshi:
Может это мне повезло, но после способа с куками у меня 0 неверных логинов в админке от ботов за сутки, все блокируются нгинксом, LA выше 1 не поднимается.

приведенное в теме решение с куками оказалось наиболее эффективным в данной ситуации, нагрузки практически нет, ложных срабатываний тоже

для тех, кто на ISPManager простое решение - добавляете в /usr/local/ispmgr/etc/nginx.inc блок:


location ~* /(wp-login\.php|administrator|admin\.php) {
set $humantest 0;
if ($http_cookie !~* "humans=checktest") {
set $humantest 1;
}
if ($args ~* (callback|logout|lostpassword)) {
set $humantest 0;
}
if ($humantest = 1) {
add_header Content-Type text/html;
return 200 "<html><body><script>document.cookie='humans=checktest;path=/';location.reload();</script></body></html>";
}
error_page 404 = @fallback;
}

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

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

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

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

разве кто-то плачет? - все довольно лояльно относятся к продукту, за эти деньги вполне удобный и хороший продукт, альтернатив мало, а ошибки - так многие сисадмины уже смирились с этим, для них это квест, вот они понимают, что поставят cPanel или DA и до ближайшей критической массовой уязвимости никаких переживаний у них нет, а с ISPManager постоянный драйвовый квест, когда все может поломаться в самом неожиданном месте, например из свежего:

  • криво перепишет xcache.ini при редактировании параметров из панельки
  • криво произведется импорт пользователя с другого сервера чем покрашит конфиг
  • повиснет намертво при установке панельки
  • в Debian 7 насильно будет ломать mod_rpaf конфиг и не там искать xcache.ini, пока не ткнешь туда симлинк

и каждый день что-то новое и интересное, без ISPManager все было бы нудно и неинтересно, знакомый много лет сидел на cPanel, так он приходит в ужас от того, что оказывается надо еще и ковыряться в конфигах ПО 😂

Всего: 1078