DDOS-атака на форум
Создана: 14 Ноября 2011 Пон 7:45:07.
Раздел: "Не актуальное"
Сообщений в теме: 263, просмотров: 53133
-
-
Shtormovoy55 писал : как это не брать? Надо же поглумиться над кем-нибудь для отвода души.
Мы не варвары, мы просто форумчане! Мы не будем уподобляться негодяям и проявлять низменные качества. Мы должны быть чистыми перед совестью. У меня, по-крайней мере, совесть никуда не исчезла -
-
-
Привет
Я тут новичок конечно, пообщаться пришел, а тут беда.
Если надо референсы на себя дам,over internet, т.е. я не виртуал. (google: Denys Fedoryshchenko nuclearcat )
По поводу ддоса, вижу у вас стоит сквида, но помоему это не самый эффективный метод борьбы.
Я делал так:
1)парсинг логов, ботов обычно легко вычислить по паттернам.
2)установка cookies в nginx фиксированных по IP (хеш), и пропускаем на php (в случае nginx это fastcgi, может быть просто прокси режим на апач) только в случае если кука присутствует. Тупые боты не умеют толком куки.
3)По определенным критериям блочим атакующие IP (geoip + п.1). Если ядро на сервере свежее - ipset, если старое через uRPF фичу линукса (могу в личку рассказать как).
Атаки легко решаются если
1)боты из стран не соответствующих основной аудитории (у вас я так понимаю РФ, а боты к примеру с разных азиатских стран)
2)боты тупые
Надеюсь мои советы не будут восприняты в штыки
Могу налабать пару прог если очень надо -
nuclearcat писал :1)парсинг логов, ботов обычно легко вычислить по паттернам.
Привет.
Примерно так и делаю, плюс ещё некоторый анализ поведения.
nuclearcat писал :2)установка cookies в nginx фиксированных по IP (хеш)
тут два минуса: во-первых, это поможет только от совсем уж тупых ботов, уметь кукисы не великая задача. во-вторых, таким образом мы будем впускать нового клиента на сервер только со второго запроса.
Думаю,тут надо слегка по-другому подходить: и cookie присваивать, и на сервер сразу пропускать, но в случае отсутствия cookie при следующих запросах это уже можно рассматривать как дополнительный признак подозрительного поведения.
nuclearcat писал :3)По определенным критериям блочим атакующие IP (geoip + п.1).
Сейчас много ботов идет с IP казахстана, украины, белоруссии, сша (помимо индии, пакистана, таиланда и прочего). Конечно зарубежность - это доп. основание для подозрений, поскольку более 90% посетителей тут РФ.
Но вообще я бы хотел сделать не разовое решение для конкретной атаки, а более-менее тиражируемую схему отражения подобного рода атак. Так что предложения конечно же приветствуются! -
Боюсь универсальных решений нет, всегда есть какое-то равновесие между эффективностью,удобством для пользователей и доп. расходами.
Если у вас траффик дешевый, то проще поставить еще один сервак и на нем обрабатывать. При наличии времени вообще можно написать хитрый tcp forwarder с epoll(), который будет отшибать ботов.
Ибо nginx/apache/squid слишком тяжеловаты для таких задач. -
Я парсил с помощью скрипта на php, к сожалению не сохранил, кажется юзал Pear geoip, т.е. сделал подобие tail -f на лог файл nginx.
К сожалению пакистаны и прочие азиатские страны (бразилия и т.п.) вообще пришлось сразу загнать в блокировку сразу всей подсетью при малейших подозрениях на атаки, иногда и /16 (подсеть выколупывал из geoip).
Если есть отдельный сервак - можно на нем выдавать ссылочку с капчей для заблокированных (тупо на tcp коннект выплевываем контент с ссылкой на разблокировку, но не более чем N раз в минуту), и если захотят - разблокируются по конкретному IP. -
nuclearcat писал : Я парсил с помощью скрипта на php, к сожалению не сохранил, кажется юзал Pear geoip, т.е. сделал подобие tail -f на лог файл nginx.
Да , по-моему это очень эффективный метод.
У меня вот такой цикл крутится:
Код: while(1) {
$handle = popen("tail -F $logfile 2>&1", 'r');
while(!feof($handle))
analyze(fgets($handle));
pclose($handle);
}
очень надёжное решение, само возобновляется при стирании или ротации логов, не приходится ничего дополнительно пинать. -
nuclearcat писал:пришлось сразу загнать в блокировку всей подсетью
а на базе чего реализован механизм блокировки?
я пытался использовать iptables, но столкнулся с некоторыми ограничениями.
есть способ такой:
route add -host 1.2.4.5 gw 127.0.0.1
пока не пробовал, но думаю тоже можно столкнуться с лимитом на размер таблицы роутинга, поскольку она не предназначена для такого рода задач.
сейчас просто добавляю список deny ip; в nginx , и вроде работает, но только размер файла с блокировками стремительно растёт - 200К и более.После изменений в списке приходится делать service nginx reload, что по-моему негативно отражается на стабильности nginx. Приходится делать service nginx restart через каждые десять релоадов, иначе через некоторое время "подвешивается". -
iptables обрабатывается линейно, потому каждый приходящий пакет на сервер будет пробегать всю цепочку, нагрузка на сервер мгновенно вырастет и начнут дропаться пакеты на сетевой карте.
nginx не знаю насколько эффективен, но помоему плодить огромный конфиг не вариант вообще.
Можно свежее ядро и ipset с хешами, тогда можно одно правило iptables -m set и т.д. (а адреса уже вносятся через ipset. Это лучший вариант, но чаще всего всякие хостинги на древних ядрах(особенно Centos, debian, RHEL), а ipset появился сравнительно недавно.
По поводу рутинга оптимальный вариант, там лимитов практически нет, если правильно включен rp_filter (осторожно, если хотите менять!). Роутинг основан или на хеше или на TRIE, и большие таблицы обрабатывает нормально. Мне приходилось обрабатывать и 260 тыс. записей без особых проблем (full BGP view). -
-
nuclearcat писал :Можно свежее ядро и ipset с хешами, тогда можно одно правило iptables -m set и т.д. (а адреса уже вносятся через ipset. Это лучший вариант
Что-то интересное, пытаюсь гуглить. -