CVE të kernel-it Linux në rritje: si Host.it i patch-on në kohë reale pa rindezur serverët

Dy dukuri janë mbivendosur dhe duhen mbajtur të ndara. E para është administrative. Që nga shkurti 2024 kernel-i Linux është një CVE Numbering Authority: shumë çështje që më parë rronin në lista postimesh ose në commit tani dalin me një ID publike. Katalogu u zgjat edhe pa një epidemi të papritur bug-esh të rinj.

E dyta është teknike, dhe kjo ka ndryshuar ritmin muajt e fundit. Fuzzing (syzkaller e shoqëria) punon prej vitesh. Ajo që ndryshoi është ndihma e AI në kërkim: agjentë që eksplorojnë sipërfaqe, ulin false positive, ndihmojnë të shkruhen riprodhues dhe e mbyllin rrethin deri te publikimi. Më shumë sy automatikë, më shumë CVE. «Faleminderit» AI, në kuptimin e ngushtë: më shumë dobësi të zbuluara dhe të komunikuar, jo një kernel që u bë papritur më i brishtë.

Çfarë nuk është (dhe çfarë është) një CVE kernel

Një CVE kernel nuk është plugin që klikohet në dashboard. Është identifikues i një të mete të sistemit operativ nën WordPress, Joomla, dyqanin, postën. Rëndësia lexohet rast pas rasti: jo çdo ID është e shfrytëzueshme në hosting të përbashkët, dhe jo çdo njëra kërkon rindezje të menjëhershme. Ajo që ndryshoi është ritmi: radha e patch-eve për t’u vlerësuar nuk është më ngjarje mujore.

Sipërfaqja që sheh agjencia është CMS, plugin, PHP, certifikata. Ajo që mund të përdorë një sulmues përfshin edhe kernel-in, driver-at, namespace-et, rrjetin. Nuk duhet të bëheni hacker kernel-i. Duhet të dini kush patch-on çfarë, sa shpejt, dhe me çfarë ndikimi te uptime.

Tre plane, tre përgjegjësi

• Aplikacioni. Core, tema, plugin: zanati juaj, ose një kanon që shesni. Staging, backup, dritare verifikimi.
• Sistemi. Kernel, libc, hypervisor: zanati i hoster-it. Nëse hoster-i patch-on vetëm me rindezje, çdo CVE serioz bëhet ndërprerje e planifikuar.
• Kontrata me klientin. Kush përgjigjet nëse dyqani bie gjatë zbritjeve? Nëse nuk është shkruar, e paguani me reputacion.

Për një agjenci me pesëdhjetë ose dyqind faqe kernel-i është i padukshëm derisa funksionon. Bëhet i dukshëm natën kur dhjetë klientë marrin timeout njëherësh. Nuk është «siguri në abstrakt»: është vazhdimësia e shërbimit që keni shitur.

Patch-i klasik i kernel-it është i thjeshtë për t’u shpjeguar dhe i shtrenjtë për t’u jetuar: instalon, rindez, pret që shërbimet të ngrihen, kontrollon PHP, bazën dhe radhën e postës. Në një server është një dritare. Në një park është kalendar ndërprerjesh.

Çfarë paguan klienti (dhe çfarë paguani ju)

• Minuta faqe e rënë. Një e-commerce në fushatë ads nuk dallon «mirëmbajtje kernel» nga «hosting i pabesueshëm».
• Dritare nate. Nëse çdo njoftim kërkon reboot, netët shumëfishohen. Ekipi i brendshëm ose furnizuesi duhet t’i mbulojë.
• Ticket në seri. Edhe një rindezje e pastër prodhon alarme monitorimi dhe telefonata. Kushton më shumë se patch-i.

Alternativa nuk është t’i injorosh CVE. Është t’i ndash korrigjimin nga reboot: ta aplikosh patch-in në memorie kur mundet, dhe ta mbash rindezjen për rastet kur duhet kernel i ri, jo për çdo ID të publikuar të hënën në mëngjes.

Te Host.it strategia është studiuar për uptime-in e Klientëve, jo për komoditetin e kalendarit të brendshëm. Kur vjen një njoftim kernel i rëndësishëm, e aplikojmë korrigjimin në nxehtësi (live / hot patch): kodi i dobët në ekzekutim zëvendësohet pa cikël fikjeje. Faqet mbeten të arritshme. Nuk është magji dhe nuk i fshin të gjitha reboot-et e jetës së një serveri: e heq nevojën për të rindezur vazhdimisht vetëm për të ndjekur ritmin e CVE.

Çfarë bëjmë, në praktikë

• Vlerësim. Jo çdo CVE kernel ka të njëjtin ndikim te stack-u ynë. Prioritizojmë ato që prekin ekspozimin real të shërbimeve.
• Patch në kohë reale. Ku live patching mbulon të metën, korrigjimi hyn në prodhim pa downtime hypervisor-i ose makine.
• Reboot vetëm kur duhet. Një kernel i ri, një varësi që patch-i i nxehtë nuk e mbulon, një dritare e planifikuar: rindezja mbetet mjet, jo përgjigjja e paracaktuar.
• Vëzhgim. Monitorojmë që shërbimet të mbeten të shëndosha pas patch-it. Uptime-in e matim, nuk e shpallim në manifest: shih transparencën e uptime.

Vlen për infrastrukturën e hosting, cloud dhe VPS: klienti përfundimtar nuk duhet të mësojë çfarë është një live patch. Duhet të gjejë faqen ndezur. Nëse menaxhoni parkun si agjenci, ndryshimin e shihni te ticket-et që nuk vijnë. Detaje te siguria Host.it dhe te VPS.

CVE e kernel-it është temë e vështirë në takim sa e tregoni si teknologji. Bëhet zë listinoje nëse e përktheni në vazhdimësi, përgjegjësi dhe kanon.

• Klauzolë uptime e ndershme. Mos premtoni 100%. Shpjegoni që përditësimet e sigurisë së sistemit nuk përkojnë me dritare faqesh të fikura në çdo njoftim. Është arsye konkrete për të qëndruar te një hoster që patch-on në nxehtësi.
• Raport mirëmbajtjeje. Një rresht në raportin mujor: «kernel i përditësuar, pa downtime nga reboot». Klienti nuk e kupton CVE; kupton që dikush e bëri punën pa ia mbyllur dyqanin.
• Hosting si qeverisje. Me Host Bucket i izoloni klientët, i rishisni me markën tuaj dhe mbani infrastrukturë italiane. Patch-i i kernel-it nuk është shtesë: është pjesë e besueshmërisë që po shisni.

Asnjë nga këto tre gjëra nuk e bën një prompt. I bën një agjenci që ka zgjedhur ku rrotullohen faqet dhe di ta shpjegojë.

CVE të kernel-it Linux do të vazhdojnë të vijnë, pjesërisht sepse numerimi është më i gjerë, pjesërisht sepse AI ndihmon t’i gjejmë më herët. Kush i përgjigjet çdo ID me reboot grumbullon downtime. Kush i injoron njoftimet grumbullon rrezik. Rruga e tretë është ajo që përdorim te Host.it: patch në kohë reale, rindezje vetëm kur duhen, uptime si kufizim.

Nëse menaxhoni faqe për të tjerë, kjo është biseda që duhet me hoster-in, jo me CMS. Për të folur për parkun tuaj: na kontaktoni. Për programin e rishitësve: hosting për agjenci web.