Полный тюнинг движка: Делаем из nginx непробиваемый Web-сервер – «Хакер»
Содержание статьи
Выделенный Web-сервер на основе nginx – отличный способ повышения производительности Web-сайтов.
В скорости обработки статического контента ему просто нет равных: он легко выдерживает несколько тысяч одновременных соединений и может быть легко оптимизирован и подогнан под любую конфигурацию.
Однако? выступая в качестве фронт-энда для Apache, nginx оказывается наиболее уязвимым местом всей Web-инфраструктуры, поэтому безопасности nginx необходимо уделить особое внимание.
Эта статья – своего рода ликбез, или, если хочешь, резюме всех техник повышения безопасности nginx. В ней не будет теории, описания основ настройки Web-сервера и прочей воды. Вместо этого ты получишь исчерпывающий практический материал, описывающий все основные шаги, которые необходимо проделать для того, чтобы получить по-настоящему защищенный Web-сервер.
Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.
Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:
static char ngx_http_server_string[] = “Server: nginx” CRLF;
static char ngx_http_server_full_string[] = “Server: ” NGINX_VER CRLF;
Замени их на что-то вроде этого:
static char ngx_http_server_string[] = “Server: ][ Web Server” CRLF;
static char ngx_http_server_full_string[] = “Server: ][ Web Server” CRLF;
Некоторая часть модулей nginx подключается к Web-серверу прямо во время компиляции, и любой из них таит в себе потенциальную опасность. Возможно, в будущем в одном из них будет найдена уязвимость, и твой сервер окажется под угрозой. Отключив ненужные модули, ты сможешь значительно снизить риск возникновения такой ситуации.
Выполни сборку с помощью следующих команд:
# ./configure –without-http_autoindex_module –without-http_ssi_module
# make
# make install
Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом ‘—help’.
После установки nginx следует настроить. На страницах журнала уже был материал, описывающий этот процесс, мы же будем придерживаться темы статьи и поговорим о способах повышения безопасности сервера.
Добавь в файл nginx.conf строку “server_tokens off”. Это заставит nginx скрывать информацию о типе и версии Web-сервера на страницах, генерируемых в ответ на ошибочный запрос клиента.
Добавь в секцию server следующие строки:
# vi /etc/nginx/nginx.conf
# Максимальный размер буфера для хранения тела запроса клиента client_body_buffer_size 1K; # Максимальный размер буфера для хранения заголовков запроса клиента client_header_buffer_size 1k; # Максимальный размер тела запроса клиента, прописанный в поле Content-Length заголовка. Если сервер должен поддерживать загрузку файлов, это значение необходимо увеличить client_max_body_size 1k; # Количество и размер буферов для чтения большого заголовка запроса клиента
large_client_header_buffers 2 1k;
Обрати внимание на директиву large_client_header_buffers. По умолчанию, для хранения строки URI nginx выделяет четыре буфера, размер каждого из которых равен размеру страницы памяти (для x86 это 4 Кб).
Буферы освобождаются каждый раз, когда по окончанию обработки запроса соединение переходит в состояние keep-alive.
Два буфера по 1 Кб могут хранить URI длиной только 2 Кб, что позволяет бороться с ботами и DoS-атаками.
Для повышения производительности добавь следующие строки:
# vi /etc/nginx/nginx.conf
# Таймаут при чтении тела запроса клиента client_body_timeout 10; # Таймаут при чтении заголовка запроса клиента client_header_timeout 10; # Таймаут, по истечению которого keep-alive соединение с клиентом не будет закрыто со стороны сервера keepalive_timeout 5 5; # Таймаут при передаче ответа клиенту
send_timeout 10;
Для защиты Web-сервера от перегрузки и попыток осуществить DoS-атаку добавь в конфиг следующие строки:
# vi /etc/nginx/nginx.conf
# Описываем зону (slimits), в которой будут храниться состояния сессий. Зона размером 1 Мб может хранить около 32000 состояний, мы устанавливаем ее размер равным 5 Мб limit_zone slimits $binary_remote_addr 5m; # Задаем максимальное количество одновременных соединений для одной сессии. По сути, это число задает максимальное количество соединений с одного IP
limit_conn slimits 5;
Первая директива должна находиться в секции HTTP, вторая – в секции location. Когда количество соединений выйдет за пределы лимитов, клиент получит сообщение «Service unavailable» с кодом 503.
Взломщики могут использовать ботов для сканирования подсетей и поиска уязвимых Web-серверов. Обычно боты просто перебирают диапазоны IP-адресов в поисках открытых 80 портов и посылают запрос HEAD для получения информации о веб-сервере (или главной странице). Ты можешь легко предотвратить такой скан, запретив обращение к серверу по IP-адресу (добавить в подсекцию location):
# vi /etc/nginx/nginx.conf
if ($host !~ ^(host.com|www.host.com)$ ) { return 444;
}
Некоторые боты используют различные методы обращения к серверу для попытки определения его типа и/или проникновения, однако в документе RFC 2616 четко сказано, что Web-сервер не обязан реализовывать их все, и неподдерживаемые методы могут просто не обрабатываться.
Сегодня используемыми остаются только методы GET (запрос документа), HEAD (запрос заголовков сервера) и POST (запрос на публикацию документа), поэтому все остальные можно безболезненно отключить с помощью помещения следующих строк в секцию server конфигурационного файла:
# vi /etc/nginx/nginx.conf
if ($request_method !~ ^(GET|HEAD|POST)$ ) { return 444;
}
Другой способ блокирования ботов, сканеров и прочей нечисти основан на определении типа клиента (user-agent). Он не слишком эффективен, потому как большинство ботов косят под вполне легитимные браузеры, но в ряде случаев остается полезным:
# vi /etc/nginx/nginx.conf
# Блокируем менеджеры загрузки if ($http_user_agent ~* LWP::Simple|BBBike|wget) { return 403; } # Блокируем некоторые типы ботов if ($http_user_agent ~* msnbot|scrapbot) { return 403;
}
Если твой сайт публикует Web-логи в общедоступном виде, ты легко можешь стать жертвой Referrer-спама (когда спам-боты обращаются к твоему серверу, указывая в заголовке referrer – адрес рекламируемого сайта).
Такой вид спама может легко испортить SEO-рейтинги интернет-страницы, поэтому его необходимо блокировать в обязательном порядке.
Один из способов сделать это – занести наиболее частые слова, встречающиеся в адресах рекламируемых сайтов, в черный список.
# vi /etc/nginx/nginx.conf
# Секция server if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) ) { return 403;
}
Хотлинк – это включение в страницу изображения (или иного контента) с другого сайта. По сути, это воровство, потому как изображение, на которое ты потратил не один час своего свободного времени, не только свободно используется другими, но и создает нагрузку на твой Web-сервер, не приводя на него посетителей.
Для борьбы с хотлинками достаточно сделать так, чтобы изображения отдавались клиенту только в том случае, если он запросил их, уже находясь на сайте (другими словами, заголовок referrer-запроса должен содержать имя твоего сайта). Добавь в секцию server конфигурационного файла nginx.conf следующие строки (host.
com – это адрес твоего сайта):
# vi /etc/nginx/nginx.conf
location /images/ { valid_referers none blocked www.host.com host.com; if ($invalid_referer) { return 403; }
}
В качестве альтернативы ты можешь настроить сервер на отдачу специального баннера с сообщением о воровстве вместо запрашиваемого изображения. Для этого замени строку «return 403» на строку:
rewrite ^/images/uploads.*.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg last
Как и любой другой Web-сервер, nginx позволяет регулировать доступ к каталогам на основе IP-адресов и паролей. Эту возможность можно использовать для закрытия некоторых частей сайта от посторонних глаз. Например, для отрезания URI от внешнего мира:
# vi /etc/nginx/nginx.conf
location /uploads/ { # Разрешаем доступ только машинам локальной сети allow 192.168.1.0/24; # Отшиваем всех остальных deny all;
}
Теперь к документам каталога uploads будут иметь доступ только пользователи локальной сети. Для установки пароля придется проделать более сложные действия. Сначала необходимо создать приватный для nginx-файл паролей и добавить в него необходимых пользователей (в качестве примера добавим пользователя admin):
# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin
Далее открой файл nginx.conf и впиши в него следующие строки:
# vi /etc/nginx/nginx.conf
location /admin/ { auth_basic “Restricted”; auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}
Новых пользователей можно добавить с помощью следующей команды:
# htpasswd -s /etc/nginx/.htpasswd/passwd пользователь
Если твой сайт работает с приватными данными пользователей, такими как номера кредитных карт, пароли от других сервисов, или же предоставляет доступ к другой важной информации, которая может стать лакомым кусочком для третьих лиц, позаботься о шифровании. 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
server { server_name host.com; listen 443; ssl on; ssl_certificate /etc/nginx/server.crt; ssl_certificate_key /etc/nginx/server.key; access_log /etc/nginx/logs/ssl.access.log; error_log /etc/nginx/logs/ssl.error.log;
}
После этого можно перезагрузить Web-сервер:
# /etc/init.d/nginx reload
Естественно, без поддержки со стороны самого Web-сайта это делать бессмысленно.
Открой файл /etc/sysctl.conf и помести в него следующие строки:
# vi /etc/sysctl.conf
# Защита от smurf-атак net.ipv4.icmp_echo_ignore_broadcasts = 1 # Защита от неправильных ICMP-сообщений net.ipv4.icmp_ignore_bogus_error_responses = 1 # Защита от SYN-флуда net.ipv4.tcp_syncookies = 1 # Запрещаем маршрутизацию от источника net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.
accept_source_route = 0 # Защита от спуфинга net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 # Мы не маршрутизатор net.ipv4.ip_forward = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 # Включаем ExecShield kernel.exec-shield = 1 kernel.
randomize_va_space = 1 # Расширяем диапазон доступных портов net.ipv4.ip_local_port_range = 2000 65000 # Увеличиваем максимальный размер TCP-буферов net.ipv4.tcp_rmem = 4096 87380 8388608 net.ipv4.tcp_wmem = 4096 87380 8388608 net.core.rmem_max = 8388608 net.core.wmem_max = 8388608 net.core.
netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1
Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:
/dev/sda5 /nginx ext4 defaults,nosuid,noexec,nodev 1 2
Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.
Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера.
По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx (http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий.
Остается только скачать и установить:
# tar -zxvf se-ngix_1_0_10.tar.gz # cd se-ngix_1_0_10/nginx # make
# /usr/sbin/semodule -i nginx.pp
Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.
Для не слишком нагруженного 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
webserver_ip=”1.1.1.1″ table persist block in quick from pass in on $ext_if proto tcp to $webserver_ip port www flags S/SA keep state (max-src-conn 100, max-src-conn-rate 15/60,
overload flush)
Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.
Если ты используешь 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 # Максимальный размер данных, отсылаемых скрипту с помощью метода POST post_max_size = 8M # Максимальный размер загружаемых файлов upload_max_filesize = 2M # Не показывать ошибки PHP-скриптов пользователям display_errors = Off # Включаем Safe Mode safe_mode = On # Включаем SQL Safe Mode sql.safe_mode = On # Позволяем выполнять внешние команды только в этом каталоге safe_mode_exec_dir = /путь/к/защищенному/каталогу # Защищаемся от утечки информации о PHP expose_php = Off # Ведем логи log_errors = On # Запрещаем открытие удаленных файлов
allow_url_fopen = Off
Применив описанные в статье рекомендации, ты получишь гораздо более защищенный Web-сервер. Но имей в виду, что не все техники подойдут к твоей конфигурации.
Например, защита от брутфорса, основанная на урезании размеров буферов, выделяемых nginx под обработку запросов клиентов, может привести к падению производительности, а в некоторых случаях и к сбоям в обработке запросов.
Ограничение на количество подключений нанесет сильный удар по производительности даже средненагруженного Web-сайта, но принесет пользу, если страница имеет низкий поток посетителей. Всегда проверяй, как внесенные тобой изменения повлияли на производительность и общую работоспособность Web-страницы.
Nginx – один самых производительных и популярных Web-серверов в мире. Согласно данным Netcraft, он используется для поддержки более чем 12 миллионов Web-сайтов по всему миру, включая таких мастодонтов как Rambler, Yandex, Begun, WordPress.com, Wrike, SourceForge.net, vkontakte.ru, megashara.com, Либрусек и Taba.ru.
Грамотная архитектура, основанная на мультиплексировании соединений с помощью системных вызовов select, epoll (Linux), kqueue (FreeBSD) и механизме управления памятью на основе пулов (небольших буферов от 1 до 16 Кб), позволяет nginx не проседать даже под очень высокими нагрузками, выдерживая свыше 10000 одновременных соединений (так называемая проблема C10K).
Изначально написан Игорем Сысоевым для компании Rambler и открыт в 2004 году под BSD-подобной лицензией.
Источник: https://xakep.ru/2010/12/15/54168/
Включаем HTTP/2 в NGINX для сайта
10 октября 2015 в 18:29 (МСК) | сохранено13 октября 2015 в 18:29 (МСК)<\p>
В этой статье мы расскажем, как включить HTTP/2 для сайта в NGINX, размещенного на VPS от Infobox и какие преимущества это даст вашему сайту. Поддержка HTTP/2 была добавлена в релиз NGINX 1.9.5.
HTTP/2 – новая версия протокола HTTP, стандартизированная в начале 2015 года. Использование HTTP/1.
1 из-за некоторых особенностей вносит негативный эффект на производительность веб-приложений. В частности HTTP/1.0 позволяет выполнять только один запрос одновременно в TCP–соединении. В HTTP/1.1 были добавлены конвейерные запросы, но они только частично помогают параллельному исполнению запросов и по-прежнему приводят к блокировкам. Клиенты HTTP/1.0 и HTTP/1.
1, которым необходимо делать много запросов сейчас используют множество соединений к серверу. Кроме этого, поля заголовка HTTP многословны и часто повторяются, производя ненужный сетевой трафик. Также время тратится на заторы TCP. Это может привести к повышенным задержкам при множестве запросов сделанных с помощью новых TCP–соединений.
HTTP/2 решает эти проблемы, определяя оптимизированную семантику протокола HTTP. В частности это позволяет выполнять чередование запросов и ответов через то же подключение и предоставляет эффективное кодирование полей HTTP-заголовка. Также HTTP/2 позволяет приоритизировать запросы, позволяя более важным запросам выполняться быстрее.
В результате протокол становится более дружественным к сети, требуя установки меньшего количества TCP–соединений в сравнении с HTTP/1.x, что приводит к более эффективному использованию сети. Также HTTP/2 дает возможность эффективнее обрабатывать сообщения с помощью бинарного формата. HTTP/2 тесно связан с SSL.
Несмотря на то, что спецификация не требует обязательного использования SSL, все веб-браузеры выпущенные на текущий момент будут работать с HTTP/2 только если веб-сайт использует SSL.
Если у вас еще нет VPS от Infobox, заказать сервер можно тут. В статье описана настройка HTTP2 для сервера с CentOS 7. После заказа и создания сервера подключитесь к нему по SSH.
Устанавливаем последнюю версию NGINX на новый VPS с CentOS 7Для установки последней версии NGINX добавим официальный репозиторий. Для этого в файл /etc/yum.repos.d/nginx.repo добавьте следующее содержимое:
[nginx]
name=nginx repo
baseurl=http://nginx.
org/packages/mainline/centos/7/$basearch/
gpgcheck=0
enabled=1
Остановите Apache и запретите его автозапуск:systemctl stop httpd && systemctl disable httpd
Обновите ОС командой:yum -y update
После этого перезагрузите ОС.
reboot
Установите nginx и firewalld командой:yum install -y nginx firewalld
Теперь запустите nginx и добавьте в автозагрузку:systemctl start nginx && systemctl enable nginx
Аналогично запустите firewalld:systemctl start firewalld && systemctl enable firewalld
Последнее, что осталось сделать — открыть порты 80, 443 и 22.
firewall-cmd –zone=public –add-port=80/tcp –add-port=443/tcp –add-port=22/tcp –permanent
firewall-cmd –reload
Теперь зайдите в браузере по ip–адресу вашей VPS. Вы увидите приветственную страницу NGINX.
Для работы HTTP/2 на текущий момент должна быть включенa поддержка соединения по HTTPS в NGINX.
Обычно этот процесс состоит из четырех шагов:
- генерация приватного ключа (key)
- создания запроса на подпись (CSR) и отправка запроса в сертифицирующий центр (CA)
- установка сертификата от сертифицирующего центра
- настройка конфигурации NGINX
Такой процесс обеспечивает доверие браузеров пользователей к сайту.
Создайте папку, в которой будут храниться ключи шифрования и перейдите в нее:mkdir /etc/nginx/ssl && cd /etc/nginx/ssl
Для понимания способов генерации ключа необходимо знать следующие понятия:
Алгоритм генерации ключа. OpenSSL поддерживает RSA, DSA и ECDSA ключи, но не все типы подходят для практического использования во всех сценариях. Например, для веб-серверов нужно использовать RSA, потому что DSA ключи ограничены 1024 битами (IE не поддерживает ничего сложнее) и ECDSA ключи еще не поддерживаются широко сертифицирующими центрами. Если бы мы генерировали ключ для SSH – подошли бы RSA и DSA, так как ECDSA еще может не поддерживаться частью клиентов.
Размер ключа. Размер ключа по-умолчанию может быть небезопасен. Например ключ по-умолчанию для RSA – только 512 бит и его использование совершенно небезопасно. Сегодня рекомендуется использовать минимум 2048 бит для RSA, 2048 бит для DSA и 256 бит для ECDSA. Мы будем использовать RSA и 4086 бит.
Для генерации приватного ключа и запроса на подписание сертификата выполните команду:
openssl req -out /etc/nginx/ssl/domain.csr -new -newkey rsa:4086 -nodes -keyout /etc/nginx/ssl/domain.key
В процессе обязательно укажите FQDN (Common name) – имя домена и email в домене, например [email protected]. Не устанавливайте пароль на ключ.
После генерации вы увидите в папке /etc/nginx/ssl два файла с расширениями key (приватный ключ) и csr (запрос на подписание сертификата).
Если вы хотите использовать доверенный сертификат — закажите его у центра сертификации (можно например заказать в тут).
Для формирования сертификата потребуется содержимое csr, которое можно посмотреть так:
cat /etc/nginx/ssl/domain.csr
После заказа и формирования сертификата сохраните его содержимое в файле /etc/nginx/ssl/domain.crt. После самого содержимого сертификата в этот же файл с новой строки добавьте содержимое Intermediate сертификата, если он будет предоставлен вам сертифицирующим центром и сохраните файл.
Если вы разворачиваете тестовое окружение — можно бесплатно сгенерировать самоподписанный сертификат так:
openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout /etc/nginx/ssl/domain.key -out /etc/nginx/ssl/domain.crt
Также необходимо сгенерировать DH параметры для того, чтобы в случае кражи приватного ключа нельзя было расшифровать последние сообщения.openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
Отредактируйте файл конфигурации NGINX /etc/nginx/conf.d/default.conf.
В нем удалите секцию server и добавьте:
server { listen 80; server_name domain.tld www.domain.tld; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name domain.tld www.domain.tld; ssl on; ssl_certificate /etc/nginx/ssl/domain.crt; ssl_certificate_key /etc/nginx/ssl/domain.key; ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_prefer_server_ciphers On; ssl_protocols TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK; add_header Strict-Transport-Security max-age=15768000; ssl_stapling on; location / { root /usr/share/nginx/html; } }
}
, где domain.tld замените на имя вашего сайта, для которого включаете HTTP2.После изменений протестируйте конфигурацию nginx на отсутствие ошибок командой:nginx -t
Теперь перезапустите NGINX:systemctl restart nginx
Откройте сайт по доменному имени в браузере. Если вы использовали самоподписанный сертификат и не заверяли его у сертифицирующего центра, вы увидите предупреждение.Добавьте сайт в исключения, браузер запомнит это и он корректно откроется.
Чтобы проверить, что сайт работает по HTTP2, установите HTTP2 indicator для Firefox или Chrome.
Теперь при заходе на сайт, поддерживающий HTTP2 или SPDY вы увидите синюю молнию.Действительно, сайт работает по HTTP2.
Вы можете настроить все, описанное в статье, на пробной версии VPS.
Для этого пришлите ваше имя и номер телефона на [email protected], в ответ получите данные для доступа к панели управления. Вы можете тестировать VPS в течение 10 дней.
Успешной работы!
Источник: https://sohabr.net/habr/post/268599/
Как я пытался включить http2 у себя на проекте с nginx
В общем, как я уже читал тут в комментах: «целые статьи пишут на то, как добавить 5 символов и пробел в конфиг». Все бы хорошо, если бы не google chrome. Они решили прекратить поддержку SPDY и NPN
Для примера берем debian 8 на google cloud engine, ставим nginx, с помощью letsencrypt делаем сертификаты.
Для тех, кто не умеет:
echo “deb http://ftp.debian.org/debian jessie-backports main” >> /etc/apt/sources.list
apt-get update
apt-get install certbot -t jessie-backports -y
certbot certonly –webroot -w /var/www/html -d domain.tld –[email protected] –agree-tos #где /var/www/html – корень вашего сайта, который виден из вне
по итогу получаем такое:
то есть все ваши ключи будут лежать здесь /etc/letsencrypt/live/domain.tld/
# ls -la /etc/letsencrypt/live/http2.kricha.info/
total 8
drwxr-xr-x 2 root root 4096 Nov 5 17:53 .
drwx—— 3 root root 4096 Nov 5 17:53 ..
lrwxrwxrwx 1 root root 41 Nov 5 17:53 cert.pem -> ../../archive/http2.kricha.info/cert1.pem
lrwxrwxrwx 1 root root 42 Nov 5 17:53 chain.pem -> ../../archive/http2.kricha.info/chain1.pem
lrwxrwxrwx 1 root root 46 Nov 5 17:53 fullchain.pem -> ../../archive/http2.kricha.info/fullchain1.pem
lrwxrwxrwx 1 root root 44 Nov 5 17:53 privkey.pem -> ../../archive/http2.kricha.info/privkey1.pem
добавляем всю эту красоту в конфиг nginx:
#let's encrypt certificates
ssl_certificate /etc/letsencrypt/live/domain.tld/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/domain.tld/chain.pem;
в итоге у вас должно получиться что-то такое:
server { server_name domain.tld; listen 443 ssl http2; server_tokens off; keepalive_timeout 70; ssl_stapling on; ssl_stapling_verify on; resolver 8.8.4.4 8.8.8.8 valid=300s; resolver_timeout 10s; ssl on; #let's encrypt certificates ssl_certificate /etc/letsencrypt/live/domain.tld/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/domain.tld/chain.pem; ssl_dhparam /etc/nginx/ssl/dhparam.pem; ssl_session_timeout 1h; ssl_session_cache shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL; add_header Strict-Transport-Security “max-age=63072000; includeSubDomains; preload” always; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; root /var/www/html; index index.nginx-debian.html; location / { try_files $uri $uri/ =404; } error_log /var/log/nginx/domain.tld.error.log; access_log /var/log/nginx/domain.tld.access.log;
} server { listen 80; listen [::]:80; server_name domain.tld; return 301 https://$host$request_uri;
}
Чтоб сделать DHE:
cd /etc/nginx
mkdir ssl
openssl dhparam -out ssl/dhparam.pem 2048
Вроде бы все и можно делать service nginx reload но фиг нам 🙂 Вы получите в ответ это: Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details., а в деталях:
ov 05 18:01:15 http2 systemd[1]: Failed to read PID from file /run/nginx.pid: Invalid argument
Nov 05 18:01:15 http2 systemd[1]: Started A high performance web server and a reverse proxy server.
Nov 05 18:14:27 http2 systemd[1]: Reloading A high performance web server and a reverse proxy server.
Nov 05 18:14:27 http2 nginx[24507]: nginx: [emerg] invalid parameter “http2” in /etc/nginx/sites-enabled/default:4
Nov 05 18:14:27 http2 systemd[1]: nginx.service: control process exited, code=exited status=1
Nov 05 18:14:27 http2 systemd[1]: Reload failed for A high performance web server and a reverse proxy server.
В общем, nginx вообще не понял чего мы от него хотели и хотим. Смотрим версию и оказывается nginx version: nginx/1.6.2, ладно, поставим последнюю версию.
Установим свежую версию nginx
echo -e “deb http://nginx.org/packages/mainline/debian/ jessie nginxndeb-src http://nginx.org/packages/mainline/debian/ jessie nginx” >>/etc/apt/sources.
list
rm -rf /var/lib/dpkg/info/nginx*
apt-get update
apt-get upgrade –force-yes -y
service nginx restart
Заходим в браузер, проверяем:
Видим Статус HTTP/2.0 200, радуемся, проверяем в хроме:
Видим Protocol http/1.
1, грустим и уходим плакать.
Нет, конечно, не сдаемся, доливаем в стаканчик ром и продолжаем.
Собираем правильный nginx
apt-get install libpcre3 libpcre3-dev libpcrecpp0 libssl-dev zlib1g-dev
cd /opt
wget http://nginx.org/download/nginx-1.11.5.tar.gz
wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz
tar xf nginx-1.11.5.tar.gz
tar xf openssl-1.0.2j.tar.gz
cd nginx-1.11.5
.
/configure –prefix=/etc/nginx –sbin-path=/usr/sbin/nginx –modules-path=/usr/lib/nginx/modules –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –pid-path=/var/run/nginx.pid –lock-path=/var/run/nginx.
lock –http-client-body-temp-path=/var/cache/nginx/client_temp –http-proxy-temp-path=/var/cache/nginx/proxy_temp –http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp –http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp –http-scgi-temp-path=/var/cache/nginx/scgi_temp –user=nginx –group=nginx –with-compat –with-file-aio –with-threads –with-http_addition_module –with-http_auth_request_module –with-http_dav_module –with-http_flv_module –with-http_gunzip_module –with-http_gzip_static_module –with-http_mp4_module –with-http_random_index_module –with-http_realip_module –with-http_secure_link_module –with-http_slice_module –with-http_ssl_module –with-http_stub_status_module –with-http_sub_module –with-http_v2_module –with-mail –with-mail_ssl_module –with-stream –with-stream_realip_module –with-stream_ssl_module –with-stream_ssl_preread_module –with-openssl=/opt/openssl-1.0.2j
make
make install
service nginx restart
Проверяем в хроме:
В сафари:
Везде видим, что используется протокол http2, проверяем еще на www.ssllabs.com, получаем
Профит! Доливаем себе ром и идем спать! Всем спасибо за внимание, надеюсь кому-то помог.
Источник: http://www.pvsm.ru/nginx/206557
Включить HTTP/2 в Nginx
Начиная с версии Nginx 1.9.5 добавлена встроенная поддержка протокола HTTP/2. На данный момент протокол работает в экспериментальном режиме, но уже к концу года разработчики обещают реализовать его полную поддержку.
Что бы подготовится к переходу и предварительно протестировать работу своих проектов под HTTP/2, необходимо обновить Nginx до последней mainline-версии. Для этого я рекомендую всегда использовать официальный репозиторий Nginx.
Добавим в /etc/apt/sources.list официальный репозиторий для mainline-ветки Nginx:
deb http://nginx.org/packages/mainline/debian/ codename nginx
deb-src http://nginx.org/packages/mainline/debian/ codename nginx
Установим PGP-ключ и обновляем индекс пакетов:
cd /tmp/ && wget http://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key
apt-get update && apt-get install nginx
После установки необходимо проверить, что Nginx собран с поддержкой модуля HTTP/2, для этого используем команду ниже:
# nginx -V
nginx version: nginx/1.9.5
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.1k 8 Jan 2015
TLS SNI support enabled
configure arguments: –prefix=/etc/nginx –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –pid-path=/var/run/nginx.pid –lock-path=/var/run/nginx.lock –http-client-body-temp-path=/var/cache/nginx/client_temp –http-proxy-temp-path=/var/cache/nginx/proxy_temp –http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp –http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp –http-scgi-temp-path=/var/cache/nginx/scgi_temp –user=nginx –group=nginx –with-http_ssl_module –with-threads –with-file-aio –with-http_v2_module –with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' –with-ld-opt=-Wl,-z,relro
Команда выведет информацию о параметрах сборки Nginx. Нас интересует опция –with-http_v2_module, которая указывает на поддержку протокола. Что бы включить поддержку HTTP/2 в Nginx, необходимо изменить параметр listen как указано в примере ниже:
listen 443 ssl http2;
Применяем настройки в Nginx:
nginx -t && service nginx reload
В заключении хочу написать о своих впечатлениях. Если в первом патче добавляющем поддержку HTTP/2 в Nginx на WordPress сайте не работала авторизация, то сейчас данной проблемы не наблюдается. Страницы открываются быстро, а Nginx стабильно работает под нагрузкой ApacheBench. Связи с этим было принято решение включить HTTP/2 для своего блога на постоянной основе.
Источник: https://codebeer.ru/vklyuchit-http2-v-nginx/
Переехал на HTTPS, включил HTTP/2
Сегодня перевел свой блог на HTTPS. Зачем? Не знаю, но почему бы и нет?) Наверное это больше связано с популязацией https в интернете в целом. Поправил конфиг SSL, получив A+ в ssllabs. Добавил Strict Transport Security. Обновил nginx до последней версии 1.9.5, подключив HTTP/2. В целом неплохо так получилось.
Под катом подробнее об этом.
Как правильно настроить HTTPS?
В этом нам поможет сервис SSLLabs. Проверяем свой сайт и, глядя в мануал NGINX, исправляем выявленные недочеты до тех пор пока не исправим их все. Так например, у меня был разрешен SSLv3, который имеет уязвимости, и пара других недочетов. Получаем:
В итоге у меня получился вот такой вот конфиг nginx-а:
| ssl_certificate “[…].crt”; ssl_certificate_key “[…].key”; ssl_dhparam “[…]/dh2048.pem”; ssl_session_cache shared:SSL:16m; ssl_trusted_certificate “[…].trusted.crt”; resolver 8.8.4.4 8.8.8.8 valid=300s; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; |
Кстати сказать плохо настроенный SSL, не даст работать протоколу HTTP/2.
Так например, при использовании небезопасного шифра/протокола, не говоря уже о невалидном сертификате, Chrome откажется открывать сайт, выдавая ошибку ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY.
Поэтому если вы планируете подключить HTTP2, обязательно обратите внимание на разрешенные протоколы и шифры (ssl_protocols и ssl_ciphers). Приведенная конфигурация выше — эталон, который следует брать за основу.
Хорошо бы сгенерировать ключ dhparam с 2048-битным ключом (ssl_dhparam), т.к. по дефолту используется 1024-битный ключ, а на данный момент это уже ненадежно. Кое-где рекомендуют 4096 бит, но я не советую этого делать, т.к. это фактически замедляет работу сервера.
Также рекомендую включить поддержку OSCP ответов:
| ssl_trusted_certificate “[…].trusted.crt”; resolver 8.8.4.4 8.8.8.8 valid=300s; |
это позволяет существенно ускорить время установления SSL соединения с сервером, а, следовательно, и время загрузки вашего сайта.
И обязательно включаем ssl_prefer_server_ciphers on — тем самым указываем, что серверные шифры были более приоритетны, чем клиентские, тем самым исключаем возможность BEAST-атаки.
Ну и включаем кеш сессий:
| ssl_session_cache shared:SSL:16m; |
Выполнение этих рекомендаций даст A+ оценку, чего мы собственно и добивались 🙂
Как включить HSTS
Кстати сказать неплохо включать HTTP Strict Transport Security для тех сайтов которые работают только по HTTPS. Добавляем в конфиг nginx:
| add_header Strict-Transport-Security “max-age=31536000;”; |
Этот заголовок говорит о том что данный браузер работает только по HTTPS, и необходимо пресекать все попытки открытия его по HTTP, если проще — то всегда открывать его по HTTPS. Но википедия конечно скажет лучше меня:
Как обновить nginx до 1.9.5 в Debian
В принципе тут проблем никаких быть не должно. Заходим на сайт nginx и выполняем пошагово их инструкцию:
В процессе обновления у вас может возникнуть конфликт со старой версией nginx, например такая ошибка:
| trying to overwrite '/etc/logrotate.d/nginx', which is also in package nginx-common |
или
| trying to overwrite '/usr/sbin/nginx', which is also in package nginx-full |
тогда вам следует удалить эти пакеты, и после таки установить nginx:
| apt-get remove nginx-full nginx-common nginx |
Как включить HTTP/2 в nginx?
Нормальная реализация HTTP2 появилась в версии nginx 1.9.5. Собственно поэтому и понадобилось обновиться до этой версии. Ну а подключить поддержку этого протокола еще легче. Правим конфиг nginx, добавляем http2 в listen:
Тут я наверное уже больше ничего не добавлю)
Как определить поддерживает ли сайт HTTP/2?
Открываем Chrome Developer Tools, переходим в раздел Network. Включаем в таблице ресурсов отображение столбца Protocol:
Жмем F5, и видим протокол по которому был загружен тот или иной ресурс:
где H2 — это HTTP/2
Источник: https://IntSystem.org/security/pereexal-na-https-vklyuchil-http2/
Nginx: HTTP/2 не работает | Evil Inside
Настройка HTTP/2 в Nginx может показаться тривиальной задачей, однако есть ряд потенциальных проблем, с которыми вы можете столкнуться. В данной статье я опишу несколько из тех, с которыми столкнулся лично я при настройке наших серверов.
Настройка HTTP/2 в Nginx
Для включения HTTP/2 в Nginx достаточно добавить пару строк в конфигурацию вашего сервера:
- server {
- listen 443 ssl http2;
- ssl_certificate ;
- ssl_certificate_key ;
- #…
- }
Указываем 443 порт, т.к. он является портом по умолчанию для SSL, а также, что сервер будет использовать SSL и работать с HTTP/2. Еще необходимо указать пути к файлам сертификатам. Ничего сложного.
Проблема 1: Invalid parameter «http2»
Если вы добавили все указанные выше настройки, перезагрузили Nginx и получили такую ошибку, то первое, что вам необходимо сделать — проверить версию Nginx:
- nginx —v
- nginx version: nginx/1.11.1
Как я описал ранее в одной из статей, Как настроить HTTP/2 с Varnish используя Nginx, Nginx должен быть версии не ниже 1.9.5, а также скомпилирован вместе с модулем http2. В противном случае строка
будет приводить к критической ошибке.
Проблема 2: Nginx по прежнему отдает данные используя HTTP/1.1 (в Chrome)
Вы можете сразу же перейти к решению, или же ознакомиться со всем более детально и понять причину и суть проблемы.
Хорошо, у вас уже установлен Nginx правильной версии вместе с http2 модулем, но как проверить все ли настроено верно и отдает ли Nginx данные используя именно HTTP/2?
Приведу несколько способов:
HTTP/2 Тест — онлайн сервис
Наиболее простым способом является проверка через инструмент http2 тест. Достаточно просто ввести домен вашего сайта и вы узнаете результаты:
Обратите внимание на секцию ALPN. В ней должно быть указано, что поддержка ALPN включена, иначе HTTP/2 не будет работать в Chrome.
Проверка HTTP/2 с помощью расширения для Chrome
Данный способ хорош тем, что вы будете постоянно видеть поддерживает тот или иной сайт HTTP/2. Вы можете установить расширение HTTP/2 and SPDY indicator. Оно добавляет индикатор справа от строки поиска, который становится синим если страница работает через HTTP/2.
Проверка с помощью Chrome Dev Tools
Еще одним способом является дополнительная настройка в Chrome Dev Tools. Откройте панель отладки, выберите вкладку Сеть, далее вызовите контекстное меню нажав на заголовок любой из колонок.
В появившемся меню отметьте Протокол. Это все, теперь у вас есть дополнительная колонка, которая отображает протокол, с помощью которого были загружены те или иные ресурсы.
Просто перезагрузите страницу у увидите что-то вроде:
Здесь мы видим, что ресурсы отдаются через HTTP/2.
Почему HTTP/2 может не работать в Chrome
В одной из статей Chrome (оригинал) было указано, что:
Это значит, что если ваш веб сервер не поддерживает ALPN расширение для TLS, то пользователи Chrome будут по прежнему получать данные через HTTP/1.1 и не увидят никаких улучшений в производительности.
SPDY
Источник: https://evilinside.ru/nginx-http-2-ne-rabotaet/
Загрузка...
