Re: Доработка limit_req

[Maxim Dounin <mdounin@xxxxxxxxxx>]

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

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru