Основываясь на замечательных вещах, о которых вы слышали Nginx, возможно, вы решили попробовать. Возможно, он вам настолько понравился, что вы подумываете о замене ваших установок Apache на Nginx после ознакомления с некоторыми статьями по этой теме, которые мы опубликовали на этом сайте.
Если да, то я уверен, что вы с распростертыми объятиями приветствуете это руководство, поскольку мы собираемся охватить 12 советов по повышению безопасности вашего Nginx серверов (от поддержания Nginx в актуальном состоянии до использования TLS и перенаправления HTTP на HTTPS), и вы заметите, что некоторые из них очень похожи на то, что вы делали бы с Apache.
Не пропустите:
13 советов по безопасности и усилению защиты веб-сервера Apache
25 хитростей Apache Htaccess для защиты веб-сервера Apache
В этом руководстве мы будем использовать следующую среду:
Имея это в виду, давайте начнем.
На момент написания статьи последние версии 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
Чтобы явно удалить модули из Nginx при установке из исходного кода, выполните следующие действия:
# ./configure --without-module1 --without-module2 --without-module3.
Например:
# ./configure --without-http_dav_module --withouthttp_spdy_module
Как вы, вероятно, догадались, удаление модулей из предыдущей установки Nginx из источника требует повторной компиляции.
Слово предостережения: Директивы конфигурации предоставляются модулями. Убедитесь, что вы не отключили модуль, содержащий директиву, которая понадобится вам в будущем! Вы должны проверить документы nginx список директив, доступных в каждом модуле, перед принятием решения об отключении модулей.
В server_tokens
Директива указывает Nginx отображать свою текущую версию на страницах ошибок. Это нежелательно, поскольку вы не хотите делиться этой информацией с миром, чтобы предотвратить атаки на ваш веб-сервер, вызванные известными уязвимостями в этой конкретной версии.
Чтобы отключить server_tokens
директива, отключите ее внутри серверного блока:
сервер {слушайте 192.168.0.25:80; server_tokens выключен; имя_сервера tecmintlovesnginx.com www.tecmintlovesnginx.com; access_log /var/www/logs/tecmintlovesnginx.access.log; error_log /var/www/logs/tecmintlovesnginx.error.log ошибка; root /var/www/tecmintlovesnginx.com/public_html; index index.html index.htm; }
Перезапустите nginx и проверьте изменения:
Пользовательский агент HTTP - это программное обеспечение, которое используется для согласования содержимого с веб-сервером. Сюда также входят вредоносные боты и сканеры, которые могут в конечном итоге повлиять на производительность вашего веб-сервера, тратя впустую системные ресурсы.
Чтобы упростить ведение списка нежелательных пользовательских агентов, создайте файл (/etc/nginx/blockuseragents.rules
например) со следующим содержанием:
карта $ http_user_agent $ blockedagent {по умолчанию 0; ~ * вредоносный 1; ~ * бот 1; ~ * бэкдор 1; ~ * поисковый робот 1; ~ * бандит 1; }
Затем поместите следующую строку перед определением серверного блока:
включить /etc/nginx/blockuseragents.rules;
И оператор if для возврата ответа 403, если строка пользовательского агента находится в черном списке, определенном выше:
Перезапустите nginx, и все пользовательские агенты, строка которых соответствует указанной выше, будут заблокированы от доступа к вашему веб-серверу. Заменять 192.168.0.25 с IP-адресом вашего сервера и вы можете выбрать другую строку для --пользователь-агент
переключатель wget:
# wget http://192.168.0.25/index.html. # wget --user-agent "Я бандит, ха-ха" http://192.168.0.25/index.html
Методы HTTP, также известные как глаголы, указывают на желаемое действие, которое должно быть выполнено с ресурсом, обслуживаемым Nginx. Для обычных веб-сайтов и приложений разрешите только ПОЛУЧАТЬ, СООБЩЕНИЕ, и ГОЛОВА и отключить все остальные.
Для этого поместите следующие строки в серверный блок. А 444 HTTP-ответ означает пустой ответ и часто используется в Nginx для обмана атак вредоносных программ:
если ($ request_method! ~ ^ (GET | HEAD | POST) $) {return 444; }
Чтобы проверить, используйте завиток послать УДАЛИТЬ запросите и сравните вывод с тем, когда вы отправляете обычный ПОЛУЧАТЬ:
# curl -X УДАЛИТЬ http://192.168.0.25/index.html. # curl -X POST http://192.168.0.25/index.html
Чтобы предотвратить атаки переполнения буфера на ваш веб-сервер Nginx, установите следующие директивы в отдельном файле (создайте новый файл с именем /etc/nginx/conf.d/buffer.conf
, Например):
client_body_buffer_size 1к; client_header_buffer_size 1k; client_max_body_size 1к; large_client_header_buffers 2 1к;
Указанные выше директивы гарантируют, что запросы к вашему веб-серверу не вызовут переполнения буфера в вашей системе. Еще раз, обратитесь к документации для получения дополнительной информации о том, что каждый из них делает.
Затем добавьте директиву include в файл конфигурации:
включить /etc/nginx/conf.d/*.conf;
Чтобы ограничить соединения по IP, используйте limit_conn_zone
(в контексте http или, по крайней мере, вне блока сервера) и limit_conn (в контексте http, блока сервера или контекста местоположения).
Однако имейте в виду, что подсчитываются не все соединения, а только те, у которых есть запрос, обработанный сервером, и весь его заголовок запроса был прочитан.
Например, давайте установим максимальное количество подключений к 1
(да, это преувеличение, но в данном случае он отлично справится со своей задачей) в зоне с именем addr (вы можете установить любое имя по своему усмотрению):
limit_conn_zone $ binary_remote_addr zone = адрес: 5м; limit_conn addr 1;
Простой тест с Тест Apache (выполнение загрузки Nginx) куда 10
все соединения сделаны с 2
одновременные запросы помогут нам продемонстрировать нашу точку зрения:
# ab -n 10 -c 2 http://192.168.0.25/index.html.
См. Следующий совет для получения дополнительных сведений.
После того, как вы выполнили тест, описанный в предыдущем совете, проверьте журнал ошибок, определенный для серверного блока:
Вы можете использовать grep для фильтрации журналов на предмет неудачных запросов к добавлятьr зона, определенная в СОВЕТ № 7:
# grep addr /var/www/logs/tecmintlovesnginx.error.log --color = auto.
Точно так же вы можете фильтровать журнал доступа по интересующей информации, например:
И примите соответствующие меры, если вы обнаружите необычную или нежелательную активность.
Горячие ссылки на изображения происходят, когда человек отображает на другом сайте изображение, размещенное на вашем. Это приводит к увеличению использования полосы пропускания (за которую вы платите), в то время как другой человек с радостью отображает изображение, как если бы оно было его собственностью. Другими словами, это двойная потеря для вас.
Например, предположим, что у вас есть подкаталог с именем img
внутри вашего серверного блока, где вы храните все изображения, используемые на этом виртуальном хосте. Чтобы другие сайты не могли использовать ваши изображения, вам нужно будет вставить следующий блок местоположения в определение вашего виртуального хоста:
местоположение / img / {valid_referers не заблокировано 192.168.0.25; если ($ invalid_referer) {возврат 403; } }
Затем измените index.html
файл на каждом виртуальном хосте следующим образом:
192.168.0.26 |
192.168.0.25 |
Nginx - это сила!![]() |
Tecmint любит Nginx!![]() |
Теперь перейдите к каждому сайту, и, как видите, изображение правильно отображается в 192.168.0.25 но заменяется 403 ответ в 192.168.0.26:
Обратите внимание, что этот совет зависит от удаленного браузера, отправляющего поле Referer.
По возможности делайте все возможное, чтобы избежать SSL в любой из его версий и использовать TLS вместо. Следующие ssl_protocols
должен быть помещен в сервер или контекст http в вашем файле виртуального хоста или представляет собой отдельный файл с помощью директивы include (некоторые люди используют файл с именем ssl.conf
, но это полностью зависит от вас):
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Например:
Во-первых, сгенерируйте ключ и сертификат. Не стесняйтесь использовать другой тип шифрования, если хотите:
# 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, в новый блок:
сервер {слушайте 192.168.0.25:443 ssl; server_tokens выключен; имя_сервера 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.
Добавьте следующую строку в первый серверный блок:
возврат 301 https://$server_name$request_uri;
Приведенная выше директива вернет 301 (Перемещен навсегда) ответ, который используется для постоянного перенаправления URL-адресов всякий раз, когда делается запрос на порт 80 вашего виртуального хоста и перенаправит запрос на серверный блок, который мы добавили в предыдущем Подсказка.
Изображение ниже показывает перенаправление и подтверждает тот факт, что мы используем TLS 1.2 и AES-256 для шифрования:
В этой статье мы поделились несколькими советами по защите вашего веб-сервера Nginx. Мы хотели бы услышать, что вы думаете, и, если у вас есть другие советы, которыми вы хотели бы поделиться остальная часть сообщества, не стесняйтесь сообщить нам, отправив нам сообщение, используя форму комментариев ниже.