Lühidalt: Pärast PHP2Shelli hoiatust lülitati Saksamaal veebisaite välja, meedia andmetel sealhulgas Mainzi linna veebiportaal ning Hesseni liidumaa valitsuse ja BKA saidid. Tegemist oli ennetusega BSI (Saksamaa föderaalne infoturbeamet) soovituse alusel, mitte kinnitatud rünnakutega. Ettevõtted saavad sellest õppida: väljalülitamine on õigustatud võimalus, kui paika ei saa kohe paigaldada, ja see õnnestub kõige paremini, kui see on ette valmistatud.
Veebisaidid PHP tõttu välja lülitatud: mis juhtus 21. oktoobril
PHP turvauuenduste päeval olid Saksamaal arvukad avalikud veebisaidid kättesaamatud. Meediaaruannete kohaselt lülitas Mainzi linn oma keskse veebiportaali ennetavalt välja. Ametid jäid kättesaadavaks telefoni ja e-posti teel.
Hessenis olid hessenschau andmetel ajutiselt võrgust väljas muu hulgas liidumaa valitsuse, Bundeskriminalamti (BKA, Saksamaa föderaalne kriminaalpolitseiamet) ning Kasseli ja Wiesbadeni linnade lehed. Riigikantselei rääkis tehnilistest kohandustest ega teatanud rünnakust. Liidumaa lehed olid õhtul taas kättesaadavad. Aruannete kohaselt võtsid ka teised omavalitsused, kõrgkoolid ja haiglad teenuseid ennetavalt võrgust maha.
Taustaks on BSI soovitus PHP2Shelli kohta: uuendage kohe ja, kui see kohe ei õnnestu, võtke mõjutatud veebiserverid ajutiselt võrgust maha. Mida BSI täpsemalt nõustab, võtab kokku leht Mida BSI PHP2Shelli kohta soovitab.
Väljalülitatud ei tähenda häkitud
Kommentaarides ja sotsiaalvõrgustikes sai „võrgust väljas“ kiiresti „häkitud“. Selle kohta, mis on teada, on see vale. Väljalülitamised olid kaitsemeede hetkel, mil paljud käitajad ei teadnud oma serverite paigatud seisu veel kindlalt.
Ettevõtete jaoks on see eristus kahekordselt oluline. Esiteks väljapoole: kes ise ennetavalt välja lülitab, peaks seda nii nimetama ja mitte vaikima. Teiseks sissepoole: väljalülitamine ei vasta küsimusele, kas serverit rünnati enne. See peatab ainult edasised katsed. Jälgede kontroll jääb vajalikuks.
Kolmas punkt jääb sageli tähelepanuta: väljalülitamine ei tohi jälgi hävitada. Kes serveri väljalülitamiseks lihtsalt uuesti paigaldab või logisid ruumi tegemiseks kustutab, võtab endalt võimaluse hiljem selgitada, mis enne väljalülitamist juhtus. Parem on suunata veebiserver hädaolukorra lehele või sulgeda juurdepääs väljastpoolt ja jätta server ise kõigi logidega muutmata.
Miks just avalikud asutused nii reageerisid
Ametiasutused haldavad sageli paljusid veebisaite kõrvuti: peaportaal, erialaportaalid, vormiteenused, üksikute ametite ja asutuste lehed. Sageli on kaasatud mitu teenusepakkujat. Hoiatuse päeval ei olnud paljudel haldusasutustel lihtsalt võimalik saada mõne tunni jooksul iga süsteemi kohta tõendatud paigatud seisu. Ennetav väljalülitamine oli selles olukorras kiireim viis BSI soovitust järgida.
Kasvanud IT-maastikuga ettevõtetel on olukord sageli sarnane. Küsimus „Kas kõik on paigatud?“ ei ebaõnnestu tehnika, vaid puuduva ülevaate tõttu.
Tähelepanuväärne on ka see, kui kiiresti Hesseni liidumaa lehed aruannete kohaselt tagasi tulid: veel samal päeval õhtul. See näitab, et ennetav väljalülitamine ei pea kestma päevi. Kes oma süsteeme tunneb ja uuendusteed valdab, saab mõne tunniga paigata, kontrollida ja uuesti võrku minna. Väljalülitamine ületab siis ainult aja, kuni selgus käes.
Millal on ennetav väljalülitamine ettevõtetele mõistlik
Ametiasutustel on eriline olukord: palju veebisaite, sageli hajutatult hooldatud, ja suur avalik nähtavus. Kaalutlus, mille ees nad seisid, on aga sama mis igas ettevõttes. Järgmine ülevaade aitab otsustada:
| Olukord | Pigem välja lülitada | Pigem võrku jätta |
|---|---|---|
| Paigatud seis | ebaselge või kinnitamata | parandatud ja tõendatud, protsessid uuesti käivitatud |
| PHP versioon | 8.1 või vanem ilma kinnitatud backportita | toetatud haru ajakohasel seisul |
| Töörežiim | Apache mod_php-ga | paigatud PHP-FPM seatud ajutiste meetmetega |
| Andmed serveris | kliendiandmed, sisselogimised, maksandmed | puhtalt staatiline sisu |
| Teenusepakkuja kättesaadavus | paik võimalik alles päevade pärast | paik lähiajal ajastatud |
Kaalutlust paikamise, väljalülitamise ja ootamise vahel süvendab artikkel Paikamine, väljalülitamine või ootamine?. Mis on tehniliselt üleminekuks võimalik, kui uuendus veel puudub, seisab lehel Kohesed meetmed ilma paigata.
Poe või kliendiportaali ajutine väljalülitamine maksab käivet. Kompromiteeritud server kliendiandmetega võib maksta märksa rohkem, kuni teavitamiskohustusteni välja. Tehke otsus teadlikult ja kirjutage see üles.
Nii valmistate väljalülitamise ette
Mainz näitas, mis loeb: haldus jäi kättesaadavaks teiste kanalite kaudu. See õnnestub ainult siis, kui see on ette valmistatud. Need sammud tasuvad end ära enne, kui järgmine hädaolukord saabub:
- Hoidke hädaolukorra leht valmis: staatiline HTML-leht ilma PHP-ta, lühikese selgituse, telefoni- ja e-posti kontaktiga ning vajaduse korral märkustega pooleli olevate tellimuste või kohtumiste kohta.
- Määrake ümberlülitamise tee: Kes saab veebisaidi hädaolukorra lehele suunata, veebiserveri, DNS-i või eelneva teenuse kaudu? Kui kaua see aega võtab?
- Selgitage otsustusõigus: Kes tohib väljalülitamist korraldada, ka väljaspool tööaega?
- Tundke sõltuvaid teenuseid: Kas liidesed, rakendused või partnerid sõltuvad veebisaidist? Keda tuleb eelnevalt teavitada?
- Määratlege tagasipöördumise kriteeriumid: paik tõendatud, taaskäivitus tehtud, esimene jälgede kontroll ilma leiuta.
- Sõnastage sõnum ette: kaks kuni kolm lauset klientidele, partneritele ja ajakirjandusele.
Kuidas sellises olukorras väljapoole suhelda, kirjeldab juhend Kriisisuhtlus.
Kuidas PHP SOS konkreetselt aitab?
- Otsuse alus: Selgitame välja teie serverite paigatud seisu, töörežiimi ja andmeolukorra ning anname teile selge hinnangu, kas väljalülitamine on näidustatud.
- Korrapärane väljalülitamine: Lülitame staatilisele hädaolukorra lehele, kaotamata logisid ega jälgi.
- Paik ja kontroll: Uuendame PHP, käivitame kõik protsessid uuesti ja kontrollime kõrvalekaldeid.
- Kontrollitud tagasipöördumine: Võtame veebisaidi uuesti võrku alles siis, kui kokkulepitud kriteeriumid on täidetud ja dokumenteeritud.
Käiku kirjeldab PHP2Shelli kohene abi.
Kokkuvõte
Ametiasutuste väljalülitamised ei olnud kontrolli kaotuse märk, vaid teadlik ettevaatusabinõu. Ettevõtete jaoks on see tegelik õppetund: võrgust väljumine on õigustatud otsus, kui paigatud seis on ebaselge. Kes on hädaolukorra lehe, vastutuse ja tagasipöördumise kriteeriumid ette valmistanud, teeb selle otsuse minutitega, mitte tundidega.
Korduma kippuvad küsimused
Miks lülitati ametiasutuste veebisaidid PHP tõttu välja?
BSI soovitab PHP2Shelli puhul kohest uuendust ja, kui see kohe ei õnnestu, veebiserverid ajutiselt võrgust maha võtta. Mitu ametiasutust on seda soovitust ennetavalt järginud, kuni nende süsteemid olid kontrollitud ja uuendatud.
Kas väljalülitatud veebisait tähendab, et see on häkitud?
Ei. Ennetav väljalülitamine on kaitsemeede. Hesseni riigikantselei näiteks ei teatanud hessenschau andmetel selgesõnaliselt ühestki rünnakust. Kas server oli enne väljalülitamist mõjutatud, selgitab alles kontroll.
Kui kaua peaks veebisait võrgust väljas olema?
Seni, kuni PHP on parandatud seisus, kõik PHP protsessid on uuesti käivitatud ja esimene jälgede kontroll ei ole kõrvalekaldeid näidanud. Kindlat kestust ei ole; Hesseni liidumaa saidid olid aruannete kohaselt samal päeval õhtul taas kättesaadavad.
Mida ma külastajatele näitan, kuni veebisait on võrgust väljas?
Kõige parem on lihtne staatiline hädaolukorra leht ilma PHP-ta, lühikese selgituse ja kontaktiteedega, mille kaudu olete kättesaadav. See peaks olema ette valmistatud enne, kui seda vaja läheb.