Пользователь
0,0
рейтинг
19 июля 2011 в 23:19

Администрирование → Правильная настройка DDoS Deflate

Оказывается такой удобный инструмент для борьбы с ДДОС атаками (или вернее со спамботами) как DDoS Deflate (который применяется тогда, когда в iptables отсутствует возможность использовать модуль connlimit), после инсталяции неправильно склонен себя конфигурировать. Это приводит к тому, что защита не работает.

Кстати, весьма важно помнить, что в отличие ограничения одновременных коннектов с 1 айпи адреса средствами iptables, когда попытки установить новые соединения просто не состоятся, при использовании DDoS Deflate айпи адрес, достигший лимита подключений, попадает в бан и все коннекты с ним прекаращаются на зданный интервал (после которого ip разбанивается).

Во-первых, в конфиге надо исправить

##### Количество соединений с 1 айпиадреса (т.к. тех, кто исчерпал лимит -
##### баним на 10 минут, лучше устанавливать не слишком маленькое значение
##### рискуем забанить офис за NAT транслятором (ipv6 ещё не пришол!)
NO_OF_CONNECTIONS=64

##### APF_BAN=0 (Включаем бан через iptables, а не по APF)
APF_BAN=0


Затем необходимо правильно сконфигурировать крон. Так как я не люблю разные cron-файлы в папке /etc/cron.d/, то рекомендую внести слегка отрадактированную строку на запуск скрипта в свой личный рутовый кронтаб, а файл /etc/cron.d/ddos.cron — удалить:

crontab -e
*/1 * * * * nice -n -5 /usr/local/ddos/ddos.sh

здесь мы увеличиваем приоритет процесса DDoS Deflate, чтобы когда система загибается от множества коннектов скрипт отработал и забанил кого надо, а у кого истекло время штрафа — разбанил.
vovansystems @vovansystems
карма
6,4
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (19)

  • 0
    Уже почти год как работает на серве. Удобно, быстро. Единственное, что — если нужно по портам (у нас трекер торрентов стоит), то

    netstat -alpn | grep ':8085\\|:8086\\|:8091' | awk '{print \$5}' | cut -d: -f1 |sort |uniq -c

    • 0
      а почему не используете iptables?
      • +1
        Потому, что данный вариант проще, чем настраивать connlimit, и не везде есть по умолчанию connlimit, об этом говорилось в начале поста
        • 0
          это-то всё понятно (хотя насчёт проще я бы поспорил), но возможно есть и другие причины.

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

          что касается самого механизма работы, который именно дропает все пакеты от провинившегося айпишника — возникает множество проблем. например в браузерах количество одновременных подключений к сайту установлено в 16. если 5 человек за NAT траслятором (офисный маршрутизатор) одновременно сидят на сайте, то они вполне могут превысить лимит соединений и лишиться какого-либо доступа к сайту на 10 минут!

          ну и как ни крути, а это всётаки костыль. довольно элегантный (для костыля), даже с конфигом, но, приходится признать, костыль.

          так что ежели чего недопонял — поделитесь :)
          • +1
            Да вы бесспорно правы и костыль это или не костыль уже мнение сугубо личное. Просто не все знают тонкости модулей iptables и ядра, а этот вариант неплохо подойдет начинающему или фрилансеру, которому некогда возится с цепочками и правилами, а также когда начался жуткий ддос.
            • 0
              Жаль от жуткого DDOS это не поможет.
              Там упор не на количество соединений, а на количество IP.
              • 0
                на DDOS и не рассчитано (там от DDOS одно название :) ), зато от всяких спам-ботов, а также от slow http post атак (где именно 1 человек инициирует множество медленных соединений), а также от пачек скрипт-киддсов с ab/sidge помогает. только возможно стоит уменьшить интервал прогона скрипта :)
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              с хэш лимитом всё понятно, но им можно лимитировать скорость открытия новых соединений и только. как без коннлимита ограничить количество существующих коннектов на айпи — непонятно

              не могли бы вы пояснить подробнее:

              # если айпишник с ттл в списке БЛОК за последние 250 сек - отклонить пакет
              iptables -A fw-input -m recent --rcheck --name BLOCK --seconds 250 --rttl -j REJECT --reject-with icmp-host-prohibited

              # если айпишник с ттл в списке БЛОК за последние 300 сек - отклонить пакет и обновить время доступа для него в списке блок (?)
              iptables -A fw-input -m recent --update --name BLOCK --seconds 300 --rttl -j REJECT --reject-with icmp-host-prohibited

              # тоже ясно
              iptables -A fw-input -m recent --rcheck --name BLOCK_PARALLELS --seconds 120 --rttl -j REJECT --reject-with icmp-host-prohibited


              т.е. логика работы такая — весь трафик идёт сначала на проверку на наличие в рисент, в который он попадает если превышает конлимит — я правильно понимаю?

              у меня, например, задача есть вполне конкретная — как без коннлимита ограничить кол-во соединений с 1го айпи :) мне кажется что средствами рисент можно добиться схожего функционала, но список правил в голове не вырисовываетс (мониторить количество syn и fin пакетов и их разницу считать за существующие коннекты?)
              • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    На FreeBSD хорошо помогал описанный мною способ с модулем к nginx — ngx_http_limit_req_module. Конечно же это не панацея, но в свое время этот способ сберег много время для сна :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      К сожалению у поисковых роботов обычно много больше IP блоков + сторонние роботы «проверяльщики» и с такими настройками есть шанс периодически вылетать из поисковой выдачи по подозрению в cloacking. Если поисковой трафик не очень важен (для больших проектов как правило), то конечно можно и так.
      • 0
        а Вы что посоветуете? :)
        • 0
          Если есть деньги у проекта/бизнеса, то потратиться на нормальную защиту, каналы и сервера.
          А для проектов где денег нет — просто переждать :)
          Все остальное малоэффективно.
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Это такая защита, которую некоторые боятся применять, дабы не потерять потенциальных клиентов. А DDoS с большим пулом адресов все равно не спасет.

    Мне, к счастью, пока хватает fail2ban. Если вижу в логах apache/nginx аномалию, придумываю банящее на время правило для fail2ban.
  • 0
    Для CentOS в скрипте ddos.sh вместо
    netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
    пришлось вписать
    netstat -ntu | grep ':' | awk '{print $5}' | sed 's/::ffff://' | cut -f1 -d ':' | sort | uniq -c | sort -nr
    или
    netstat -ntu | grep ffff | awk '{print $5}' | cut -d: -f4 | sort | uniq -c | sort -nr
    по вкусу.
    Иначе в правила попадают адреса вида 0.0.0.ххх. Netstat не везде одинаково возвращает результат, а cut этим давится и итог вообще получается кривой. Проверяйте вручную как именно у вас на конкретном хосте отрабатывает эта строчка.
  • 0
    «Большинство провайдеров интернета используют NAT, поэтому многие пользователи имеют один и тот же IP. Со стороны WEB-сервера невозможно понять — большое количество соединений с одного IP это атака или это разные пользователи с одинаковым IP. При этом один и тот же сайт может генерировать совершенно разное количество запросов с одного IP, например, поиск картинок. Поиск может дать 10, а может и 100 результатов — каждый ресурс это запрос с IP.»

    indusov.net/защита-от-http-флуда-flood-и-небольших-ddos

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.