nginx auth_request (3/3): Web-Application firewall, WAF

Сразу оговорюсь - я знаю про существование nginx naxsi и mod_security, речь про то, как вообще такое делается.

Под WAF я понимаю некое дополнение к веб-серверу, выполняющее одну или несколько следющих задач:

  • блокировка вредоносных запросов
  • подтверждение юзером "сомнительных" запросов
  • ограничение частоты запросов по сложным критериям

Дополнительно можно собирать статистику.

Принцип работы всё тот же - nginx сначала пересылает копию запроса на какой-то внешний сервис и на основании ответа от этого сервиса - решает, пропускать ли исходный запрос или нет.

Механизм работы опсан в предыдущей статье, поэтому интересны прежде всего алгоритмы: 1) выделение запросов одного пользователя, 2) ограничения частоты запросов. 3) определения "вредоносности" или "подозрительности" запроса, Нетрудно заметить, третья задача зависит от первой, а вторая и третья тесно связаны.

По порядку.

Выделение запросов одного пользователя

Первая и очевидная мысль, приходящая в голову - просто смотреть запросы с одного ip. Но тут есть множество тонкостей. Случаев, когда с одного адреса могут сидеть несколько пользователей - достаточно много: nat, vpn, tor, ipv6-to-4 брокер. И обратный случай - когда один юзер может сидеть с нескольких адресов: tor.

Что делать? На заголовки полагаться нельзя, там можно подделать абсолютно всё. Комбинация ip+заголовок, например User-Agent? Это ещё хуже, подделкой заголовка можно добиться, чтобы система определяла тебя как разных юзеров, даже не меняя свой ip.

Один из возможных вариантов - заставить каждого неопознанного клиента произвоить некую ресурсоёмкую операцию, после выполнения которой этому клиенту присваивается уникальный идентификатор, который тот будет предъявлять в дальнейшем как доказательство выполненной работы. Разумеется, его нужно защитить от подделки и ограничить срок годности.

Блок схема (исходник):

Путь "известного" юзера показан жирной линией, "неизвестного" - прерывистой. Операция (3) может быть к/либо вычислением на стороне пользователя, с сообщением результата. Или же - проверкой на робота, например следование по редиректам. сделанных средствами самого html.

Схема может изменяться в некоторых пределах, например (2) "N" может переходить не в (4), а в (3). Можно например, "неизвестных" клиентов сразу кидать на капчу, т.е. (1) "N" -> (4).

Думаю не нужно напоминать, что все операции, кроме (3) следует оптимизировать на минимальные затраты ресурсов и максимальное быстродействие. Если используется капча, её лучше нагенерить заранее и продумать механизм "карантина" на какое-то время для показанных, но не решённых.

Обратите внимание, путь по жирной линии выполняется в пределах одного обработчика. А вот переходы к другим состояниям - требуют перехода на другие странички. Помните, что я говорил про error_page и поддержку редиректов?

Ограничение частоты запросов

Здесь может быть куча вариантов реализации.

Например самое простое и железобетонное решение: выделять временн*ы*е слоты определённой длительности и считать запросы юзера в пределах текущего слота.

my $len = 5; # новый слот каждые 5 минут
my $time = time();
# вычисляем имя слота
my $slot = sprintf "req:%d:%d", $len, ($time - ($time % ($len * 60)));
# увеличиваем число запросов для юзера с $uuid
# и узнаём, сколько запросов он уже сделал в пределах данного слота
my $reqs = $redis->hincr($slot, $uuid => 1); # O(1)
$redis->expire($slot, 3600) if $reqs == 1;
# если $reqs >= $limit - блокируем запрос

Метод хорош тем, что крайне прост (1 запрос), хорошо масштабируется и может работать вообще без обслуживания. Основной недостаток - низкая "разрешающая способность", на границе временного слота можно превысить лимит до 2х раз.

Если нам нужна гарантия, что в каждый момент времени лимит не будет превышен, подход несколько другой. На каждого юзера заводится по персональному списку, туда пишется время запросов. Недостатки: стоимость выше, больший расход памяти.

Принцип действия такой: при частых запросах в начале очереди растёт число "недавних" запросов. Как только N-ый элемент оказывается "недавним", значит лимит превышен.

Вариант 2/а:

my ($time, $limit) = (5, 60); # время окна в минутах и количество запросов
my $now  = time();
my $key  = sprintf "user:%s", $uuid;
my $some = $redis->lindex($key, $limit - 1); # O(N)
my $next = $some + ($time * 60);
if ($now > $next) {
  $redis->lpush($key, $now);    # O(1)
  # периодически подрезаем список, чтоб не разрастался сверх меры
  $redis->ltrim($key, 0, $limit - 1); # O(N), где N - количество удалённых элементов
  $redis->expire($key, 3600) if $some == 0;
} else {
  # лимит превышен
}

Вариант 2/б, где "гарантированно дорогой" lindex() с O(N), заменяется на llen() + lindex(-1), т.е. 2 x O(1). Хотя в теории, lindex(N) для списка в котором меньше N элементов - тоже должен отрабатывать за O(1).

my ($time, $limit) = (5, 60); # время окна в минутах и количество запросов
my $now  = time();
my $key  = sprintf "user:%s", $uuid;
my $len  = $redis->llen($key); # O(1)
if ($len < $limit) {
  # первичное заполнение
  $redis->lpush($key, $now); # O(1)
  $redis->expire($key, 3600) if $len == 0;
  return;
} else {
  $redis->ltrim($key, 0, $limit - 1);  # O(N), где N - количество удалённых элементов
  my $last = $redis->lindex($key, -1); # O(1)
  my $next = $last + ($time * 60);
  if ($now >= $next) {
    $redis->lpush($key, $now);
    return;
  }
}
# лимит превышен

Впринципе, всё это экономия на спичках. Значительно большего эффекта можно добиться, если считать не абстрактные "запросы", а прикинуть стоимость конкретного запроса в плане нагрузки и выделять пользователю "бюджет" на пользование.

Например, показ странички с картинками, где половина содержимого - статика, а остальное закешировано - это одно. Полнотекстовый поиск по сайту - это уже другое. А попытка авторизации на сайте - совсем даже третье.

"Вредоносность" и "подозрительность" запроса

Здесь сложно дать какие-то рекомендации, смотрите по ситуации. Можно анализировать заголовки (User-Agent/Referer/Accept/...), частоту запросов, их логическую взаимосвязь. Например, запрос к автодополнению с X-Requested-With - это с высокой вероятностью человек. Постоянная долбёжка поля поиска с интервалом в секунду - практически наверняка бот-дудосер. Монотонные запросы несвязанные друг с другом - поисковый бот. Пиковые всплески запросов с интервалом в несколько минут - юзер, который открывает несколько вкладок сразу, а потом сидит их читает.

Вобщем, на практке быстро научитесь на что нужно смотреть.

Ну и не стоит забывать про типовые запросы для поиска админок вордпресса, скуэля, гостевух и прочего говнокода на похапе. Клиенту, спалившемся на таком можно просто возвращать 404 на все запросы, чтоб больше не приходил.

nginx software devel репост