Index · Правила · Поиск· Группы · Регистрация · Личные сообщения· Вход

Список разделов Не актуальное
 
 
 

Раздел: Не актуальное DDOS-атака на форум 

Создана: 14 Ноября 2011 Пон 7:45:07.
Раздел: "Не актуальное"
Сообщений в теме: 263, просмотров: 53254

На страницу: Назад  1, 2, 3 ... 13,
, 15, 16, 17, 18  Вперёд
  1. 14 Ноября 2011 Пон 7:45:07
    Начиная с 13 ноября продолжается ддос-атака на форум.
    Тысячи злобных ботов посылают нам тысячи запросов в секунду.
    В общем адЪ, израилЪ, локалхостЪ.
    Не удивляйтесь тормозам и отказам.
  2. 18 Ноября 2011 Птн 16:31:22
    Shtormovoy55 писал : как это не брать? Надо же поглумиться над кем-нибудь для отвода души.


    Мы не варвары, мы просто форумчане! Мы не будем уподобляться негодяям и проявлять низменные качества. Мы должны быть чистыми перед совестью. У меня, по-крайней мере, совесть никуда не исчезла Very Happy
  3. 18 Ноября 2011 Птн 18:36:37
    Где-то порядка 10000 атакующих зомбей пока видно.
    Наверное, по современным масштабам это так себе ддосик, детский сад.
  4. Parussnik55


    Завсегдатай


    Более 10 лет на форумеБан, запрет писать в публичных разделах форумаМуж.
    18 Ноября 2011 Птн 21:03:34
    AlexAdmin писал : Где-то порядка 10000 атакующих зомбей пока видно.
    Наверное, по современным масштабам это так себе ддосик, детский сад.

    10000, это пользователи твоего форума )))
  5. 18 Ноября 2011 Птн 21:46:02
    Привет

    Я тут новичок конечно, пообщаться пришел, а тут беда.
    Если надо референсы на себя дам,over internet, т.е. я не виртуал. (google: Denys Fedoryshchenko nuclearcat )

    По поводу ддоса, вижу у вас стоит сквида, но помоему это не самый эффективный метод борьбы.
    Я делал так:
    1)парсинг логов, ботов обычно легко вычислить по паттернам.
    2)установка cookies в nginx фиксированных по IP (хеш), и пропускаем на php (в случае nginx это fastcgi, может быть просто прокси режим на апач) только в случае если кука присутствует. Тупые боты не умеют толком куки.
    3)По определенным критериям блочим атакующие IP (geoip + п.1). Если ядро на сервере свежее - ipset, если старое через uRPF фичу линукса (могу в личку рассказать как).

    Атаки легко решаются если
    1)боты из стран не соответствующих основной аудитории (у вас я так понимаю РФ, а боты к примеру с разных азиатских стран)
    2)боты тупые

    Надеюсь мои советы не будут восприняты в штыки Смайлик :-)
    Могу налабать пару прог если очень надо Смайлик :-)
  6. 18 Ноября 2011 Птн 22:28:06
    nuclearcat писал :1)парсинг логов, ботов обычно легко вычислить по паттернам.

    Привет.
    Примерно так и делаю, плюс ещё некоторый анализ поведения.

    nuclearcat писал :2)установка cookies в nginx фиксированных по IP (хеш)

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

    Думаю,тут надо слегка по-другому подходить: и cookie присваивать, и на сервер сразу пропускать, но в случае отсутствия cookie при следующих запросах это уже можно рассматривать как дополнительный признак подозрительного поведения.

    nuclearcat писал :3)По определенным критериям блочим атакующие IP (geoip + п.1).

    Сейчас много ботов идет с IP казахстана, украины, белоруссии, сша (помимо индии, пакистана, таиланда и прочего). Конечно зарубежность - это доп. основание для подозрений, поскольку более 90% посетителей тут РФ.

    Но вообще я бы хотел сделать не разовое решение для конкретной атаки, а более-менее тиражируемую схему отражения подобного рода атак. Так что предложения конечно же приветствуются!
  7. 18 Ноября 2011 Птн 22:36:47
    Боюсь универсальных решений нет, всегда есть какое-то равновесие между эффективностью,удобством для пользователей и доп. расходами.

    Если у вас траффик дешевый, то проще поставить еще один сервак и на нем обрабатывать. При наличии времени вообще можно написать хитрый tcp forwarder с epoll(), который будет отшибать ботов.
    Ибо nginx/apache/squid слишком тяжеловаты для таких задач.
  8. 18 Ноября 2011 Птн 22:43:00
    Я парсил с помощью скрипта на php, к сожалению не сохранил, кажется юзал Pear geoip, т.е. сделал подобие tail -f на лог файл nginx.

    К сожалению пакистаны и прочие азиатские страны (бразилия и т.п.) вообще пришлось сразу загнать в блокировку сразу всей подсетью при малейших подозрениях на атаки, иногда и /16 (подсеть выколупывал из geoip).
    Если есть отдельный сервак - можно на нем выдавать ссылочку с капчей для заблокированных (тупо на tcp коннект выплевываем контент с ссылкой на разблокировку, но не более чем N раз в минуту), и если захотят - разблокируются по конкретному IP.
  9. 18 Ноября 2011 Птн 23:13:04
    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);
    }

    очень надёжное решение, само возобновляется при стирании или ротации логов, не приходится ничего дополнительно пинать.
  10. 18 Ноября 2011 Птн 23:23:26
    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 через каждые десять релоадов, иначе через некоторое время "подвешивается".
  11. 18 Ноября 2011 Птн 23:35:47
    iptables обрабатывается линейно, потому каждый приходящий пакет на сервер будет пробегать всю цепочку, нагрузка на сервер мгновенно вырастет и начнут дропаться пакеты на сетевой карте.
    nginx не знаю насколько эффективен, но помоему плодить огромный конфиг не вариант вообще.

    Можно свежее ядро и ipset с хешами, тогда можно одно правило iptables -m set и т.д. (а адреса уже вносятся через ipset. Это лучший вариант, но чаще всего всякие хостинги на древних ядрах(особенно Centos, debian, RHEL), а ipset появился сравнительно недавно.

    По поводу рутинга оптимальный вариант, там лимитов практически нет, если правильно включен rp_filter (осторожно, если хотите менять!). Роутинг основан или на хеше или на TRIE, и большие таблицы обрабатывает нормально. Мне приходилось обрабатывать и 260 тыс. записей без особых проблем (full BGP view).
  12. 18 Ноября 2011 Птн 23:37:33
    мой мозг взорвался Офигеть
  13. 18 Ноября 2011 Птн 23:41:00
    Лёха Юрич писал(а) : мой мозг взорвался Офигеть

    А мой вообще ничего не пропустил... Думаю, чего я, дура, вообще залезла в эту тему?
  14. 18 Ноября 2011 Птн 23:57:03
    Лёха Юрич писал(а) : мой мозг взорвался Офигеть

    Балетный! А ты возмущался по поводу новичков!!!))) Нормальный такой новичок попался! Сказка, а не диалог! Хотя я тоже ни черта не понимаю! Very Happy Very Happy Very Happy
  15. 19 Ноября 2011 Суб 0:06:40
    nuclearcat писал :Можно свежее ядро и ipset с хешами, тогда можно одно правило iptables -m set и т.д. (а адреса уже вносятся через ipset. Это лучший вариант

    Что-то интересное, пытаюсь гуглить.
На страницу: Назад  1, 2, 3 ... 13,
, 15, 16, 17, 18  Вперёд