TuxCare ELS: Fortsat sikker drift af ældre Linux-versioner

Hvad TuxCare ELS supplerer

Når den regelmæssige vedligeholdelse af en Linux-distribution ophører, modtager en server ikke nødvendigvis fortsat sikkerhedsopdateringer via de hidtidige pakkekilder. Dette er især problematisk, hvis et specialprogram stadig er bundet til det gamle miljø. Udvidet support kan give tid til en kontrolleret overgang uden at gøre afslutningen af den regelmæssige vedligeholdelse ugyldig.

TuxCare Uendelig support gennem hele produktets livscyklus for OS leverer sikkerhedsopdateringer og udvalgte fejlrettelser til understøttede ældre distributioner. Ifølge producenten omfatter tilbuddet kernen og et distributionsafhængigt udvalg af vigtige pakker. Der installeres ingen ny hovedversion af Linux: Serveren forbliver på sin hidtidige distributionsversion og modtager yderligere vedligeholdelse for de dækkede komponenter.

For virksomheden kan dette være en vigtig midlertidig løsning: I stedet for straks at skulle skifte et inkompatibelt program ud, kan man forberede overgangen, mens de tilgængelige sikkerhedsopdateringer til de omfattede pakker installeres. Det forudsætter dog, at de pakker, der rent faktisk er brug for, arkitekturen og den valgte løsning passer sammen.

Die Pakkeafdækning kan ikke sidestilles med sikkerheden for hele serveren. Et program, en udvidelse eller en tjeneste, som man selv har installeret fra en anden pakkekilde, kan ligge uden for operativsystemets rammer. Konfigurationsfejl og unødvendigt tilgængelige tjenester forsvinder heller ikke ved et abonnement; de skal fortsat kontrolleres og sikres.

Også for de pakker, der er dækket, er alvorlighedsgraden relevant: TuxCare tilbyder sikkerhedsrettelser for høje og kritiske risici fra CVSS 7 og opefter. For mellemstore risici fra CVSS 4,0 til 6,9 kommer der ifølge udbyderen mulighed for patches, hvis der ikke findes nogen afbødende foranstaltninger, og der er tilstrækkelig efterspørgsel fra kunderne. TuxCare forbeholder sig desuden retten til at tilbyde en afbødende foranstaltning i stedet for en direkte kodekorrektion. Et dækket pakke betyder derfor ikke, at alle kendte sårbarheder i pakken bliver rettet.

Det afgørende er derfor ikke kun, om distributionen står på en supportliste. For Linux-sikkerhed registrerer, hvilke komponenter der anvendes på den pågældende server, om der findes passende rettelser, og om disse rent faktisk er installeret. ELS supplerer patch-processen, men erstatter hverken en statusopgørelse eller en migrationsplan.

Kontroller dækning og serverudstyr

Inden man vælger TuxCare ELS, skal man Serverudstyr. Registrer distributionen samt den nøjagtige version, arkitektur og den aktuelle kerne. Dokumenter desuden de konfigurerede pakkekilder og de tjenester, der er tilgængelige offentligt eller fra andre netværk. På den måde kan man sammenligne listen over producenter med det faktiske system, i stedet for blot at afkrydse navnet på distributionen.

På en ældre webserver skal man for eksempel medtage webserverpakken, kryptografibiblioteker, PHP-runtime og nødvendige PHP-udvidelser i oversigten. Notér hver gang, hvor pakken stammer fra, og hvilken version der er installeret. En udvidelse fra et eksternt repository kan have andre vedligeholdelsesbetingelser end en pakke fra den oprindelige distribution.

Sammenlign disse komponenter enkeltvis med den aktuelle pakkeliste for den pågældende distribution. Kontroller også arkitekturen og betingelserne for det påtænkte tilbud. At en distribution understøttes, betyder ikke, at hvert eneste pakke, der er installeret der, eller hver eneste version af et runtime automatisk dækkes af ELS for OS. Selv for pakker, der er dækket, afhænger håndteringen af de enkelte sårbarheder blandt andet af alvorlighedsgraden.

Især selvkompilerede programmer og separat installerede kørselsmiljøer overses let. Også et container-image indeholder sine egne komponenter: Vedligeholdelsen af værtsoperativsystemet er ikke ensbetydende med, at pakkerne i imaget er opdateret. For sådanne komponenter har du brug for en særskilt dokumentation og en egen opdateringsproces.

ELS til OS og ELS til anvendelser er separate tilbud. Om en gammel PHP-version kan vedligeholdes via et ekstra tilbud, afhænger blandt andet af version, pakkeformat, arkitektur og leveringsmåde. Et andet muligt miljø for ældre PHP-applikationer beskrives i artiklen om CloudLinux Alt-PHP og dets sikkerhedsaspekter; dette betyder, at det ikke er omfattet af et TuxCare-OS-abonnement.

At indordne supportfrister korrekt

En supportudløbsdato giver kun mening i sammenhæng med den pågældende vedligeholdelsesfase. Afslutningen af den regelmæssige vedligeholdelse betyder ikke altid, at alle betalingsbaserede eller supplerende tilbud ophører på samme tid. For at kunne træffe en beslutning bør du derfor notere både tidsperioden samt de omfattede pakker, arkitekturer og kontraktvilkår.

Den aktuelt tilgængelige TuxCare-dokumentation angiver en garanteret ELS-levetid for de understøttede operativsystemer på 25 år fra den angivne oprindelige supportudløbsdato. Som eksempler nævner hun den 30. juni 2049 for CentOS 7 og den 31. maj 2048 for Ubuntu 18.04. Dette er oplysninger fra udbyderen om supportperioden, ikke en garanti for hvert enkelt installeret program.

For Ubuntu 18.04 skelner Canonical mellem flere faser: Standardvedligeholdelsen udløb i maj 2023; Ubuntu Pro dækkes frem til maj 2028. Den aktuelle oversigt angiver maj 2033 som slutdato for yderligere legacy-dækning. Disse tilbud kan ikke sammenlignes alene ud fra deres slutdatoer, da pakkens omfang, arkitektur og kontraktvilkår for den konkrete server også spiller en rolle.

Sammenlign f.eks. i forbindelse med en Ubuntu-webserver, om de nødvendige pakker rent faktisk er inkluderet i den valgte vedligeholdelsespakke, og hvordan opdateringerne passer ind i den eksisterende driftsproces. En længere tidsperiode hjælper ikke meget, hvis en kritisk driftstid eller udvidelse ligger uden for det aftalte omfang.

De nævnte frister er baseret på dynamiske producentwebsteder i henhold til den undersøgte kildestatus pr. 4. november 2026. Det er ikke muligt at verificere retroaktivt, om alle aktuelle oplysninger allerede var gældende på denne dato. Kontroller derfor frister og pakkelister igen inden offentliggørelse eller indgåelse af aftalen, og overhold den respektive Antal hentninger fast. Selv et løfte om langvarig support er ingen garanti for en samlet set sikker server.

Praktisk opsætning af en CentOS 7-server

Lad os antage, at en CentOS 7-webserver midlertidigt skal fortsætte med at køre et ældre specialprogram. Inden du TuxCare ELS Når du vælger dette, registrerer du systemets faktiske tilstand og applikationens afhængigheder. Det afgørende er ikke kun, om CentOS 7 understøttes, men også om de nødvendige komponenter til den eksisterende arkitektur er dækket.

Du kan køre følgende kommandoer i en shell på serveren. De henter oplysninger om distributionskoden, maskinarkitekturen og versionen af den kørende kerne; de ændrer hverken pakker eller pakkekilder. Notér resultaterne i serveroversigten, og sammenlign dem med den aktuelle CentOS 7-vejledning.

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

Udfyld det Serverudstyr konfigurerede pakkekilder, installerede pakkeversioner og offentligt tilgængelige tjenester. For en webserver omfatter dette især webserverpakken, kryptografibiblioteker, PHP-runtime og udvidelser. Notér også, hvilke komponenter der stammer fra eksterne kilder eller er kompileret af dig selv; de må ikke uden nærmere kontrol betragtes som en del af OS-dækningen.

For CentOS 7 angiver TuxCare en gyldig licensnøgle, root-adgang og HTTPS-forbindelser som forudsætninger. Vejledningen skelner desuden mellem arkitekturer: For aarch64 og i686 beskriver den dækning af brugerrummet, mens live-patching af kernen kun beskrives for x86_64. Denne begrænsning gælder for CentOS 7-vejledningen og kan ikke generelt overføres til andre distributioner.

Kontroller derefter for den konkrete faglige anvendelse, om alle nødvendige pakker er på den aktuelle liste, og afklar eventuelle mangler med den pågældende udbyder. Selv en understøttet, kørende kerne er i sig selv hverken et bevis på, at applikationen er dækket, eller at alle tilgængelige opdateringer er installeret og aktive.

Opsætning af repository og udrulning af opdateringer

Planlæg indretningen som en kontrolleret Kontrolkæde: Først skal licensen, arkitekturen og de nødvendige pakker stemme overens. Derefter skal du afklare, om serveren har tilladelse til at oprette forbindelse til de mål via HTTPS, der kræves af dens distribution. Brug den aktuelle, distributionsspecifikke originale vejledning til registrering og opsætning af repositoriet, da forudsætningerne og måladresserne kan ændre sig.

I forbindelse med CentOS 7 beskriver TuxCare, hvordan man registrerer systemet, tilføjer pakkekilden og en PGP-nøgle. Kilden gør det derefter muligt at hente de relevante pakker, men den installerer ikke automatisk alle tilgængelige opdateringer. Kontroller efter opsætningen, om repositoriet er integreret som forventet, og om pakkehåndteringen tilbyder de relevante opdateringer.

En proxy eller restriktive regler for udgående trafik i firewallen skal inddrages i planlægningen. Ved flere systemer kan en lokal spejlserver komme på tale efter aftale med TuxCare. Overtag ikke blindt måladresser fra en generel FAQ: Sammenlign dem inden frigivelsen med den aktuelle vejledning for den valgte distribution og den planlagte driftsvej.

Test først de tilgængelige opdateringer i et testmiljø, der ligner det produktive system så meget som muligt. Kontroller i den forbindelse opstarten, vigtige forretningsprocesser og grænseflader. Derefter følger driftsgodkendelse og installation på produktionssystemet; dokumenter pakkeversioner, tidspunkt og resultat, i stedet for blot at registrere den vellykkede aktivering i repositoryet som afslutning.

Hvis en forventet opdatering endnu ikke er tilgængelig, skal du også tjekke Status for implementering. TuxCare udsender opdateringer trinvist til flere platforme; efter offentliggørelsen i det stabile repository kan det tage op til 14 dage yderligere. Hvis det er nødvendigt, beskriver udbyderen en midlertidig løsning: Brug den kun i henhold til de aktuelle instruktioner for den pågældende distribution og den konkrete udgave samt efter godkendelse fra driftsafdelingen. Ud fra udrulningsperioden kan der ikke garanteres en samlet tidsramme for en patch.

Sørg desuden for at have en nødplan og et passende vedligeholdelsesvindue klar. Licensnøgler hører ikke hjemme i offentliggjorte eksempelkommandoer, supportanmodninger eller ubeskyttede logfiler. Til den konkrete registrering bør du følge producentens aktuelle vejledning og kun videregive adgangsoplysninger via de dertil beregnede procedurer.

Sammenligning af vedligeholdelsesalternativer

Valget mellem TuxCare ELS og en udvidet producentvedligeholdelse afhænger af den faktiske pakkebestand og kontraktbetingelserne. Tabellen indeholder eksempler på forudvalg, ikke en generel tilsagn for hver arkitektur eller hvert pakke. Undersøgelsen er baseret på 4. november 2026; de dynamiske producentoplysninger og pakkelister skal kontrolleres igen inden offentliggørelse.

For Ubuntu 18.04 udløb standardvedligeholdelsen i maj 2023. Canonical angiver support for Ubuntu Pro frem til maj 2028 og, i sin aktuelle oversigt over yderligere legacy-dækning, frem til maj 2033. TuxCare angiver i øjeblikket den 31. maj 2048 som ELS-slutdato for Ubuntu 18.04. Disse datoer beskriver forskellige tilbud; en senere slutdato betyder ikke automatisk, at der er passende pakkedækning.

Sammenlign derfor Omfanget af vedligeholdelsen for hvert nødvendigt pakke og den faktisk anvendte arkitektur. I Ubuntu er især Main- og Universe-komponenter samt betingelserne for Pro og et eventuelt Legacy-tillæg relevante. Notér desuden, hvordan tilgængelige CVE-rettelser kan dokumenteres, og om de eksisterende godkendelses- og opdateringsprocesser passer til tilbuddet.

I begge eksempler forbliver migrationsmålet en planlægningsbeslutning og ikke en del af vedligeholdelseskontrakten. Hvis den faglige applikation endnu ikke kan køre på en understøttet platform, kan et passende vedligeholdelsesalternativ give tid til test. Hvis ingen af tilbuddene dækker en kritisk afhængighed, skal dette hul behandles separat, før den videre drift kan anses for ansvarlig.

Kontroller CVE-meddelelser og backports

Hvis en scanner efter en opdatering fortsat rapporterer om en sårbarhed, skal du først kontrollere den nøjagtige distribution og version samt navnet, arkitekturen og den installerede udgave af den pågældende pakke. Find desuden ud af, hvilken pakkekilde den stammer fra. Et fund vedrørende en distributionspakke kan ikke uden videre overføres til et selvkompileret program eller en pakke fra et eksternt repository.

Årsagen til tilsyneladende modsigelser kan være en Backport være: Her overføres en sikkerhedskorrektion til en ældre udviklingsversion, uden at dennes synlige upstream-versionsnummer svarer til den seneste udgivelse. Et ældre versionsnummer i sig selv beviser derfor hverken, at pakken er sårbar, eller at scannerens meddelelse nødvendigvis er forkert.

Sammenlign den konkrete CVE og den installerede pakkeversion med oplysningerne for din distribution i TuxCare-CVE-trackeren. „In Testing“ betyder, at en rettelse stadig er under test; ved „In Rollout“ distribueres den via rollout-repositorier. „Released“ angiver derimod, at rettelsen er fuldt ud frigivet til alle brugere. Også i dette tilfælde skal du kontrollere, om den korrekte version rent faktisk er installeret; „Not Vulnerable“ betyder, at TuxCare-versionen ikke er berørt.

Hvis en forventet opdatering mangler i pakkehåndteringen, skal du ud over pakkekilden og versionen også kontrollere Status for implementering. Ved flere platforme kan den trinvise udrulning efter offentliggørelse i det stabile repository tage op til 14 ekstra dage. En eventuel omgåelse må kun indgå i processen i henhold til de aktuelle, distributions- og udgivelsesrelaterede originale retningslinjer og efter driftsmæssig godkendelse; dette medfører ingen garanteret samlet patch-frist.

Undersøg derefter scannerens database og analyse. TuxCare stiller OVAL-data til rådighed for en række ELS-produkter; du skal selv kontrollere, om dit værktøj bruger de data, der passer til det pågældende system, og fortolker dem korrekt. Dokumenter pakkeversion, CVE-status og scanningsdato. Hvis sammenligningen forbliver uklar, skal du fortsat behandle fundet som uafklaret og afklare det med de ansvarlige faginstanser eller udbyderen.

Planlægning af patch-drift og genstarter

Et oprettet repository er starten på patch-driften, ikke afslutningen. Fastlæg, hvem der regelmæssigt skal tjekke for tilgængelige opdateringer, hvem der skal godkende dem, og hvordan fejlbehæftede opdateringer skal identificeres. Sammenlign i den forbindelse de faktisk installerede pakkeversioner med de tilgængelige opdateringer, og registrer afvigelser for hvert enkelt system.

Test opdateringer om muligt først på et tilsvarende testsystem med samme applikation og relevante pakkekilder. Kontroller især opstart, login og vigtige grænseflader i den faglige applikation. Først efter godkendelse fra driftsafdelingen skal du rulle pakkerne ud på en kontrolleret måde; resultatet og eventuelle fejl skal medtages i installationsrapporten.

Sørg desuden for at indregne ændringer Vedligeholdelsesvindue. Selv efter en vellykket pakkeopdatering kan kørende processer stadig bruge gamle biblioteker, indtil de genstartes. Programmer skal muligvis også genstartes; ved ændringer i kernen kan det være nødvendigt at genstarte systemet. Kontroller efter genstarten både tjenestens funktion samt den forventede pakke- og driftstilstand.

KernelCare Live Patching er et supplerende produkt og skal adskilles fra de almindelige ELS-pakkeopdateringer. Det kan levere understøttede kerneopdateringer under drift, men erstatter hverken alle opdateringer eller enhver genstart af tjenester eller systemet. Kontroller produkt, distribution og arkitektur: For CentOS 7 dokumenterer TuxCare kun kernel-live-patching til x86_64. Yderligere grundlæggende oplysninger findes i artiklen om KernelCare Patch Feed.

Udgivelsen af uname -r viser den aktuelle kerne, men ikke serverens fulde opdateringsstatus. En installeret kernepakke kan for eksempel først træde i kraft efter en genstart; omvendt siger udskriften intet om, hvorvidt biblioteker og applikationer er blevet opdateret og genstartet.

Vælg mellem en midlertidig løsning eller migration

Om TuxCare ELS er tilstrækkeligt til en bestemt server, afhænger af serverens faktiske komponenter og risici. Sammenlign de nødvendige pakker med den tilgængelige dækning, og kortlæg eventuelle mangler i applikationer, kørselsmiljøer og tredjepartssoftware. ELS for OS dækker et distributionsafhængigt udvalg; understøttelsen af operativsystemet indebærer ikke vedligeholdelse af alle applikationer, der kører på det.

Kontroller også for eventuelle resterende CVE-sårbarheder i de pakker, der er dækket. Ifølge TuxCare tages der kun højde for mellemstore risici, hvis der er opfyldt yderligere betingelser for en patch; desuden kan udbyderen tilbyde en afbødende foranstaltning i stedet for en direkte kodekorrektion. Vurder derfor for den konkrete sårbarhed, om der er en rettelse eller en afbødende foranstaltning tilgængelig, og om de resterende risici er acceptable for din drift.

En midlertidig løsning kan være fornuftig, hvis et specialprogram foreløbig er bundet til den gamle platform, og de resterende risici er håndterbare. Sammenlign dog også den tilgængelige vedligeholdelse fra producenten: For Ubuntu 18.04 kan Ubuntu Pro og eventuelt Legacy-tilføjelsen komme i betragtning som alternativer, afhængigt af det nødvendige omfang. Tjek pakker, arkitektur og kontraktbetingelser i stedet for kun den respektive udløbsdato.

For en offentligt tilgængelig tjeneste med en uopdateret applikation eller en ikke-dækket driftsperiode kan ELS alene være utilstrækkeligt. Begræns derfor adgangen til de netværk og tjenester, der rent faktisk er nødvendige, fjern unødvendige adgangsrettigheder og kontroller de administrative adgangsrettigheder. Disse Netværksbegrænsning mindsker sikkerhedsrisikoen, men erstatter ikke manglende sikkerhedsopdateringer.

Sørg for, at den fortsatte drift er tidsbegrænset, og fastlæg et migrationsmål med ansvarlige personer og en tidsfrist, der kan kontrolleres. Planlæg applikationstests på målplatformen, dataoverførslen og kontrollen af alle relevante grænseflader. En nødplan bør fastlægge, under hvilke betingelser du afbryder overgangen, og hvordan du vender tilbage til den hidtidige drift.

Kontroller planen regelmæssigt i lyset af nye sikkerhedshuller i pakker, ændrede afhængigheder af producenter og driftsomkostningerne. Hvis nødvendige komponenter ikke længere kan vedligeholdes, eller hvis nødvendige adgangsrettigheder ikke kan begrænses tilstrækkeligt, er en simpel forlængelse af operativsystemets vedligeholdelse muligvis ikke tilstrækkelig. I så fald skal migration, udskiftning af applikationen eller kontrolleret nedlukning vurderes på ny.