vovansystems Jul 19 2011 at 23:19

Правильная настройка DDoS Deflate

1 min

17K

System administration*

+17

Comments 19

link0ln Jul 20 2011 at 15:09

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

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

vovansystems Jul 20 2011 at 15:11

а почему не используете iptables?

depporter Jul 20 2011 at 15:43

Потому, что данный вариант проще, чем настраивать connlimit, и не везде есть по умолчанию connlimit, об этом говорилось в начале поста

vovansystems Jul 20 2011 at 15:52

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

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

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

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

так что ежели чего недопонял — поделитесь :)

depporter Jul 20 2011 at 15:56

Да вы бесспорно правы и костыль это или не костыль уже мнение сугубо личное. Просто не все знают тонкости модулей iptables и ядра, а этот вариант неплохо подойдет начинающему или фрилансеру, которому некогда возится с цепочками и правилами, а также когда начался жуткий ддос.

dlancer Jul 20 2011 at 17:38

Жаль от жуткого DDOS это не поможет.
Там упор не на количество соединений, а на количество IP.

vovansystems Jul 20 2011 at 17:44

на DDOS и не рассчитано (там от DDOS одно название :) ), зато от всяких спам-ботов, а также от slow http post атак (где именно 1 человек инициирует множество медленных соединений), а также от пачек скрипт-киддсов с ab/sidge помогает. только возможно стоит уменьшить интервал прогона скрипта :)

UFO just landed and posted this here

vovansystems Jul 22 2011 at 12:53

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

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

# если айпишник с ттл в списке БЛОК за последние 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 пакетов и их разницу считать за существующие коннекты?)

UFO just landed and posted this here

Orenlab Jul 20 2011 at 19:18

На FreeBSD хорошо помогал описанный мною способ с модулем к nginx — ngx_http_limit_req_module. Конечно же это не панацея, но в свое время этот способ сберег много время для сна :)

UFO just landed and posted this here

dlancer Jul 21 2011 at 06:15

К сожалению у поисковых роботов обычно много больше IP блоков + сторонние роботы «проверяльщики» и с такими настройками есть шанс периодически вылетать из поисковой выдачи по подозрению в cloacking. Если поисковой трафик не очень важен (для больших проектов как правило), то конечно можно и так.

vovansystems Jul 21 2011 at 12:30

а Вы что посоветуете? :)

dlancer Jul 21 2011 at 16:00

Если есть деньги у проекта/бизнеса, то потратиться на нормальную защиту, каналы и сервера.
А для проектов где денег нет — просто переждать :)
Все остальное малоэффективно.

UFO just landed and posted this here

Nastradamus Jul 21 2011 at 15:11

Это такая защита, которую некоторые боятся применять, дабы не потерять потенциальных клиентов. А DDoS с большим пулом адресов все равно не спасет.

Мне, к счастью, пока хватает fail2ban. Если вижу в логах apache/nginx аномалию, придумываю банящее на время правило для fail2ban.

fdv Sep 7 2011 at 18:02

Для 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 этим давится и итог вообще получается кривой. Проверяйте вручную как именно у вас на конкретном хосте отрабатывает эта строчка.

servancho Dec 28 2015 at 13:38

«Большинство провайдеров интернета используют NAT, поэтому многие пользователи имеют один и тот же IP. Со стороны WEB-сервера невозможно понять — большое количество соединений с одного IP это атака или это разные пользователи с одинаковым IP. При этом один и тот же сайт может генерировать совершенно разное количество запросов с одного IP, например, поиск картинок. Поиск может дать 10, а может и 100 результатов — каждый ресурс это запрос с IP.»

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