Сигурна конфигурация на Apache за PHP

Накратко: За да конфигурирате Apache за PHP сигурно, свържете PHP през PHP-FPM и mod_proxy_fcgi, изключете .htaccess с AllowOverride None и задайте ServerTokens Prod, ServerSignature Off, TraceEnable Off и Options -Indexes. LimitRequestBody съобразете с лимитите на PHP, ненужните модули изключете. Конфигурацията не замества актуализацията на PHP, но осезаемо намалява повърхността за атака.

Apache след PHP2Shell: повече от едно рестартиране

Операторите на Apache през октомври 2026 г. бяха под особен натиск. Екипът на PHP оценява риска при mod_php като най-висок, защото там е показан експлойт още преди изобщо да работи кодът на приложението. Острите стъпки, тоест пачване и пълно рестартиране, описва страницата Защо mod_php носи най-големия риск.

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

Тази статия описва стегната, сигурна основна конфигурация за Apache 2.4 с PHP-FPM. Примерите ползват пътищата на Debian и Ubuntu; при семейството RHEL файловете са в /etc/httpd/.

Свързване на PHP през PHP-FPM вместо mod_php

С PHP-FPM PHP работи в собствени процеси, отделно от уеб сървъра. Apache предава заявките през mod_proxy_fcgi. Според документацията на Apache свързването чрез SetHandler има предимство пред ProxyPassMatch: Apache първо сам съпоставя заявката с файл във файловата система и едва след това предава към PHP-FPM.

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>

Модулите активирате при Debian и Ubuntu с a2enmod proxy_fcgi. Който преминава от mod_php, деактивира модула на PHP и след това сменя от Prefork към Event MPM. Контекст за стария режим на работа обяснява mod_php обяснен: PHP в процеса на Apache.

От страна на PHP-FPM security.limit_extensions = .php принадлежи във всеки пул. Според ръководството на PHP FPM иначе изпълнява и файлове .phar.

Сигурна конфигурация на Apache за PHP: основните опции

Някои настройки важат за целия сървър и принадлежат в отделен конфигурационен файл, например /etc/apache2/conf-available/haertung.conf, активиран с a2enconf haertung.

# Съкращаване на данните за версията (възможно само за целия сървър)
ServerTokens Prod
ServerSignature Off

# Изключване на метода TRACE
TraceEnable Off

# По принцип нищо не се разрешава, сайтовете разрешават целенасочено
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

Следната таблица подрежда най-важните опции. Стойностите по подразбиране и ефектът идват от документацията на Apache.

Важно при AllowOverride: много дистрибуции и ръководства за CMS задават за уеб корена AllowOverride All. Така всеки файл .htaccess може да променя правила за пренаписване, обработчици и при mod_php дори настройки на PHP. Нападател с права за писане в папка за качване може да постави там собствен .htaccess. С AllowOverride None този път е затворен.

VirtualHost като шаблон

Следният VirtualHost свързва точките за един отделен сайт. Пътищата до сертификатите, сокета и директориите адаптирайте. mod_ssl и mod_headers трябва да са активни.

<VirtualHost *:443>
    ServerName www.example.de
    DocumentRoot /var/www/seite1/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/seite1/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/seite1/privkey.pem

    <Directory /var/www/seite1/public>
        Options -Indexes +SymLinksIfOwnerMatch
        AllowOverride None
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
    </FilesMatch>

    # Блокиране на управлението на версии и файловете на средата
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, съобразено с post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>

Двойното Header unset не е пропуск. Според документацията на Apache заглавията от mod_proxy_fcgi попадат в друга вътрешна таблица от заглавията на самия сървър; с двата варианта улавяте и двата случая. Други заглавия, които активно защитават посетителите, описва ръководството Хедъри за сигурност на уебсайтове.

Папките за качване и кеш се нуждаят допълнително от блокиране на изпълнението. Как да намерите и блокирате всички папки, в които може да се пише, е описано в Забрана за изпълнение на PHP в папки за качване.

Изчистване на модулите и проверка на резултата

Всеки зареден модул е код, който реагира на заявки. Проверете кои модули са активни и изключете ненужните. Типични кандидати са autoindex, status без ограничение на достъпа, cgi и userdir.

# Показване на активните модули
apachectl -M | sort
# Пример Debian/Ubuntu: изключване на модула за списъци на директории
sudo a2dismod autoindex
# Проверка на конфигурацията и едва след това презареждане
sudo apachectl configtest && sudo systemctl reload apache2
# Тест отвън: TRACE трябва да върне 405, .git 403
curl -s -o /dev/null -w "%{http_code}\n" -X TRACE https://www.example.de/
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD

Особено внимание заслужава mod_status. Статус страницата показва работещите заявки с адреси и извикани пътища. Ако е нужна, ограничете достъпа с Require ip до Вашите мрежи за администриране. Същото важи за статус страниците на PHP-FPM, направени достъпни през Apache.

Като допълнителен слой пред приложението може да е смислена собствена Web Application Firewall; въведение дава Внедряване на ModSecurity и OWASP Core Rule Set.

Извод: редът побеждава единичната мярка

Сигурната конфигурация на Apache за PHP се състои от малко, добре разбрани градивни елементи. PHP работи през PHP-FPM отделно от уеб сървъра, .htaccess не се обработва, данните за версията и TRACE са изключени, лимитите за размер съответстват на PHP, а папките, в които може да се пише, не изпълняват скриптове. Нито една от тези точки сама по себе си не е впечатляваща. Заедно те гарантират, че грешка на едно място не води веднага до превземане на сървъра.

За ръководството и отговорниците на проекти едно второ свойство е почти по-важно: подредената конфигурация е проследима. Ако всички правила са във VirtualHost, а не разпръснати в десетки файлове .htaccess, при следващата критична уязвимост бързо може да се провери кой сайт как е свързан. В положение като това през октомври 2026 г. това спестява точно времето, което е от значение.

Все пак планирайте прехода спокойно и с тестова среда. Прибързана смяна от mod_php на PHP-FPM малко преди уикенд по-скоро създава нови проблеми, отколкото решава.

Как помага PHP SOS конкретно?

• Проверка на наличното: прочитаме цялата конфигурация на Apache, всички активни модули и всички файлове .htaccess.
• Планиране на прехода: където още работи mod_php, подготвяме прехода към PHP-FPM със собствени пулове за всеки сайт.
• Заздравяване на конфигурацията: задаваме основните опции, пренасяме правилата от .htaccess във VirtualHost и блокираме папките, в които може да се пише.
• Тест и документиране: след всяка промяна проверяваме сайтовете отвън и записваме състоянието в рамките на заздравяването на сървъра.

Често задавани въпроси

Източници

• Apache: основни функции (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: Съобщения за сигурност