Представь особняк с дорогой охраной. Камеры, датчики, бронированные двери. Каждый посетитель проходит проверку.
Но продукты на кухню доставляют через служебный вход. Охранники проверяют главные ворота, а доверенный поставщик передаёт коробки непосредственно повару.
Однажды в коробке оказывается не то, что указано на этикетке.
И проблема даже не в том, что охрана плохо работает. Просто никто не проверил, как устроена передача между двумя доверенными участниками системы.
В веб-инфраструктуре похожая ситуация возникает на границе NGINX и PHP-FPM.
Внешний запрос принимает веб-сервер. Затем он передаёт необходимые данные PHP-интерпретатору через протокол FastCGI. Обычно эта схема работает надёжно. Но ошибки конфигурации или уязвимости обработки данных способны превратить внутренний интерфейс в точку атаки.
И здесь возникает неприятный вопрос: что делать, если проблема находится не в коде сайта, а в механизме, который этот код запускает?
Когда защита сайта не защищает сам интерпретатор
NGINX принимает HTTP-запросы, выбирает маршрут обработки и передаёт PHP-запросы соответствующему обработчику.
PHP-FPM управляет рабочими процессами PHP, которые исполняют серверные скрипты.
Между ними находится FastCGI — протокол передачи параметров запроса, переменных окружения и данных.
В этой архитектуре есть несколько принципиально разных классов угроз:
- Ошибки маршрутизации запросов к PHP-скриптам.
- Небезопасная передача параметров FastCGI.
- Незащищённый сетевой интерфейс PHP-FPM.
- Уязвимости памяти в конкретных версиях PHP.
- Ошибки самого приложения, позволяющие выполнять нежелательные операции.
Их нельзя смешивать. Неправильный PATH_INFO не означает автоматического переполнения памяти, а доступ к FastCGI не гарантирует удалённого выполнения кода. Но при определённых условиях последствия могут быть серьёзными.
Реальный случай: CVE-2019-11043
В октябре 2019 года была раскрыта уязвимость CVE-2019-11043.
Она затрагивала определённые версии PHP 7 и конфигурации NGINX с PHP-FPM. Ошибка обработки PATH_INFO могла приводить к повреждению памяти процесса и в конечном счёте к удалённому выполнению кода.
Ключевую роль играло сочетание нескольких обстоятельств: уязвимой версии PHP, определённой обработки пути запроса и отсутствия необходимых проверок существования PHP-файла.
Проблема была исправлена в PHP 7.1.33, 7.2.24 и 7.3.11.
Это важный исторический пример: даже если разработчики приложения не допустили SQL-инъекций и не принимают опасные загрузки файлов, ошибка на уровне серверного обработчика может создать самостоятельный путь атаки.
Но переносить механизм CVE-2019-11043 на любую современную установку PHP-FPM неправильно.
Почему злоумышленникам интересна оперативная память
При эксплуатации некоторых уязвимостей атакующий стремится изменить поведение работающего процесса, не создавая привычный вредоносный файл в каталоге сайта.
Это затрудняет обнаружение средствами, которые контролируют исключительно изменения файлов.
Однако выражение «атака без следов» вводит в заблуждение.
Даже когда вредоносная программа не записывается на диск, могут сохраняться следы в сетевой телеметрии, журналах прокси, событиях процессов, системном аудите и памяти.
Отсутствие нового PHP-файла ещё не означает отсутствие атаки. И отсутствие подозрительных записей в обычном access.log тоже не является доказательством безопасности.
Для специалистов важно различать три вещи:
Memory corruption. Ошибка обращения к памяти, способная нарушить работу процесса и при определённых условиях дать атакующему управление.
FastCGI configuration injection. Риск изменения поведения PHP через неправильно защищённый интерфейс и параметры конфигурации.
Fileless execution. Выполнение вредоносных действий без традиционного сохранения исполняемого файла на диск.
Эти механизмы могут встречаться в разных атаках, но не образуют одну обязательную цепочку.
Как защищать связку NGINX + PHP-FPM
Первое правило — обновлять PHP и связанные компоненты. Никакая настройка веб-сервера не должна заменять исправление известной уязвимости.
Второе — ограничивать доступ к PHP-FPM. FastCGI-сокет должен быть доступен только тем процессам, которым он действительно необходим. Если используется TCP, интерфейс нельзя без необходимости открывать в интернет.
Третье — проверять маршрутизацию PHP-запросов. NGINX не должен передавать произвольные несуществующие пути обработчику PHP. Конкретные правила необходимо согласовывать с архитектурой приложения, особенно если оно использует PATH_INFO.
Четвёртое — изолировать приложения. Отдельные пользователи ОС, ограниченные права на запись, минимальные доступы к секретам и разделение сервисов уменьшают последствия компрометации.
Пятое — контролировать исходящие соединения. Серверу могут быть нужны внешние API, платёжные шлюзы и почтовые сервисы. Поэтому разумная сетевая политика ограничивает ненужные направления, а не отключает весь исходящий трафик одной командой.
Шестое — использовать системные механизмы усиления защиты. Ограничения systemd, seccomp, AppArmor или SELinux способны сократить возможности скомпрометированного процесса. Но их внедряют после тестирования совместимости, а не копированием универсального набора директив.
И наконец, необходимы журналы и мониторинг за пределами самого PHP-приложения. Если злоумышленник получил контроль над рабочим процессом, доверять только его собственным логам уже нельзя.
Почему WAF недостаточно
Cloudflare WAF и другие межсетевые фильтры остаются полезными средствами защиты.
Они помогают отсекать множество известных атак, подозрительные запросы и автоматизированную активность.
Но WAF не исправляет уязвимый PHP-интерпретатор, не заменяет безопасную конфигурацию FastCGI и не гарантирует обнаружение неизвестных методов эксплуатации.
Поэтому защищённость определяется не наличием одного продукта, а сочетанием обновлений, правильной архитектуры, минимальных привилегий и наблюдаемости.
Последний рубеж
Самая опасная ошибка администратора — считать, что отсутствие тревоги означает отсутствие проблемы.
Сайт может выглядеть нормально. База данных продолжит отвечать. Посетители ничего не заметят.
Но если серверный процесс получил возможности, которых ему не должно быть предоставлено, последствия могут проявиться гораздо позже.
Настоящая безопасность начинается там, где даже взломанный компонент не получает свободы управлять всей системой.
Именно поэтому стоит защищать не только входные двери цифрового особняка, но и служебные проходы между его собственными механизмами.
Технические источники
- CVE-2019-11043, запись CVE: https://www.cve.org/CVERecord?id=CVE-2019-11043
- Документация PHP-FPM: https://www.php.net/manual/en/install.fpm.configuration.php
- Документация systemd.exec: https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
- Технический разбор Qualys: https://blog.qualys.com/product-tech/2019/10/30/php-remote-code-execution-vulnerability-cve-2019-11043