# Заздравяване (hardening) на сървъри за PHP

> Заздравяване на сървър за PHP: разделяме уебсайтовете, настройваме сигурно php.ini, правата и достъпите и документираме всяка промяна на Вашите уеб сървъри.

Източник: https://phpsos.de/bg/leistungen/server-haertung/  
Актуалност: 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

**Накратко:** Който иска да заздрави сървъра си за PHP, се грижи една-единствена уязвимост да не отваря целия сървър. Разделяме уебсайтовете един от друг, настройваме PHP и уеб сървъра сигурно, ограничаваме правата и достъпите и документираме всяка промяна. Така щетите остават по-малки, ако все пак нещо се случи.

## Защо заздравяването стана по-важно след PHP2Shell

PHP2Shell показа колко бързо една уязвимост в самия PHP се превръща в проблем за всички уебсайтове на един сървър. Чрез CVE-2026-109618 и CVE-2026-109619 атакуващите могат да изпълняват код без удостоверяване. Пачът затваря тази врата. Заздравяването отговаря на друг въпрос: какво може да направи някой, който въпреки това влезе, през тази или през следващата уязвимост?

На незаздравен сървър често всички уебсайтове работят под един и същи потребител, PHP има право да изпълнява системни команди, а данните за достъп са четими за всички процеси. Проникване в малък страничен сайт стига тогава чак до онлайн магазина. Доброто заздравяване разделя тези области. То не е еднократно действие, а базово състояние, което трябва да се запази при всеки нов уебсайт и при всяка смяна на версия.

## Заздравяване на сървър за PHP: какво конкретно настройваме

### Изолация за всеки уебсайт

Всеки уебсайт получава собствен системен потребител и собствен PHP-FPM пул. С `open_basedir` и подходящи права върху файловете приложението вижда само собствената си директория. Повече има на страницата [open_basedir и изолация за всеки уебсайт](https://phpsos.de/bg/ratgeber/open-basedir/).

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

Настройваме php.ini и конфигурацията на пула така, че приложенията да не могат сами да презаписват стойности, свързани със сигурността. Откъс как може да изглежда това в един FPM пул:

```ini
; Стойностите се задават твърдо в FPM пула и не могат да се променят чрез ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
```

Кои функции могат допълнително да се блокират, зависи от приложението. Бележки по темата има на страниците [Как да конфигурирате php.ini сигурно](https://phpsos.de/bg/ratgeber/php-ini-sicher-konfigurieren/) и [Правилно използване на disable_functions](https://phpsos.de/bg/ratgeber/disable-functions/).

### Права върху файловете и достъп за запис

Уеб сървърът има право да пише само там, където е нужно, например в папката за качвания. В директориите за качвания изпълнението на PHP се забранява. Програмният код принадлежи на друг потребител, различен от този, под който работи PHP. Принципите обяснява страницата [Права върху файловете на уеб сървъра](https://phpsos.de/bg/ratgeber/dateirechte-webserver/).

### Достъпи, услуги и протоколи

SSH само с ключ, администраторски интерфейси с двуфакторно удостоверяване, ненужни услуги и портове затворени. Логовете се съхраняват и архивират така, че да са налични и след инцидент. Резервните копия проверяваме дали могат да бъдат възстановени.

### Уеб сървър и хедъри за сигурност

И самият уеб сървър е част от заздравяването: скриване на данните за версията, изключване на списъците с директории, блокиране на достъпа до конфигурационни файлове, архиви и файлове на системи за контрол на версиите и допълнителна защита на администраторските области, например чрез разрешаване само на определени IP адреси. Хедъри за сигурност като Content-Security-Policy или HSTS защитават посетителите на Вашия уебсайт в браузъра.

## Какво често намираме при описа

Много слабости се повтарят от сървър на сървър. Типични са няколко уебсайта под общ потребител, публично достъпни интерфейси на бази данни, стари тестови инсталации в поддиректории, забравени PHP версии до актуалната и резервни копия, които лежат в уеб директорията и могат да се изтеглят. Често липсва и всякакво протоколиране на влизанията или логовете се изтриват след няколко дни.

Нито една от тези точки сама по себе си не е зрелищна. Заедно обаче те решават дали едно проникване остава ограничено до един уебсайт, или засяга целия сървър.

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

1. **Опис:** Събираме операционната система, уеб сървъра, PHP версиите, уебсайтовете, потребителите, отворените услуги и наличните архиви.
2. **План от мерки:** Получавате приоритизиран списък с усилията и възможните последици за всяка точка. Вие решавате какво да се изпълни.
3. **Изпълнение на стъпки:** Променяме конфигурациите след уговорка, тестваме уебсайтовете след всяка стъпка и записваме как всяка промяна може да се върне.
4. **Контрол:** След изпълнението проверяваме ефекта, например дали даден уебсайт наистина вече не може да чете чужди директории.
5. **Предаване:** Получавате документация на новото състояние, която може да следва и Вашият хостинг доставчик или Вашата агенция.

## Какво получавате и какво ни е нужно

Получавате доклад за заздравяването с изходното положение, изпълнените мерки, съзнателно оставените неуредени точки с обосновка и препоръка за редовен контрол. Промените в конфигурационните файлове са документирани проследимо.

От Вас ни е нужно:

- **Root или администраторски достъп** до сървъра, при панели допълнително достъп до панела
- **списък с приложенията** и техните особености, например качвания, интерфейси, cron задачи
- **технически лице за контакт**, което може да потвърждава функциите след промени
- **прозорци за поддръжка** за рестартиране
- **актуално резервно копие** или поръчка предварително да се направи такова

## Какво не обещаваме

Заздравяването не прави един сървър неуязвим. То намалява повърхността за атака и ограничава щетите, но не замества нито актуализациите, нито наблюдението. Непачната PHP версия остава уязвима, колкото и добре да е настроено останалото. Затова свързваме заздравяването с [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/) и препоръчваме след това постоянна грижа чрез [договор за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/).

При споделен хостинг много неща не могат да се настройват, защото хостинг доставчикът задава конфигурацията. Тогава показваме какво е възможно в рамките на Вашия пакет и къде би било разумно преминаване към собствен или управляван сървър.


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

**Какво означава да се заздрави един сървър?**  
Заздравяването означава да се изключи или ограничи всичко, което не е нужно за работата. Към това спадат излишни услуги, прекалено широки права, отворени портове и несигурни стандартни настройки. Целта е една-единствена грешка да не отваря веднага целия сървър.

**Би ли предотвратило заздравяването PHP2Shell?**  
Не, срещу уязвимост в самия PHP помага само пачът. Заздравяването обаче ограничава какво може да постигне атакуващият след успешно проникване, например дали може да достигне други уебсайтове или данни за достъп.

**Ще се счупи ли уебсайтът ми от заздравяването?**  
Рискът съществува, ако настройките се променят без тест. Внасяме промените стъпка по стъпка, проверяваме функциите след всяка стъпка и записваме как всяка промяна може да се върне.

**Колко често трябва да се проверява заздравяването?**  
Най-късно след по-големи актуализации, смяна на PHP версията или нови приложения на сървъра. Разумен е редовен контрол в рамките на текущата поддръжка.

## Източници

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: Съобщения за сигурност](https://www.php.net/)