Pull to refresh

Comments 19

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

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

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

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

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

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

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

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

# если айпишник с ттл в списке БЛОК за последние 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 landed and left these words here
На FreeBSD хорошо помогал описанный мною способ с модулем к nginx — ngx_http_limit_req_module. Конечно же это не панацея, но в свое время этот способ сберег много время для сна :)
UFO landed and left these words here
К сожалению у поисковых роботов обычно много больше IP блоков + сторонние роботы «проверяльщики» и с такими настройками есть шанс периодически вылетать из поисковой выдачи по подозрению в cloacking. Если поисковой трафик не очень важен (для больших проектов как правило), то конечно можно и так.
Если есть деньги у проекта/бизнеса, то потратиться на нормальную защиту, каналы и сервера.
А для проектов где денег нет — просто переждать :)
Все остальное малоэффективно.
UFO landed and left these words here
Это такая защита, которую некоторые боятся применять, дабы не потерять потенциальных клиентов. А DDoS с большим пулом адресов все равно не спасет.

Мне, к счастью, пока хватает fail2ban. Если вижу в логах apache/nginx аномалию, придумываю банящее на время правило для fail2ban.
Для 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 этим давится и итог вообще получается кривой. Проверяйте вручную как именно у вас на конкретном хосте отрабатывает эта строчка.
«Большинство провайдеров интернета используют NAT, поэтому многие пользователи имеют один и тот же IP. Со стороны WEB-сервера невозможно понять — большое количество соединений с одного IP это атака или это разные пользователи с одинаковым IP. При этом один и тот же сайт может генерировать совершенно разное количество запросов с одного IP, например, поиск картинок. Поиск может дать 10, а может и 100 результатов — каждый ресурс это запрос с IP.»

indusov.net/защита-от-http-флуда-flood-и-небольших-ddos
Only those users with full accounts are able to leave comments. Log in, please.