Paaiškėjus kritinėms PHP saugumo spragoms, prie kai kurių projektų sėdome jau tą pačią naktį.

Nepamenu tokios situacijos: iš anksto paskelbiama atnaujinimo išleidimo valanda, o tu su partneriais planuoji, ką iki jos reikia padaryti ir kaip greitai galėsi atnaujinti sistemas.

Kalbame apie dvi spragas, kurių pavojingumas, NKSC duomenimis, įvertintas 9,2 balo iš 10.

Jas išnaudojus būtų galima nuotoliniu būdu vykdyti kenkėjišką kodą serveryje. Jos palietė ir labai senas PHP versijas. Vadinasi, susirūpinti teko ir dėl prieš daugelį metų paleistų svetainių, kurių niekas nebeatnaujina ir nebeprižiūri. Veikia, tai niekas ir nesuka galvos.

Manau, daliai organizacijų dabar teks apsispręsti: senus projektus atnaujinti, perdaryti ar uždaryti. Ši situacija man paliko tris pamokas, kuriom dalinuosi:

1. Lenktynėms kas pirmesnis geriau pasiruošti iš anksto.

DI padeda testuoti sistemų saugumą ir atrasti spragas. Tačiau juo naudojasi ir įsilaužėliai – ieškodami silpnų vietų ir būdų jas išnaudoti.

Pasirodžius saugumo atnaujinimui, galima analizuoti, kas kode pasikeitė ir kaip atakuoti dar neatnaujintas sistemas. DI gali pagreitinti šį procesą, o automatizuoti įrankiai – pažeidžiamų projektų paiešką.

Todėl manau, kad tokių ir panašių situacijų tik daugės. Turime būti pasiruošę veikti greitai.
Neužtenka žinoti, kad atnaujinimas bus. Reikia iš anksto susitarti, kas jį įdiegs, kas patikrins projektą ir kas priims sprendimą, jeigu svetainę teks laikinai išjungti.

2. Labai aiškiai pamatai partnerių vertę.

Dirbame su hostingo paslaugų partneriais Lietuvoje ir Nyderlanduose. Šįkart labai pasimatė, kiek reiškia jų pasiruošimas.

Partneriai iš anksto informavo, kas laukia, susiderinome veiksmus. Laukdami saugumo pataisymų, dalį projektų nusprendėme porai valandų išjungti, kad sumažintume įsilaužimo riziką. Pasirodžius atnaujinimams – įdiegėme, patikrinome ir vėl paleidome.
Kai kiekvienas žino, ką daro, galima ramiau miegoti. Bet naktį, gavus pranešimą apie kritinę spragą, jau vėlu pradėti aiškintis, kas už ką atsakingas. Verta tą išsiaiškinti su partneriais iš anksto.

3. Negalime turėti „miegančių“ projektų be priežiūros.

Svetainė sukurta prieš daug metų. Veikia. Priežiūrai biudžeto nėra. Taip nutinka verslui, valstybinėms įstaigoms, NVO.

O tada paaiškėja kritinė spraga. Reikia atnaujinti PHP, bet su naujesne versija senas projektas – nebeveikia. Vien įdiegti atnaujinimą nebepakanka.

Kai kurioms senoms PHP versijoms šįkart buvo parengti išimtiniai pataisymai. Tačiau negalime planuoti priežiūros tikėdamiesi tokių išimčių.

Jeigu projekto negalima saugiai atnaujinti, gali tekti riboti jo prieinamumą arba laikinai išjungti. Kai kuriems projektams tai gali reikšti ir sprendimą juos uždaryti visam laikui.
Todėl dabar gera proga peržiūrėti visus prieš kelerius metus paleistus ir pamirštus projektus. Ar jų dar reikia? Kas juos prižiūri? Ar juos apskritai dar galima atnaujinti ar reikia uždaryti?
Su šiuo saugumo atnaujinimu namų darbai tikrai nesibaigs.