Накратко: White Label ИТ сигурността означава за Вашата агенция: Вие запазвате отношенията с клиента, а ние вършим на заден план работата по сигурността. При PHP2Shell това значи опис на всички сайтове на клиенти, приоритизиране по риск, пач и рестартиране за всеки сървър и доказателство за всеки клиент, което можете да предадете нататък.
Защо агенциите са под особен натиск при PHP2Shell
Агенция с много клиенти рядко поддържа еднородна среда. Част от сайтовете са на собствени сървъри с Plesk, част – при хостинг доставчиците на клиентите, някои стари проекти – на версии на PHP, които отдавна не получават официални актуализации. Към това се добавят различни системи: WordPress, TYPO3, Shopware, Craft CMS, собствени разработки на Laravel.
При уязвимост в самия PHP удрят се всички проекти едновременно. Клиентите очакват отговор дали сайтът им е сигурен, а проектният екип е зает с текущи поръчки. Много договори за поддръжка уреждат CMS, но не и сървъра под него.
Към това се добавят системи, които не фигурират в никакъв списък с проекти: staging среди на поддомейни, кампанийни страници от приключили проекти, тестови инсталации на разработчици на собствени vServer-и. Те често работят на по-стари версии на PHP, не се наблюдават и въпреки това носят името на Вашата агенция или на Вашия клиент. За автоматизираните сканирания те са толкова видими, колкото и основният сайт.
Какви въпроси задават сега Вашите клиенти
- Засегнат ли е моят уебсайт и пачнат ли е междувременно?
- Внедрено ли е вече нещо преди пача?
- Смята ли се актуализацията на CMS за защита? Не, актуализацията на CMS не затваря PHP уязвимостта.
- Трябва ли да изключа уебсайта от мрежата? BSI (Федералната служба за информационна сигурност на Германия) го препоръчва за сървъри, които не могат да бъдат актуализирани веднага.
На всеки от тези въпроси Вашата агенция се нуждае от доказуем отговор за всеки клиент, а не от общ циркулярен имейл с общи твърдения.
Как протича White Label ИТ сигурността за агенции
Работим като част от Вашия екип, но без собствен контакт с клиента. Разпределението е ясно:
| Задача | Вашата агенция | PHP SOS |
|---|---|---|
| Комуникация с клиентите и фактуриране | да | не |
| Опис на всички сайтове на клиенти със състоянието на PHP | предоставя достъпи | създава и поддържа |
| Пач, рестартиране, проверка за всеки сървър | одобрява прозорец за поддръжка | изпълнява или координира с хостинг доставчиците |
| Проверка за компрометиране | получава находката | търси уеб шелове и нередности |
| Доказателство за всеки клиент | предава нататък | изготвя неутрално или във Вашия формат |
При сайтове на чужди хостинг доставчици получаваме потвърждение за състоянието на пакета. Показаният номер на версията сам по себе си не стига, защото backport корекциите могат да го оставят непроменен.
Приоритизирайте първо сървърите с Apache и mod_php, където екипът на PHP оценява риска като най-висок, после магазините и сайтовете с вход, после проектите на PHP 8.1 и по-стар. Статичните стари проекти, от които никой няма нужда, по-добре изключете, отколкото да ги пачвате.
Няколко сайта на клиенти на един сървър: проверете изолацията
На сървърите на агенциите често много сайтове на клиенти споделят една машина. Ако един от тях бъде компрометиран, разделянето решава дали атакуващият достига и останалите. Важни са отделни системни потребители и PHP-FPM пулове за всеки уебсайт, чисти права върху файловете и ограничения като open_basedir. На сървъри с Plesk тези настройки могат да се проверят за всеки абонамент.
След пача важи: рестартирайте всички пулове и worker процеси. Едва тогава в паметта не работят стари PHP процеси. Логовете от 20.10.2026 г. трябва да се съхраняват за всеки сайт на клиент.
Информиране на клиентите: какво е доказано и какво не
Най-голямото изкушение в тази ситуация е успокояващият циркулярен имейл. По-безопасно е твърдение за всеки клиент, което съдържа само доказаното: кой сървър, какво състояние на PHP пакета, кога е рестартиран, дали е извършена проверка за компрометиране и с какъв резултат. В него се посочва и какво още е открито.
Формулировки като „Вашият сайт е сигурен“ е по-добре да избягвате. Пачът затваря уязвимостта, но не доказва, че преди това нищо не се е случило. Който разграничава това честно, по-късно не е задължен да се обяснява, ако все пак се появи находка.
Нова уредба на договорите за поддръжка след PHP2Shell
Много договори на агенции уреждат актуализациите на CMS и разширенията, но мълчат за сървъра. Използвайте ситуацията, за да запишете за всеки клиент кой актуализира PHP, кой отговаря за рестартиранията, кой решава при инцидент и кои услуги се възлагат отделно. Към това спада и споразумение за обработване на данни с всички участващи изпълнители. Договорното оформление изяснете със своя правен съветник.
Как помага PHP SOS конкретно?
- Поемаме инвентаризацията на всички сайтове на клиенти с версия на PHP, режим на работа, хостинг доставчик и отговорност.
- Чрез нашата услуга за PHP пачове пачваме Вашите собствени сървъри, рестартираме всички worker процеси и доказваме това за всеки клиент.
- Проверяваме приоритетните сайтове за компрометиране и при находка почистваме, докато инцидентът бъде приключен и документиран.
- Предоставяме текстови блокове за Вашата информация към клиентите, които адаптирате и изпращате сами.
- След това по желание поемаме с договор за поддръжка на сигурността текущата грижа за сигурността на заден план.
Често задавани въпроси
Представяте ли се пред нашите клиенти?
Само ако желаете. При модела White Label работим изцяло на заден план и цялата комуникация минава през Вашата агенция. Нашата документация предоставяме неутрално или във Вашия формат.
Нужен ли ни е за това договор за обработване на лични данни?
Ако получаваме достъп до системи с лични данни на Вашите клиенти, по правило е необходимо споразумение за обработване на данни, често като подизпълнител. Как това се вписва във Вашите съществуващи договори, изяснете със своя правен съветник. Ние предоставяме необходимите данни за нашите дейности.
А сайтовете на клиенти, чиито сървъри изобщо не управляваме?
Ако сайтовете на клиенти са при чужди хостинг доставчици, ние получаваме от Ваше име или по Ваши образци потвърждения за състоянието на пача и рестартирането. Където има само FTP или CMS достъп, проверяваме какво е възможно оттам и открито отбелязваме какво може да докаже само хостинг доставчикът.
Можем ли да възложим това на външен изпълнител трайно и след PHP2Shell?
Да. Много задачи се повтарят при всяка уязвимост: поддържане на опис, инсталиране на пачове, доказване на рестартиранията, съобщаване за нередности. Тази работа може да се организира като текуща грижа на заден план.