Amikor elkészül egy weboldal, könnyű azt hinni, hogy kész is van. Valójában a szerver, amelyen fut, és a programcsomagok, amelyekből felépül, hétről hétre változnak. Folyamatosan derülnek ki bennük új hibák, és ezeket automatizált programok a bejelentés után gyorsan és tömegesen próbálják ki a weboldalakon. Ön ebből jó esetben semmit sem lát. Mi viszont látjuk, és ez a cikk arról szól, mit csinálunk vele.
Egy novemberi hét a naplónkból
November második hetében a figyelőrendszerünk több olyan, nyilvánosan bejelentett sérülékenységet talált, amely a mi szervereinket vagy az általunk használt programokat érintette. Így kezeltük őket (budapesti idő szerint):
• November 10., két súlyos hiba a PHP-csomagkezelőben (Composer). A bejelentéstől számítva kb. 2 óra alatt minden szerverünkön frissítettük.
• November 10., kritikus rés két webes keretrendszerben, amelyeket az általunk üzemeltetett alkalmazások csak egy kis része használ (Next.js és React Server Components). A hiba bejelentkezés nélküli kódfuttatást tett volna lehetővé.
• November 10., kritikus Linux-kernel hiba. Mielőtt riadót fújtunk, szerverenként ellenőriztük a pontos verziókat: a szervereink többsége már a javított kernelt futtatta, egyetlen gépen kellett frissíteni, és ez még aznap megtörtént.
• November 11., Node.js biztonsági kiadás. A javított csomag nem azonnal került fel a hivatalos tárolóba, ezért óránként figyeltük, és a kiadás után kb. 2 órával már telepítve volt minden szerverünkön.
Amiért nem kellett riadót fújni
Legalább ilyen fontos, hogy mikor nem kapkodunk. Ugyanezen a héten egy rendszercsomag-hibáról kiderült, hogy minden szerverünkön már javítva volt, egy másik pedig csak olyan rendszert érint, amilyet mi nem használunk. Ezeknél semmihez nem nyúltunk, mert a felesleges beavatkozás is okozhat hibát.
Hogyan dolgozunk, amikor új rés jelenik meg?
1. Figyelés: óránként automatikus ellenőrzés fut a nyilvános biztonsági adatbázisokon és a gyártói közleményeken, ezen felül külső szolgáltatók biztonsági hírlevél listájára is fel vagyunk iratkozva, hogy kritikus rés esetén azonnali beavatkozást tudjunk nyújtani.
2. Ellenőrzés: minden találatot összevetünk a saját szervereink pontos verzióival. Csak akkor lépünk, ha az érintettség megerősített.
3. Javítás: frissítünk, és ahol a hiba a weboldal kódját érinti, ott a kódot is átnézzük.
4. Visszaellenőrzés: a frissítés után megnézzük, hogy a javítás valóban felkerült, és az oldal ugyanúgy működik.
Mindez a napi munka mellett történik: a karbantartott oldalak programcsomagjait rendszeresen ellenőrizzük, és szükség szerint, de legalább heti rendszerességgel frissítjük.
Október 21.: amikor a javítás sem volt letölthető
Október 21-én egy súlyos PHP-sérülékenység vált nyilvánossá. A karbantartott oldalainkon még aznap kezeltük a hibát. Volt olyan szerver, ahol a javított verzió átmenetileg nem volt letölthető. Ott tudatosan úgy döntöttünk, hogy a szervert leállítjuk, és csak a javítás telepítése után indítjuk újra. Inkább legyen egy oldal átmenetileg elérhetetlen, mint hogy nyitott ajtóval fusson.
Mit lát ebből Ön? A havi jelentés
A karbantartás nem láthatatlan munka. Karbantartási ügyfeleink havonta írásos jelentést kapnak, amelyet laikusként is végig lehet olvasni. Benne van:
• egy rövid összefoglaló a hónapról,
• mely programcsomagok frissültek, és miért,
• milyen hibákat javítottunk, mi volt a tünet, és mikor készült el a javítás,
• a biztonsági állapot: a kezelt rések és az automatikus ellenőrzés eredménye.
A jelentés néhány oldal, és szakzsargon nélkül olvasható.
Mit vállalunk, és mit nem
Százszázalékos védelmet senki nem tud ígérni, és mi sem ígérünk. Amit vállalunk: figyeljük az oldala alatti rendszereket, gyorsan reagálunk, és havonta írásban részletesen beszámolunk arról, mit csináltunk.
Hogyan áll az Ön oldala?
Kérjen tőlünk mintajelentést, és elküldjük, hogyan nézne ki az Ön oldalának havi jelentése. Ha Ön az oldal tulajdonosa vagy üzemeltetője, írja meg a címét is, és egy rövid külső ellenőrzéssel díjmentesen megnézzük, látszik-e rajta elavult szoftver.
