TuxCare ELS: Fortsatt säker drift av äldre Linux-versioner

Vad TuxCare ELS kompletterar

När det reguljära underhållet för en Linux-distribution upphör kommer en server inte nödvändigtvis att fortsätta att få säkerhetsuppdateringar via de tidigare paketkällorna. Detta är särskilt problematiskt om en specialapplikation fortfarande är bunden till den gamla miljön. Utökad support kan ge tid för en kontrollerad övergång utan att det innebär att det ordinarie underhållet upphör.

TuxCare Stöd under hela livscykeln for OS tillhandahåller säkerhetsuppdateringar och utvalda felkorrigeringar för äldre distributioner som stöds. Enligt tillverkaren omfattar erbjudandet kärnan och ett distributionsberoende urval av viktiga paket. Det installerar ingen ny huvudversion av Linux: servern behåller sin befintliga distributionsversion och får ytterligare underhåll för de komponenter som omfattas.

För verksamheten kan detta vara en viktig övergångslösning: Istället för att omedelbart behöva byta ut ett inkompatibelt program kan man förbereda migreringen samtidigt som tillgängliga säkerhetsuppdateringar för de paket som omfattas installeras. En förutsättning är dock att de paket som faktiskt behövs, arkitekturen och den valda lösningen passar ihop.

Die Paketlock kan inte likställas med säkerheten för hela servern. En egeninstallerad applikation, ett tillägg eller en tjänst från en annan paketkälla kan ligga utanför operativsystemets utbud. Inte heller konfigurationsfel och onödigt tillgängliga tjänster försvinner genom ett abonnemang; de måste fortfarande kontrolleras och säkras.

Även för paket som omfattas av tjänsten är allvarlighetsgraden relevant: TuxCare tillhandahåller säkerhetskorrigeringar för höga och kritiska risker från CVSS 7 och uppåt. För medelhöga risker mellan CVSS 4,0 och 6,9 kan enligt leverantören korrigeringar komma ifråga om ingen riskbegränsning finns tillgänglig och det finns tillräcklig efterfrågan från kunderna. TuxCare förbehåller sig dessutom rätten att erbjuda en riskbegränsande åtgärd istället för en direkt kodkorrigering. Att ett paket omfattas innebär därför inte att varje känd sårbarhet i det åtgärdas.

Det avgörande är därför inte bara om distributionen finns med på en supportlista. För Linux-säkerhet räknar upp vilka komponenter som används på den specifika servern, om lämpliga korrigeringar finns tillgängliga och om dessa faktiskt är installerade. ELS kompletterar patchprocessen, men ersätter varken inventeringen eller en migreringsplan.

Kontrollera täckningen och serverinventariet

Innan man väljer TuxCare ELS måste man Serverutrustning. Registrera distributionen samt exakt version, arkitektur och aktuell kärna. Dokumentera dessutom de konfigurerade paketkällorna och de tjänster som är tillgängliga offentligt eller från andra nätverk. På så sätt kan tillverkarförteckningen jämföras med det faktiska systemet, istället för att bara kryssa av distributionens namn.

För en äldre webbserver bör exempelvis webbserverpaketet, krypteringsbibliotek, PHP-runtidsmiljön och nödvändiga PHP-tillägg ingå i inventeringen. Notera varje gång varifrån paketet kommer och vilken version som är installerad. En tilläggsmodul från ett externt arkiv kan ha andra underhållsvillkor än ett paket från den ursprungliga distributionen.

Jämför dessa komponenter en efter en med den aktuella paketlistan för den aktuella distributionen. Kontrollera även arkitekturen och villkoren för det avsedda erbjudandet. Att en distribution stöds innebär inte att varje paket som är installerat där eller varje version av en runtime automatiskt täcks av ELS for OS. Även för paket som täcks beror hanteringen av enskilda sårbarheter bland annat på allvarlighetsgraden.

Särskilt lätt att förbise är program som man själv har kompilerat och separat installerade körmiljöer. Även en containerbild innehåller egna komponenter: Underhållet av värdoperativsystemet garanterar inte att paketen i bilden är uppdaterade. För sådana komponenter behöver du ett separat bevis och en egen uppdateringsprocess.

ELS för OS och ELS för olika tillämpningar är separata tjänster. Huruvida en äldre PHP-version kan underhållas via en extra tjänst beror bland annat på version, paketformat, arkitektur och anskaffningssätt. En annan möjlig miljö för äldre PHP-applikationer beskrivs i artikeln om CloudLinux Alt-PHP och dess säkerhetsaspekter; detta innebär att det inte omfattas av ett TuxCare-OS-abonnemang.

Att korrekt tolka supporttidsfristerna

Ett supportslut är endast meningsfullt i samband med den aktuella underhållsfasen. Att det ordinarie underhållet upphör innebär inte alltid att alla avgiftsbelagda eller kompletterande tjänster upphör samtidigt. För att kunna fatta ett beslut bör du därför notera både tidsperioden och vilka paket, arkitekturer och avtalsvillkor som omfattas.

I den TuxCare-dokumentation som för närvarande finns tillgänglig anges en garanterad ELS-körningstid för de operativsystem som stöds på 25 år från och med det angivna ursprungliga supportslutet. Som exempel anger man den 30 juni 2049 för CentOS 7 och den 31 maj 2048 för Ubuntu 18.04. Detta är leverantörens uppgifter om supportperioden, inte något löfte för varje installerad applikation.

För Ubuntu 18.04 skiljer Canonical mellan flera faser: Standardunderhållet avslutades i maj 2023; Ubuntu Pro gäller fram till maj 2028. Den aktuella översikten anger maj 2033 för ytterligare legacy-täckning. Dessa erbjudanden kan inte jämföras enbart utifrån sina slutdatum, eftersom paketets omfattning, arkitektur och avtalsvillkor för den specifika servern spelar roll.

Kontrollera till exempel vid en Ubuntu-webbserver om de nödvändiga paketen verkligen ingår i den valda underhållsplanen och hur uppdateringarna passar in i den befintliga driftsprocessen. En längre tidsperiod hjälper föga om en kritisk drifttid eller utökning ligger utanför den överenskomna omfattningen.

De angivna tidsfristerna baseras på dynamiska tillverkarsidor enligt den informationsstatus som gällde den 4 november 2026. Det går inte att i alla fall verifiera retroaktivt om alla aktuella uppgifter redan gällde vid detta datum. Kontrollera därför tidsfrister och paketlistor på nytt innan publicering eller avtalsingående och håll dig uppdaterad om respektive Aktuell status fast. Inte ens ett långsiktigt supportlöfte är någon garanti för en överlag säker server.

Att sätta igång en CentOS 7-server på ett praktiskt sätt

Anta att en CentOS 7-webbserver tillfälligt måste fortsätta köra en äldre branschapplikation. Innan du TuxCare ELS När du väljer detta registrerar du systemets faktiska tillstånd och applikationens beroenden. Det avgörande är inte bara om CentOS 7 stöds, utan också om de nödvändiga komponenterna för den befintliga arkitekturen ingår.

Du kan köra följande kommandon i en shell på servern. De hämtar information om distributionskod, maskinarkitektur och versionen på den aktiva kärnan; de ändrar varken paket eller paketkällor. Notera utdata i serverinventariet och jämför dem med den aktuella CentOS 7-guiden.

cat /etc/os-release
uname -m
uname -r

Fyll i det här Serverutrustning konfigurerade paketkällor, installerade paketversioner och offentligt tillgängliga tjänster. För en webbserver omfattar detta framför allt webbserverpaketet, krypteringsbibliotek, PHP-runtime och tillägg. Notera även vilka komponenter som härrör från externa källor eller som har kompilerats själv; dessa får inte utan granskning räknas som en del av OS-täckningen.

För CentOS 7 anger TuxCare en giltig licensnyckel, root-åtkomst och HTTPS-anslutningar som förutsättningar. Instruktionerna skiljer dessutom mellan arkitekturer: För aarch64 och i686 beskrivs täckning av användarutrymmet, medan live-patching av kärnan endast beskrivs för x86_64. Denna begränsning gäller instruktionerna för CentOS 7 och kan inte generellt överföras till andra distributioner.

Kontrollera därefter, för den specifika tillämpningen, varje nödvändigt paket mot den aktuella listan och klargör eventuella kvarstående luckor med respektive leverantör. Inte heller en stödd, aktiv kärna bevisar i sig att tillämpningen täcks eller att alla tillgängliga uppdateringar är installerade och aktiva.

Konfigurera repositoriet och distribuera uppdateringar

Planera inredningen som en kontrollerad Testkedja: Först måste licensen, arkitekturen och de nödvändiga paketen stämma överens. Därefter måste du kontrollera om servern har behörighet att nå de mål via HTTPS som krävs för dess distribution. Använd de aktuella, distributionsspecifika originalanvisningarna för registrering och konfiguration av repositoriet, eftersom förutsättningar och måladresser kan ändras.

För CentOS 7 beskriver TuxCare hur man registrerar systemet, lägger till paketkällan och en PGP-nyckel. Källan gör det sedan möjligt att hämta lämpliga paket, men den installerar inte automatiskt alla tillgängliga uppdateringar. Kontrollera efter installationen om paketförvaret har integrerats som förväntat och om pakethanteraren erbjuder lämpliga uppdateringar.

En proxy eller restriktiva regler för utgående trafik måste beaktas i planeringen. För flera system kan en lokal spegel vara ett alternativ efter samråd med TuxCare. Överför inte måladresser blint från en allmän FAQ: Jämför dem före godkännandet med den aktuella instruktionen för den valda distributionen och den avsedda driftsvägen.

Testa först tillgängliga uppdateringar i en testmiljö som är så lik den faktiska driftsmiljön som möjligt. Kontrollera då att programmet startar, samt viktiga affärsprocesser och gränssnitt. Därefter följer driftsgodkännande och installation på produktionssystemet; dokumentera paketversioner, tidpunkt och resultat, istället för att enbart betrakta den lyckade aktiveringen i repositoriet som slutförandet.

Om en förväntad uppdatering ännu inte finns tillgänglig, kontrollera även Lanseringsstatus. För flera plattformar distribuerar TuxCare uppdateringar stegvis; efter publicering i det stabila arkivet kan detta ta upp till 14 ytterligare dagar. Vid behov beskriver leverantören en tillfällig lösning: Använd den endast enligt de aktuella anvisningarna för respektive distribution och den specifika versionen samt efter godkännande från driftsavdelningen. Utifrån utrullningstiden kan ingen garanterad total tidsram för en patch fastställas.

Se också till att ha en återgångsväg och ett lämpligt underhållsfönster tillgängliga. Licensnycklar hör inte hemma i publicerade exempelkommandon, ärenden eller oskyddade loggar. För den faktiska registreringen bör du följa tillverkarens aktuella anvisningar och endast tillhandahålla inloggningsuppgifter via de avsedda förfarandena.

Jämförelse av underhållsalternativ

Valet mellan TuxCare ELS och utökad tillverkarsupport beror på den faktiska paketbeståndet och avtalsvillkoren. Tabellen innehåller exempel för förhandsurval, inte någon allmän garanti för varje arkitektur eller varje paket. Sökningen gäller den 4 november 2026; de dynamiska uppgifterna från tillverkaren och paketlistorna måste kontrolleras på nytt före publicering.

För Ubuntu 18.04 upphörde standardunderhållet i maj 2023. Canonical anger att supporten för Ubuntu Pro sträcker sig till maj 2028 och, i sin aktuella översikt över ytterligare legacy-täckning, till maj 2033. TuxCare anger för närvarande den 31 maj 2048 som slutdatum för ELS för Ubuntu 18.04. Dessa datum avser olika erbjudanden; ett senare slutdatum innebär inte automatiskt att det finns ett passande supportpaket.

Jämför därför Underhållsomfattning för varje paket som behövs och den arkitektur som faktiskt används. För Ubuntu är framför allt Main- och Universe-komponenterna samt villkoren för Pro och ett eventuellt Legacy-tillägg relevanta. Notera dessutom hur tillgängliga CVE-korrigeringar kan verifieras och om de befintliga godkännande- och uppdateringsprocesserna passar erbjudandet.

I båda exemplen förblir migrationsmålet ett planeringsbeslut, inte en del av underhållsavtalet. Om den specialiserade applikationen ännu inte kan köras på en plattform som stöds kan ett lämpligt underhållsalternativ ge tid för tester. Om inget av erbjudandena täcker en kritisk beroendeförhållande måste denna lucka hanteras separat innan fortsatt drift kan anses vara ansvarsfull.

Kontrollera CVE-rapporter och bakåtportningar

Om en skanner fortfarande rapporterar en sårbarhet efter en uppdatering, kontrollera först den exakta distributionen och versionen samt namnet, arkitekturen och den installerade versionen av det berörda paketet. Ta dessutom reda på vilken paketkälla det kommer från. Ett resultat för ett distributionspaket kan inte utan vidare överföras till en egenkompilerad applikation eller ett paket från ett externt arkiv.

Orsaken till de till synes motstridiga uppgifterna kan vara en Backport vara: I detta fall införlivas en säkerhetskorrigering i en äldre utvecklingsversion utan att dess synliga uppströmsversionsnummer motsvarar den senaste utgåvan. Ett äldre versionsnummer i sig bevisar därför varken att paketet är sårbart eller att skannerns meddelande nödvändigtvis är felaktigt.

Jämför den specifika CVE-koden och den installerade paketversionen med uppgifterna för din distribution i TuxCare-CVE-Tracker. „In Testing“ betyder att en korrigering fortfarande testas; vid „In Rollout“ distribueras den via rollout-repositorier. „Released“ betyder däremot att den är fullständigt släppt för alla användare. Även då måste du kontrollera om rätt version verkligen har installerats; „Not Vulnerable“ innebär att TuxCare-versionen inte är drabbad.

Om en förväntad uppdatering saknas i pakethanteraren, kontrollera förutom paketkällan och versionen även Lanseringsstatus. Vid flera plattformar kan den stegvisa distributionen efter publicering i det stabila repositoriet ta upp till 14 ytterligare dagar. En eventuell förkortning av processen är endast tillåten enligt aktuella, distributions- och versionsspecifika originalanvisningar samt efter operativt godkännande; detta medför ingen garanterad total tidsfrist för patchen.

Granska därefter skannerns databas och utvärdering. TuxCare tillhandahåller OVAL-data för en rad ELS-produkter; du måste själv kontrollera om ditt verktyg använder de data som är lämpliga för det specifika systemet och tolkar dem korrekt. Dokumentera paketversion, CVE-status och tidpunkt för skanningen. Om jämförelsen förblir oklar ska du fortsätta att behandla fyndet som öppet och klargöra det med berörda avdelningar eller leverantören.

Planera patch-drift och omstarter

Ett konfigurerat paketarkiv är början på uppdateringsarbetet, inte slutet. Bestäm vem som regelbundet ska kontrollera om det finns tillgängliga uppdateringar, vem som godkänner dem och hur felaktiga uppdateringar ska identifieras. Jämför samtidigt de faktiskt installerade paketversionerna med de tillgängliga uppdateringarna och dokumentera avvikelser för varje system.

Testa uppdateringar i möjligaste mån först på ett likvärdigt testsystem med samma applikation och relevanta paketkällor. Kontrollera där särskilt uppstart, inloggning och viktiga gränssnitt i affärsapplikationen. Först efter att systemet har godkänts för drift ska du rulla ut paketen på ett kontrollerat sätt; resultatet och eventuella fel ska dokumenteras i installationsrapporten.

Planera även in tid för ändringar Fönster för underhåll. Även efter en lyckad paketuppdatering kan pågående processer fortfarande använda gamla bibliotek tills de startas om. Program kan också behöva startas om; vid ändringar i kärnan kan det krävas en omstart av systemet. Kontrollera efter omstarten både att tjänsten fungerar och att paketet och driftsläget är som förväntat.

KernelCare Live Patching är en kompletterande produkt och ska inte förväxlas med vanliga ELS-paketuppdateringar. Den kan tillhandahålla stödda kärnkorrigeringar under drift, men ersätter varken alla uppdateringar eller varje omstart av tjänster eller systemet. Kontrollera produkt, distribution och arkitektur: För CentOS 7 dokumenterar TuxCare endast Live Patching för x86_64. Ytterligare grundläggande information finns i artikeln om KernelCare Patch Feed.

Utgåvan av uname -r visar den aktuella kärnan, men inte serverns fullständiga uppdateringsstatus. Ett installerat kärnpaket kan till exempel först aktiveras efter en omstart; omvänt säger utdata ingenting om huruvida bibliotek och applikationer har uppdaterats och startats om.

Välj mellan en tillfällig lösning eller migrering

Huruvida TuxCare ELS är tillräckligt för en specifik server beror på dess faktiska komponenter och risker. Jämför de nödvändiga paketen med den tillgängliga täckningen och kartlägg eventuella luckor i applikationer, körmiljöer och tredjepartsprogramvara. ELS for OS täcker ett distributionsberoende urval; stödet för operativsystemet innebär inte att varje applikation som körs på det underhålls.

Kontrollera även kvarvarande CVE-sårbarheter i de paket som omfattas. Enligt TuxCare beaktas medelstora risker endast under ytterligare förutsättningar för en patch; dessutom kan leverantören tillhandahålla en riskbegränsande åtgärd istället för en direkt kodkorrigering. Bedöm därför för den specifika sårbarheten om en korrigering eller en riskbegränsande åtgärd finns tillgänglig och om de kvarvarande riskerna är acceptabla för din verksamhet.

En övergångslösning kan vara lämplig om en specialapplikation för tillfället är bunden till den gamla plattformen och de återstående riskerna är hanterbara. Jämför dock även tillgänglig support från tillverkaren: För Ubuntu 18.04 kan Ubuntu Pro och eventuellt tillägget Legacy vara alternativ, beroende på vilken omfattning som krävs. Kontrollera paket, arkitektur och avtalsvillkor istället för att bara titta på respektive slutdatum.

För en offentligt tillgänglig tjänst med en föråldrad applikation eller en driftstid som inte täcks kan ELS i sig vara otillräckligt. Begränsa därför åtkomsten till de nätverk och tjänster som faktiskt behövs, ta bort onödiga behörigheter och kontrollera administrativa åtkomster. Dessa Nätverksbegränsning minskar attackytan, men ersätter inte uteblivna säkerhetsuppdateringar.

Se till att den fortsatta driften är tidsbegränsad och fastställ ett migrationsmål med ansvariga personer och en kontrollerbart datum. Planera applikationstester på målplattformen, dataöverföringen och kontrollen av alla relevanta gränssnitt. En återfallsplan bör fastställa under vilka förhållanden du avbryter övergången och hur du återgår till den tidigare driften.

Granska planen regelbundet med hänsyn till nya säkerhetsluckor i paket, ändrade beroenden av tillverkare och driftskostnaderna. Om nödvändiga komponenter inte längre kan underhållas eller om nödvändiga åtkomster inte kan begränsas i tillräcklig utsträckning, räcker det kanske inte med enbart en förlängning av operativsystemets underhåll. Då måste migrering, utbyte av applikationen eller kontrollerad avveckling omvärderas.