Hello!
On Wed, Oct 26, 2011 at 12:12:50PM +0400, Михаил Монашёв wrote:
> Здравствуйте, Maxim.
>
> >> Иногда возникает задача блокировать кого-то, кто чересчур часто что-то
> >> с сайта запрашивает. Сейчас можно ограничить его по количеству
> >> запросов в единицу времени. Но запросы, которые вписываются в лимит
> >> будут проходить. Но это не совсем то, что иногда нужно. Иногда надо
> >> заблокировать до тех пор, пока количество запросов не снизится до
> >> установленного лимита. И это легко могло бы решаться, если у limit_req
> >> добавить параметр, который заставлял бы сохранять информацию о каждом
> >> запросе, а не только о том, который вписывается в установленный лимит.
>
> > (just for history)
>
> > В общем случае "сохранять информацию о каждом запросе" - нельзя,
> > ибо это даст возможность заблокировать лимитируемый параметр
> > практически навечно. E.g. evil hacker запрашивает ip под DHCP у
> > какого-нибудь stream'а, делает N (или M) запросов, запрашивает
> > следующий ip, ... В результате со стрима ни у кого твой сайт не
> > работает. Или ещё хуже: у хостера стоит лимит запросов на домен,
> > и тебе на этот сайт наливают M**2 запросов - сайт заблокирован на
> > неизвестное время.
>
> Я имел ввиду другое: если льётся более, чем Х запросов в единицу
> времени, то вообще ни один запрос не пропускать.
Ну вот это реализуется методом
limit_req ... burst=10 считать-до=11;
в предложенном мной варианте.
> Проблемы со злостным
> хакером нет. Он сменит ip, запросы кончатся и ip разблокируется по
> истечении единицы времени. С доменом та же история - кончилась атака и
> через единицу времени пропадает лимит.
Если считать до бесконечности - то проблема есть.
> > Какой-то механизм, обеспечивающий контролируемый гистерезис -
> > наверное нужен. Я исходно хотел сделать помимо параметра burst=
> > ещё и какой-то параметр <считать-до>=, но хорошего названия так и
> > не придумалось, да и руки не дошли.
>
> > Возможно, альтернативным вариантом будет некая дополнительная
> > таблица блокировки, в которую "нехорошие люди" будут заносится на
> > заданное время при превышении лимита (её же можно будет
> > использовать при превышении других ограничений, а равно при просто
> > при выполнении определённых условий). Тут надо ещё подумать.
>
> ИМХО, надо отделять подсчёт лимита от самого блокирования, а не
> совмещать их в одной директиве.
Может быть.
> P.S.
> Так как nginx кроме всего прочего часто выполняет функции фаервола, то
> возможно что-то из фаерволов имеет смысл позаимствовать.
Используемые в limit_req алгоритмы leaky bucket / token bucket -
это как раз алгоритмы из области traffic shaping'а... :)
Maxim Dounin
