Īsi sakot: White Label IT drošība jūsu aģentūrai nozīmē: jūs paturat attiecības ar klientiem, mēs fonā veicam drošības darbu. PHP2Shell gadījumā tas ir visu klientu vietņu inventārs, prioritizēšana pēc riska, ielāps un pārstartēšana katram serverim un apliecinājums katram klientam, ko varat nodot tālāk.
Kāpēc aģentūras PHP2Shell gadījumā ir īpaši spiestas
Aģentūrai ar daudziem klientiem reti ir vienota ainava. Daļa lapu atrodas uz paša serveriem ar Plesk, daļa pie klientu hostinga sniedzējiem, daži vecie projekti uz PHP versijām, kas jau sen vairs nesaņem oficiālus atjauninājumus. Klāt nāk dažādas sistēmas: WordPress, TYPO3, Shopware, Craft CMS, Laravel pašu izstrādes.
Ievainojamības pašā PHP gadījumā tiek skarti visi projekti vienlaikus. Klienti sagaida atbildi, vai viņu vietne ir droša, un projekta komanda ir noslogota ar notiekošajiem uzdevumiem. Daudzi apkopes līgumi regulē CMS, bet ne serveri zem tā.
Klāt nāk sistēmas, kas vairs neparādās nevienā projektu sarakstā: staging vides apakšdomēnos, kampaņu lapas no pabeigtiem projektiem, izstrādātāju testa instalācijas uz paša vServer. Tās bieži darbojas uz vecākām PHP versijām, netiek uzraudzītas un tomēr nes jūsu aģentūras vai klienta vārdu. Automatizētajai skenēšanai tās ir tikpat redzamas kā galvenā vietne.
Kādus jautājumus jūsu klienti tagad uzdod
- Vai mana vietne ir skarta, un vai tā starplaikā ir ielāpota?
- Vai pirms ielāpa jau kaut kas netika ievadīts?
- Vai CMS atjauninājums skaitās aizsardzība? Nē, CMS atjauninājums PHP ievainojamību neaizver.
- Vai man jāatvieno vietne no tīkla? BSI (Vācijas Federālais informācijas drošības birojs) to iesaka serveriem, kurus nevar atjaunināt nekavējoties.
Uz katru no šiem jautājumiem jūsu aģentūrai nepieciešama pierādāma atbilde par katru klientu, nevis kolektīvs e-pasts ar vispārīgiem apgalvojumiem.
Kā norit White Label IT drošība aģentūrām
Mēs strādājam kā jūsu komandas daļa, bet bez savas saskarsmes ar klientiem. Sadalījums ir skaidrs:
| Uzdevums | Jūsu aģentūra | PHP SOS |
|---|---|---|
| Komunikācija ar klientiem un norēķini | jā | nē |
| Visu klientu vietņu inventārs ar PHP stāvokli | sniedz piekļuves | izveido un uztur |
| Ielāps, pārstartēšana, pārbaude katram serverim | piešķir apkopes logu | veic vai koordinē ar hostinga sniedzējiem |
| Kompromitācijas pārbaude | saņem konstatējumu | meklē webshell un neparastas pazīmes |
| Apliecinājums katram klientam | nodod tālāk | izveido neitrāli vai jūsu formātā |
Vietnēm pie svešiem hostinga sniedzējiem mēs iegūstam pakotnes stāvokļa apstiprinājumu. Redzamais versijas numurs vien nepietiek, jo backport to var atstāt negrozītu.
Vispirms prioritizējiet serverus ar Apache un mod_php, kur PHP komanda risku vērtē kā augstāko, pēc tam veikalus un lapas ar pieteikšanos, tad projektus uz PHP 8.1 un vecākas. Statiskos vecos projektus, kurus neviens vairs nevajag, labāk izslēdziet, nevis ielāpojiet.
Vairākas klientu vietnes vienā serverī: pārbaudīt izolāciju
Aģentūru serveros daudzas klientu vietnes bieži dala vienu mašīnu. Ja viena no tām tiek kompromitēta, nodalījums nosaka, vai uzbrucējs var piekļūt arī citām. Svarīgi ir atsevišķi sistēmas lietotāji un PHP-FPM pūli katrai vietnei, pareizas failu tiesības un ierobežojumi, piemēram, open_basedir. Plesk serveros šos iestatījumus var pārbaudīt katram abonementam.
Pēc ielāpa ir spēkā: pārstartēt visus pūlus un darbprocesus. Tikai tad atmiņā vairs nedarbojas veci PHP procesi. Žurnāli no 20.10.2026 jāsaglabā katrai klienta vietnei.
Informācija klientiem: kas ir pierādīts un kas nav
Lielākā kārdinājums šajā situācijā ir nomierinošs kolektīvs e-pasts. Drošāks ir apgalvojums par katru klientu, kas satur tikai to, kas ir pierādīts: kurš serveris, kāds PHP pakotnes stāvoklis, kad pārstartēts, vai notikusi kompromitācijas pārbaude un ar kādu rezultātu. Kas vēl ir atklāts, arī ir tur norādīts.
Formulējumus, piemēram, „Jūsu vietne ir droša“, labāk izvairieties. Ielāps ievainojamību aizver, bet nepierāda, ka iepriekš nekas nav noticis. Kas to godīgi nodala, vēlāk nav spiests skaidroties, ja tomēr parādās konstatējums.
Apkopes līgumus pēc PHP2Shell pārskatīt
Daudzi aģentūru līgumi regulē CMS un paplašinājumu atjauninājumus, bet par serveri klusē. Izmantojiet situāciju, lai katram klientam fiksētu, kurš atjaunina PHP, kurš atbild par pārstartēšanu, kurš incidenta gadījumā lemj un kuri pakalpojumi tiek pasūtīti atsevišķi. Arī vienošanās par datu apstrādi ar visiem iesaistītajiem pakalpojumu sniedzējiem ir šīs daļa. Līguma izveidi noskaidrojiet ar savu juridisko konsultantu.
Kā PHP SOS palīdz konkrēti?
- Mēs uzņemamies visu klientu vietņu uzskaiti ar PHP versiju, darbības režīmu, hostinga sniedzēju un atbildību.
- Ar mūsu PHP ielāpu pakalpojumu mēs ielāpojam jūsu pašu serverus, pārstartējam visus darbprocesus un apliecinām to katram klientam.
- Mēs pārbaudām prioritizētās vietnes uz kompromitāciju un konstatējuma gadījumā attīrām, līdz incidents ir slēgts un dokumentēts.
- Mēs piegādājam teksta blokus jūsu klientu informēšanai, ko varat pielāgot un nosūtīt paši.
- Pēc tam pēc vēlēšanās ar drošības apkopes līgumu uzņemamies pastāvīgo drošības apkalpošanu fonā.
Biežāk uzdotie jautājumi
Vai jūs uzstājaties pret mūsu klientiem?
Tikai tad, ja to vēlaties. White Label modelī mēs strādājam tikai fonā, un visa komunikācija iet caur jūsu aģentūru. Savu dokumentāciju sniedzam neitrālu vai jūsu formātā.
Vai tam mums vajadzīgs datu apstrādes līgums?
Ja mēs piekļūstam sistēmām ar jūsu klientu personas datiem, parasti ir nepieciešama vienošanās par datu apstrādi, bieži kā apakšapstrāde. Kā tas iekļaujas jūsu esošajos līgumos, noskaidrojiet ar savu juridisko konsultantu. Mēs nodrošinām nepieciešamās ziņas par savām darbībām.
Kā ir ar klientu vietnēm, kuru serverus mēs vispār nepārvaldām?
Ja klientu vietnes atrodas pie svešiem hostinga sniedzējiem, mēs jūsu vārdā vai ar jūsu paraugiem iegūstam apstiprinājumus par ielāpa stāvokli un pārstartēšanu. Kur ir tikai FTP vai CMS piekļuve, mēs pārbaudām, kas no turienes ir iespējams, un atklāti norādām, ko var apliecināt tikai hostinga sniedzējs.
Vai to var pēc PHP2Shell uz pastāvīgu laiku nodot ārpakalpojumā?
Jā. Daudzi uzdevumi atkārtojas pie katras ievainojamības: uzturēt inventāru, ieviest ielāpus, apliecināt pārstartēšanu, ziņot par neparastām pazīmēm. Šo darbu var organizēt kā pastāvīgu apkalpošanu fonā.