Накратко: Времевият прозорец между пач и атака при PHP2Shell беше отрицателен: според медийни съобщения имаше първи опит за атака още на 17 октомври 2026 г., четири дни преди актуализациите. За операторите затова не въпросът „Колко време остава?“ е важен, а „Докога е отворен моят сървър?“. Този личен прозорец свършва едва когато актуализацията е инсталирана и всички PHP процеси са рестартирани.
Поводът: атаки преди пача
Дълго важеше едно удобно допускане: между актуализацията за сигурност и първите атаки минават няколко дни, достатъчно за следващия прозорец за поддръжка. PHP2Shell опроверга това допускане. Според медийни съобщения, които се позовават на Amazon, първи опит за атака е наблюдаван още на 17 октомври. Cloudflare също съобщи за ранни атаки. Пачовете дойдоха на 21 октомври в 14:00 UTC.
Тази статия обяснява как възникват такива времеви прозорци и как да съкратите Вашия. Точната последователност на датите ще намерите в хронологията на PHP2Shell.
Времевият прозорец между пач и атака по фази
Около една уязвимост могат да се разграничат няколко фази. При PHP2Shell те изглеждаха така:
| Фаза | Общо | При PHP2Shell |
|---|---|---|
| Преди да стане известна | уязвимостта е известна само на откривателите и на производителя | разработка на поправката под ембарго |
| Първи атаки без пач | нападателите ползват уязвимостта, преди да има актуализация | според медийни съобщения първи опит на 17.10. |
| Предварително известие | производителят обявява актуализация | 20.10., php.net обявява изданието |
| Пач наличен | излизат актуализацията и съобщението за сигурност | 21.10., 14:00 UTC |
| Анализ на пача | изследователи и нападатели анализират промените | watchTowr според собствените си данни е възпроизвела CVE-2026-109618 |
| Масова експлоатация | автоматизирани кампании срещу непачнати сървъри | очаквана от BSI; потвърдени успешни атаки в голям мащаб първоначално не са известни |
| Вашият пач | актуализация и рестарт на Вашите сървъри | индивидуално |
Последният ред е единственият, който можете да повлиявате. Всичко преди него определят други.
Защо самият пач увеличава натиска
Актуализацията за сигурност затваря уязвимостта, но едновременно я прави видима. Промените в изходния код при проекти с отворен код като PHP са публични. Който сравнява разликите между старата и новата версия, научава на кое място е била грешката. Това не е упрек към PHP проекта, а нормалният случай при отворен софтуер и основата дистрибуциите да могат да изграждат backport-ове.
За операторите от това следва: с всеки ден след пача расте броят на онези, които знаят как работи уязвимостта. В същото време намалява броят на непачнатите сървъри. Останалите стават така очевидните цели. Как PHP доставя актуализации за сигурност в рамките на поддръжката на версиите си, обяснява статията за цикъла на издания на PHP.
Ако Вашият сървър е бил достъпен между 17 октомври и Вашия пач, проверката за следи е задължителна. Запазете логовете от 20 октомври, преди да бъдат загубени чрез ротация.
Измерете собствения си времеви прозорец
Вашият личен времеви прозорец започва най-късно с публикуването на пачовете и свършва с рестарта на последния PHP процес. Запишете за всеки сървър:
- Узнаване: Кога някой във фирмата е научил за уязвимостта?
- Наличност: Кога пакетът на Вашата дистрибуция или на хостинг доставчика е бил наличен?
- Инсталиране: Кога е бил инсталиран?
- Рестарт: Кога вече не са работили стари PHP процеси?
Именно рестартът често се забравя. Инсталираната актуализация действа едва когато старите процеси са спрени. Как да проверите това, описва Рестартиране на PHP-FPM и на всички PHP процеси. Дали още работят процеси отпреди актуализацията, показва поглед към времената на стартиране:
# Показване на времето на стартиране на всички PHP процеси
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Ако времето на стартиране е преди инсталирането на актуализацията, прозорецът още е отворен.
Защо Вашият прозорец зависи от пътя на доставка
Колко бързо можете да пачнете, не зависи само от Вас, а и от това откъде идва Вашият PHP. Дистрибуциите според съобщенията на места са доставили backport-ове още на 21 октомври. Който получава PHP от хранилище на трета страна, зависи от неговото темпо. Който ползва контейнери, трябва да изгради наново и да разгърне образите, обикновена актуализация в работещия контейнер не стига. А при споделения хостинг моментът го определя хостинг доставчикът.
Когато познавате пътя на доставка на всеки сървър, знаете и къде Вашият прозорец остава най-дълго отворен. Именно там подготовката си струва най-много, например чрез договорка с хостинг доставчика или изпробван процес за нови контейнерни образи.
Как да съкратите времевия прозорец следващия път
- Абонирайте се за съобщения: Получавайте съобщенията за сигурност на php.net и на Вашата дистрибуция директно, не едва чрез пресата.
- Определете отговорността: За всеки сървър отговорно лице със заместник.
- Ползвайте автоматика, където е подходяща: Актуализациите за сигурност от дистрибуцията могат да се инсталират автоматично. Какво говори за и какво против, описва Автоматични актуализации за сигурност.
- Планирайте рестарта: Рестартът на PHP услугите е твърда част от процеса, не от последващата работа.
- Подгответе авариен път: Страница за извънредни случаи и решение за временно изключване, ако актуализация не е възможна веднага.
- Водете доказателство: Документирайте моментите на инсталиране и рестарт, за да можете по-късно да докажете своя прозорец.
Траен процес, който обединява тези точки, е описан в статията за процеса на управление на пачовете.
Как помага PHP SOS конкретно?
- Пач и рестарт: Инсталираме актуализацията и осигуряваме, че вече не работят стари PHP процеси.
- Доказване на прозореца: Документираме инсталирането и рестарта за всеки сървър с момент.
- Проверка за следи: За времето, в което Вашият сървър е бил отворен, запазваме логове и проверяваме за необичайни находки.
- Процес за бъдещето: Изграждаме с Вас пътища за съобщаване, отговорности и процеси за актуализация.
Повече на услугата за пач на PHP.
Заключение
При PHP2Shell нямаше гратисен период. Времевият прозорец между пач и атака при критични уязвимости днес често е нула или дори отрицателен. Каквото можете да управлявате, е Вашият собствен прозорец: той свършва с рестарта и с подготовка може да се съкрати от дни на часове.
Често задавани въпроси
Колко време остава след актуализация за сигурност до атаките?
Фиксиран срок няма. При PHP2Shell според медийни съобщения първи опит за атака е наблюдаван още на 17 октомври, тоест четири дни преди пачовете. При критични уязвимости в разпространен софтуер приемайте, че практически няма гратисен период.
Какво е Zero-Day?
Уязвимост, която се атакува, преди да има налична актуализация. Производителят е имал, така да се каже, нула дни, за да я поправи. След това често се говори за позната или N-Day уязвимост, за която вече има пач.
Защо атаките след пача често стават по-чести?
С пача става публично известно на кое място е била грешката. Изследователите на сигурността и нападателите могат да анализират промените. В същото време много сървъри остават непачнати още дни или седмици и така са изгодни цели.
Кога сървърът ми е наистина защитен?
Когато актуализацията е инсталирана и всички PHP процеси са рестартирани. Новите файлове сами не действат, докато в паметта работят стари процеси. Краят на Вашия личен времеви прозорец е следователно рестартът, не изтеглянето.