Re: Борьба с нарушителями одного коннекта.

[Gena Makhomed]

On Sunday, March 15, 2009 at 15:38:55, Anton Kuznetsov wrote:

AK> Многие здесь, как и я, занимаются раздачей больших файлов, этому
AK> занятию как правило сопутствует настройка limit_conn one 1;
AK> чтобы диски совсем не порвало.

AK> Следствие этой настройки - постоянная долбежка сервера
AK> паразитными коннектами. Эдакая DDOS атака от настроенных по
AK> умолчанию в 5-10 конектов "Download Master" & etc... Сложно
AK> сказать о вреде, но если смотеть в лог куда сливается 503 -
AK> то при моих нагузках становится страшно. Лог наверно вообще надо
AK> отключить, но это отдельный вопрос. У меня при 1к-1,5к полезных
AK> коннектов, 2к-3к - паразитных и это если еще по башке стучать и
AK> заставлять читать правила настройки качалок. Вопрос в том, как
AK> минимизировать вред от этого явления. Я до этого момента честно
AK> занимался баном - 50 попаданий в лог-503 - правило в ipfw на
AK> день-неделю и чувство жалости давно атрофировалось. Качают те, кто
AK> умеют настраивать. Но... жалко по прежнему сервер, ему даже и так
AK> плохо. Чистый эксперимент показал что включение pf без правил на
AK> сервере при скорости 500 мегабит добавляют процессу "irq30: em0"
AK> (top -S) сразу добрых 20%, а этот процесс у меня и без этого близок к 100%.
AK> Сейчас я отключил ipfw & pf и пробую тихо игнорировать эту
AK> долбежку на самом nginx - вопрос как это лучше делать?

AK> Сейчас у меня стоит location = /503.html {limit_rate 1 ;}
AK> Но меня гложут смутные сомнения - хорошо ли nginx-у
AK> каждую секунду думать о том как в 2к-3к соединений отдать по байту?

AK> Вторая напасть похоже некоторые качалки (помню такое было
AK> в reget) не любят когда коннект отдает им слишком медленно
AK> и делают реконнект. Может я не прав, но в логе основная масса
AK> строчек "HTTP/1.0  503 0" - вроде как вообще не удалось ничего отдать,
AK> хотя время выполнения этих запросов солидное - в среднем более 100 секунд.
AK> Можно придумать что-то еще более легкое и эффективное или отключить лог и забыть?

я бы сделал так:

1. если не больше N паразитных коннектов к серверу с какого-то ip
за определенный промежуток времени - просто возвращал бы 503 ответ.

2. при превышении этого лимита - возможно return 444 - качалка ведь всеравно
сделает retry через 60 секунд вне зависимости от того, получила она в ответ
503 или просто произошел обрыв соединения, - а серверу от этого будет легче.

"нестандартный код 444 закрывает соединение без передачи заголовка ответа."
http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.html#return

3. если какие-то качалки будут совсем часто долбиться, например,
больше K запросов за определенный период времени - тогда можно
будет вместо запрашиваемого файла отдавать редирект на мелкий файл
в котором будут описаны правила работы с сервисом - не более 1 потока
скачивания для каждого файла с одного ip. - "DOS атака" сразу прекратится.

при уменьшении частоты запросов - fallback до уровня 2, а потом и до уровня 1.

PS возможно будет лучше, если ограничиться только п.2 или только п.3 после п.1.

PPS но это всё workaround`ы, solution`ом тут может быть
    наверное только использование протокола BitTorrent.

-- 
Best regards,
 Gena