Кейс NGINX: Как противостоять DDoS-атакам

Original author: Rick Nelson
  • Translation
Основная цель нашей работы состоит в том, чтобы сделать IaaS простым и понятным даже для тех, кто не сталкивался с ИТ-сферой. Поэтому мы проводим постоянную оптимизацию всех систем и рассказываем о том, что нам удалось сделать, в нашем блоге на Хабре.

Пара примеров:


Сегодня мы решили взглянуть на западный опыт и кратко проанализировать тему балансировки нагрузки. Нас привлекла заметка на тему работы с DDoS-атаками.


/ Фото Dennis van Zuijlekom / CC

Если начинать с терминологии, то DDoS можно определить как атаку на ИТ-систему с целью довести её до состояния, в котором будет невозможно обслуживать запросы с должным уровнем качества. Здесь работает количественное воздействие, которое производят специальными ботами, использующими ту или иную уязвимость для DDoS-атаки.

Слабая подготовленность системы к обработка большого числа запросов или распараллеливанию соединений и балансировке нагрузки может стать такой уязвимостью. В случае начала простейшей DDoS-атаки трафик на вашу систему пойдет с определенных адресов, которые будут генерировать аномальное число запросов и соединений. Помимо интенсивности трафика атаку можно вычислить о по нестандартным заголовкам User-Agent'а.

NGINX позволяет управлять трафиком с помощью его маршрутизации и ограничения частоты входящих запросов по средним показателям, характерным для людей (а не ботов). Помимо этого можно задать вилку числа соединений, которые могут исходить от одного IP.

Дополнительная возможность — разрыв соединений, которые практически не используются, но остаются открытыми на протяжении существенного отрезка времени. Таким образом вы сможете обезопасить систему от Slowloris-атаки.

Более жесткой мерой будет внесение IP в черный список с помощью директивы deny. После этого NGINX уже не будет обрабатывать запросы с этого адреса. Альтернатива — задать диапазон разрешенных IP.


/ Фото Joe The Goat Farmer / CC

Для предотвращения скачков трафика вы можете воспользоваться возможностью кеширования. NGINX сможет обновлять устаревшие объекты по мере необходимости и тем самым сглаживать пики нагрузки на вашу систему.

Дополнительно вы можете настроить фильтры по URL (для случая, когда атаке подвергается определенная часть вашего ресурса) и заголовкам User-Agent (если вы хотели бы отсечь аномальный трафик, который не похож на обычное поведение пользователей). Еще есть возможность ограничения числа соединений на уровне внутренней маршрутизации между серверами.

Внутренний инструментарий NGINX позволяет анализировать различные метрики входящего трафика. Мониторинг доступен в том числе и с помощью API.
  • +14
  • 24.9k
  • 5
1cloud.ru
229.31
IaaS, VPS, VDS, Частное и публичное облако, SSL
Share post

Comments 5

    +10
    К сожалению, нормальную DDoS атаку таким образом не отразишь. Кроме того, если будет забит сетевой канал, никакие средства nginx не помогут.
      +5
      Почему не написали про 444 код
      что на основе скориговой системы можнло логировать и блогировать через ipset или iptables raw

      set $add 1;
      location /index.php {
      limit_except GET POST {
      deny all;
      }
      set $ban "";
      if ($http_referer = "" ) {set $ban $ban$add;}
      if ($request_method = POST ) {set $ban $ban$add;}
      if ($query_string = «action=login» ){set $ban $ban$add;}
      if ($ban = 111 ) {
      access_log /var/log/[133]nginx/ban IP;
      return 444;
      }
      proxy_pass 127.0.0.1:8000;
      }
      ну и метрик для скоринга накрутить
      ни слова про тюнинг ядра… хоть это напрямую к нгинксу и не относится тему можно было бы осветить.
        0
        А не поделитесь опытом работы со скоринговыми системами, если таковой имеется?
          +1
          if ($http_referer = "" ) {set $ban $ban$add;}
          if ($request_method = POST ) {set $ban $ban$add;}
          if ($query_string = «action=login» ){set $ban $ban$add;}
          if ($ban = 111 ){
          return 444;
          }

          >>

          map "$http_referer$request_method$query_string" $ban {
              "POSTaction=login"  "1";
          }
          if ($ban) {
              return 444;
          }
          
          
          +2
          Директива client_body_timeout контролирует время ожидания NGINX между записями в теле клиента. Директива client_header_timeout делает то же для заголовков. По умолчанию в обоих случаях ставится 60 секунд. В следующем примере этот интервал устанавливается на значении 5 секунд.

          Аккуратнее с такими значениями. Можно легко так пустить под нож мобильных клиентов.

          Only users with full accounts can post comments. Log in, please.