Beste klant/collega,

(Is dit bericht niet goed leesbaar? Bekijk dan de online versie.)

In de periode 8–18 juni vindt er onderhoud plaats aan het on-prem “netboot” hosting platform. Alle servers worden voorzien van een kernel update en dientengevolge gereboot. Hiermee wordt de stabiliteit en veiligheid van het platform verder verhoogd.

Over een periode van 10 dagen worden +/- 60 systemen gereboot.

Het schema is als volgt:

Impact: klein. Bijna alle systemen draaien in een High Availability of Load Balancing setup. Dat betekent dat een individueel systeem gereboot kan worden, zonder dat het impact voor de dienstverlening heeft. Al deze reboots vinden dan ook gedurende kantoortijden plaats.

De enige uitzondering hierop is de audio encoding omgeving. Dit betreft de systemen die het audiosignaal van de NPO radiozenders aanleveren aan het NEP streaming platform, het NPO icecast platform en via die platforms aan de online luisteraars op de websites en de apps.

Voor de icecast streams levert dat geen onderbreking van het signaal op. De taak van de primaire encoding server wordt tijdelijk overgenomen door de fallback server. Voor het NEP smooth streaming platform levert dit naar verwachting een korte onderbreking van ongeveer 1 minuut per zender op. Hierom vindt het onderhoud aan de icecast encoding processen overdag plaats op 17 juni. Het onderhoud aan de NEP encoding processen vindt plaats in de nacht van woensdag 18 op donderdag 19 juni tussen 1:00AM en 2:00 AM.

Het risico van alle individuele reboots is klein. Maar, omdat het om vrij veel systemen gaat en de kansen –dat er ergens iets mis gaat– optellen, wordt het risico van deze change geclassificeerd als “middel”.

De volgende maatregelen zijn genomen:

1. De bulk van de diensten is zodanig ingericht dat er geen single point of faillure is, en dat dus de onderliggende servers gereboot kunnen worden zonder dat dit impact voor de dienst heeft.
2. Deze reboot ronde wordt +/- 1x per jaar uitgevoerd. Dus er is ervaring en eventuele knelpunten zijn bekend.
3. De reboots worden in de week voorafgaande aan de daadwerkelijke change ook uitgerold in de interne test- en beheeromgevingen, zodat eventuele problemen hopelijk in een vroeg stadium aan het licht komen.
4. Er is een rollback scenario, wat eenvoudig uitgevoerd kan worden indien nodig.

De directe aanleiding voor deze reboot ronde zijn de recent gevonden linux kernel vulnerabilities (CopyFail, DirtyFrag en Fragnesia). Hoewel het netboot platform hier niet kwetsbaar voor was is het altijd mogelijk om de boel nog een stukje veiliger te maken. Deze kwetsbaarheden hebben met elkaar gemeen dat ze op 2 stukken kernel functionaliteit berusten:

• User Namespaces. Dit is een linux kernel techniek waarin het mogelijk is een proces in een namespace (een soort container) te zetten, waarbij het binnen de namespace net lijkt of je superuser bent, terwijl het buiten de namespace gewoon onder je eigen user ID draait.
• User Crypto API's. Hier wordt de cryptografische code die toch al in de kernel zit beschikbaar gesteld aan gebruikers.

User Namespaces klinkt als een goed idee en dat is het ook. (het is bijvoorbeeld wat het mogelijk maakt om op je eigen systeem podman based containers te runnen zonder dat er een centraal hoog gepriviligeerd docker-achtig proces voor nodig is.) Echter, deze functionaliteit komt met een prijs, namelijk toegenomen complexiteit. In die extra complexiteit kunnen bugs zitten die tot privilege escalations kunnen leiden. Een heldere uitleg staat hier.

Nu wil het geval dat netboot helemaal geen gebruik maakt van user namespaces (de support daarvoor is ooit aangezet omdat er toen plannen waren om het misschien ooit in de toekomst te gebruiken). Dus door nu support voor user namespaces in z'n geheel uit te zetten worden toekomstige aanvallen langs deze weg bij voorbaat uitgesloten.

Iets vergelijkbaars geldt voor de User Crypto API's. Normaal heeft een kernel tot taak om als een middle-man tussen de hardware en de gebruiker in te zitten. Op een unix/linux systeem kan een gebruiker niet zelf direct de hardware opdrachten geven. De gebruiker kan enkel de kernel vriendelijk vragen om hardware dingen te laten doen. Het verschil is dat in dit model de kernel “nee” kan zeggen, bijvoorbeeld als de gebruiker de rechten niet heeft om bepaalde zaken te doen. Echter, voor User Crypto API's is dat een beetje anders. Het nut hiervan is om cryptografische code die toch al in de kernel zit ook aan gebruikers beschikbaar te stellen. Dus dit gaat niet primair om het ontsluiten van hardware, maar meer om het ontsluiten van software.

Maar, er is meestal geen reden om hier kernel code voor de gebruiken. Een userspace proces kan prima userspace code (denk aan OpenSSL) gebruiken voor cryptografische operaties. Ook hier geldt: die kernel ontsluiting wordt in het netboot platform helemaal niet gebruikt en kan dus in z'n geheel uitgezet worden, waarmee ook hier toekomstige aanvallen via dit pad bij voorbaat worden uitgesloten.

Team Hosting&Streaming is gedurende het onderhoud via de normale kanalen bereikbaar. Zie de contact pagina