Nginx (сервер)

nginx - веб-сервер и почтовый прокси-сервер. Ориентирован на Unix-подобные ОС.

2023

nginx 1.25.2 с устранением ошибки в реализации HTTP/3

Сформирован выпуск основной ветки nginx 1.25.2, в рамках которой продолжается развитие дополнительных возможностей. В параллельно поддерживаемой стабильной ветке 1.24.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.25.x будет сформирована стабильная ветка 1.26. Код проекта написан на языке Си и распространяется под лицензией BSD. Об этом стало известно 16 августа 2023 года.

Среди изменений:

• При использовании HTTP/3 реализовано определение максимального размера информации, которая при обмене данных с заданным хостом может быть передана в пакете без фрагментации (Path MTU Discovery).
• При использовании HTTP/3 предоставлена возможность использования набора шифров TLS_AES_128_CCM_SHA256.
• При загрузке конфигурации OpenSSL обеспечено использование "nginx" в качестве имени приложения (параметр appname).
• Прекращены попытки загрузки конфигурации OpenSSL в случае, если nginx собран с опцией "--with-openssl", но не выставлена переменная окружения OPENSSL_CONF.
• При использовании HTTP/3 налажено выставление переменной $body_bytes_sent.
• Устранены ошибки в реализации HTTP/3^[1].

Уязвимость ряда серверов из-за ошибки в настройке nginx

5 июля 2023 года стало известно о том, что некоторые серверы с nginx остаются уязвимы для техники Nginx Alias Traversal, которая позволяет получить доступ к файлам и каталогам, размещённым вне корневого каталога, заданного в директиве "alias". Проблема проявляется только в конфигурациях с директивой "alias", размещённой внутри блока "location", параметр которой не завершается на символ "/", в то время как "alias" завершается на "/".

Суть проблемы в том, что файлы для блоков с директивой alias отдаются через прикрепление запрошенного пути, после его сопоставления с маской из директивы location и вырезания заданной в этой маске части пути. Для показанного выше примера уязвимой конфигурации атакующий может запросить файл "/img../test.txt" и этот запрос подпадёт под указанную в location маску "/img", после чего остающийся хвост "../test.txt" будет прикреплён к пути из директивы alias "/var/images/" и в итоге будет запрошен файл "/var/images/../test.txt". Таким образом, атакующим может получить доступ к любым файлам в каталоге "/var", а не только к файлам в "/var/images/", например, для загрузки лога nginx можно отправить запрос "/img../log/nginx/access.log".

В конфигурациях, в которых значение директивы alias не завершается символом "/" (например, "alias /var/images;"), атакующий не может перейти в родительский каталог, но имеет возможность запросить другой каталог в /var, начало имени которого совпадает с указанным в конфигурации. Например, запросив "/img.old/test.txt" можно получить доступ к каталогу "var/images.old/test.txt".

Анализ репозиториев на GitHub показал, что приводящие к проблеме ошибки в настройке nginx до сих пор встречаются в реальных проектах. Например, наличие проблемы было выявлено в серверной части менеджера паролей Bitwarden и могло использоваться для доступа ко всем файлам в каталоге /etc/bitwarden (запросы /attachments отдавались из /etc/bitwarden/attachments/), включая хранимую там БД с паролями "vault.db", сертификат и логи, для получения которых достаточно было отправить запросы "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log" и т.п.

Метод также сработал с Google HPC Toolkit, в котором запросы /static перенаправлялись в каталог "../hpc-toolkit/community/front-end/website/static/". Для получения БД с закрытым ключом и учётными данными атакующий мог отправить запросы "/static../.secret_key" и "/static../db.sqlite3"^[2].

Nginx 1.25.1 с директивой "http2"

Сформирован выпуск основной ветки nginx 1.25.1, в рамках которой продолжается развитие возможностей. В параллельно поддерживаемой стабильной ветке 1.24.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.25.x будет сформирована стабильная ветка 1.26. Об этом стало известно 13 июня 2023 года.

Среди изменений:

• Добавлена отдельная директива "http2" для выборочного включения протокола HTTP/2 в привязке к серверам (может использоваться в отдельных блоках "server"). Параметр "http2" в директиве "listen" объявлен устаревшим.
• Удалена поддержка технологии Server push в HTTP/2.
• Прекращена поддержка директивы "ssl", ранее объявленной устаревшей.
• Решены проблемы при использовании HTTP/3 при сборке с библиотекой OpenSSL^[3].

Версия nginx 1.24.0

12 апреля 2023 года стало известно о том, что после 11 месяцев разработки представлена стабильная ветка HTTP-сервера и многопротокольного прокси-сервера nginx 1.24.0, которая вобрала в себя изменения, накопленные в основной ветке 1.23.x. В дальнейшем все изменения в стабильной ветке 1.24 будут связаны с устранением серьёзных ошибок и уязвимостей. В скором времени будет сформирована основная ветка nginx 1.25, в которой будет продолжено развитие дополнительных возможностей. Для обычных пользователей, у которых нет задачи обеспечить совместимость со сторонними модулями, рекомендуется использовать основную ветку, на базе которой раз в три месяца формируются выпуски коммерческого продукта Nginx Plus.

Версия nginx 1.24.0. Иллюстрация: alternativeto.net.

Как сообщалось, в соответствии с мартовским отчетом компании Netcraft nginx используется на 18.94% всех активных сайтов (год назад 20.08%, два года назад 20.15%), что соответствует второму месту по популярности в данной категории (доля Apache соответствует 20.52% (год назад 22.58%, два года назад 25.38%), Cloudflare - 11.32% (10.42%, 8.51%), Google - 9.89% (8.89%, 10.09%). При этом при рассмотрении всех сайтов nginx сохраняет лидерство и занимает 25.94% рынка (год назад 31.13%, два года назад - 35.34%), в то время как доля Apache соответствует 20.58% (23.08%), Cloudflare - 10.17% (5.49%), OpenResty (платформа на базе nginx и LuaJIT) - 7.94% (8.01%).

Среди миллиона самых посещаемых сайтов в мире в 2023 году в лидеры выбился Cloudflare, доля которого составила 21.62%. Для сравнения доля nginx составляет 21.37% (год назад 21.79%, два года назад 23.06%), а Apache httpd - 21.18%. На 2023 год под управлением nginx работает около 289 млн сайтов (год назад 361 млн). По данным W3Techs nginx используется на 34.5% сайтов из миллиона самых посещаемых, в апреля 2022 года этот показатель составлял 33.1%, позапрошлого - 33.8%. Доля Apache за год увеличилась с 31.3% до 32.2%, а доля Node.js с 1.8% до 2%. Доля Microsoft IIS снизилась с 6% до 5.6%, а доля LiteSpeed с 12.2% до 11.8%. В России nginx используется на 81.3% самых посещаемых сайтов (год назад - 79.8%).

Наиболее заметные изменения, добавленные в процессе формирования основной ветки 1.23.x:

• По умолчанию включён протокол TLSv1.3.
• Обеспечена автоматическая ротация ключей шифрования для сессионных тикетов TLS, применяемая при использовании разделяемой памяти в директиве ssl_session_cache.
• Проведена оптимизация потребления памяти в конфигурациях с проксированием SSL.
• Добавлена поддержка переменных "$proxy_protocol_tlv_*", в которые записываются значения полей TLV (Type-Length-Value), фигурирующих в протоколе Type-Length-Value PROXY v2.
• В модуле ngx_http_gzip_static_module добавлена поддержка байтовых диапазонов (byte range).
• В директиву "resolver" добавлен параметр "ipv4=off", позволяющий отключить поиск IPv4-адресов при преобразовании имён и адреса.
• Переделан внутренний API, строки заголовков теперь передаются в форме связанного списка.
• Обеспечено объединение строк заголовков с идентичными именами при передаче в бэкенды FastCGI, SCGI и uwsgi, в методе $r->header_in() модуля ngx_http_perl_module и в переменных "$http_...", "$sent_http_...", "$sent_trailer_...", "$upstream_http_..." и "$upstream_trailer_...".
• Обеспечен вывод предупреждения в случае переопределения настроек используемых протоколов для слушающего сокета.
• Уровень логов для многих ошибок SSL понижен с критического до информационного.
• На платформе Windows в модулях ngx_http_autoindex_module и ngx_http_dav_module, а также в директиве include добавлена поддержка не-ASCII символов в именах файлов. В Windows также налажена сборка nginx с OpenSSL 3.0^[4].

2022

Версии 1.22.1 и 1.23.2 с устранением уязвимостей

Сформирован выпуск основной ветки nginx 1.23.2, в рамках которой продолжается развитие дополнительных возможностей, а также выпуск параллельно поддерживаемой стабильной ветки nginx 1.22.1, в которую вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. Об этом стало известно 19 октября 2022 года.

В обновленных версиях устранены две уязвимости (CVE-2022-41741, CVE-2022-41742) в модуле ngx_http_mp4_module, применяемом для организации потокового вещания из файлов в формате H.264/AAC. Уязвимости могут привести к повреждению памяти или утечке содержимого памяти при обработке специально оформленного файла в формате mp4. В качестве последствий упоминается аварийное завершение рабочего процесса, но не исключаются и иные проявления, такие как организация выполнения кода на сервере.

Примечательно, что похожая уязвимость уже устранялась в модуле ngx_http_mp4_module в 2012 году. Кроме того, компания F5 сообщила о похожей уязвимости (CVE-2022-41743) в продукте NGINX Plus, затрагивающей модуль ngx_http_hls_module, обеспечивающий поддержку протокола HLS (Apple HTTP Live Streaming).

Кроме устранения уязвимостей в nginx 1.23.2 предложены следующие изменения:

• Добавлена поддержка переменных "$proxy_protocol_tlv_*", в которые записываются значения полей TLV (Type-Length-Value), фигурирующих в протоколе Type-Length-Value PROXY v2.
• Обеспечена автоматическая ротация ключей шифрования для сессионных тикетов TLS, применяемая при использовании разделяемой памяти в директиве ssl_session_cache.
• Уровень ведения лога для ошибок, связанных с некорректным типом записей SSL, понижен с критического до информационного уровня.
• Уровень ведения лога для сообщений о невозможности выделить память для нового сеанса изменён с alert на warn и ограничен выводом одной записи в секунду.
• На платформе Windows налажена сборка с OpenSSL 3.0.
• Налажено отражение в логе ошибок протокола PROXY.
• Устранена проблема, из-за которой при использовании TLSv1.3 на базе OpenSSL или BoringSSL не работал таймаут, указанный в директиве «ssl_session_timeout»^[5].

Выпуск основной ветки nginx 1.23.0

Представлен первый выпуск обновленной основной ветки nginx 1.23.0, в рамках которой будет продолжено развитие новых возможностей. Об этом стало известно 21 июня 2022 года. В параллельно поддерживаемой стабильной ветке 1.22.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В 2023 году на базе основной ветки 1.23.x будет сформирована стабильная ветка 1.24.

Основные изменения:

• Переделан внутренний API, строки заголовков теперь передаются в форме связанного списка.
• Обеспечено объединение строк заголовков с идентичными именами при передаче в бэкенды FastCGI, SCGI и uwsgi, в методе $r->header_in() модуля ngx_http_perl_module и в переменных "$http_...", "$sent_http_...", "$sent_trailer_...", "$upstream_http_..." и "$upstream_trailer_...".
• Для ошибок SSL "application data after close notify" уровень логов понижен с "crit" до "info".
• Устранена проблема с зависанием соединений в nginx, собранном на Linux-системах с ядром 2.6.17 и новее, но используемом на системах без поддержки EPOLLRDHUP (например, при применении эмуляции epoll).
• Устранена проблема с кэшированием ответов, если заголовок "Expires" запрещал кэширование, а "Cache-Control" разрешал.
• Решены проблемы, проявляющиеся, если бэкенд выдавал в ответе в несколько заголовков "Vary" и "WWW-Authenticate".

Возможная уязвимость 0-day в Nginx 1.18

12 апреля 2022 года стало известно, что неделей ранее на странице Twitter, связанной с хакерской группой BlueHornet, появилась информация об уязвимости в ПО для аутентификации пользователей Nginx LDAP. По словам хакеров, они подготовили экспериментальный эксплоит для Nginx 1.18, протестировав который выяснили, что к нему уязвим целый ряд компаний и корпораций.

Иллюстрация: securitylab.ru

Как пояснили хакеры, эксплуатация уязвимости проходит в два этапа. Первый этап - LDAP-инъекция (тип атаки на web-приложения, предусматривающий создание операторов LDAP на основе вводимых пользователями данных).

По словам BlueHornet, группа намеревалась сообщить о своем открытии команде безопасности Nginx через bug bounty-платформу HackerOne. Позднее была создана GitHub-страница с подробными объяснениями эксплуатации уязвимости.

Группа заявила, что уязвимость затрагивает конфигурации Nginx по умолчанию и раскритиковала разработчиков за то, что они никак не отреагировали на ее сообщение. Если верить хакерам, они протестировали свой эксплоит на системах «Королевского банка Канады», однако, были ли они взломаны, неизвестно. Позднее группа также сообщила о взломе систем китайского представительства компании UBS Securities.

В понедельник, 11 апреля, разработчики Nginx опубликовали заявление касательно уязвимости и отметили, что она затрагивает только эталонные реализации, но не Nginx Open Source и Nginx Plus.

Как пояснили в компании, эталонные реализации подвержены уязвимостям в трех случаях: если для конфигурации демона использовались параметры командной строки; применяются опциональные параметры конфигурации; аутентификация LDAP зависит от конкретного членства в группе. Для всех трех случаев были разработаны методы защиты от эксплуатации уязвимости.^[6]

2017

NGINX Application Platform

NGINX Application Platform – это набор из четырех продуктов с открытым исходным кодом, который призван помочь компаниям быстрее и стабильнее разрабатывать или модернизировать веб-приложения.

Сервер приложений NGINX Unit

14 сентября 2017 года запущена бета-версия сервера приложений NGINX Unit, один из компонентов платформы NGINX Application Platform. Использование NGINX Unit создает меньше прослоек между пользователем и исполняемым кодом, что снижает нагрузку на сервер и позволяет выдерживать большее число RPS. Тестирование проведено компанией-экспертом удаленного администрирования серверов ITSumma.

ITSumma тестировала один из компонентов платформы NGINX Unit — сервер, позволяющий запускать веб-приложения, написанные на различных языках программирования (PHP, Python, Go). Был разработан примерный набор типичных конфигураций для развертывания веб-приложений на Laravel, «1С-Битрикс» и Wordpress, и проведено нагрузочное испытание проектов, запущенных на NGINX Unit в качестве бэкенд-сервера и NGINX в качестве фронтенд-сервера. В результате тестов был выявлен ряд недочетов и ошибок. Все они были оперативно исправлены NGINX.

На рынке негласным стандартом стала связка PHP с PHP-FPM или веб-сервером Apache, Python-приложения через uWSGI. А при необходимости поддерживать разные версии PHP единственным выходом было запускать одновременно несколько менеджеров процессов PHP-FPM c различными конфигурациями.

Теперь NGINX Unit помогает разработчикам и организациям избежать хаоса в конфигурации составляющих сложных гетерогенных систем, а конфигурирование через REST API значительно упрощает выстраивание инфраструктуры на сложных микросервисных архитектурах.

Nginx Plus R12

15 марта 2017 года компания Nginx сообщила о выпуске релиза веб-сервера Nginx Plus R12. В его составе ряд функций, включая масштабируемость и кэширование контента, усовершенствования конфигурационного управления внутри кластера и возможности программирования посредством nginScript.

NGINX Plus - программная платформа доставки приложений, в составе которой балансировщик нагрузки, кэш контента и веб-сервер^[7].

Скриншот информационной панели NGINX Plus R12, (2017)

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

К другим модификациям релиза Plus R12 относится процесс проверки и распространения балансировки нагрузки и конфигурации веб-сервера по кластеру серверов NGINX Plus. Компания заявила: инструмент конфигурирования nginScript на базе скриптового языка, впервые выпущенный в 2015 году, «достиг зрелости и полностью поддерживается в NGINX Plus».

2002: nginx

Продукт создал Игорь Сысоев в 2002 году.

С июля 2011 работу над продуктом продолжает компания Nginx.

HTTP-сервер, свойства

• обслуживание неизменяемых запросов, индексных файлов, автоматическое создание списка файлов, кеш дескрипторов открытых файлов
• акселерированное проксирование без кэширования, простое распределение нагрузки и отказоустойчивость
• поддержка кеширования при акселерированном проксировании и FastCGI
• акселерированная поддержка FastCGI и memcached серверов, простое распределение нагрузки и отказоустойчивость
• модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, HTTP-аутентификация, SSI-фильтр
• несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно
• поддержка SSL
• поддержка PSGI, WSGI
• экспериментальная поддержка встроенного Perl

SMTP/IMAP/POP3-прокси сервер

• перенаправление пользователя на SMTP/IMAP/POP3-бэкенд с использованием внешнего HTTP-сервера аутентификации
• простая аутентификация (LOGIN, USER/PASS)
• поддержка SSL и STARTTLS

Примечания