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

> Сигурна конфигурация на Apache за PHP: PHP-FPM чрез mod_proxy_fcgi, AllowOverride None, ServerTokens, TraceEnable и LimitRequestBody - задаване и проверка.

Източник: https://phpsos.de/bg/blog/apache-fuer-php-absichern/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** За да конфигурирате 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 носи най-големия риск](https://phpsos.de/bg/php2shell/mod-php-risiko/).

След пача остава въпросът колко добра е самата конфигурация на 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.

```apache
<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](https://phpsos.de/bg/php/mod-php-erklaert/).

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

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

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

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

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

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

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

| Директива | По подразбиране | Препоръка | Защо |
|---|---|---|---|
| `ServerTokens` | `Full` | `Prod` | заглавието `Server` посочва само „Apache“ |
| `ServerSignature` | `Off` | `Off` | без ред с версия под страниците с грешки |
| `TraceEnable` | `on` | `Off` | TRACE се отхвърля с 405 |
| `Options` | `FollowSymlinks` | `-Indexes`, символни връзки само при съвпадение на собственика | без списъци на директории |
| `AllowOverride` | `None` | `None` | `.htaccess` не се обработва |
| `LimitRequestBody` | 1 GiB (от 2.4.54) | съобразено с `post_max_size` | ранно отхвърляне на големи заявки |

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

## VirtualHost като шаблон

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

```apache
<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` попадат в друга вътрешна таблица от заглавията на самия сървър; с двата варианта улавяте и двата случая. Други заглавия, които активно защитават посетителите, описва ръководството [Хедъри за сигурност на уебсайтове](https://phpsos.de/bg/ratgeber/sicherheits-header/).

Папките за качване и кеш се нуждаят допълнително от блокиране на изпълнението. Как да намерите и блокирате всички папки, в които може да се пише, е описано в [Забрана за изпълнение на PHP в папки за качване](https://phpsos.de/bg/blog/php-in-uploads-verbieten/).

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

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

```bash
# Показване на активните модули
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.

> **Важно:**
> Не превключвайте `AllowOverride` без подготовка. Първо пренесете правилата от всички файлове `.htaccess` във VirtualHost и тествайте сайта върху копие. Иначе пренасочванията и красивите URL адреси след презареждането престават да работят.

Като допълнителен слой пред приложението може да е смислена собствена Web Application Firewall; въведение дава [Внедряване на ModSecurity и OWASP Core Rule Set](https://phpsos.de/bg/blog/modsecurity-owasp-crs/).

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

Сигурната конфигурация на 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 и блокираме папките, в които може да се пише.
- **Тест и документиране:** след всяка промяна проверяваме сайтовете отвън и записваме състоянието в рамките на [заздравяването на сървъра](https://phpsos.de/bg/leistungen/server-haertung/).


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

**Трябва ли още да използвам mod_php?**  
За нови инсталации препоръчваме PHP-FPM през mod_proxy_fcgi. Екипът на PHP оценява риска от PHP2Shell при mod_php като най-висок. При PHP-FPM PHP работи отделно от уеб сървъра, със собствени потребители за всеки сайт и собствени лимити.

**Защо AllowOverride None, ако моят CMS се нуждае от .htaccess?**  
Файл .htaccess може да създаде всеки, който има права за писане в уеб корена, включително внедрен код. С AllowOverride None Apache не обработва такива файлове. Правилата на Вашия CMS тогава пренасяте еднократно във VirtualHost. Това е известно усилие, но прави конфигурацията проследима и по-бърза.

**Мога ли да задавам ServerTokens различно за всеки сайт?**  
Не. Според документацията на Apache ServerTokens важи за целия сървър и не може да се променя за всеки VirtualHost. Той управлява едновременно данните за версията под страниците с грешки, които ServerSignature показва.

**Каква е стойността на LimitRequestBody по подразбиране?**  
От Apache 2.4.54 стойността по подразбиране е 1 GiB, във версия 2.4.53 и по-стари беше неограничена. Задайте стойността в съответствие с post_max_size във Вашата конфигурация на PHP, за да се отхвърлят прекомерно големите заявки още в уеб сървъра.

## Източници

- [Apache: основни функции (core)](https://httpd.apache.org/docs/2.4/mod/core.html)
- [Apache: mod_proxy_fcgi](https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html)
- [Apache: mod_headers](https://httpd.apache.org/docs/2.4/mod/mod_headers.html)
- [php.net: Съобщения за сигурност](https://www.php.net/)