Уязвимость mod_php: риски и как защитить сайты

Как работает mod_php

mod_php (в системе это библиотека `libphp`) подключается к веб-серверу Apache как обычный модуль. Интерпретатор PHP загружается прямо в рабочие процессы Apache. Когда приходит запрос к файлу `.php`, Apache не обращается к отдельной программе: он сам выполняет код внутри своего процесса. Поэтому mod_php быстр и прост в настройке.

У этой схемы есть следствие. Процессы Apache запускаются от имени одного пользователя, указанного в конфигурации: `www-data` в Debian и Ubuntu, `apache` в семействе RHEL. Значит, и PHP-код каждого виртуального хоста исполняется с одними и теми же правами. Для операционной системы разницы между `site-a.ru` и `shop-c.ru` нет: это один и тот же пользователь.

Как выглядит атака на практике

Типичный сценарий начинается не с mod_php, а с уязвимого плагина, устаревшей CMS или формы загрузки файлов без проверки. Злоумышленник заливает на сайт небольшой PHP-скрипт (веб-шелл). Дальше всё определяет то, под каким пользователем он выполняется.

При mod_php этот скрипт получает права `www-data`. Он читает `wp-config.php` и `.env` соседних проектов, забирает пароли от баз данных, перебирает каталоги в `/var/www`, внедряет вредоносный код в чужие файлы, если у пользователя Apache есть на них запись. В итоге заражается не один сайт, а весь сервер. Владельцы замечают это обычно по спаму в выдаче Яндекса и Google или по санкциям в панелях вебмастеров.

Prefork, память и риск отказа в обслуживании

Второй блок проблем связан с производительностью, но он влияет и на безопасность. Классическая сборка PHP для mod_php не потокобезопасна, поэтому Apache приходится запускать в режиме `prefork`: один процесс на одно соединение. Каждый такой процесс несёт в памяти интерпретатор PHP и расширения, даже если отдаёт обычную картинку или файл стилей.

Предел `MaxRequestWorkers` быстро заканчивается. Медленные соединения в стиле Slowloris, всплеск ботов или спонтанный наплыв посетителей занимают все процессы, и сайт перестаёт отвечать. При PHP-FPM статику отдаёт веб-сервер, а PHP вызывается только для динамических запросов, поэтому тот же сервер выдерживает заметно больше одновременных подключений.

Когда mod_php ещё допустим

Говорить, что mod_php нужно удалить везде, неверно. Если на сервере работает один сайт или несколько проектов одного владельца, где компрометация одного всё равно означает компрометацию остальных, изоляция нужна меньше. На небольшом лендинге или учебном стенде mod_php не создаёт дополнительного риска по сравнению с другими схемами.

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

Что проверить после переключения

Чаще всего после миграции ломаются сайты, которые полагались на `.htaccess` с директивами `php_value`. Их нужно перенести в конфигурацию пула или в файл `.user.ini`. Ещё один частый случай — права на каталоги кеша и загрузок: после смены владельца пользователь пула должен иметь в них запись, а остальные — нет.

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

Почему защита работает только в комплексе

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

Что делать, если сайт уже взломан

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