Для новых коннектов можно на фаерволе ловушку сочинить через 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@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@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru