Поиск по сайту:

Полное руководство по защите, усилению защиты и повышению производительности веб-сервера Nginx

Учитывая то замечательное, что вы слышали о Nginx, возможно, вы решили попробовать. Возможно, вам он настолько понравился, что вы подумываете о замене ваших установок Apache на Nginx после прочтения некоторых статей по этой теме, которые мы опубликовали на этом сайте.

Если да, то я уверен, что вы примете это руководство с распростертыми объятиями, поскольку мы собираемся рассмотреть 12 советов по повышению безопасности ваших серверов Nginx (от обновления Nginx до используя TLS и перенаправляя HTTP на HTTPS), и вы заметите, что некоторые из них очень похожи на то, что вы бы сделали с Apache.

Не пропустите:

13 советов по безопасности и усилению безопасности веб-сервера Apache

25 приемов Apache Htaccess для защиты веб-сервера Apache

Среда тестирования Nginx

В этом руководстве мы будем использовать следующую среду:

  1. Debian GNU/Linux 8.1 (Джесси).

  2. IP-адрес: 192.168.0.25 (tecmintlovesnginx.com) и 192.168.0.26 (nginxmeanspower.com), как описано в виртуальном IP-интерфейсе. раздел хостов на

    1. «Как настроить виртуальные хосты на основе имени и IP (серверные блоки) с помощью Nginx»
  3. Версия Nginx: nginx/1.6.2.
  4. Для вашего удобства вот окончательный файл конфигурации (ссылка Pastebin).

Имея это в виду, давайте начнем.

СОВЕТ №1: Поддерживайте актуальность Nginx

На момент написания этой статьи последними версиями Nginx в репозиториях CentOS (в EPEL) и Debian являются 1.6.3 и 1.6.2-5 . соответственно.

Не пропустите: Установите последнюю стабильную версию Nginx из репозиториев и исходных кодов.

Хотя устанавливать программное обеспечение из репозиториев проще, чем компилировать программу из исходного кода, последний вариант имеет два преимущества: 1) он позволяет встраивать в Nginx дополнительные модули (например, mod_security) и 2) он всегда предоставляет более новую версию. чем репозитории (1.9.9 на сегодняшний день). Примечания к выпуску всегда доступны на веб-сайте Nginx.

Не пропустите:

Защитите Apache от грубой силы и DDoS-атак с помощью Mod_Security и Mod_Evasive

СОВЕТ №2: удалите ненужные модули в Nginx

Чтобы явно удалить модули из Nginx при установке из исходного кода, выполните:

./configure --without-module1 --without-module2 --without-module3

Например:

./configure  --without-http_dav_module --withouthttp_spdy_module

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

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

СОВЕТ №3: Отключите директиву server_tokens в Nginx

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

Чтобы отключить директиву server_tokens, установите ее значение off внутри блока сервера:

server {
    listen       192.168.0.25:80;
    server_tokens        off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    access_log  /var/www/logs/tecmintlovesnginx.access.log;
    error_log  /var/www/logs/tecmintlovesnginx.error.log error;
        root   /var/www/tecmintlovesnginx.com/public_html;
        index  index.html index.htm;
}

Перезапустите nginx и проверьте изменения:

СОВЕТ № 4: Запретите HTTP-агенты пользователя в Nginx

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

Чтобы упростить ведение списка нежелательных пользовательских агентов, создайте файл (например, /etc/nginx/blockuseragents.rules) со следующим содержимым:

map $http_user_agent $blockedagent {
        default         0;
        ~*malicious     1;
        ~*bot           1;
        ~*backdoor      1;
        ~*crawler       1;
        ~*bandit        1;
}

Затем поместите следующую строку перед определением блока сервера:

include /etc/nginx/blockuseragents.rules;

И оператор if для возврата ответа 403, если строка пользовательского агента находится в черном списке, определенном выше:

Перезапустите nginx, и всем пользовательским агентам, чья строка соответствует указанной выше, будет заблокирован доступ к вашему веб-серверу. Замените 192.168.0.25 на IP-адрес вашего сервера и смело выбирайте другую строку для переключателя --user-agent wget:

wget http://192.168.0.25/index.html
wget --user-agent "I am a bandit haha" http://192.168.0.25/index.html

СОВЕТ №5: отключите нежелательные методы HTTP в Nginx

Методы HTTP, также известные как глаголы, указывают желаемое действие, которое необходимо выполнить над ресурсом, обслуживаемым Nginx. Для обычных веб-сайтов и приложений следует разрешить только GET, POST и HEAD и отключить все остальные.

Для этого поместите следующие строки внутри блока сервера. HTTP-ответ 444 означает пустой ответ и часто используется в Nginx для обмана атак вредоносных программ:

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

Для проверки используйте curl, чтобы отправить запрос DELETE, и сравните результат с обычным запросом GET:

curl -X DELETE http://192.168.0.25/index.html
curl -X POST http://192.168.0.25/index.html

СОВЕТ №6: Установите ограничения размера буфера в Nginx

Чтобы предотвратить атаки переполнения буфера на ваш веб-сервер Nginx, установите следующие директивы в отдельном файле (например, создайте новый файл с именем /etc/nginx/conf.d/buffer.conf):

client_body_buffer_size  1k;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;

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

Затем добавьте директиву include в файл конфигурации:

include /etc/nginx/conf.d/*.conf;

СОВЕТ №7: Ограничьте количество подключений по IP в Nginx

Чтобы ограничить соединения по IP, используйте директивы limit_conn_zone (в контексте http или, по крайней мере, вне блока сервера) и limit_conn (в контексте http, блока сервера или контекста местоположения).

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

Например, давайте установим максимальное количество подключений равным 1 (да, это преувеличение, но в данном случае оно отлично справится со своей задачей) в зоне с именем addr (вы можете установить любое значение имя по вашему желанию):

limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 1;

Простой тест с использованием Apache Benchmark (выполнение загрузки Nginx), в котором всего 10 соединений выполняется с 2 одновременными запросами, поможет нам продемонстрировать нашу точку зрения:

ab -n 10 -c 2 http://192.168.0.25/index.html

Дополнительную информацию смотрите в следующем совете.

СОВЕТ № 8: Настройка журналов монитора для Nginx

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

Вы можете использовать grep для фильтрации журналов неудачных запросов, отправленных в зону addr, определенную в СОВЕТ № 7:

grep addr /var/www/logs/tecmintlovesnginx.error.log --color=auto

Аналогичным образом вы можете отфильтровать журнал доступа на предмет интересующей информации, например:

  1. IP-адрес клиента
  2. Тип браузера
  3. Тип HTTP-запроса
  4. Запрошенный ресурс
  5. Блокировка сервера, отвечающая на запрос (полезно, если несколько виртуальных хостов регистрируются в одном файле).

И примите соответствующие меры, если обнаружите какую-либо необычную или нежелательную активность.

СОВЕТ №9: предотвратите хотлинкинг изображений в Nginx

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

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

location /img/ {
  valid_referers none blocked 192.168.0.25;
   if ($invalid_referer) {
     return   403;
   }
}

Затем измените файл index.html на каждом виртуальном хосте следующим образом:

192.168.0.26

192.168.0.25

<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8″>
<title>Nginx means power</title>
</head>
<body>
<h1>Nginx means power!</h1>
<img src=”http://192.168.0.25/img/nginx.png” />
</body>
</html>



<head>

Tecmint любит Nginx

<body>

Tecmint любит Nginx!




Теперь перейдите на каждый сайт, и, как вы можете видеть, изображение правильно отображается в 192.168.0.25, но заменяется ответом 403 в 192.168.0.26 . :

Обратите внимание, что этот совет зависит от удаленного браузера, отправляющего поле Referer.

СОВЕТ № 10: отключите SSL и включайте только TLS в Nginx

По возможности делайте все возможное, чтобы избежать использования SSL в любой из его версий и вместо этого использовать TLS. Следующий ssl_protocols должен быть помещен в контекст сервера или http в файле вашего виртуального хоста или представляет собой отдельный файл с помощью директивы include (некоторые люди используют файл с именем ssl.conf) , но это полностью зависит от вас):

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;

Например:

СОВЕТ № 11: Создайте сертификаты в Nginx

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

openssl genrsa -aes256 -out tecmintlovesnginx.key 1024
openssl req -new -key tecmintlovesnginx.key -out tecmintlovesnginx.csr
cp tecmintlovesnginx.key tecmintlovesnginx.key.org
openssl rsa -in tecmintlovesnginx.key.org -out tecmintlovesnginx.key
openssl x509 -req -days 365 -in tecmintlovesnginx.csr -signkey tecmintlovesnginx.key -out tecmintlovesnginx.crt

Затем добавьте следующие строки в отдельный блок сервера, готовясь к следующему совету (перенаправление http --> https), а также переместите директивы, связанные с SSL, в новый блок:

server {
    listen 192.168.0.25:443 ssl;
    server_tokens off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    root   /var/www/tecmintlovesnginx.com/public_html;
    ssl_certificate /etc/nginx/sites-enabled/certs/tecmintlovesnginx.crt;
    ssl_certificate_key /etc/nginx/sites-enabled/certs/tecmintlovesnginx.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
}

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

СОВЕТ № 12. Перенаправление HTTP-трафика на HTTPS в Nginx

Добавьте следующую строку в первый блок сервера:

return 301 https://$server_name$request_uri;

Приведенная выше директива вернет ответ 301 (перемещено навсегда), который используется для постоянного перенаправления URL-адреса всякий раз, когда делается запрос на порт 80 вашего виртуального хоста, и перенаправляет запрос на блокируемый нами сервер. добавлено в предыдущем совете.

На изображении ниже показано перенаправление и подтверждается тот факт, что мы используем TLS 1.2 и AES-256 для шифрования:

Краткое содержание

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