Защита серверов Nginx (1/2)

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

Я предполагаю, что к этому моменту вы уже знаете, что такое типы директив, как установить и собрать свой экземпляр Nginx, переменные и все эти забавные вещи, если нет, есть много сайтов с практическими рекомендациями.

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

Виртуальные хосты Nginx

Виртуальный хост — это блок контекста сервера, который обрабатывает настройки для обработки статических файлов, портов, корневых каталогов и т. д.

Почему статические файлы? При рендеринге статических файлов вам не нужен внутренний язык программирования, чтобы что-то делать, поэтому сам Nginx может сохранять маршрутизацию трафика, напрямую обслуживая файлы, кроме того, вы можете установить, на основе типов mime, какие файлы вы хотите обрабатывать. обрабатываться.

Вот пример базового блока контекста сервера

types { 
  text/html html;
  text/css css;
  include mime.types; ---> well known file extensions
}
http {
  server { <--- This is the server context
    listen 80; <--- can be also 443 for HTTPS
    server_name [Whatever IP or domain name of the machine];
    root /var/www/demo; <--- Where to look the files
   }
}

Итак, что из этого можно сделать?

Иногда вы можете дать немного воздуха своей серверной логике.
Это отвечает за смену портов
Вы можете указать, какие расширения файлов могут быть обработаны

Ограничение скорости

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

Для этого используется инструкция limit_req_zone . Проверьте следующий пример.

http {
 location / {
   ...
   limit_req_zone $server_name $binary_remote_addr $request_uri   zone=MYZONE:10m rate=60r/m burst=5 nodelay;
   ...
  }
}

Объяснение можно разделить на несколько этапов.

$server_name — это IP-адрес сервера или доменное имя вашего компьютера.
$binary_remote_addr — это представление входящих пользователей, подключающийся IP-адрес
$request_uri используется для ограничения соединения для каждого URI, независимо от всего остального.
zone=MYZONE:10m — это зона памяти, установленная для отслеживания лимитов соединений с определенной продолжительностью.
Значение rate – это количество запросов в минуту, которые можно обработать.
burst — это допустимое значение для всех реализаций зоны, оно изменяет условие превышения до тех пор, пока не будет выполнено пакетное значение.
Инструкция nodelay (пакетный набор) обслуживать как можно быстрее.

В двух словах, мы контролируем топовые соединения, которые могут обрабатывать по шаблону запросов в минуту, оставшийся входящий трафик не сразу удаляется, но и не обрабатывается.

В примере шаблона 1r/s, если вы получаете 6 подключений, только первое из них будет управляться сервером.

Расширенную лекцию можно найти здесь.

Заголовки с истекающим сроком действия

Еще один быстрый и эффективный способ управления ответами — настройка времени кэширования. С точки зрения производительности отказ от любых неизменяемых ресурсов — это выигрыш.

В определенных местах вы можете управлять определенными заголовками с разным сроком действия с помощью всего одной строки кода.

location {
  add_header Cache-Control public;
  add_header Pragma public;
  add_header my_header "Something here";
  expires 1h; <---- This is it.
}

У этого есть свои недостатки, но если вы знаете свои ресурсы, почему бы их не использовать?

Сжатые ответы

Nginx использует gzip для сжатия данных ответа. Браузер может запрашивать, а также принимает форматы данных.

Итак, если мы можем сжать ответ, мы можем уменьшить его размер, чем меньше время, тем лучше. При получении браузер распаковывает

Это можно установить в блоке HTTP Nginx. Вот как.

http {
  ... 
  gzip on; 
  gzip_comp_level 3; <--- this is the compression level 
  gzip_types text/css text/javascript (file extensions to compress)
  ...
}

Вот две вещи, которые стоит упомянуть для сжатых ответов.

Уровень сжатия — это число от 0 до 5 (я думаю), с 3 по умолчанию, чем меньше число, тем лучше для больших файлов, и наоборот.
Конфигурация заголовка в запросах обязательна для получения закодированных данных. В команде curl (в качестве примера) мы можем использовать для нее заголовок -H "Accept-Encoding: gzip, deflate".

Безопасность Nginx с SSL

Конфигурация SSL — это новый стандарт в веб-разработке. При работе с HTTPS нам нужно установить стратегию для обработки небезопасных соединений, часто это делается путем переадресации связи между портами 80 и 445, сопровождаемой множеством дополнительных настроек для протоколов, ключей, транспорта, настроек SSL и многого другого.

Такое перенаправление:

server {
  listen 80;
  server_name davidlares.com;
  return 301 https://$host$request_uri;
}

Я думаю, что перенаправление объясняет само собой. Но как насчет тех настроек, о которых я говорил, ну, они находятся в другом блоке сервера, который обрабатывает соединения HTTPS. Вот в чем дело

server {
  listen 80;
  server_name davidlares.com;
  return 301 https://$server_name$request_uri;
}
server {
  listen 443 ssl;
  server_name davidlares.com;
  [Here goes the ssl_certificate and the ssl_certificate_key]
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on:
  ssl_ciphers ECDH:AESGCM:ECDH+AES256:ECDH+AES128+3DES:!ADH ...
  ssl_dhparam /etc/nginx/ssl/dhparam.pem;
  add_header Strict-Transport-Security "max-age=31536000" always;
  ssl_session_cache shared:SSL:40m;
  ssl_session_timeout 4h;
  ssl_session_tickets on;
  ...
}

Здесь много чего происходит, но об этом позже.

Нам нужно отключить протоколы SSL, теперь TLS является стандартом, потому что.
Шифры - это шифрование, которое можно использовать для передачи данных, те, что с (!) сегодня не используются, многие из них устарели.
ssl_dhparam предназначен для обмена ключами Диффи Хелмана, это механизм, который позволяет серверу выполнять обмен ключами между клиентом и сервером с полной секретностью.

Кроме того, у нас есть стратегия HSTS, которая означает строгую транспортную безопасность. Это заголовок, который говорит браузеру ничего не загружать с HTTP (порт 80), избегая/минимизируя полное перенаправление на порт 443.

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

В более широком плане инструкции по кэшированию задаются в разделе http. Вот как это выглядит

http {  
  ssl_session_cache shared:SSL:40m;
  ssl_session_timeout 4h; (how long)
  ssl_session_tickets on;
  server {
    [port 80 - redirection]
  }
  server {
   [port 443 - all SSL settings]
  }
}

session_cache представляет собой механизм, который хранится в памяти и доступен любому работнику с именем и размером. session_timeout устанавливает, как долго кеш будет доступен, а session_tickets — для проверки сеансов SSL, выдаются сервером.

Более подробную информацию вы можете найти здесь

Есть еще что настроить. Увидимся во второй части.

👋 Присоединяйтесь к FAUN сегодня и получайте похожие истории каждую неделю на свой почтовый ящик! ️ Получайте еженедельную порцию обязательных к прочтению технических статей, новостей и руководств.

Подпишитесь на нас в Twitter🐦и Facebook👥и Instagram📷 и присоединяйтесь к нашим Facebook и Linkedin Группы💬