Правильная настройка 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, чтобы когда система загибается от множества коннектов скрипт отработал и забанил кого надо, а у кого истекло время штрафа — разбанил.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 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

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