Componenten en beveiliging

Op je servers draait meer dan het paneel en de agent: een webserver, een mailserver, PHP in twaalf reeksen, een FTP-server, een spamfilter, een kernel. Elk van die onderdelen krijgt beveiligingsupdates van iemand — Canonical, een leverancier, of CoreCP zelf — en de vraag die je als beheerder elke dag zou willen stellen is: is er een lek bekend in iets wat bij mij draait, en is de oplossing er al?

Deze pagina beantwoordt die vraag. Open Servers → Componenten & beveiliging.

Alleen beheerders zien dit. Resellers en eindklanten zien nooit welke software er op een server staat, laat staan welke lekken erin zitten.

Wat je bovenaan leest

Zes tegels, in de volgorde waarin je ze wilt weten:

• Open bevindingen — alles wat de bewaking nog niet opgelost ziet.
• Kritiek — bevindingen waar je vandaag iets mee moet.
• Actief misbruikt — lekken die op de lijst van de Amerikaanse CISA staan als "wordt in het wild misbruikt". Dat is de zwaarste categorie: iemand kan er al binnen zijn.
• Oplossing te laat — een Ubuntu-onderdeel waarvoor Canonical de oplossing nog niet geleverd heeft binnen de termijn die het platform hanteert.
• Einde ondersteuning — reeksen die binnen negentig dagen aflopen, of al afgelopen zijn.
• Servers geraakt — hoeveel machines in je vloot een open bevinding hebben.

Staat er een oranje balk boven de tegels, dan kon de bouwserver vanochtend niet elke bron bereiken en heeft hij voor die bron het antwoord van een eerdere dag gebruikt. Dat is geen fout, maar het is goed om te weten dat een deel van wat je ziet van gisteren is. Onderaan de pagina staat per bron of hij vers was.

Het register

De tabel is het register: elk onderdeel dat het platform levert, met de klasse die zegt wie het bijhoudt.

De ernstigste open bevinding staat bovenaan. Filter op klasse of zoek op een naam of pakket; klik op een rij om het onderdeel te openen.

Wat een bevinding zegt

In het zijpaneel staan de feiten van het onderdeel — welke reeks het platform volgt, waar het vandaan komt, wanneer de ondersteuning eindigt, welke bronnen erover gelezen worden — en daaronder de bevindingen als kaarten. Elke kaart zegt vijf dingen:

1. Hoe ernstig het is: kritiek, hoog, middel, laag. Kritiek is een lek dat actief misbruikt wordt, dat de bron zelf kritiek noemt, of een oplossing die te laat is.
2. Wat voor soort nieuws het is: een beveiligingslek, een nieuwe uitgave, een nieuwe hoofdversie waarover beslist moet worden, een reeks die afloopt.
3. Welke servers het raakt — alleen machines die de kwetsbare versie echt draaien, niet "alles waar het pakket op staat".
4. Of er een oplossing is, en welke versie dat is.
5. Welke bron het meldde, met een link om verder te lezen.

Een bevinding die de bewaking niet meer ziet — de oplossing is geïnstalleerd, de reeks is weg — wordt als opgelost gemarkeerd. Met Ook opgeloste tonen lees je de geschiedenis van een onderdeel terug.

Wat er gebeurt zonder dat je iets doet

• Een kritieke bevinding (actief misbruikt, of te laat) stuurt direct een bericht: een e-mail op het alarmadres en een pushmelding op elk toestel dat meldingen aan heeft staan. Eén keer per bevinding, niet elke dag opnieuw.
• Elke andere bevinding is een regel in je bel, onder Systeem.
• Op maandagochtend staat er een weekoverzicht in je bel: wat er vorige week gevonden en opgelost is en wat er nog openstaat. Hetzelfde overzicht staat onderaan deze pagina.
• Voor een onderdeel van klasse C bouwt de bouwstraat de oplossing en test hem op de testomgeving; als dat gelukt is krijg je de melding klaar voor uitrol. De uitrol zelf blijft jouw handeling, via Releases.

Er wordt op deze pagina nooit iets geïnstalleerd. De bouwserver leest de bronnen, vergelijkt ze met wat je vloot draait en meldt het verschil.

Klaar voor uitrol: wat de bouwstraat voor je doet

Voor een onderdeel van klasse C hoeft niemand te wachten tot jij tijd hebt. Zo gauw de bron een nieuwe versie heeft, doet de bouwstraat in één keer het hele voortraject:

1. De bron ophalen. Uit het archief van Debian, over de handtekening van dat archief en de controlegetallen die daarin staan. Klopt er iets niet aan de handtekening of aan één bestand, dan stopt het daar — er wordt niets gebouwd van bytes die niet kloppen.
2. Bouwen. In een schone, verse Ubuntu 26.04-omgeving zonder netwerk, zodat het pakket is wat de bron zegt en niets anders.
3. Ondertekenen. Elk pakket krijgt een handtekening en een materiaallijst — welke bronnen erin zitten en hoe ze gecontroleerd zijn.
4. In het kanaal edge zetten. Daar staat elke build; nog niets installeert hem.
5. Testen op de testomgeving. Precies die versie wordt op een testserver geïnstalleerd, en dan krijgt het onderdeel zelf de vraag: doe je het nog? ProFTPD moet zijn configuratie lezen en een client begroeten, Rspamd moet een bericht scannen. Daarna zet de test de server terug op de versie die hij had.
6. Bij groen: naar beta. Alleen die pakketten, niets anders beweegt mee. Je krijgt de melding klaar voor uitrol, met de ernst, de termijn en de servers die het raakt.

Rood is het einde van de rit. Zakt de test, dan wordt er niets doorgeschoven: het pakket blijft in edge staan en je krijgt een melding met de plek van het testverslag, zodat de versie die op je servers draait blijft draaien tot er iets beters is.

De laatste stap — uitrollen naar productie — gebeurt nooit vanzelf. De bouwstraat komt tot beta en niet verder; productie haalt op wanneer jij dat via Releases in gang zet.

Eén onderdeel hangt aan een ander: de firewallmotor op nginx

Op een server met alleen nginx is de motor van de firewall voor websites (in het register ModSecurity v3) een module die alleen laadt in precies de nginx-versie waarvoor hij gebouwd is. Een nginx-update naar een nieuwe versie wordt daarom tegengehouden op elke server waar de firewall aanstaat, tot er een motor voor die versie gebouwd, getest en uitgerold is — de server houdt de nginx die zijn firewall kan laden, in plaats van een nginx die niet start. Je ziet het als een nginx-update die nog wacht; hij gaat door zodra de passende motor er is. Zie De firewall vóór je websites.

Uitrollen via de patchroute

Staat een onderdeel klaar in beta, dan zie je in het paneel — bij die bevinding, in het zijpaneel van het onderdeel — de knop Uitrollen via patchroute. Dat is de enige knop op deze pagina die iets doet, en hij doet precies één ding: de servers die je aanvinkt vragen om de versie te installeren die hun eigen kanaal al aanbiedt.

Wat je ziet voordat je klikt: welke versie, in welk kanaal, en om welke servers het gaat. Je kunt eerst proefdraaien — dan vertelt elke server wat hij zou installeren en installeert hij niets. Daarna krijg je per server één regel terug: wat er bewoog, of dat hij al bij was, of waarom hij weigerde. Vijftien servers en één weigering is veertien servers klaar en één regel die zegt welke niet — geen rode balk die de andere veertien verbergt.

Naar productie gaat hier niets. Een pakket in een ander kanaal zetten is een handeling van een mens op de bouwserver; deze knop kan dat niet, en dat is geen belofte maar hoe het in elkaar zit.

Wat de server zelf controleert

Een onderdeel dat wij zelf bouwen heet net zo als het pakket van Ubuntu — proftpd-core blijft proftpd-core. De server lost dat op twee manieren op:

• Hij kiest de onze. Niet op versienummer (dan zou een hoger nummer van Ubuntu je ongemerkt van onze patch af halen), maar op het kanaal waar het pakket vandaan komt.
• Hij controleert de handtekening. Voor elk pakket dat van ons kanaal komt wordt de ondertekende materiaallijst gecontroleerd én worden de bytes op schijf ernaast gelegd, vóórdat er iets wordt uitgepakt. Klopt er één byte niet, dan wordt er niets geïnstalleerd, blijft de server op de versie die hij had, en komt de weigering in het logboek dat het paneel leest. Een pakket zonder handtekening is geen uitzondering maar een weigering.

Pakketten van Ubuntu zelf — ook als je onze spiegel gebruikt — blijven gewoon via de nachtelijke beveiligingsupdates binnenkomen.

Terugrollen

Blijkt een nieuwe versie toch verkeerd te vallen, dan kun je terug. De vorige versie blijft in het kanaal staan (de huidige plus drie oudere), en terugrollen zet hem terug én houdt hem daar vast tot jij verder wilt. Vraag je een versie die er niet meer is, dan zegt de server dat, met de lijst van wat er wél is — je krijgt geen server die stilletjes stopt met updaten. Teruggaan naar de versie van Ubuntu mag ook: "onze patch valt verkeerd" is een geldig antwoord.

Vanaf de terminal

Op de bouwserver, waar de bewaking draait:

Bouwen doe je vanaf de machine waar je de andere releasegereedschappen ook draait (de bouwstraat werkt zelf op de bouwserver):

scripts/component-build list                    # wat de bouwstraat kan bouwen
scripts/component-build proftpd --dry-run       # wat een run zou doen
scripts/component-build proftpd --severity critical --cve CVE-2026-1234

Op de bouwserver, waar de bewaking draait:

component-watch validate               # is het register geldig?
component-watch sync --dry-run         # kijk, druk af, schrijf niets
component-watch show                   # het laatste rapport
systemctl list-timers component-watch.timer

Op de paneelserver:

corecp-panel components list           # het register met open bevindingen
corecp-panel components findings --component proftpd
corecp-panel components digest --force # het weekoverzicht nu schrijven

Het register zelf is infra/components/components.yaml in de broncode; docs/components.md beschrijft hoe een onderdeel wordt toegevoegd en hoe de bronnen worden gelezen.

Waar een productieserver zijn onderdelen vandaan haalt

Op productie praat een server met één bron: het productiepaneel. Dat paneel serveert niet alleen de pakketten van CoreCP, maar spiegelt ook de leveranciersonderdelen (PowerDNS, MariaDB, MySQL, LiteSpeed, de PostgreSQL-hoofdversies) en de onderdelen die CoreCP zelf bouwt (PHP, Rspamd, ProFTPD, …): ieder uur alleen-lezend opgehaald bij de buildserver, gecontroleerd tegen de handtekening van de buildserver en opnieuw ondertekend met de werksleutel van het paneel. Ubuntu zelf — ook de beveiligingsupdates — blijft van Canonical komen; het paneel spiegelt Ubuntu niet, en de nachtelijke beveiligingsronde leest die updates dus rechtstreeks. Wat je hiervan ziet staat bij Releases beheren → De spiegels: welke spiegels het paneel serveert, welk snapshot, en of er een geweigerd is.