Установка и настройка nginx - Блог компании Селектел

Установка и настройка nginx – Блог компании Селектел

304 not modified не устанавливается

Если возникает проблема с правильным отображением ответного заголовка сервера 304 Not Modified, то проблема, скорее всего, в пунктах:

Правильность ответа 304 Not Modified можно проверить с помощью:

413 request entity too large

Ошибка возникает, когда на сервер загружается файл, превышающий значение директивы client_max_body_size, по умолчанию – 1 Мб. Добавим в блок server:

server {
	### остальные директивы
client_max_body_size 50m;
	### остальные директивы
}

В примере максимально допустимый размер тела запроса клиента увеличен до 50 Мб. При повторном возникновении ошибки – снова увеличить. Не забываем сохраняться и после изменений – перезапускать nginx:

service nginx restart

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

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

502 bad gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.

Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.

listen = /tmp/php5-fpm.sock 
listen.group = www-data
listen.owner = www-data

504 gateway time-out

Одна из причин возникновения ошибки – превышение времени ожидания ответа от сервера, например от php-fpm. Такое случается, когда скрипты php долго выполняются или зависли. Если обработка запроса требует большего времени – увеличим время ожидания на передачу запроса fastcgi_send_timeout и получение ответа fastcgi_read_timeout, редактируем блок location ~ .php$:

Config для включения ssi nginx?

Вопрос:

Лучший ответ:

Ответ №1

Похоже, у вас была та же проблема, что и у меня; найти кристально четкое объяснение того, как включить SSI на NGINX. Crystal Clear подразумевает не только какой синтаксис использовать, но и формат и где именно его включать. Я понял это, и это не так сложно, но отсутствие четких инструкций в интернете расстраивало.

Вам нужно открыть файл nginx.conf и найти раздел, который отформатирован следующим образом (я также включил синтаксис “ssi on”):

location / {
root   E:websiteFinalJRLWeb;
index  index.html index.shtml;
ssi on;
}

Мне потребовалось немного времени, чтобы понять это местоположение, но это действительно так просто, как добавление строки “ssi on” прямо под указанными именами индексных файлов (и она должна быть в состоянии пойти куда угодно, я полагаю, не думаю, что порядок имеет значение, если он заключен в две скобки {}).

После этого, чтобы убедиться, что SSI работает на вашем сервере NGINX, добавьте следующую строку в любом месте тега “body” пустой HTML-страницы

<!--#echo var="DATE_LOCAL" -->

и сохраните его с расширением .shtml в корневом каталоге вашего веб-сервера.

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

Вот страница документации NGINX по SSI (которая, честно говоря, не помогала мне так сильно, как хотелось бы, но тем не менее полезна и может стать только более и более полезной)

http://nginx.org/en/docs/http/ngx_http_ssi_module.html#ssi_last_modified

Ответ №2

Ответ №3

Csp and x-xss-protection

Политика безопасности контента (CSP) защищает ваш веб-сервер от определенных типов атак, включая атаки с использованием Cross-site Scripting (XSS) и атаки с использованием data injection. Вы можете реализовать CSP, добавив следующий пример заголовка Content-Security-Policy (обратите внимание, что фактический заголовок должен быть настроен в соответствии с вашими уникальными требованиями):

Nginx wordpress multisite

Ниже конфигурация под WordPress Multisite с сайтами в поддиректориях:

Nginx в docker

Для установки Docker, нужно подготовить систему. Устанавливаем необходимые пакеты:

Nginx, ssi и last-modified

Здравствуйте!

Захотел сделать такой трюк с Nginx на одном веб-сервисе. Главную страницу сделать статичным html файлом, в который вставлять все css и js зависимости с помощью SSI для оптимизации загрузки. Остальные данные подгружать с помощью javascript. Знаю, что плохо, для поисковых систем. Но нужно снизить количество запросов от пользователя. Проблема в том, что при включении SSI — Nginx перестаёт отдавать Last-Modified. Что убивает на корню использование такого трюка для кеширование и минимизации запросов от клиента.

Кто знает, как заставить Nginx слать Last-Modified заголовок для статичного файла после SSI обработки?

Балансировка нагрузки

Для улучшения отказоустойчивости, масштабируемости, уменьшения время отклика, распределения полезной нагрузки придумали балансировщики нагрузок. На примере посмотрим, как приспособить для этого nginx.

Открываем файл виртуального хоста:

Безопасность nginx

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

В чём разница между reload и restart

Как происходит перезагрузка в NGINX:

  1. Команда посылается серверу
  2. Сервер анализирует конфигурационный файл
  3. Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу
  4. Если конфигурация содержит ошибки, то при использовании
    1. restart процесс перезагрузки сервера прерывается, сервер не запускается
    2. reload сервер откатывается назад к старой конфигурации, работа продолжается

Короче говоря, restart обрывает работу резко, reload делает это плавно.Restart рекомендуется использовать, только когда внесены глобальные изменения, например, заменено ядро сервера, либо нужно увидеть результат внесённых изменений прямо здесь и сейчас. В остальных случаях используйте reload.

Ещё лучше, если вы будете предварительно проверять правильность конфигурации командой nginx -t, например:

nginx -t && service nginx reload

или

nginx -t && nginx -s reload

Директивы

Существует два вида директив – простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и в конце строки ставится точкой с запятой (;). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ({ и }). Рассмотрим те, которые пригодятся нам для примера:

Запуск nginx

Стартуем наш веб-сервер:

service nginx start

Проверяем статус:

service nginx status

Если в статусе присутствует строка Active: active (running), значит сервер работает. Также в этом можно убедиться, набрав в адресной строке браузера IP адрес сервера, будет отображено приветственное сообщение от nginx, которое выглядит так:

Защищай важные каталоги от посторонних

Как и любой другой Web-сервер, nginx позволяет регулировать доступ к каталогам на основе IP-адресов и паролей. Эту возможность можно использовать для закрытия некоторых частей сайта от посторонних глаз. Например, для отрезания URI от внешнего мира:

# vi /etc/nginx/nginx.conf

location /uploads/ {# Разрешаем доступ только машинам локальной сетиallow 192.168.1.0/24;# Отшиваем всех остальныхdeny all;}

Сейчас ищут техподдержку:  Сайт не открывается С или БЕЗ «www» перед доменным именем • Former – web-хостинг и домены

Иерархия каталогов nginx

Администрирование сервера nginx в основном заключается в настройке и поддержке его файлов конфигурации, которые находятся в папке /etc/nginx. Рассмотрим подробнее:

  • /etc/nginx/nginx.conf – главный файл конфигурации nginx.
  • /etc/nginx/sites-available – каталог с конфигурациями виртуальных хостов, т.е. каждый файл, находящийся в этом каталоге, содержит информацию о конкретном сайте – его имени, IP адресе, рабочей директории и многое другое.
  • /etc/nginx/sites-enabled – в этом каталоге содержаться конфигурации сайтов, обслуживаемых nginx, т.е. активных, как правило, это символические ссылки sites-available конфигураций, что очень удобно для оперативного включения и отключения сайтов.

Используй ssl

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

Для настройки SSL-шифрования средствами nginx достаточно выполнить несколько простых шагов. Сначала ты должен создать сертификат с помощью следующей последовательности команд:

# cd /etc/nginx# openssl genrsa -des3 -out server.key 1024# openssl req -new -key server.key -out server.csr# cp server.key server.key.org# openssl rsa -in server.key.org -out server.key# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Затем описать сертификат в конфигурационном файле nginx:

# vi /etc/nginx/nginx.conf

Как в nginx сделать редирект на мобильную версию сайта

Данный код вставляется на уровне server в самое начало файла (не обязательно в самое начало, но главное, чтобы перед определением обработчика скриптов php, иначе редирект может не сработать).

Как в nginx указать размер и время

Размеры:

Время задаётся в следующих суффиксах:

  • ms — миллисекунды
  • s — секунды
  • m — минуты
  • h — часы
  • d — дни
  • w — недели
  • M — месяцы, 30 дней
  • Y — годы, 365 дней

В одном значении можно комбинировать различные единицы, указывая их в порядке от более к менее значащим, и по желанию отделяя их пробелами. Например, 1h 30m задаёт то же время, что и 90m или 5400s. Значение без суффикса задаёт секунды.

Рекомендуется всегда указывать суффикс

Некоторые интервалы времени можно задать лишь с точностью до секунд.

Как вместо 404 ошибки делать 301 редирект на главную

error_page 404 = @gotomain;

location @gotomain {
  return 301 /;
}

Как заблокировать по ip в nginx

Блокировать можно с помощью директив allow и deny.

Правила обработки таковы, что поиск идёт сверху вниз. Если IP совпадает с одним из правил, поиск прекращается.Таким образом, вы можете как забанить все IP, кроме своих, так и заблокировать определённый IP:

  deny 1.2.3.4 ; # Здесь мы вводим IP нарушителя
  deny 192.168.1.1/23 ; # А это пример того, как можно добавить подсеть в бан
  deny 2001:0db8::/32 ; # Пример заблокированного IPv6
  allow all ; # Всем остальным разрешаем доступ

Приведу пример конфигурации, как можно закрыть доступ к панели администратора WordPress по IP:

Как настроить last-modified

Алгоритм такой: поисковой робот «спрашивает» у сервера – не изменилась ли страница с определенной даты. Если страница изменилась – сервер возвращает страницу как обычно, если изменений не было возвращает только заголовок «304 Not Modified».

Пример для модуля статей или новостей, предполагается что в БД хранится даты создания и изменения статьи в формате UnixTime. Код ставится до вывода контента в браузер.

Теперь на странице где работает код в ответе сервера будет заголовок Last-Modified. Проверить можно в сервисе last-modified.com/ru/ или в код-инспекторе браузера:

Заголовка нет в ответе сервера, а например Last-Modified-x есть:

Причина тут в nginx и модуле ngx_http_ssi_module – он удаляет заголовок Last-Modified отправленный из PHP, нужно в конфиге nginx отключить модуль SSI.

location / {
	ssi off;
	...
}

Как настроить last-modified nginx php

location ~ .php$
{ 
 …
 if_modified_since off;

 fastcgi_pass fcgi;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME /<путь > /web$fastcgi_script_name;
 …
 fastcgi_pass_header Last-Modified;
 include fastcgi_params;
}

Как перезагрузить nginx

Для перезагрузки NGINX используйте restart или reload.Команда в консоли:

service nginx reload

либо

/etc/init.d/nginx reload

либо

nginx -s reload

Эти команды остановят и перезапустят сервер NGINX.

Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:

nginx -s reload

Проверить правильность конфигурации можно командой

nginx -t 

Как правильно составить правила nginx.conf

Идём изучать мануалы на официальный сайт.Пример рабочей конфигурации NGINX в роли кеширующего проксирующего сервера с Apache в бекенде

Как проверить, установлен ли nginx

Пишете в консоль SSH следующую команду, она покажет версию NGINX

nginx -v

Если видите что-то навродеnginx version: nginx/1.10.3Значит, всё в порядке, установлен NGINX версии 1.10.3. Если нет, установим его.

Как установить nginx

Если вы сидите не под root, предваряйте команды apt-get префиксом sudo, например sudo apt-get install nginx

  1. Обновляем порты (не обязательно)
    apt-get update && apt-get upgrade
  2. Установка NGINX
    apt-get install nginx
  3. Проверим, установлен ли NGINX
    nginx -v

    Команда должна показать версию сервера, что-то подобное:
    nginx version: nginx/1.10.3

Контролируй количество одновременных соединений

Для защиты Web-сервера от перегрузки и попыток осуществить DoS-атаку добавь в конфиг следующие строки:

# vi /etc/nginx/nginx.conf

# Описываем зону (slimits), в которой будут храниться состояния сессий. Зона размером 1 Мб может хранить около 32000 состояний, мы устанавливаем ее размер равным 5 Мбlimit_zone slimits $binary_remote_addr 5m;# Задаем максимальное количество одновременных соединений для одной сессии. По сути, это число задает максимальное количество соединений с одного IPlimit_conn slimits 5;

Кэширование в nginx

Основная задача кэширования – это минимизация времени доступа к данным. Nginx умеет работать с несколькими видами кэширования: на стороне сервера, на стороне клиента. Серверное кэширование может иметь самую разнообразную конфигурацию, в зависимости от архитектуры проекта. Поэтому в нашем частном случае рассмотрим кэширование на стороне клиента (браузера) для статического контента.

Открываем файл нашего тестового виртуального хоста:

Мониторинг nginx

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

Настрой php

Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:

# vi /etc/php/php.ini

# Отключаем опасные функцииdisable_functions = phpinfo, system, mail, exec# Максимальное время исполнения скриптаmax_execution_time = 30# Максимальное время, которое может потратить скрипт на обработку данных запросаmax_input_time = 60# Максимальное количество памяти, выделяемое каждому скриптуmemory_limit = 8M# Максимальный размер данных, отсылаемых скрипту с помощью метода POSTpost_max_size = 8M# Максимальный размер загружаемых файловupload_max_filesize = 2M# Не показывать ошибки PHP-скриптов пользователямdisplay_errors = Off# Включаем Safe Modesafe_mode = On# Включаем SQL Safe Modesql.

safe_mode = On# Позволяем выполнять внешние команды только в этом каталогеsafe_mode_exec_dir = /путь/к/защищенному/каталогу# Защищаемся от утечки информации о PHPexpose_php = Off# Ведем логиlog_errors = On# Запрещаем открытие удаленных файловallow_url_fopen = Off

Настрой брандмауэр

Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.

Сейчас ищут техподдержку:  Почему не работает post__not_in? — Хабр Q&A

Настройка nginx

Рассмотрим главный конфигурационный файл nginx — /etc/nginx/nginx.conf. По умолчанию он выглядит следующим образом:

Настройка заголовка last-modified

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

Цитата из руководства Яндекса:

Ограничение доступа по ip адресу

В качестве примера отредактируем тренировочный виртуальный хост:

Ограничь количество доступных методов обращения к web-серверу

Некоторые боты используют различные методы обращения к серверу для попытки определения его типа и/или проникновения, однако в документе RFC 2616 четко сказано, что Web-сервер не обязан реализовывать их все, и неподдерживаемые методы могут просто не обрабатываться.

Сегодня используемыми остаются только методы GET (запрос документа), HEAD (запрос заголовков сервера) и POST (запрос на публикацию документа), поэтому все остальные можно безболезненно отключить с помощью помещения следующих строк в секцию server конфигурационного файла:

# vi /etc/nginx/nginx.conf

if ($request_method !~ ^(GET|HEAD|POST)$ ) {return 444;}

Ограничь количество соединений с помощью брандмауэра

Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:

# iptables -A INPUT -p tcp –dport 80 -i eth0 -m state –state NEW -m recent –set# iptables -A INPUT -p tcp –dport 80 -i eth0 -m state –state NEW -m recent –update –seconds 60 –hitcount 15 -j DROP

Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:

# vi /etc/pf.conf

Отключи показ версии сервера на всех ошибочных страницах

Добавь в файл nginx.conf строку “server_tokens off”. Это заставит nginx скрывать информацию о типе и версии Web-сервера на страницах, генерируемых в ответ на ошибочный запрос клиента.

Ошибки nginx

В работе любых систем, а особенно на этапе пуско-наладочных работ, возникают ошибки, в данном разделе рассмотрим наиболее распространенные и методы их устранения.

Переменные в nginx

В конфигурационных файлах nginx допустимо пользоваться встроенными переменными. Преимущественно это переменные, представляющие собой поля заголовка запроса клиента, такие как $remote_addr, $server_name. Все переменные начинаются со знака $, с полным перечнем можно ознакомиться в документации, на официальном сайте.

Подготовка сервера

Для начала установим сам сервер. После прохождения регистрации, необходимо войти в панель управления. Далее в меню «Облачная платформа» — «Создать сервер».

Откроется оснастка создания сервера, где необходимо задать понятное для дальнейшей работы имя сервера, в примере это «WebSrv01». Регион и зону можно оставить без изменения. Для выбора операционной системы необходимо нажать кнопку «Выбрать другой источник».

Откроется меню «Выбор источника».

В поле «Операционные системы», выбираем Ubuntu, в левом поле появится список всех доступных образов операционных систем на базе данной ОС, выбираем «Ubuntu 20.04 LTS 64-bit» и нажимаем кнопку «Выбрать».

Перемещаемся вниз по странице. В нашем примере используется только «Локальный диск», флажок установлен, в поле «Сетевые диски» нажимаем кнопку «Удалить диск».

В поле «Сеть», поскольку это наш первый сервер выбираем «Приватная подсеть 1 плавающий IP», после выбора значение в поле сменится на «Новый плавающий IP адрес».

Необходимо скопировать «Пароль для root», он понадобиться для первоначальной настройки сервера через SSH протокол.

Нажимаем кнопку «Создать», сервер будет доступен примерно через 1 минуту. Переходим в меню «Облачная платформа» — «Серверы».

В списке появится сервер с именем, что задали ранее, его IP адрес, который будем использовать для удаленного подключения, на скриншоте в области с цифрой 3, статус сервера ALIVE, означает готовность сервера. Подключаемся к серверу, используя любой SSH-клиент.

Проведем небольшую первоначальную настройку сервера. Обновим информацию о доступных пакетах из подключенных репозиториев:

apt update

Помести nginx в chroot/jail-окружение

Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.

Предотвращение ddos атак

DDoS — это распределенная атака отказа в обслуживании, происходит с нескольких IP адресов, направлена на ухудшение или полное отсутствие доступности сервера за счёт огромного количества запросов. Чаще всего, это происки недобросовестных конкурентов, реже из хулиганских побуждений.

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

Препарируем nginx.conf

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

Проверить last-modified

Когда передача заголовка клиенту настроена, не повредит проверка last modified на корректность. Проверить Last-Modified на собственном или стороннем сайта можно через онлайн сервисы.

Или сделать свою проверку на корректную обработку заголовка Last-Modified:

Проксирование запросов

Nginx умеет проксировать запросы на другие сервера, понадобиться это для масштабирования и защиты back-end серверов. В качестве примера, запустим back-end сервер apache в контейнере:

Размести корневой каталог web-сервера на выделенном разделе

Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:

/dev/sda5 /nginx ext4 defaults,nosuid,noexec,nodev 1 2

Разреши коннекты только к своему домену

Взломщики могут использовать ботов для сканирования подсетей и поиска уязвимых Web-серверов. Обычно боты просто перебирают диапазоны IP-адресов в поисках открытых 80 портов и посылают запрос HEAD для получения информации о веб-сервере (или главной странице). Ты можешь легко предотвратить такой скан, запретив обращение к серверу по IP-адресу (добавить в подсекцию location):

# vi /etc/nginx/nginx.conf

Удали все неиспользуемые тобой nginx-модули

Некоторая часть модулей nginx подключается к Web-серверу прямо во время компиляции, и любой из них таит в себе потенциальную опасность. Возможно, в будущем в одном из них будет найдена уязвимость, и твой сервер окажется под угрозой. Отключив ненужные модули, ты сможешь значительно снизить риск возникновения такой ситуации.

Выполни сборку с помощью следующих команд:

Установи правильные значения системных переменных

Открой файл /etc/sysctl.conf и помести в него следующие строки:

# vi /etc/sysctl.conf

Установка

Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.

Установка nginx

Установка сервера nginx может быть выполнена как непосредственно на машину, так и в виде docker контейнера. У каждого метода есть свои преимущества и недостатки, описание которых выходит за рамки данной статьи. Мы посмотрим оба варианта.

Сейчас ищут техподдержку:  МТС и ЯД: ошибочный платеж. В поисках здравого смысла / Хабр

Начнем с непосредственной установки на сервер:

apt install nginx

Будет задан вопрос: Do you want to continue? [Y/n]Нажимаем Y, затем ENTER.

Дожидаемся окончания процесса установки.

Разрешим автозапуск сервера:

systemctl enable nginx

Проверяем результат:

systemctl is-enabled nginx

Если в ответ получили «enabled», значит nginx успешно добавлен в автозагрузку.

Установка и настройка php-fpm

Для работы веб приложений, написанных на языке PHP необходимо установить php-fpm в качестве бэкэнда:

apt install php-fpm php-mysql

Будет задан вопрос: Do you want to continue? [Y/n]Нажимаем Y, затем ENTER.

Шаг 1. отключить любые нежелательные модули nginx

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

Для этого используйте опцию configure во время установки. В приведенном ниже примере мы отключаем модуль autoindex, который генерирует автоматические списки каталогов, а затем перекомпилируем nginx.

Шаг 10. регулярно обновляйте ваш сервер

Как и с любым другим программным обеспечением, мы рекомендуем вам всегда обновлять сервер nginx до последней стабильной версии. Новые обновления часто содержат исправления для уязвимостей, выявленных в предыдущих версиях, таких как уязвимость обхода каталога (CVE-2009-3898), существовавшая в версиях nginx до 0.7.63 и 0.8.x до 0.8.17.

Шаг 11. проверьте свою конфигурацию с gixy

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

Вы можете найти Gixy здесь.

Шаг 12. вам не нужно делать это вручную

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

Вы можете найти этот инструмент здесь.

Шаг 3. контроль ресурсов и ограничения

Чтобы предотвратить потенциальные DoS-атаки на nginx, вы можете установить ограничения на размер буфера для всех клиентов. Вы можете сделать это в файле конфигурации nginx, используя следующие директивы:

  • client_body_buffer_size – используйте эту директиву, чтобы указать размер буфера тела запроса клиента. Значение по умолчанию — 8 КБ или 16 КБ, но рекомендуется установить его равным 1 КБ: client_body_buffer_size 1k.
  • client_header_buffer_size – используйте эту директиву, чтобы указать размер буфера заголовка для заголовка запроса клиента. Размер буфера 1k подходит для большинства запросов.
  • client_max_body_size – используйте эту директиву, чтобы указать максимально допустимый размер тела для клиентского запроса. Директивы 1k должно быть достаточно, но вам нужно увеличить ее, если вы получаете загрузку файлов методом POST.
  • large_client_header_buffers – используйте эту директиву, чтобы указать максимальное количество и размер буферов, которые будут использоваться для чтения больших заголовков клиентских запросов. Директива large_client_header_buffers 2 1k устанавливает максимальное количество буферов в 2, каждый с максимальным размером 1k. Эта директива будет принимать URI данных размером 2 КБ.

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

Шаг 5. установите modsecurity для вашего веб-сервера nginx

ModSecurity — это модуль с открытым исходным кодом, который работает как брандмауэр веб-приложения (WAF). Его функции включают в себя фильтрацию, маскировку идентификатора сервера и предотвращение атак с нулевым байтом. Модуль также позволяет выполнять мониторинг трафика в режиме реального времени.

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

Шаг 6. установка и настройка access и error logs nginx

Журналы access и error logs nginx включены по умолчанию и расположены соответственно в logs/error.log и logs/access.log. Если вы хотите изменить местоположение, вы можете использовать директиву error_log в файле конфигурации nginx. Вы также можете использовать эту директиву, чтобы указать журналы, которые будут записываться в соответствии с их уровнем безопасности.

Например, уровень crit заставит nginx регистрировать критические проблемы и все проблемы, которые имеют более высокий уровень, чем уровень crit. Чтобы установить уровень crit, установите директиву error_log следующим образом:

error_log logs/error.log crit;

Вы можете найти полный список уровней error_log в официальной документации nginx.

Вы также можете изменить директиву access_log в файле конфигурации nginx, указав расположение не по умолчанию для журналов доступа. Наконец, вы можете использовать директиву log_format для настройки формата записываемых сообщений, как описано в документации по nginx.

Шаг 7. мониторинг журналов access и error

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

Шаг 9. настройте ssl и cipher suites

Конфигурация nginx по умолчанию позволяет использовать небезопасные старые версии протокола TLS (согласно официальной документации: ssl_protocols TLSv1 TLSv1.1 TLSv1.2). Это может привести к таким атакам, как атака BEAST. Поэтому мы рекомендуем вам не использовать старые протоколы TLS и изменять конфигурацию для поддержки только новых, безопасных версий TLS.

Для этого добавьте следующую директиву в раздел server файла конфигурации nginx:

ssl_protocols TLSv1.2 TLSv1.3;

Кроме того, вы должны указать наборы шифров, чтобы убедиться, что уязвимые наборы не поддерживаются. Чтобы выбрать лучшие комплекты шифров, прочитайте нашу статью об усилении шифрования TLS и добавьте директиву ssl_ciphers в раздел сервера для выбора шифров (как предлагается в статье об усилении шифрования). Мы также рекомендуем добавить следующую директиву в раздел сервера:

ssl_prefer_server_ciphers on;

Эта директива позволит принять решение о том, какие шифры использовать, на стороне сервера, а не на стороне клиента.

Client intended to send too large body

Решается с помощью увеличения параметра client_max_body_size

client_max_body_size 200m;

Выводы

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

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

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (Пока оценок нет)
Загрузка...

Оставьте комментарий

Adblock
detector