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

[vitaly на rcdesign.ru]

Для новых коннектов можно на фаерволе ловушку сочинить через hashlimit и
ip_recent. Я делал вот так:
http://habrahabr.ru/blogs/sysadm/124492/#comment_4094950

Правда есть нюансы, что вышибет оперу турбо, но это белым списком решается.
Проблем с фаерволом две:

1. Нельзя ограничить по доменам
2. Пропускает множественные запросы внутри keep-alive (а это уже хуже)

В общем, более навернутый limit_req действительно был бы удобен. Задача
"полочить шибко шустрых, пока не остынут" - действительно типовая.

Vitaly Puzrin
http://www.rcdesign.ru


2011/10/26 Maxim Dounin <mdounin at mdounin.ru>

> 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20111027/084e3e1a/attachment-0001.html>