Прежде чем перейти к другим методам защиты, я думаю, уместно кратко рассказать о рабочих процессах в Nginx, и вот в чем дело: экземпляр Nginx использует главный процесс, который используется для порождения новых процессов с конкретной целью прослушивания и ответа на запросы клиентов. . Вы можете рассматривать это как способ делегирования функциональных возможностей разным исполнителям (может быть, подпроцессам?).
Увеличение количества рабочих процессов в конфигурации Nginx увеличит количество создаваемых рабочих процессов, что не совсем хорошо для производительности, поскольку зависит от аппаратных возможностей вашего сервера.
Компьютеры с одним или несколькими ядрами не могут обмениваться процессами между собой, поэтому один рабочий процесс Nginx может работать только на одном ядре ЦП. Назначив больше рабочих процессов, вы можете по одному на каждое ядро ЦП вашей машины.
С этим нужно быть очень осторожным. Если у вас одноядерный процессор и вы установили worker_processes на 2, каждый рабочий будет работать на 50% по очевидным причинам. К счастью, характеристики вашей машины можно найти с помощью довольно простых команд, для ядер ЦП вы просто используете lscpu или ulimit -n команды.
Рабочие процессы можно настроить внутри nginx.conf, вот как.
worker_processes 2; <--- sometimes, the word "auto" is set
events {
worker_connections 1024; <--- The number of connections accepted
}
pid /var/run/new_nginx.pid;
Этот опыт может быть полезен для того, чтобы узнать и установить максимальное количество одновременных запросов, которое может обрабатывать аппаратное обеспечение. Хороший и правильный способ рассчитать максимальное количество подключений — умножить worker processes и worker connections. Вся эта конфигурация процесса достаточно хороша для производительности и во избежание проблем, когда требуется перезагрузка (без сбоя системы).
Буферы и тайм-ауты
Процесс настройки прост, а вот настройка размеров буфера и таймаута нет, это не связано с возможностями машины, но поскольку трафик может сильно меняться, характер запросов порождает неопределенность в отношении того, как поведет себя система.
Буферизация — это процесс, выполняемый рабочим Nginx, который считывает данные в ОЗУ перед записью в следующее поколение. Он состоит из:
- Nginx получает запрос (чтение с TCP-порта)
- Запись данных в буферы памяти, если мало то записать на диск.
- Nginx отвечает на запрос (может быть статическим файлом), который читает из ОЗУ или диска
- Отправка данных клиенту из самой памяти.
Весь этот процесс подразумевает создание буфера, который может действовать как уровень защиты для чтения/записи данных, и эта упомянутая неопределенность усложняет планирование.
С другой стороны, Тайм-аут предлагает время отключения для данного события. Этот конкретный элемент имеет множество конфигураций, потому что может напрямую работать со временем отклика.
Вот пример: при получении запроса от клиента с помощью тайм-аутов вы можете контролировать или останавливать цикл через определенное количество секунд, таким образом предотвращая отправку клиентом строки потока и ломая сервер.
Nginx может контролировать оба поведения с помощью простых инструкций. Вот несколько из них:
1. client_body_buffer_size 10K; — это объем памяти, выделяемый для буферизации POST данных от клиента. Увеличение этой памяти может привести к трате памяти на нашем сервере, но слишком маленькое значение приводит к записи на диск части буфера — делает это медленным.
2. The client_max_body_size 8m; представляет максимальное количество данных, которые можно передать через формы. Это безопасная мера, гарантирующая, что пользователь не отправит по ошибке очень большой почтовый запрос. Если не обрабатывать, это может потребовать дискового пространства и замедлить обработку.
3. client_header_buffer_size 1k это память, выделенная для чтения заголовков
4. client_body_timeout 12; и client_header_timeout 12; - это время, установленное для чтения в буфер, а не весь процесс. Это относится к телу и заголовку запроса.
5. keepalive_timeout 15; — это время, которое эта директива устанавливает как количество времени, в течение которого инженеры должны сохранять соединение чистым и открытым для входящих данных.
6. send_timeout 10 представляет время, когда клиент не получает данные ответа в течение этого времени. Уилл завершает ответ, если передает это значение
7. sendfile on; — инструкция для разрешения отправки данных с диска напрямую
8. tcp_nopush on; оптимизировать размер пакетов, отправляемых клиенту (оптимизация) для статических ресурсов.
Дополнительные рекомендации
- Обновляйте свое программное обеспечение: пакеты ОС, исправления безопасности, все.
- Скройте сведения о сервере (версия Nginx) в заголовке HTTP. Делается это с помощью команды
server_tokens off;. - Помогите своим заголовкам с параметрами заголовка
X-FRAME options, это может помочь предотвратить злонамеренное использование для встраивания веб-сайтов или кликджекинга. - И, наконец, удалите неиспользуемые модули Nginx или замените устаревшие. Это закрывает путь потенциальным векторам атаки. Это делается путем простой перенастройки, сборки и установки. Подсказка: используйте
--without-[package]для удаления модулей.
При этом вы можете легко установить стратегию для защиты вашего сервиса, конечно, есть больше концепций, основанных на аутентификации, HTTP2, обратных прокси-серверах и балансировке, но я думаю, что это больше зависит от функций приложения, чем от аспектов безопасности.
Пересмотрите эти понятия в официальной документации, а также постарайтесь ознакомиться с правильной терминологией и отнеситесь к этому серьезно.
👋 Присоединяйтесь к FAUN сегодня и получайте похожие истории каждую неделю на свой почтовый ящик! ️ Получайте еженедельную порцию обязательных к прочтению технических статей, новостей и руководств.
Подпишитесь на нас в Twitter🐦и Facebook👥и Instagram📷 и присоединяйтесь к нашим Facebook и Linkedin Группы💬
