TuxCare ELS: oude Linux-versies op een gecontroleerde manier blijven gebruiken

Wat TuxCare ELS aanvult

Wanneer de reguliere ondersteuning voor een Linux-distributie afloopt, ontvangt een server niet noodzakelijkerwijs nog steeds beveiligingsupdates via de bestaande pakketbronnen. Dit is vooral problematisch wanneer een gespecialiseerde toepassing nog steeds aan de oude omgeving is gekoppeld. Uitgebreide ondersteuning kan tijd creëren voor een gecontroleerde overgang, zonder dat het einde van de reguliere ondersteuning ongedaan wordt gemaakt.

TuxCare Onbeperkte ondersteuning gedurende de hele levenscyclus for OS biedt beveiligingsupdates en een selectie van bugfixes voor ondersteunde oudere distributies. Volgens de fabrikant omvat het aanbod de kernel en een distributieafhankelijke selectie van belangrijke pakketten. Er wordt geen nieuwe hoofdversie van Linux geïnstalleerd: de server blijft op zijn huidige distributieversie draaien en krijgt extra onderhoud voor de ondersteunde componenten.

Voor de bedrijfsvoering kan dit een belangrijke tijdelijke oplossing zijn: in plaats van een incompatibele toepassing onmiddellijk te moeten omzetten, kan de migratie worden voorbereid terwijl beschikbare beveiligingsupdates voor de ondersteunde pakketten worden geïnstalleerd. Voorwaarde is echter wel dat de daadwerkelijk benodigde pakketten, de architectuur en het gekozen aanbod op elkaar zijn afgestemd.

De Pakketafdekking is niet hetzelfde als de beveiliging van de gehele server. Een zelf geïnstalleerde toepassing, een uitbreiding of een dienst uit een andere pakketbron kan buiten het aanbod van het besturingssysteem vallen. Ook configuratiefouten en onnodig toegankelijke diensten verdwijnen niet door een abonnement; ze moeten nog steeds worden gecontroleerd en beveiligd.

Ook bij gedekte pakketten is de ernst van belang: TuxCare voorziet in beveiligingscorrecties voor hoge en kritieke risico’s vanaf CVSS 7. Bij gemiddelde risico’s van CVSS 4,0 tot 6,9 komen patches volgens de aanbieder in aanmerking als er geen mitigatie beschikbaar is en er voldoende vraag vanuit klanten bestaat. TuxCare behoudt zich bovendien het recht voor om in plaats van een directe codecorrectie een mitigatiemaatregel aan te bieden. Een gedekt pakket betekent daarom niet dat elke bekende kwetsbaarheid daarin wordt verholpen.

Het is daarom niet alleen van belang of de distributie op een ondersteuningslijst staat. Voor Linux-beveiliging houdt bij welke componenten op de betreffende server worden gebruikt, of er geschikte correcties beschikbaar zijn en of deze daadwerkelijk zijn geïnstalleerd. ELS vormt een aanvulling op het patchproces, maar vervangt noch de inventarisatie, noch een migratieplan.

Controleer de afdekking en de serverinventaris

Voordat je TuxCare ELS kiest, moet je eerst Serverinventaris. Noteer de distributie en de exacte versie, architectuur en actieve kernel. Documenteer bovendien de geconfigureerde pakketbronnen en de diensten die openbaar of vanuit andere netwerken bereikbaar zijn. Zo kan de lijst van fabrikanten worden vergeleken met het daadwerkelijke systeem, in plaats van alleen de naam van de distributie af te vinken.

Bij een oudere webserver moeten bijvoorbeeld het webserverpakket, cryptografische bibliotheken, de PHP-runtime en de benodigde PHP-uitbreidingen in de inventarisatie worden opgenomen. Noteer telkens waar het pakket vandaan komt en welke versie is geïnstalleerd. Een uitbreiding uit een externe repository kan andere onderhoudsvoorwaarden hebben dan een pakket uit de oorspronkelijke distributie.

Vergelijk deze componenten één voor één met de actuele pakketlijst voor de betreffende distributie. Controleer ook de architectuur en de voorwaarden van het beoogde aanbod. Het feit dat een distributie wordt ondersteund, betekent niet dat elk daar geïnstalleerd pakket of elke versie daarvan automatisch door ELS for OS wordt gedekt. Zelfs bij pakketten die wel worden gedekt, hangt de aanpak van individuele kwetsbaarheden onder andere af van de ernst ervan.

Vooral zelf gecompileerde programma’s en afzonderlijk geïnstalleerde runtime-omgevingen worden gemakkelijk over het hoofd gezien. Ook een containerimage bevat zijn eigen componenten: het onderhoud van het hostbesturingssysteem garandeert niet dat de pakketten in de image zijn bijgewerkt. Voor dergelijke onderdelen heb je een afzonderlijk bewijs en een eigen updateproces nodig.

ELS voor OS en ELS voor toepassingen zijn afzonderlijke aanbiedingen. Of een oude PHP-versie via een aanvullende aanbieding kan worden onderhouden, hangt onder andere af van de versie, het pakketformaat, de architectuur en de manier waarop deze is verkregen. Een andere mogelijke omgeving voor oudere PHP-toepassingen wordt beschreven in het artikel over CloudLinux Alt-PHP en de bijbehorende beveiligingsaspecten; dit betekent dat er geen dekking is via een TuxCare-OS-abonnement.

Ondersteuningstermijnen correct indelen

Het einde van de ondersteuning is alleen zinvol in combinatie met de betreffende onderhoudsfase. Het einde van het reguliere onderhoud betekent niet altijd dat alle betaalde of aanvullende diensten tegelijkertijd aflopen. Om een beslissing te kunnen nemen, moet je daarom zowel de periode als de gedekte pakketten, architecturen en contractvoorwaarden noteren.

In de momenteel beschikbare TuxCare-documentatie wordt voor ondersteunde besturingssystemen een gegarandeerde ELS-looptijd van 25 jaar vanaf de telkens aangegeven oorspronkelijke einddatum van de ondersteuning. Als voorbeelden noemt zij voor CentOS 7 30 juni 2049 en voor Ubuntu 18.04 31 mei 2048. Dit zijn gegevens van de aanbieder over de ondersteuningsperiode, geen toezegging voor elke geïnstalleerde toepassing.

Voor Ubuntu 18.04 onderscheidt Canonical verschillende fasen: het standaardonderhoud liep af in mei 2023; Ubuntu Pro wordt tot mei 2028 ondersteund. Het huidige overzicht vermeldt mei 2033 voor aanvullende legacy-ondersteuning. Deze aanbiedingen zijn niet alleen op basis van hun einddatums vergelijkbaar, omdat de omvang van het pakket, de architectuur en de contractvoorwaarden voor de specifieke server van belang zijn.

Controleer bijvoorbeeld bij een Ubuntu-webserver of de benodigde pakketten daadwerkelijk in de gekozen onderhoudsversie zijn opgenomen en hoe de updates in het bestaande bedrijfsproces passen. Een langere periode helpt weinig als een kritieke looptijd of uitbreiding buiten de overeengekomen omvang valt.

De genoemde termijnen zijn gebaseerd op dynamische websites van fabrikanten, zoals die op 4 november 2026 bij het onderzoek werden aangetroffen. Of alle actuele gegevens op die peildatum al van kracht waren, kan niet altijd met terugwerkende kracht worden geverifieerd. Controleer daarom de termijnen en pakketlijsten nogmaals vóór publicatie of het sluiten van een overeenkomst en houd rekening met de betreffende Stand van de opvragingen zeker. Zelfs een langdurige ondersteuningsgarantie is geen garantie voor een over het algemeen veilige server.

Een CentOS 7-server in de praktijk opzetten

Stel dat een CentOS 7-webserver tijdelijk een oudere bedrijfsapplicatie moet blijven uitvoeren. Voordat je TuxCare ELS Door deze optie te selecteren, breng je de daadwerkelijke systeemstatus en de afhankelijkheden van de toepassing in kaart. Het is niet alleen van belang of CentOS 7 wordt ondersteund, maar ook of de benodigde componenten voor de bestaande architectuur worden ondersteund.

Je kunt de volgende commando's op de server in een shell uitvoeren. Ze lezen de distributiecode, de machinearchitectuur en de versie van de actieve kernel uit; ze brengen geen wijzigingen aan in pakketten of pakketbronnen. Noteer de uitvoer in de serverinventaris en vergelijk deze met de actuele CentOS 7-handleiding.

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

Vul dit aan Serverinventaris zoals geconfigureerde pakketbronnen, geïnstalleerde pakketversies en openbaar toegankelijke diensten. Bij een webserver gaat het hierbij met name om het webserverpakket, cryptografische bibliotheken, de PHP-runtime en uitbreidingen. Noteer ook welke componenten afkomstig zijn uit externe bronnen of zelf zijn gecompileerd; deze mogen niet zonder controle worden beschouwd als onderdeel van de OS-dekking.

Voor CentOS 7 noemt TuxCare een geldige licentiesleutel, root-toegang en HTTPS-verbindingen als vereisten. De handleiding maakt bovendien onderscheid naar architectuur: voor aarch64 en i686 wordt de userspace-dekking beschreven, terwijl kernel-live-patching alleen voor x86_64 wordt behandeld. Deze beperking geldt voor de CentOS 7-handleiding en kan niet zonder meer worden toegepast op andere distributies.

Controleer vervolgens voor de specifieke toepassing elk benodigd pakket aan de hand van de actuele lijst en neem contact op met de betreffende aanbieder om eventuele hiaten op te lossen. Ook een ondersteunde, actieve kernel bewijst op zichzelf noch dat de toepassing volledig wordt ondersteund, noch dat alle beschikbare updates zijn geïnstalleerd en actief zijn.

Een repository instellen en updates uitrollen

Plan de inrichting als een gecontroleerde controleketen: Allereerst moeten de licentie, de architectuur en de benodigde pakketten op elkaar aansluiten. Vervolgens moet je nagaan of de server via HTTPS toegang mag krijgen tot de doelen die voor zijn distributie vereist zijn. Gebruik voor de registratie en het instellen van de repository de actuele, distributiespecifieke originele handleiding, aangezien de vereisten en doeladressen kunnen veranderen.

Voor CentOS 7 beschrijft TuxCare hoe je het systeem registreert, de pakketbron toevoegt en een PGP-sleutel installeert. Via deze bron kun je vervolgens de juiste pakketten ophalen; de bron installeert echter niet automatisch alle beschikbare updates. Controleer na de installatie of de repository naar behoren is geïntegreerd en of de pakketbeheerder de juiste updates aanbiedt.

Er moet rekening worden gehouden met een proxy of restrictieve uitgaande firewallregels. Voor meerdere systemen kan een lokale mirror, na overleg met TuxCare, een optie zijn. Neem doeladressen niet klakkeloos over uit een algemene FAQ: vergelijk ze vóór de vrijgave met de actuele handleiding voor de gekozen distributie en het beoogde gebruikspad.

Test beschikbare updates eerst in een testomgeving die zo veel mogelijk overeenkomt met de productieomgeving van de bedrijfsapplicatie. Controleer daarbij het opstarten, belangrijke bedrijfsprocessen en koppelingen. Daarna volgen de operationele vrijgave en de installatie op het productiesysteem; documenteer pakketversies, tijdstip en resultaat, in plaats van alleen de succesvolle activering in de repository als afsluiting te registreren.

Als een verwachte update nog niet beschikbaar is, kijk dan ook eens bij de Status van de uitrol. Voor meerdere platforms verspreidt TuxCare updates gefaseerd; na publicatie in de stabiele repository kan dit nog tot 14 dagen duren. Indien nodig beschrijft de aanbieder een tijdelijke oplossing: gebruik deze alleen volgens de actuele instructies voor de betreffende distributie en de specifieke release, en na goedkeuring door de organisatie. Uit de uitrolperiode volgt geen gegarandeerde totale termijn voor een patch.

Zorg bovendien voor een terugvalplan en een geschikt onderhoudsvenster. Licentiesleutels horen niet thuis in gepubliceerde voorbeeldopdrachten, tickets of onbeveiligde logbestanden. Voor de daadwerkelijke registratie moet je de actuele instructies van de fabrikant volgen en toegangsgegevens alleen via de daarvoor bestemde procedures verstrekken.

Vergelijking van onderhoudsalternatieven

De keuze tussen TuxCare ELS en uitgebreid onderhoud door de fabrikant hangt af van de daadwerkelijke pakketlijst en de contractvoorwaarden. De tabel bevat voorbeelden voor de voorselectie, geen algemene toezegging voor elke architectuur of elk pakket. De zoekopdracht is gebaseerd op 4 november 2026; de dynamische gegevens van de fabrikant en de pakketlijsten moeten vóór publicatie opnieuw worden gecontroleerd.

Voor Ubuntu 18.04 liep het standaardonderhoud af in mei 2023. Canonical vermeldt voor Ubuntu Pro ondersteuning tot mei 2028 en in zijn huidige overzicht voor aanvullende legacy-ondersteuning mei 2033. TuxCare noemt voor Ubuntu 18.04 momenteel 31 mei 2048 als einddatum voor ELS. Deze data hebben betrekking op verschillende aanbiedingen; uit een latere einddatum volgt niet automatisch de bijbehorende pakketdekking.

Vergelijk daarom de Omvang van het onderhoud voor elk benodigd pakket en de daadwerkelijk gebruikte architectuur. Bij Ubuntu zijn met name Main- en Universe-componenten relevant, evenals de voorwaarden voor Pro en een eventuele Legacy-toevoeging. Noteer bovendien hoe beschikbare CVE-fixes kunnen worden aangetoond en of de bestaande vrijgave- en updateprocessen aansluiten bij het aanbod.

In beide voorbeelden blijft de migratiebestemming een planningsbeslissing, en geen onderdeel van het onderhoudscontract. Als de bedrijfsapplicatie nog niet op een ondersteund platform kan draaien, kan een geschikt onderhoudsalternatief tijd creëren voor tests. Als geen van de aanbiedingen een kritieke afhankelijkheid dekt, moet deze leemte apart worden aangepakt voordat voortzetting van de exploitatie verantwoord is.

CVE-meldingen en backports controleren

Als een scanner na een update nog steeds een kwetsbaarheid meldt, controleer dan eerst de exacte distributie en versie, evenals de naam, architectuur en geïnstalleerde versie van het betreffende pakket. Ga bovendien na uit welke pakketbron het afkomstig is. Een bevinding met betrekking tot een distributiepakket kan niet zomaar worden toegepast op een zelf gecompileerde toepassing of een pakket uit een externe repository.

De reden voor schijnbare tegenstrijdigheden kan een Backport zijn: Hierbij wordt een beveiligingscorrectie overgenomen in een oudere ontwikkelingsversie, zonder dat het zichtbare upstream-versienummer daarvan overeenkomt met dat van de nieuwste release. Een ouder versienummer op zich bewijst daarom noch dat het pakket kwetsbaar is, noch dat de melding van de scanner onjuist moet zijn.

Vergelijk de specifieke CVE en de geïnstalleerde pakketversie met de gegevens voor jouw distributie in de TuxCare-CVE-tracker. „In Testing“ betekent dat een oplossing nog wordt getest; bij „In Rollout“ wordt deze via rollout-repositories verspreid. „Released“ duidt daarentegen op de volledige vrijgave voor alle gebruikers. Ook dan moet je controleren of de juiste versie daadwerkelijk is geïnstalleerd; „Not Vulnerable“ betekent dat de TuxCare-versie niet is getroffen.

Als een verwachte update ontbreekt in de pakketbeheerder, controleer dan naast de pakketbron en de versie ook de Status van de uitrol. Bij meerdere platforms kan de gefaseerde uitrol na publicatie in de stabiele repository tot 14 extra dagen in beslag nemen. Een eventuele bypass mag alleen in het proces worden opgenomen volgens de actuele, op de distributie en release gebaseerde originele instructies en na goedkeuring door het bedrijf; hieruit volgt geen gegarandeerde totale patchtermijn.

Onderzoek vervolgens de gegevensbasis en de analyse van de scanner. TuxCare stelt voor een reeks ELS-producten OVAL-gegevens ter beschikking; je moet zelf controleren of je tool de juiste gegevens voor het betreffende systeem gebruikt en deze correct interpreteert. Leg de pakketversie, de CVE-status en het tijdstip van de scan vast. Als de afstemming onduidelijk blijft, behandel de bevinding dan verder als openstaand en zoek opheldering bij de bevoegde instanties of de leverancier.

Patch-activiteiten en herstarts plannen

Het opzetten van een repository is het begin van het patchproces, niet het einde ervan. Bepaal wie er regelmatig controleert of er updates beschikbaar zijn, wie de goedkeuring geeft en hoe mislukte updates worden gedetecteerd. Vergelijk daarbij de daadwerkelijk geïnstalleerde pakketversies met de beschikbare updates en noteer de afwijkingen voor elk systeem.

Test updates indien mogelijk eerst op een vergelijkbaar testsysteem met dezelfde applicatie en relevante pakketbronnen. Controleer daar met name het opstarten, het inloggen en belangrijke interfaces van de bedrijfsapplicatie. Pas na goedkeuring door de organisatie rol je de pakketten op gecontroleerde wijze uit; het resultaat en eventuele fouten moeten worden vastgelegd in het installatierapport.

Houd ook rekening met eventuele wijzigingen Onderhoudsvenster. Zelfs na een succesvolle pakketupdate kunnen actieve processen nog steeds oude bibliotheken gebruiken totdat ze opnieuw worden gestart. Eventueel moeten ook applicaties opnieuw worden gestart; bij wijzigingen aan de kernel kan een herstart van het systeem nodig zijn. Controleer na de herstart zowel de werking van de dienst als de verwachte pakket- en bedrijfsstatus.

KernelCare Live Patching is een aanvullend product en moet worden onderscheiden van reguliere ELS-pakketupdates. Het kan ondersteunde kernelcorrecties tijdens het gebruik doorvoeren, maar vervangt noch alle updates, noch elke herstart van een dienst of het systeem. Controleer het product, de distributie en de architectuur: voor CentOS 7 documenteert TuxCare kernel-live-patching alleen voor x86_64. Meer basisinformatie wordt uitgelegd in het artikel over KernelCare Patch Feed.

De uitgave van uname -r geeft de huidige kernel weer, maar niet de volledige updatestatus van de server. Een geïnstalleerd kernelpakket kan bijvoorbeeld pas na een herstart actief worden; omgekeerd zegt de uitvoer niets over de vraag of bibliotheken en applicaties zijn bijgewerkt en opnieuw zijn gestart.

Kies voor een tijdelijke oplossing of migratie

Of TuxCare ELS volstaat voor een specifieke server, hangt af van de daadwerkelijke componenten en risico’s van die server. Vergelijk de benodigde pakketten met de beschikbare dekking en breng openstaande hiaten in applicaties, runtime-omgevingen en externe software in kaart. ELS for OS dekt een distributieafhankelijke selectie; uit de ondersteuning van het besturingssysteem volgt geen onderhoud van elke applicatie die daarop draait.

Controleer ook of er nog CVE-kwetsbaarheden aanwezig zijn in de pakketten die al zijn gedekt. Volgens TuxCare worden gemiddelde risico's alleen in aanmerking genomen voor een patch onder aanvullende voorwaarden; bovendien kan de leverancier een mitigatiemaatregel voorzien in plaats van een directe codecorrectie. Beoordeel daarom voor de specifieke kwetsbaarheid of er een fix of een mitigatiemaatregel beschikbaar is en of de resterende risico's voor je bedrijf aanvaardbaar zijn.

Een tijdelijke oplossing kan zinvol zijn als een gespecialiseerde toepassing voorlopig aan het oude platform gebonden is en de resterende risico’s beheersbaar zijn. Vergelijk echter ook de beschikbare ondersteuning door de fabrikant: voor Ubuntu 18.04 komen, afhankelijk van de benodigde omvang, Ubuntu Pro en eventueel de Legacy-uitbreiding als alternatieven in aanmerking. Controleer pakketten, architectuur en contractvoorwaarden in plaats van alleen de betreffende einddatum.

Voor een openbaar toegankelijke dienst met een verouderde applicatie of een niet-gedekte looptijd kan ELS op zichzelf onvoldoende zijn. Beperk daarom de toegang tot de netwerken en diensten die daadwerkelijk nodig zijn, verwijder onnodige toegangsrechten en controleer de administratieve toegangsrechten. Deze Netwerkbeperking verkleint het aanvalsoppervlak, maar is geen vervanging voor ontbrekende beveiligingsupdates.

Beperk de voortzetting van de bedrijfsvoering tot een bepaalde periode en stel een migratiedoel vast, met verantwoordelijken en een controleerbare deadline. Plan applicatietests op het doelplatform, de gegevensoverdracht en het testen van alle relevante interfaces. Een noodplan moet vastleggen onder welke omstandigheden je de overstap afbreekt en hoe je terugkeert naar de huidige bedrijfsvoering.

Controleer het plan regelmatig aan de hand van nieuwe kwetsbaarheden in pakketten, gewijzigde afhankelijkheden van fabrikanten en de exploitatiekosten. Als benodigde componenten niet langer kunnen worden onderhouden of als de benodigde toegang niet voldoende kan worden beperkt, is een loutere verlenging van het onderhoud van het besturingssysteem mogelijk niet voldoende. In dat geval moeten migratie, vervanging van de applicatie of een gecontroleerde buitengebruikstelling opnieuw worden overwogen.