Безопасность nginx: как улучшить конфигурацию вашего сервера

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

sudo nano /etc/php/7.4/fpm/

Найдите ключевое слово expose_php и установите его значение в Off:

expose_php = off

Если вы используете PHP как FPM, то вам нужно будет перезагрузить PHP-FPM:

sudo service php-fpm reload

После перезагрузки заголовок ответа X-Powered-By: PHP/7.4 должен отсутствовать

Если не помогло, то прописываем в следующее

proxy_hide_header X-Powered-By; # или #more_clear_headers 'X-Powered-By';

Если есть вопросы, то пишем в комментариях.

Также можете помочь проекту, заранее всем СПАСИБО!!!

Пожертвовать

Как это будет работать?

Допустим, у нас есть несколько доменов , , Первые два будут обрабатываться Apache, последний только Nginx. Все запросы будут поступать к Nginx, который работает на порту 80, если это запрос к одному из доменов Apache и он требует работы PHP, тогда он будет передан веб-серверу Apache, который работает на порту 8080.

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

Временные метки для видео:

• 0:00 – Обратный отсчет

• 3:10 – С 1 сентября! Тема эфира: Как установить NGINX для быстрого сайта

• 5:55 – Бесплатный автоинсталлер (Auto installer) NGINX -autoinstall, подробнее 7:50

• 10:08 – Устанавливайте наше расширение для Chrome, замеряйте скорость загрузки сайта в один клик

• 10:40 – Пакет наших наработок от – готовые скрипты по оптимизации из прошлых эфиров Проверить скорость ответа сервера можно тут

• 10:55 – Как запустить автоинсталлер на сервере через командную строку. Выбираем нужные модули NGINX

• 14:57 – Разбираем подключаемые модули: Headers More – управление заголовками, GeoIP – распознавание локации посетителя по IP-адресу

• 15:16 – Fancy Index – создание индекс страницы. ngx_cache_purge – очистка кэша с помощью NGINX. ngx_http_lua_module — поддержка синтаксиса lua script

• 16:31 – WebDav – протокол для поддержки на сервере облачной файловой системы

• 17:48 – testcookie – для работы с куки. HTTP/3 от CloudFlare

• 18:50 – Про 0RTT и TLS patch

• 19:11 – О предстоящих эфирах, будем ли разбирать кейсы с WordPress

• 20:00 – О сложности универсального решения для сайтов на WordPress

• 20:38 – Говорим о WebAssist

• 21:20 – Вопрос из зала: «Какие дадите рекомендации с nginx_cookie_flag_module?»

• 21:50 – Разбираем вопрос от зрителя: «Chrome ругается на счетчики и т.д, cross-site resources at URL was set without ‘SameSite’ attribute»

• 22:42 – Предложение из зала: «Сделайте сюжет по оптимизации БД SQL по оперативке 2-4-6-8. Пару примеров конфигов на VPSах»

• 25:00 – Вопрос из зала о предварительной загрузке: «И сюжет о новомодных атрибутах rel (Preload, prefetch и.д)»

• 26:12 — Подробнее о: dns-prefetch — 26:20, preconnect — 26:32, prefetch — 26:45, preload — 26:53

• 28:20 – Краткие итоги

Измеряйте скорость сайта каждый день с нашим автоматическим решением проверки скорости сайта. Узнайте подробности в чате с нами.

Что еще почитать про NGINX:

• Официальный сайт
• Документация
• Википедия про NGINX
• Руководство для начинающих
• Nginx: скачать
• Веб-сервер и почтовый прокси-сервер — Хабр
• Сайт Игоря Сысоева, который создал Nginx
• nginx — Docker Hub
• Оптимальная настройка Nginx от Ruhighload
• Как установить SSL-сертификат на Nginx
• Apache vs. Nginx
• Мастер-класс по настройке Nginx
• Что значит 502 bad gateway Nginx

Совместное функционирование Apache + Nginx

Рассмотренные характеристики веб-серверов обуславливают выбор в пользу того или иного для каждого конкретного проекта. В некоторых случаях целесообразно использовать связку Apache + Nginx. Последний разворачивается перед Apache для выполнения функций реверс-прокси. За обработку всех входящих запросов отвечает Nginx, способный успешно справляться с их большим количеством. Его основная задача в данной конфигурации – обработка статического контента. Если требуется выполнение, например, PHP-сценариев, запрос поступает на Apache, где происходит его обработка. Полученный результат передается вначале Nginx, а затем – конечному пользователю.

Таким образом, Nginx сортирует запросы на статические и динамические. С первыми он успешно справляется сам, вторые – адресует Apache. Этот подход обуславливает частичное снижение нагрузки на последний.

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

Многие сервисы , например виртуальный хостинг, так же используют связку Apache + Nginx. Apache отвечает за работу с динамическим контентом, а Nginx за статический контент. Поскольку веб сервер Nginx находится впереди, проксируя весь трафик на Apache, с его помощью мы фильтруем часть “вредного трафика” во время DDOS атаки и попыток взлома сайтов.

ПОДОБРАТЬ

ХОСТИНГот 29 грн./мес.

— 3000 мб диск — почта без ограничений — авто установка CMS — бесплатный домен

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

Серверные блоки

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

server { listen 80 default_server; listen [::]:80 default_server; server_name ; root /var/www/; index ; try_files $uri /; }

Директива server_name позволяет размещать несколько доменов на одном IP-адресе (виртуальные хосты). Выбор домена осуществляется на основании информации в заголовке полученного запроса.

Директива listen задает Nginx имя или IP-адрес узла и TCP-порт, который он должен прослушивать для HTTP-соединений. Аргумент default_server означает, что этот виртуальный хост будет отвечать на все запросы на порт 80, в которых в явном виде не будет указан другой виртуальный хост. Вторая такая директива устанавливает аналогичное поведение для IPv6-соединений.

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

запросов к и :

server_name ;

2.В директиве server_name можно использовать маски. Например, * и указывают серверу обрабатывать запросы на все поддомены :

server_name *; server_name ;

запросов ко всем доменным именам, начинающимся с example.:

server_name example.*;

Nginx разрешает указывать имена сервера, не соответствующие правилам доменных имен. Для ответа на запросы используется имя из заголовка HTTP вне зависимости от того, является ли оно допустимым доменным именем.

Это полезно, если ваш сервер работает в локальной сети или вы точно знаете все клиенты, которые будут осуществлять запросы, например, front-end прокси-серверы, у которых записи в /etc/hosts настроены на IP-адрес Nginx.

Заключение

Теперь вы знаете, как настроить Apache в качестве обратного прокси-сервера для одного или нескольких внутренних серверов. mod_proxy можно эффективно использоваться для того, чтобы настраивать обратный прокси для серверов с приложениями, написанных на различных языках программирования и технологиях, таких как Python, Django или Ruby и Ruby on Rails. Также mod_proxy можно использовать для балансировки нагрузки между несколькими бэкенд-серверами для сайтов с большой нагрузкой, чтобы обеспечить высокую доступность таких ресурсов.

mod_proxy и mod_proxy_http самая популярная комбинация модулей, однако есть несколько других, которые поддерживают другие сетевые протоколы. Хотя в этом руководстве они не использовались, их тоже можно выделить отдельным списком:

• mod_proxy_ftp для FTP;
• mod_proxy_connect для SSL-туннеля;
• mod_proxy_ajp для протокола AJP (Apache JServ Protocol);
• mod_proxy_wstunnel для веб-сокетов.

Узнать более подробно о них вы можете в официальной документации mod_proxy Apache: _

Шаг Настройте 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;

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