INsec PRAKTIKA · LINUX SERVERIŲ SAUGUMAS

Linux serveris veikia be sustojimo. Bet ar jame jau veikia saugumo pataisos?

Ilgas serverio veikimas be perkrovimo atrodo kaip stabilumo ženklas. Tačiau įdiegtas atnaujinimas dar ne visada reiškia, kad sistema jau naudoja pataisytą branduolį. Įmonei svarbu žinoti ne tik kada atnaujinta, bet ir ar pataisa iš tikrųjų įsigaliojo.

· INsec techninė praktika · Linux / Branduolio pataisos / Serverių priežiūra
SkirtumasĮdiegtas paketas ir veikiantis branduolys – atskiros patikros.
VertinimasTikrinama konkreti distribucija ir jos saugumo pranešimas.
LivepatchGali padėti, tačiau nepakeičia visų atnaujinimų.
RezultatasPatvirtinta pataisa ir veikiančios verslo paslaugos.

Kodėl verta patikrinti dabar?

2026 m. rugsėjo 19 d. „The Hacker News“ pranešė apie tris „Linux“ branduolio spragas – CVE-2025-39682, CVE-2026-53266 ir CVE-2025-39964 – įtrauktas į CISA žinomai išnaudojamų pažeidžiamumų katalogą. Tai aktualus priminimas peržiūrėti serverių pataisų būklę. „The Hacker News“ publikacija.

Vien šis sąrašas neparodo, ar pažeidžiamas konkretus įmonės serveris. Pavyzdžiui, „Red Hat“ CVE-2025-39682 apraše nurodo priklausomybę nuo naudojamo branduolio TLS mechanizmo, vadinamo kTLS. Todėl vertinamos ir programinės įrangos pataisos, ir konkrečios konfigūracijos sąlygos. „Red Hat“ pažeidžiamumo paaiškinimas.

Atnaujinimas įdiegtas. Kodėl klausimas dar neuždarytas?

Įprastai diegiant naują branduolio paketą jo failai įrašomi diske, tačiau jau veikianti sistema toliau naudoja paleidimo metu įkeltą branduolį. Norint pradėti naudoti naują branduolį reikia perkrovimo. „Canonical“ dokumentacija tai aiškiai atskiria nuo veikiančio branduolio pataisymo naudojant „Livepatch“. „Canonical“: kada reikia perkrauti.

Praktinis pavyzdys: administratorius įdiegė paketų atnaujinimus, bet dėl vykstančių darbų perkrovimą atidėjo. Ataskaitoje gali būti pažymėta, kad atnaujinimas atliktas, nors perėjimas prie naujo branduolio dar laukia. Tai iliustracinė situacija, o ne konkretaus INsec kliento incidentas.

Atnaujinimo užduotis turi turėti patikrinamą pabaigą. Reikia patvirtinti, kad konkrečiai sistemai taikoma pataisa jau veikia, o ne tik kad paketų diegimo komanda baigė darbą.

Kodėl vien versijos numeris gali klaidinti?

„Red Hat“ paaiškina, kad saugumo pataisos dažnai perkeliamos į senesnę programinės įrangos šaką, išlaikant jos stabilumą ir suderinamumą. Tai vadinama „backporting“. Dėl to vien palyginti pagrindinį versijos numerį su naujausia projekto versija nepakanka: svarbus visas gamintojo paketo leidimas ir jam taikomos saugumo pataisos. „Red Hat“ pataisų perkėlimo praktika.

INsec rekomenduoja kiekvienam serveriui užfiksuoti distribuciją, jos leidimą, veikiantį branduolį ir gamintojo nurodytą konkretaus CVE būseną. „Ubuntu“ naudotojai, pavyzdžiui, gali tikrinti oficialų CVE įrašą pagal leidimą ir paketo variantą. Vienos distribucijos pataisyto paketo numerio nereikėtų taikyti kitai.

Ar „Livepatch“ leidžia serverio niekada neperkrauti?

Ne. „Canonical“ nurodo, kad „Livepatch“ skirtas aukšto ir kritinio prioriteto branduolio saugumo spragoms, tačiau ne visas problemas galima pataisyti veikiančioje sistemoje. Be to, ši paslauga neįjungia įprastų APT saugumo atnaujinimų. Naujam branduoliui ir kitų komponentų pakeitimams gali reikėti perkrovimo. „Livepatch“ ribos ir perkrovimo poreikis.

Jeigu įmonė naudoja tokį sprendimą, patikroje turi būti jo faktinė būsena ir konkrečios pataisos taikymas. Užrašas „Livepatch įjungtas“ savaime nepatvirtina, kad pašalintas kiekvienas naujai paskelbtas pažeidžiamumas.

INsec siūlomas saugaus atnaujinimo planas

  1. Nustatyti paveiktas sistemas. Peržiūrėti fizinius ir virtualius serverius, jų vaidmenis, gamintojo pranešimus bei naudotojams svarbias paslaugas.
  2. Sutarti darbų laiką. Įvardyti atsakingą žmogų, numatomą prastovą ir veiksmus, kuriuos po atnaujinimo patikrins paslaugos savininkas.
  3. Pasiruošti nesėkmei. Patikrinti atsarginių kopijų būklę, atkūrimo procedūrą ir prieigą per serverio valdymo konsolę. Vien tik SSH prieiga gali nepadėti, jei sistema po perkrovimo nepasieks tinklo.
  4. Įdiegti gamintojo pataisas. Naudoti konkrečiai platformai skirtą atnaujinimo kelią ir įvertinti pranešimus apie būtinus papildomus veiksmus.
  5. Perkrauti, kai to reikia. Prastovą valdyti pagal sutartą planą. Klasteryje pirmiausia patikrinti, ar likę mazgai gali perimti apkrovą ir ar leidžiama konkreti priežiūros seka.
  6. Patikrinti rezultatą. Patvirtinti veikiantį branduolį arba pritaikytą veikiančio branduolio pataisą, programų darbą, tinklą, stebėseną ir atsarginių kopijų užduotis.

Ką užfiksuoti atlikus darbus?

Priežiūros įraše verta palikti serverio identifikatorių, atlikimo datą, tikrintą saugumo pranešimą, patvirtintą pataisos būklę ir verslo funkcijų patikros rezultatą. Jei perkrovimas atidėtas, turi likti konkretus terminas ir atsakingas asmuo, o ne bendras pažadas atlikti „vėliau“.

Grįžimas prie ankstesnio branduolio gali padėti sprendžiant suderinamumo problemą, bet kartu gali grąžinti ir saugumo riziką. Todėl grįžimo scenarijų vertinkite kaip laikiną atkūrimo priemonę su tolesniu veiksmų planu.

Klausimas IT prižiūrėtojui

„Ar galite parodyti, kad mūsų svarbiausiuose Linux serveriuose reikiamos pataisos jau veikia, ir kurie serveriai dar laukia perkrovimo?“

Toks klausimas padeda pereiti nuo atnaujinimų diegimo sąrašo prie patvirtintos sistemų būklės.

Patikrinkime jūsų serverių atnaujinimų būklę

INsec padeda peržiūrėti Linux serverių priežiūrą, suplanuoti atnaujinimus, atkūrimo veiksmus ir svarbiausių paslaugų patikrą.

Aptarti serverių priežiūrą

Šaltiniai

Šaltiniai patikrinti 2026-09-21. Naujienos kontekstas – „The Hacker News“; techniniai paaiškinimai – gamintojų dokumentacija. Darbų planas – INsec praktinės rekomendacijos. Pataisų prieinamumas vertinamas pagal konkrečią sistemą.

Susiję straipsniai