Накратко: ИТ инвентарът за уеб сървъри е списък на всички уебсайтове, портали, магазини и сървъри с данните, които са нужни веднага при съобщение за сигурност: къде работи, с каква версия и начин на работа на PHP, кое приложение, кой е отговорен и кои данни биха били засегнати. Без този списък всяка реакция започва с търсене. С него сверяването при съобщение като PHP2Shell отнема минути вместо дни.
Първият въпрос беше: къде при нас изобщо работи PHP?
Когато PHP проектът публикува пачовете на 21.10.2026 г., а BSI (Федералната служба за информационна сигурност на Германия) препоръча незабавни действия, указанието беше ясно: да се актуализира PHP и да се рестартират всички процеси. За много фирми първата стъпка все пак не беше актуализацията, а инвентаризация. Основният уебсайт беше известен. Но порталът за търговци? Страницата за кариери при друг доставчик? Целевата страница от кампания отпреди три години? Вътрешното уики?
Специализираната преса и измервателните услуги направиха видим мащаба на проблема. Palo Alto Networks (Unit 42) преброи над 22,6 милиона изложени на риск, потенциално уязвими инстанции. Сред тях вероятно има много системи, за които операторите им просто вече не се сещат.
Какво влиза в ИТ инвентара за уеб сървъри
Използваемият инвентар е таблица с един ред за всеки уебсайт или приложение. Тези колони са се доказали:
| Колона | Пример | За какво служи |
|---|---|---|
| Адрес | shop.beispiel.de | еднозначно съотнасяне |
| Предназначение и значение | онлайн магазин, критичен за оборота | приоритизиране |
| Хостинг доставчик или местоположение | управляван сървър при доставчик X | на кого да се звъни |
| Сървър и операционна система | vServer, Debian | път на актуализация, източници за сигурност |
| Уеб сървър и начин на работа на PHP | Nginx с PHP-FPM | риск, напр. mod_php |
| Версия на PHP и състояние на пакета | 8.3, пакет с дата | сверяване със съобщенията |
| Приложение и версия | Shopware, добавки | съобщения на производителя |
| Отговорен вътрешен / външен | ръководител ИТ / агенция Y | кой действа |
| Обработвани данни | клиентски акаунти, поръчки | задължения за уведомяване, спешност |
| Резервни копия | ежедневно, външно, последно тествано на … | възстановяване |
| Последно доказателство за пач | дата и документ | доказателство пред трети лица |
Начинът на работа заслужава особено внимание. При PHP2Shell екипът на PHP определи риска като най-висок при Apache с mod_php. Който знае кои системи работят така, може да се заеме първо с тях. Колоната за състоянието на пакета е важна, защото показваният номер на версията често остава същият след backport-ове; насоки има в Как да проверите правилно версията на PHP и състоянието на пача.
Как да намерите забравените системи
Известните системи се вписват бързо. Истинската работа са неизвестните. Тези източници помагат да ги откриете:
- Домейни и DNS: Прегледайте всички домейни на фирмата и техните поддомейни. Всеки запис, сочещ към уеб сървър, е кандидат.
- Фактури: Счетоводството познава всеки хостинг доставчик, регистратор и облачен доставчик, който получава пари. Това често е най-пълният списък.
- Агенции и отдели: Маркетингът, продажбите и човешките ресурси с удоволствие поръчват уебсайтове директно. Попитайте.
- Известни сървъри: На всеки сървър конфигурацията показва кои уебсайтове той действително обслужва.
- Устройства с уеб интерфейс: NAS, рутери и уреди носят понякога собствен PHP, вижте PHP на NAS, рутери и уреди.
За стъпка 4 на Linux сървъри помагат няколко команди, които само четат. Те показват конфигурираните уебсайтове, PHP услугите и FPM пуловете:
# Конфигурирани уебсайтове (Apache, респективно Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Работещи PHP услуги и процеси
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# FPM пулове под Debian и Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Ако на един сървър работят няколко версии на PHP една до друга, всяка трябва да е в списъка. Всяка трябва да се актуализира и рестартира поотделно.
Вписвайте и системи, които всъщност би трябвало да бъдат изключени. Именно те често още работят, от години не са актуализирани и се забравят. С запис „изключване до …“ задачата остава видима.
Как да поддържате инвентара актуален
Един инвентар е толкова добър, колкото е последното му обновяване. Три правила го поддържат жив. Първо: едно лице е отговорно и се информира при всеки нов уебсайт, всяко преместване и всяко изключване, дори когато работата е извършена от агенция. Второ: веднъж на тримесечие списъкът се сверява с DNS, фактури и конфигурация на сървърите. Трето: инвентарът е част от плана за извънредни ситуации и е на разположение и извън собствения ИТ отдел, например разпечатан.
За фирми с много разпръснати системи, например портали за търговци, конфигуратори и достъпи за доставчици, ИТ сигурност за средния бизнес и индустрията описва типични места за откриване. Как инвентарът се включва в плана за извънредни ситуации, е описано в Как да изготвите ИТ план за извънредни ситуации за уеб сървъри.
Чести грешки при инвентара на уеб сървъри
Много инвентари съществуват, но в критичен момент не помагат. Причините си приличат:
- Само сървъри, без уебсайтове: Списъкът назовава машини, но не и кои уебсайтове работят на тях и кой отговаря за тях по същество. При уязвимост тогава никой не знае кой отдел е засегнат.
- Версия вместо състояние на пакета: „PHP 8.3“ казва малко след PHP2Shell. Едва състоянието на пакета и датата показват дали корекцията е включена.
- Липсват външни системи: Това, което работи при агенция или платформен доставчик, се пропуска, защото „там не сме отговорни“. Отговорността за данните въпреки това остава във фирмата.
- Няма лица за контакт: Запис без име и телефонен номер на отговорното звено губи време в критичен момент.
- Еднократна акция: Инвентарът се изготвя в една кризисна седмица и после никога повече не се отваря. След година голяма част от него вече не отговаря на истината.
Който избегне тези пет точки, при следващото съобщение ще има списък, с който наистина може да се работи.
Как помага PHP SOS конкретно?
- Описваме заедно с Вас всички уебсайтове и сървъри, включително забравените, чрез DNS, фактури, доставчици и конфигурация на сървърите.
- Установяваме за всяка система начин на работа, версия на PHP и действителното състояние на пакета.
- Приоритизираме системите по достъпност, данни и начин на работа и казваме къде трябва да се действа първо.
- Където PHP2Shell още е отворена, затваряме уязвимостта чрез Спешната помощ при PHP2Shell и вписваме доказателството в инвентара.
Извод: Инвентарът е най-незабележимата и същевременно най-ефективна мярка за сигурност. Който знае какво работи, може при следващото съобщение да действа веднага, вместо първо да търси.
Често задавани въпроси
Какви данни са нужни най-малко в инвентара за уеб сървъри?
Адрес на уебсайта, сървър или хостинг доставчик, начин на работа на PHP, версия на PHP със състояние на пакета, приложение с версия, отговорно лице вътре във фирмата и външно, вид на обработваните данни и място на резервните копия. С тези данни всяко ново съобщение за сигурност може бързо да се свери.
Как да открия уебсайтове, за които никой вече не знае?
По няколко пътя едновременно: управление на домейни и DNS зони, фактури от хостинг доставчици и регистратори, въпроси към агенции и отдели, както и конфигурацията на известните сървъри. Така обикновено излизат на бял свят стари страници на кампании, тестови системи и поддомейни.
Кой трябва да поддържа инвентара?
Едно определено лице, обикновено в ИТ отдела или при ръководителя на ИТ. Важно е всяка промяна по уебсайтовете и сървърите да се съобщава там, дори когато я е инициирал отдел или агенция.
Достатъчна ли е една таблица или е нужен софтуер?
За повечето средни фирми е достатъчна добре поддържана таблица. Софтуерът си заслужава, когато много системи трябва да се отчитат автоматично. Решаваща е актуалността, а не инструментът.