Īsi sakot: Kam pēc drošības incidenta jāmaina hostinga sniedzējs, vispirms jāsaglabā pierādījumi un jānoskaidro incidents, tad uz no jauna uzstādītu sistēmu jāpārnes tikai pārbaudīti dati un tikai pēc tam jāpārtrauc vecais līgums. Jauno sniedzēju izvēlieties pēc drošības kritērijiem: pierādāmi ielāpošanas procesi, klientu nošķiršana, piekļuve žurnāliem, rezerves kopijas un skaidri kontaktu partneri. Hostinga sniedzēja maiņa ir lietderīga, ja trūkst uzticības vai pakalpojuma kvalitātes, taču tā neaizstāj attīrīšanu.
Ja uzticība ir zudusi
Pēc PHP2Shell daudzi uzņēmumi savu hostinga sniedzēju pirmoreiz piedzīvo zem spiediena. Daži ātri saņēma skaidru informāciju par ielāpa stāvokli. Citi dienām gaidīja atbildi, saņēma tikai vispārīgas frāzes vai konstatēja, ka viņu vietne darbojas ar novecojušu PHP versiju. Ja tam pievienojas vēl incidents, vēlme mainīt sniedzēju ir saprotama.
Hostinga sniedzēja maiņa tomēr nav incidenta pārvarēšanas solis, bet jaunā nostādījuma solis pēc tā. Kas to dara nepareizā secībā, sliktākajā gadījumā paņem līdzi uzbrucēju un vienlaikus zaudē pēdas, kas parāda, kas noticis.
Pareizā secība maiņas laikā
- Saglabājiet pēdas, kamēr tās vēl ir. Vecās sistēmas žurnāli, faili un datubāze jāiekļauj rezerves kopijā, pirms kaut kas tiek dzēsts vai uzteikts. Skaidri pieprasiet vecajam hostinga sniedzējam piekļuves un kļūdu žurnālus no 2026. gada 20. oktobra un jautājiet par to glabāšanas ilgumu. Kā rīkoties, apraksta raksts Saglabājiet pierādījumus, pirms uzstādāt no jauna.
- Ierobežojiet incidentu. Kuras sistēmas ir skartas, kuras piekļuves tika izmantotas, kuri dati bija sasniedzami? No tā ir atkarīgi ziņošanas pienākumi un jautājums, ko drīkstat paņemt līdzi.
- Pārbaudiet ziņošanas pienākumus. Ja var būt skarti personas dati, termiņš iespējamam VDAR ziņojumam sākas, kad uzzināts par incidentu, nevis pārcelšanās brīdī. Fona informācija ir lapā VDAR ziņošanas pienākums: 72 stundas.
- Jauno sistēmu uzbūvējiet tīru. Atbalstīta PHP versija, aktuālas pakotnes, nostiprināta konfigurācija, pirms tiek pārnests pirmais fails.
- Pārnesiet tikai pārbaudīto. Kods no tīra avota, datubāze un multivide pēc pārbaudes.
- Nomainiet visus piekļuves datus. Datubāze, administratoru konti, SSH, FTP, API atslēgas, arī tās, kas atrodas konfigurācijas failos.
- Pārslēdziet un novērojiet. DNS pārslēgšana, pēc tam kādu laiku stingrāka uzraudzība.
- Pārtrauciet veco līgumu. Tikai tad, kad žurnāli un rezerves kopijas ir nodrošinātas un jaunā darbība ir stabila.
Neuzsakiet veco līgumu, kamēr žurnāli un rezerves kopijas nav jūsu rokās. Beidzoties līgumam, pie sniedzēja var tikt izdzēsti dati, kas jums vajadzīgi apdrošinātājam, iestādēm vai pašu izmeklēšanai.
Ko nevajadzētu pārnest
Ērti būtu vienkārši nokopēt visu tīmekļa direktoriju vai servera attēlu. Tieši tas pēc incidenta ir riskanti. Webshell maskējas kā nekaitīgi faili, slēptās piekļuves atrodas konfigurācijas failos, piemēram, .htaccess vai .user.ini, un ievadīts kods var atrasties datubāzes saturā.
Tāpēc lietojumprogrammas kodu pārnesiet no tīra avota, piemēram, ražotāja pakotnes piemērotajā versijā vai jūsu versiju kontroles sistēmas. Multividi pārņemiet bez izpildāmiem failiem, datubāzi pēc pārbaudes uz uzkrītošu saturu un jauniem administratoru kontiem. Ko atradāt vecajā sistēmā, palīdz šajā pārbaudē.
Padomājiet arī par visu, kas pie vecā sniedzēja atrodas blakus vietnei. E-pasta kastītes, DNS ieraksti, sertifikāti un pāradresācijas pārcelšanās laikā viegli tiek aizmirsti. Dažas dienas pirms pārslēgšanas samaziniet DNS ierakstu derīguma laiku, lai pārslēgšana ātri sasniegtu apmeklētājus. Ja līdzi pārceļas arī e-pasts, plānojiet pastkastīšu maiņu atsevišķi, jo arī tur pēc incidenta var būt skarti piekļuves dati.
Jauno hostinga sniedzēju izvēlēties pēc drošības
Cena un diska vieta ir katrā piedāvājumā. Izšķirošie drošības jautājumi jums parasti jāuzdod pašam. Šis saraksts palīdz salīdzināšanā:
| Kritērijs | Jautājums sniedzējam | Kāpēc tas ir svarīgi |
|---|---|---|
| Ielāpošanas process | Kā un kādā ietvarā tiek ieviesti PHP drošības atjauninājumi un veikta pārstartēšana? | PHP2Shell parādīja, cik svarīgs ir pierādāms process |
| Pierādījums | Vai pēc pieprasījuma saņemu rakstisku apstiprinājumu par ielāpa stāvokli? | Pamats jūsu pašu dokumentācijai |
| PHP versijas | Kādi atzari tiek piedāvāti un cik ilgi vēl? | Veci atzari bez atjauninājumiem ir pastāvīgs risks |
| Nošķiršana | Vai katra vietne darbojas ar savu lietotāju un savu PHP procesu? | Ierobežo bojājumus, ja uzbrūk kaimiņam |
| Žurnāli | Vai man ir piekļuve piekļuves un kļūdu žurnāliem, cik ilgi tie tiek glabāti? | Bez žurnāliem nav izmeklēšanas |
| Rezerves kopijas | Cik bieži, cik ilgi, atsevišķi no tīmekļa servera, ar atjaunošanas testu? | Atjaunošana pēc incidenta |
| Ārkārtas kontakts | Kā incidenta gadījumā sazināties ar kompetentu personu? | Nopietnā gadījumā laiks ir visdeficītākais faktors |
| Datu apstrāde | Vai ir VDAR atbilstošs līgums un apakšuzņēmēju saraksts? | Pienākums, ja tiek apstrādāti personas dati |
Paraugu jautājumam par ielāpa stāvokli piedāvā ceļvedis Pajautāt hostinga sniedzējam par ielāpa stāvokli. Tas der arī sniedzēju salīdzināšanai pirms līguma noslēgšanas.
Vai labāka atbilde ir cits darbības modelis?
Dažkārt problēma ir ne tik daudz hostinga sniedzējā, cik darbības modelī. Kas uztur savu serveri bez regulālas kopšanas, ar labi apkalpotu pārvaldīto piedāvājumu bieži ir labāk aizsargāts. Un otrādi, uzņēmums ar savu IT var iegūt lielāku kontroli pār ielāpošanas laikiem, ja pārvalda pats. Šo izvērtējumu apraksta raksts Pārvaldīts hostings vai savs serveris?.
Neatkarīgi no modeļa: uzdevumu sadali nofiksējiet rakstiski. Kas ievieš PHP atjauninājumus, kas veic pārstartēšanu, kas pārbauda lietojumprogrammu, kas ārkārtas gadījumā ar ko sazinās? Pie PHP2Shell daudzi kavējumi radās tieši šajā vietā, jo katra puse domāja, ka otra ar to nodarbosies.
Kā PHP SOS palīdz konkrēti?
- Mēs saglabājam vecās sistēmas žurnālus un datus un noskaidrojam, kas incidenta laikā noticis.
- Mēs jauno sistēmu uzbūvējam nostiprinātu un pārnesam tikai pārbaudītu saturu no tīriem avotiem.
- Mēs pārbaudām jauno sniedzēju piedāvājumus pēc drošības kritērijiem un uzdodam pareizos jautājumus.
- Notiekoša incidenta gadījumā mēs strādājam savas Incident Response ietvaros, līdz incidents ir noslēgts un dokumentēts.
Biežāk uzdotie jautājumi
Vai pēc uzlaušanas hostinga sniedzējs jāmaina nekavējoties?
Ne nekavējoties. Vispirms jāsaglabā pēdas, jāierobežo incidents un jānoskaidro cēlonis. Pārsteidzīga pārcelšanās var līdzi paņemt ļaunprātīgu kodu un iznīcināt pierādījumus pie vecā sniedzēja.
Vai hostinga sniedzējs bija vainīgs, ja mana vietne tika uzbrukta ar PHP2Shell?
Tas atkarīgs no līguma un laika brīža. Koplietošanas hostingā par PHP atjauninājumiem parasti atbild hostinga sniedzējs, pašu serveru gadījumā operators. Ielāpi parādījās 2026. gada 21. oktobrī; vai un kad tie tika ieviesti, var noskaidrot tikai ar pierādījumiem. Atbildības jautājumos konsultējieties ar advokātu.
Kādus datus drīkstu pārnest uz jauno hostinga sniedzēju?
Tikai pārbaudītu saturu: datubāzi pēc pārbaudes uz ievadītu kodu, multividi bez izpildāmiem failiem un kodu no tīra avota, piemēram, ražotāja pakotnes vai jūsu versiju kontroles sistēmas. Pilnus servera attēlus vai tīmekļa direktorijus no kompromitētās sistēmas nevajadzētu pārnest bez pārbaudes.
Vai pēc incidenta jāiesaista datu aizsardzība?
Ja var būt skarti personas dati, var pastāvēt ziņošanas pienākums saskaņā ar VDAR, parasti 72 stundu laikā. Pie jaunā hostinga sniedzēja jums turklāt vajadzīgs datu apstrādes līgums. Noskaidrojiet to ar savu datu aizsardzības speciālistu; šī nav juridiskā konsultācija.