Röviden: A PHP2Shellre vonatkozó figyelmeztetés után Németországban weboldalakat állítottak le, médiaértesülések szerint köztük Mainz városi webportálját, valamint a hesseni tartományi kormány és a BKA (a német Szövetségi Bűnügyi Hivatal) oldalait. Elővigyázatosságról volt szó a BSI (a német szövetségi információbiztonsági hivatal) ajánlása nyomán, nem megerősített támadásokról. A vállalatok ebből azt tanulhatják: a leállítás legitim lehetőség, ha a javítás nem azonnal lehetséges, és akkor sikerül a legjobban, ha elő van készítve.
PHP miatt leállított weboldalak: mi történt október 21-én
A PHP biztonsági frissítéseinek napján Németországban számos közületi weboldal nem volt elérhető. Médiabeszámolók szerint Mainz városa elővigyázatosságból leállította központi webportálját. A hivatalok telefonon és e-mailben továbbra is elérhetők maradtak.
Hessenben a hessenschau szerint többek között a tartományi kormány, a Szövetségi Bűnügyi Hivatal, valamint Kassel és Wiesbaden városának oldalai voltak átmenetileg offline. Az Államkancellária műszaki módosításokról beszélt, és nem jelentett támadást. A tartományi oldalak este újra elérhetők voltak. Beszámolók szerint további települések, főiskolák és klinikák is elővigyázatosságból levettek szolgáltatásokat a hálózatról.
A háttérben a BSI PHP2Shellre vonatkozó ajánlása áll: azonnal frissíteni, és ha ez nem megy azonnal, az érintett webszervereket átmenetileg leválasztani a hálózatról. Hogy a BSI részletesen mit javasol, azt a Mit javasol a BSI a PHP2Shellről oldal foglalja össze.
Leállítva nem jelenti, hogy feltörték
A kommentekben és a közösségi hálózatokon az „offline” gyorsan „feltört” lett. Mindazok alapján, amit tudunk, ez téves. A leállítások védelmi intézkedések voltak egy olyan pillanatban, amikor sok üzemeltető még nem tudta biztosan, milyen a szervereik javítási állapota.
A vállalatok számára ez a megkülönböztetés kétszeresen fontos. Először kifelé: aki maga állít le elővigyázatosságból, nevezze is így, és ne hallgasson. Másodszor befelé: a leállítás nem válaszolja meg azt a kérdést, hogy a szervert megtámadták-e korábban. Csak a további kísérleteket állítja meg. A nyomok ellenőrzése továbbra is szükséges.
Egy harmadik pontot gyakran figyelmen kívül hagynak: a leállítás nem semmisíthet meg nyomokat. Aki a leállításhoz egyszerűen újratelepíti a szervert, vagy helyszabadítás miatt töröl naplókat, megfosztja magát attól a lehetőségtől, hogy később tisztázza, mi történt a leállítás előtt. Jobb a webszervert átirányítani egy vészhelyzeti oldalra, vagy kívülről lezárni a hozzáférést, magát a szervert pedig az összes naplóval együtt változatlanul hagyni.
Miért reagáltak így éppen a közületi szervek
A hatóságok gyakran sok weboldalt üzemeltetnek egymás mellett: főportált, szakportálokat, űrlapszolgáltatásokat, egyes hivatalok és intézmények oldalait. Ebben gyakran több szolgáltató is részt vesz. A figyelmeztetés napján sok közigazgatásnak egyszerűen nem volt lehetséges órákon belül minden rendszerhez igazolt javítási állapotot szerezni. Az elővigyázatossági leállítás ebben a helyzetben a leggyorsabb út volt a BSI ajánlásának követésére.
A szervezetileg kinőtt IT-környezetű vállalatoknál a helyzet gyakran hasonló. A „Minden javítva van?” kérdés nem a technikán, hanem az áttekintés hiányán bukik el.
Figyelemre méltó az is, milyen gyorsan tértek vissza a hesseni tartományi oldalak beszámolók szerint: még ugyanazon az estén. Ez megmutatja, hogy egy elővigyázatossági leállítás nem kell hogy napokig tartson. Aki ismeri a rendszereit és uralja a frissítési utat, néhány óra alatt javíthat, ellenőrizhet és újra online mehet. A leállítás ilyenkor csak áthidalja az időt a tisztázásig.
Mikor van értelme az elővigyázatossági leállításnak vállalatoknál
A hatóságok helyzete különleges: sok weboldal, gyakran elosztott gondozásban, és nagy nyilvános láthatóság. A mérlegelés azonban, amely előtt álltak, ugyanaz, mint bármely vállalatnál. A következő áttekintés segít a döntésben:
| Helyzet | Inkább leállítani | Inkább online hagyni |
|---|---|---|
| Javítási állapot | tisztázatlan vagy nem megerősített | javított és igazolt, a folyamatok újraindítva |
| PHP-verzió | 8.1 vagy régebbi, megerősített backport nélkül | támogatott ág, aktuális állapotban |
| Üzemmód | Apache mod_php-vel | javított PHP-FPM, beállított átmeneti intézkedésekkel |
| Adatok a szerveren | ügyféladatok, bejelentkezések, fizetési adatok | tisztán statikus tartalom |
| A szolgáltató elérhetősége | a javítás csak napok múlva lehetséges | a javítás rövidesen ütemezve |
A javítás, a leállítás és a várakozás közötti mérlegelést mélyíti a Javítani, leállítani vagy várni? írás. Hogy mi lehetséges műszakilag átmenetként, ha a frissítés még hiányzik, azt a Azonnali intézkedések javítás nélkül oldal tartalmazza.
Egy webshop vagy ügyfélportál átmeneti leállítása bevételbe kerül. Egy feltört szerver ügyféladatokkal ennél jóval többe kerülhet, egészen a bejelentési kötelezettségekig. Hozza meg a döntést tudatosan, és rögzítse írásban.
Így készítse elő a leállítást
Mainz megmutatta, mi a lényeg: a közigazgatás más csatornákon elérhető maradt. Ez csak akkor sikerül, ha elő van készítve. Ezek a lépések megérik a fáradságot, mielőtt jön a következő éles helyzet:
- Tartson készenlétben vészhelyzeti oldalt: egy statikus, PHP nélküli HTML-oldalt rövid magyarázattal, telefonos és e-mail-elérhetőséggel, és szükség esetén a folyamatban lévő rendelésekre vagy időpontokra vonatkozó tudnivalókkal.
- Határozza meg az átkapcsolás útját: Ki irányíthatja át a weboldalt a vészhelyzeti oldalra, a webszerveren, a DNS-en vagy egy előtét-szolgáltatáson keresztül? Mennyi ideig tart ez?
- Tisztázza a döntési jogosultságot: Ki rendelhet el leállítást, munkaidőn kívül is?
- Ismerje a függő szolgáltatásokat: Függnek-e a weboldaltól interfészek, alkalmazások vagy partnerek? Kit kell előre tájékoztatni?
- Határozza meg a visszatérés feltételeit: igazolt javítás, megtörtént újraindítás, a nyomok első ellenőrzése lelet nélkül.
- Fogalmazza meg előre az üzenetet: két-három mondat ügyfeleknek, partnereknek és a sajtónak.
Hogyan kommunikáljon kifelé ilyen helyzetben, azt a Válságkommunikáció útmutató írja le.
Hogyan segít konkrétan a PHP SOS?
- Döntési alap: Felmérjük a szerverei javítási állapotát, üzemmódját és adathelyzetét, és világos értékelést adunk arról, indokolt-e a leállítás.
- Rendezett leállítás: Átkapcsolunk egy statikus vészhelyzeti oldalra, naplók vagy nyomok elvesztése nélkül.
- Javítás és ellenőrzés: Frissítjük a PHP-t, újraindítjuk az összes folyamatot, és feltűnő jelenségeket keresünk.
- Ellenőrzött visszatérés: A weboldalt csak akkor vesszük újra online, ha a megállapodott feltételek teljesültek és dokumentálva vannak.
A folyamatot a PHP2Shell azonnali segítség írja le.
Összegzés
A hatóságok leállításai nem az irányítás elvesztésének jelei voltak, hanem tudatos óvintézkedések. A vállalatok számára ez az igazi tanulság: offline menni legitim döntés, ha a javítási állapot tisztázatlan. Aki előkészítette a vészhelyzeti oldalt, a felelősséget és a visszatérési feltételeket, az percek alatt meghozza, nem órák alatt.
Gyakori kérdések
Miért állították le a hatósági weboldalakat a PHP miatt?
A BSI (a német szövetségi információbiztonsági hivatal) a PHP2Shell esetében az azonnali frissítést javasolja, és ha az nem lehetséges azonnal, a webszerverek átmeneti leválasztását a hálózatról. Több hatóság elővigyázatosságból követte ezt az ajánlást, amíg a rendszereiket meg nem vizsgálták és nem frissítették.
Azt jelenti egy leállított weboldal, hogy feltörték?
Nem. Az elővigyázatossági leállítás védelmi intézkedés. A hesseni Államkancellária például a hessenschau szerint kifejezetten nem jelentett támadást. Hogy egy szerver érintett volt-e a leállítás előtt, azt csak egy vizsgálat tisztázza.
Meddig maradjon offline egy weboldal?
Addig, amíg a PHP javított állapotban nincs, az összes PHP-folyamat újra nem indult, és a nyomok első ellenőrzése nem hozott feltűnő eredményt. Rögzített időtartam nincs; a hesseni tartományi oldalak beszámolók szerint még ugyanazon az estén újra elérhetők voltak.
Mit mutassak a látogatóknak, amíg a weboldal offline van?
A legjobb egy egyszerű, statikus, PHP nélküli vészhelyzeti oldal rövid magyarázattal és azokkal az elérhetőségekkel, amelyeken Ön elérhető marad. Az oldalnak elő kell lennie készítve, mielőtt szükség lenne rá.