# Как сами да обезопасите root сървър и vServer

> Защита на vServer след PHP2Shell: проверка на PHP пакетите, разпознаване на бекпортове, рестарт на работните процеси и трайно укрепване на root сървъра.

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

**Накратко:** Който сам управлява root сървър или vServer, трябва след PHP2Shell сам да го и обезопаси: да доведе PHP пакетите до коригирано състояние, да рестартира всички PHP процеси и да провери резултата. Операторът на центъра за данни по правило се грижи само за хардуера, виртуализацията и мрежата. След това си струва сървърът да се укрепи трайно.

## Вашата отговорност при собствен сървър

При неуправляван root сървър или vServer наемате изчислителна мощ, а не обслужване. Операционната система, уеб сървърът, PHP, базата данни, защитната стена, резервните копия и наблюдението са във Ваши ръце. За ръководството и собствениците това означава: ако никой във фирмата или при външен доставчик на услуги не е поел изрично тези задачи, никой не ги изпълнява.

PHP2Shell го прави видимо. Двете уязвимости CVE-2026-109618 и CVE-2026-109619 са в самия PHP и позволяват изпълнение на код без вход в системата. Проектът PHP публикува на 21.10.2026 г. версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35. BSI (Федерална служба за информационна сигурност на Германия) препоръчва незабавна актуализация, а когато това не е възможно, уеб сървърът да се изключи временно от мрежата.

## Защита на vServer: проверка на наличното и на състоянието на пакетите

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

```bash
# Debian/Ubuntu: инсталирани PHP пакети и откъде идват
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'

# Какви PHP изпълними файлове изобщо има?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
```

Само номерът на версията не е достатъчен. Дистрибуциите често доставят корекциите за сигурност като бекпорт и тогава показаният номер остава по-стар. Решаващ е дневникът на промените на пакета.

```bash
# Debian/Ubuntu (името на пакета е пример)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# Семейство RHEL (името на пакета е пример)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
```

Подробно ръководство има в [Проверка на версията на PHP и на състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).

## Внесете актуализацията и обновете всички процеси

Внесете актуализациите чрез управлението на пакетите и след това рестартирайте всяка услуга, която зарежда PHP. В зависимост от построението това са PHP-FPM, Apache с mod_php, LiteSpeed или сървър за приложения. Новите файлове на диска не са достатъчни, докато стари процеси продължават да работят в паметта.

```bash
# Намиране на услугите с PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Показване на процесите с време на стартиране
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu: разпознаване на програми със стари библиотеки (ако е инсталирано)
needrestart -r l
```

Всеки съществен процес трябва да е стартиран след актуализацията. Полезен е инструментът `needrestart` в системите на Debian, който показва услуги със стари библиотеки. Подробности за рестарта описва [Рестартиране на PHP-FPM и на всички работни процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/).

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

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

```bash
# PHP файлове, променени от 17.10.2026 г. насам (пътят е пример)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Мрежови връзки със съответния процес
ss -tupn
```

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

## Трайно укрепване на сървъра

След острия пач следва основната защита. Тя не предотвратява всяка уязвимост, но ограничава щетите и съкращава времето за реакция следващия път. Доказали са се следните точки:

- **Достъпи:** SSH само с ключ, без директен вход като root, интерфейсите за управление достъпни само от познати мрежи.
- **Защитна стена:** отваряйте само портовете, които наистина са нужни, ограничете изходящите връзки на уеб сървъра.
- **Конфигурация на PHP:** изключете опасните функции, `open_basedir` за всеки уебсайт, отделни пулове и потребители за всяко приложение.
- **Права върху файловете:** уеб сървърът не бива да може да записва програмен код, директориите за качване не изпълняват PHP.
- **Актуализации:** внасяйте актуализациите за сигурност автоматично, планирайте твърдо рестарт и проверка.
- **Резервни копия:** копия по правилото 3-2-1, поне едно копие извън сървъра и защитено от промяна.
- **Протоколи:** събирайте логовете централно и ги пазете достатъчно дълго.

Как изглежда надеждното резервно копие, описва [Резервни копия по правилото 3-2-1](https://phpsos.de/bg/ratgeber/backups-3-2-1/). Като рамка за фирми е подходящ IT-Grundschutz на BSI.

## Кога управляваният сървър е по-добрият избор

Собственият сървър си струва, когато някой поеме надеждно поддръжката: следене на актуализациите, оценка на ситуации като PHP2Shell, възможност за реакция през нощта. Ако този капацитет липсва, смисъл има или управляван сървър, или постоянен договор за поддръжка. И в двата случая е важно отговорностите да се запишат писмено. Повече по темата има в [Управляван сървър: изяснете отговорността](https://phpsos.de/bg/server/managed-server/).

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

- Описваме всички PHP инсталации, източници на пакети и услуги на Вашия сървър и оценяваме действителното състояние на пача.
- Внасяме актуализациите, рестартираме всички процеси и документираме резултата.
- Проверяваме сървъра за следи от компрометиране и запазваме логовете за по-късен анализ.
- В рамките на нашето [укрепване на сървъри](https://phpsos.de/bg/leistungen/server-haertung/) настройваме правилно достъпите, защитната стена, PHP пуловете и правата.
- При желание поемаме текущата поддръжка чрез [договор за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/).


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

**Пачва ли центърът за данни моя vServer автоматично?**  
При неуправляваните root сървъри и vServer по правило не. Доставчикът осигурява хардуера или виртуализацията и мрежата, а операционната система и всички услуги върху нея управлявате сами. При съмнение проверете договора си.

**Достатъчни ли са автоматичните актуализации за сигурност?**  
Те помагат, но не заместват проверката. Автоматичните актуализации не винаги рестартират работещите PHP процеси и често не обхващат пакети от външни източници. След всяка актуализация за сигурност проверявайте състоянието на пакетите и времето на стартиране на процесите.

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

**Какво да направя, ако за моята версия на PHP не излезе пач?**  
PHP 8.1 и по-стари вече не получават официални актуализации. Приложете временните мерки по php.net, планирайте бързо преминаване към поддържана версия и при нужда изключете сървъра временно от мрежата според препоръката на BSI.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: Поддържани версии](https://www.php.net/supported-versions.php)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)