Q&A met serverbeheerder Kees Hoekzema

Vraag alles over servers, hosting en security

titel

Het feit dat je iedere dag zonder problemen op Tweakers kunt kijken, komt voor een belangrijk deel door het werk van Kees Hoekzema. Hij doet de devops bij Tweakers en zorgt dat de servers iedere dag blijven draaien, de beveiliging op orde is, de laadtijden van de site zo minimaal mogelijk zijn en dat de site ook nog bereikbaar blijft als wij ineens een heel populair artikel schrijven en de bezoekcijfers door het dak gaan. Vorige week kon je een video zien waarin Kees alles vertelt over de servers van Tweakers, en op vrijdag kun je Kees in dit artikel alles vragen over zijn werk.

Kees werkt al sinds 2002 voor Tweakers. Hij is dus een zolderkamernerd van het eerste uur, samen met Femme en Arjen. Overigens was hij, getuige dit artikel, al in 2000 betrokken bij de site. We schreven daar ter ere van de 25e verjaardag van Tweakers al eens een artikel over. In 2001 nam hij het serverbeheer van de site over, en dat is hij sindsdien altijd blijven doen. In 2018 was hij ook degene die de ddos'er Jelle S. op wist te sporen, nadat die niet alleen banken en de Belastingdienst maar ook Tweakers probeerde plat te leggen. Eerder deze week publiceerden we ook een video met een kijkje achter de schermen van het serverpark van Tweakers, waar Kees uitgebreid vertelt over de hard- en software die nodig is om de site up-and-running te houden. We raden je vooral ook aan die te kijken om te weten hoe Kees te werk gaat!

Waar, wanneer en hoe?

Over Kees Hoekzema

Kees werkt sinds 2002 bij Tweakers. Als serverbeheerder is hij verantwoordelijk voor het draaiend en veilig houden van de servers.

Kees zit op vrijdag tussen 15.00 en 17.00 klaar om jullie vragen te beantwoorden. Die kun je nu al onder dit artikel in de comments stellen. Wil je live meelezen of vervolgvragen stellen, check de comments dan tussen de genoemde tijden of zorg dat je notificaties voor replies op jouw reactie aanstaan (belicoontje rechtsbovenin > 'Ontvang pushnotificaties').

Een Q&A? Hoe zit dat?

Tweakers organiseert regelmatig Q&A's met redacteuren en werknemers. Tijdens een Q&A kun je vooraf vragen stellen aan deze tweakers, die de vragen in de middag beantwoordt. Later publiceren we ook een overzichtsartikel met de beste vragen en antwoorden.

In de toekomst willen we meer Q&A's organiseren met Tweakers-redacteuren. Laat ons in de comments dan ook vooral weten welke redacteur jij graag het vuur aan de schenen zou willen leggen!

We organiseerden eerder al Q&A's met andere redacteuren:

• Tomas Hochstenbach over pc-hardware
• Olaf Weijers over netwerken en wifitestprotocollen
• Jeroen Horlings over duurzaamheid, EV's en fotografie
• Arnoud Wokke over telefoons, AI en 15 jaar Tweakers
• Donovan Kerssenberg over smartphones en retrogaming
• Wout Funnekotter over Tweakers-redacties en smarthomes
• Luke van Drie over videostudio-set-ups, camera's en video's maken
• Jurian Ubachs over gamen voor je werk
• Sjef Weller over televisies en audio
• Jelle Stuip over laptops en wifitestprotocollen
• Eugène van der Put en Monique van der Boomen over eindredactie, d/t-fouten en schrijfwijzers
• Jasper Janssen over Tweakers op sociale media
• Friso Weijers over monitors, smartphones en treinen
• Eric van Ballegoie over wearables en thuisbioscopen
• Daan van Monsjou over cpu's, gpu's en andere componenten

Reacties (116)

[Ireyon]

Welke certificeringen heb je in je carriere behaald? (Geloof je in certificeringen of pure kennis en werkervaring?)

Wie heeft de huidige front-end en back-end stack bepaald en hoevaak zijn jullie van FE/BE-stack veranderd?

Doe je echt alles zelf, of huren jullie handjes in wanneer het werk teveel wordt? (Is er een "back-up" Kees)

Ik ben gestopt na 23 jaar systeembeheer omdat alle on-prem bare metal veranderde naar cloud hosting en veel werk uitbesteed ging worden. Jij hebt nog veel on-prem draaien en werkt hands-on. Vind je dat het leukste, of zie je een transitie naar de cloud veel leuker worden voor jezelf?

(Als voormalig systeembeheerder bofh kan ik niks anders dan respect hebben voor andere bofh's)

[Kees]

Mijn studie (informatica) heeft eigenlijk weinig invloed in mijn dagelijkse werk. Sommige technieken die ik daar leerde waren (achteraf gezien) tijdloos en gebruik ik nog afentoe (zoals kennis van compilers en programmeer talen), andere zijn hopeloos achterhaald (zoals een vak over softwareontwikkeling).

Andere certificaten heb ik nooit gehaald, als eerste was daar gewoon geen vraag naar vanuit het management, en aan de andere kant ben ik iemand die voornamelijk leert door iets zelf te doen. Ik vind het dus lastig om iets te leren alleen voor een certificaat zonder dat ik het in de praktijk ga gebruiken.

Over de frontend weet ik niet genoeg om te zeggen hoe vaak we van stack zijn veranderd, wellicht dat @crisp daar meer van weet.

De backend is eigenlijk altijd php geweest, en vanaf 2006 een stuk java. De code is te complex om zomaar te herschrijven in een andere taal of stack en ons team is daar te klein voor. We zijn dus gewoon php en java blijven onderhouden.

Ik ben gestopt na 23 jaar systeembeheer omdat alle on-prem bare metal veranderde naar cloud hosting en veel werk uitbesteed ging worden. Jij hebt nog veel on-prem draaien en werkt hands-on. Vind je dat het leukste, of zie je een transitie naar de cloud veel leuker worden voor jezelf?

De cloud is ook leuk, maar dan wel als ik het zelf mag opzetten "Gewoon" richtlijnen volgen van anderen en weinig inspraak hebben op hoe zaken opgezet worden zou denk ik niet echt aan mij besteed zijn. Maar daar is voor zover ik weet nog geen sprake van.

[Reactie gewijzigd door Kees op 3 januari 2025 17:23]

[crisp]

Onze front-end stack is ook niet heel erg veranderd. We gebruiken nog steeds voornamelijk vanilla JS en CSS. We gebruiken inmiddels wel webpack voor bundling en transpiling/polyfills en zijn bezig om alle oude - voornamelijk procedurele - code om te zetten naar (web)components en modules. Voor testing gebruiken we Jest en Cypress, en op dat punt hebben we de laatste jaren echt vooruitgang gemaakt, vooral omdat anders niemand mijn oude JS code durfde aan te raken

[synoniem]

De primaire database is MySQL maar daarnaast wordt er ook MongoDB en MEMcache gebruikt. MEMcache is een logische qua snelheid maar MongoDB hoe heb je dat geïntegreerd? Waarbij ik gemakshalve aanneem dat MySQL een historische keuze is waarbij ik zelf als ik nu zou beginnen voor deze omvang databases eerder PostGreSQL zou kiezen. Hoe zie jij dat?

[Kees]

Klopt dat mysql een historische keuze is en we wellicht iets anders zouden kiezen als we het opnieuw moeten opzetten. Maar dan zou ik het hele database landschap bekijken en mischien alsnog bij mysql uitkomen. Zo slecht is het niet

Mongodb zijn we gaan gebruiken om sessies in op te slaan, waarbij de sessie een document is en je er willekeurige data in kon stoppen. Voornamelijk om mysql te ontlasten en omdat mysql toen geen goede json ondersteuning had. Later zijn er nog wat meer 'document'-achtige zaken in gezet, maar we gebruiken het relatief weinig. De mongo database is nu zo'n 15G groot, de mysql database zo'n 750G.

[InfoTracer]

@Kees of @crisp wat is de rede dat jullie er voor hebben gekozen om de sessie op te slaan in Mongodb en niet bijvoorbeeld in Redis aangezien er toch gekozen moest worden voor een hele nieuwe data storage service.

[ACM]

Aanvullend op @Kees; ik ben zelf groot fan van PostgreSQL. Maar het heeft helaas niet alleen voordelen tov MySQL.

Ik denk dat het grootste nadeel voor Tweakers is dat "rolling upgrades" niet mogelijk zijn bij nieuwe major versies, dus van versie 16 naar 17 kon je niet gewoon met 17 werken op de data die in versie 16 was opgebouwd. In MySQL kan dat wel, hoewel je niet altijd meer daarna kunt terugrollen naar een oudere versie.

Zoals je kan lezen bij Kees is onze MySQL database zo'n 750GB groot; zo'n hoeveelheid data moeten exporteren in versie X-1 en weer importeren in versie X gaat wel even duren... En we hadden in het verleden ook niet altijd de benodigde reserve disk-capaciteit om een kopie van de database te kunnen hosten.
Het doen van een update zonder downtime en zonder dataverlies zal in ieder geval complexer zijn dan bijvoorbeeld bij MySQL. Je moet onder andere iets hebben om wijzigingen die tijdens de export of import gebeuren alsnog ook in de nieuwe versie te krijgen. Daar zijn in de Postgres-wereld vast oplossingen voor, maar MySQL (en vast ook andere database) heeft dat niet nodig omdat ie zelf de data update.

En ook rond replicatie was MySQL een eenvoudiger oplossing dan Postgres, we hebben nu al jaren effectief een multi-master opstelling, iets wat in Postgres nog steeds niet 'native' bestaat (hoewel dat met Logical replication wel mogelijk lijkt?).

Overigens is de moderne MySQL best goed geworden in SQL, de achterstand in data-integriteit tov Postgres is grotendeels ingelopen en ook qua query-mogelijkheden is er veel mogelijk geworden met versies 4, 5 en 8 (ze hebben 6 en 7 overgeslagen).

[Reactie gewijzigd door ACM op 3 januari 2025 16:45]

[Q]

Dag Kees,

Algemeen
Wat vind jij op dit moment interessant in de context van je vakgebied (devops), wat heeft op dit moment jouw interesse, waar zou je iets mee willen doen? Kan tech zijn of wat dan ook.

K8s
Misschien kun je iets delen over de beweegredenen om Kubernetes / containers toe te passen gegeven de context van Tweakers. Het lijkt vooral een keuze vanwege de behoefte van development en het release proces, niet zo zeer schalen van services, maar misschien dat je dit kunt verduidelijken / mij corrigeren.

Eventueel ben ik ook benieuwd of je de Kubernetes clusters upgraded of dat je een nieuwer cluster uitrolt en switched. Of kies je misschien voor een andere aanpak?

Cloud VS servers
Naar mijn weten draait nu.nl in de cloud. Waarom denk je - afgezien van enkele breaking news incidenten - de cloud financieel voor hun wél werkt?

Cheers en thanks!

[Reactie gewijzigd door Q op 3 januari 2025 15:08]

[Kees]

Ook al is het al een tijd bezig, containers (met bijvoorbeeld podman of docker) blijft toch een facinerend iets ook al zitten daar nog steeds veel nadelen aan. Zo is er nog niet echt een goede manier om containers goed up-to-date te houden (ik zie vaak genoeg images die al 5 jaar lang geen updates hebben gehad, maar omdat ze niet verdwijnen van dockerhub blijf je onbewust de oude images gebruiken).

Verder wil ik meer gaan doen met canary deployments en automatisch terugdraaien van releases als ze niet goed werken.

Misschien kun je iets delen over de beweegredenen om Kubernetes / containers toe te passen gegeven de context van Tweakers. Het lijkt vooral een keuze vanwege de behoefte van development en het release proces, niet zo zeer schalen van services, maar misschien dat je dit kunt verduidelijken / mij corrigeren.

Klopt helemaal, we schalen nog niet al teveel services, ook omdat wij niets extra's betalen als een service relatief ongebruikt blijft doordraaien. Maar waar we het voornamelijk voor gebruiken is de orchestration. Het is makkelijker om services up-to-date te houden en niet afhankelijk te zijn van de versie in de linux distributie die je nu gebruikt.

Je hebt bijvoorbeeld MongoDB. Daar gebruikten we lange tijd de versie uit de ubuntu repository, maar die wilden we updaten. Echter bleek dat niet zo eenvoudig te zijn, en uiteindelijk hebben we die in een container gezet (met een HostPath voor data) zodat we nu eenvoudig MongoDB 6.x kunnen gebruiken zonder afhankelijk te zijn welke distributie er op de servers draait.

Hetzelfde gaat op voor Tomcat, PHP etc. Je kan natuurlijk wel extra repositories toevoegen aan de distributie die je gebruikt, maar dat zul je toch moeten blijven bijhouden. Het 'gewoon' in een container draaien maakt het testen van nieuwe versies ook eenvoudiger. We hebben bijvoorbeeld al een test omgeving met PHP8.4 zonder dat we alle servers naar 8.4 om hebben hoeven te zetten.

En dan ook die tomcat-container als voorbeeld. Als we een java versie willen updaten dan is dat nu simpelweg een merge request mergen die RenovatBot aanmaakt en hoef ik niet meer alle servers bij langs om daar een specifieke java versie te instaleren (puppet zou het doen, maar dan nog moet het wel op elke server gebeuren in plaats van dat je eenmalig een container bouwt)

Eventueel ben ik ook benieuwd of je de Kubernetes clusters upgraded of dat je een nieuwer cluster uitrolt en switched. Of kies je misschien voor een andere aanpak?

Hier worstel ik nog mee. Momenteel kies ik ervoor om de servers te upgraden (volgens de guide van kubernetes) en geen nieuw cluster op te tuigen voor elke upgrade. Met name omdat er nog iets te veel handmatig werk zit in de interne routering tussen de loadbalancers en services.

Maar dan krijg je elk jaar weer de verassing als certificaten verlopen en je daar in moet duiken. En als je te laat bent, dan is het updaten van verlopen certificaten niet perse een kwestie van een enkel commando.

En ook de interne services van kubernetes up-to-date houden (zoals bijvoorbeeld calico) heb ik nog geen goede oplossing voor. Die zijn ooit een keer tijdens het opzetten van het cluster geinstaleerd maar worden niet automatisch bijgewerkt.

Naar mijn weten draait nu.nl in de cloud. Waarom denk je - afgezien van enkele breaking news incidenten - de cloud financieel voor hun wél werkt?

Het is denk ik ook een stuk waar ze vandaag komen en welke reis ze hebben gemaakt naar de cloud. Wat ik vaak zie is dat de 'operations' in een bedrijf ver weg staat van development en je dan frictie krijgt waar de developers iets willen, maar operations dat niet wil opzetten en/of draaien. Die developers gaan dan zelf maar iets verzinnen en omdat ze niet zelf 'operations' mogen doen en een eigen colocatie op mogen zetten (omdat het er al is) gaan ze de cloud maar gebruiken, want dat is anders..

Overigens krijg je daarna ook weer een beweging de andere kant op, waar teams vanalles zelf doen en er een team (dat nu niet meer operations heet maar secdevops) ontstaat dat weer werk van de developers overneemt en standaarden gaat afdwingen. En na een paar jaar zal je ongetwijfeld weer die zelfde frictie krijgen die er toe leidde dat men in de cloud is gaan zitten.

Bij ons was die frictie er nooit, ik zit altijd al in/naast het development team en ben dus eigenlijk devops lang voordat die term ontstond. Bij ons hadden we dus weinig reden om een alternatief te zoeken.

Overigens zouden we financieel gezien best in de cloud kunnen draaien, maar hoe we nu draaien is een stuk goedkoper dus waarom zouden we verkassen?

[good_username]

Wat betreft de "extra" beheertaken die bij het upgraden k8s horen vind ik kubespray wel een ideaale oplossing.
Is wel gebaseerd op Ansible (ik begreep ergens anders dat er standaard Puppet gebruikt word)
Maar je zou je kubernetes/kleine ansible basis met Puppet kunnen aanleggen en daar dan kubespray overheen gooien via een pipeline of handmatig.
Deze upgradet ook alle onderdelen zoals calico en vervangt de certificaten bij een upgrade, dus als je hier in bij blijft verlopen deze in principe niet.

[Q]

Bedankt Kees voor de zeer uitgebreide en verhelderende toelichting. Wordt gewaardeerd.
Ik vind de open en genuanceerde ervaring met Kubernetes/Containers (positieve en negatieve kanten) erg interessant. Ik denk dat je evaluatie van nu.nl ook wel op zijn plaats is, ik heb in omgevingen gewerkt waar ik precies deze dynamiek tussen dev en ops heb gezien.

[TheBrain]

Het verlopen van certificaten zou maar maximaal 1 keer een verrassing moeten zijn natuurlijk. Mik ergens in een ticket systeem / CMDB / certificate management een ticket met een verloopdatum in en een alert 30 of 60 dagen voor het verlopen van het ticket. Dan heb je altijd voldoende tijd om zonder kunst en vliegwerk en/of ongeplande downtime de certs te vervangen.

[eJazz42]

Als oud server beheerder (begin jaren 2000) weet ik nog de tijden dat je weer in de auto moest springen om een server of switch hard te resetten. Hadden jullie dit ook? En vanaf welk moment had jij het idee dat je niet meer elk moment beschikbaar hoefde te zijn bij soft of hardware falen?

[Kees]

Klopt helemaal. Zeker in de begintijd kon ik de meeste servers niet op afstand beheren. Dus een van de eerste 'extra' aankopen in ~2002 was een slimme APC powerswitch die op afstand te bedienen was. Dat hielp al wel een beetje, maar dan kon je nog steeds naar de colo als de server niet wilde booten.

De volgende aankoop was een console switch, maar dan moest je de server wel goed voorbereiden, onder andere door in de bios aan te zetten dat hij de bios ook over serieel moest weergeven.

Dat hielp al een beetje, maar vrij kort daarna begonnen we prebuild servers te kopen en al snel ontdekte ik de remote controllers zoals imm, ilom of idrac. Die heb ik vanaf ~2006 standaard aangevinkt als ik een server kocht.

Zelfs dat was nog niet helemaal ideaal, dus in 2012 hebben we een project afgerond om alles redundant uit te voeren, inclusief locatie, netwerk, stroomvoorziening etc. Dat hielp nog het meeste. Dus het antwoord is dat vanaf 2012 ik rustig een server een weekend lang plat kon laten liggen en niet meer mijn bed uit kwam als ik een alert binnen kreeg.

Tegenwoordig kom ik alleen in het datacenter om nieuwe servers op te hangen en oude servers te verwijderen en soms de dag erna nog een keer omdat ik een kabel vergeten ben of die is niet goed aangedrukt

[darioboy75]

Tegenwoording kan je met een slimme PDU (bv een Schleifenbauer of vergelijkbaars) de stroom uit of aan schakelen naar je servers, verbruik meten en meer.

Met digitale serial switches kan je van afstand een seriele poort bedienen, technisch gezien hoef je bijna niet meer in een datacenter te komen. Mits geen hardware failures enzo / fysieke wijzigingen.

[KoeKk]

Die APC powerswitch is zo een slimme pdu, bestaat al zeker sinds 2000, en is dus zeker niet iets van ‘tegenwoordig’ . Ook ‘lights out management’ (LOM) voor servers zoals iLO en iDRAC is iets uit begin 2000.

Wat ik veel tegenkom is de combi van serieel naar IP voor netwerkapparaten (zoals die van Digi, Perle of OpenGear), en dan het open IPMI of HPE iLO of Dell iDrac (of het vergelijkbare van de hardware fabrikant) voor LOM

[GewoonWatSpulle]

De dual Pentium 3 dagen was dat volgens mij al over ik meen mij Tyan moederborden te herinneren die een soort management port hadden, een soort rudimentaire IPMI. Volgens mij had Tweakers destijds vergelijkbare machines.

[zwittrooper]

Leuk om wat meer inzicht te hebben in jullie infrastructuur! Ben zelf ook beheerder en was benieuwd van welk OS/virtualisatie oplossing jullie eigenlijk gebruik maken? En waarom hebben jullie daarvoor gekozen?

[Kees]

We gebruiken standaard Debian (en een verdwaalde Ubuntu/Centos/Rocky/Alma server) en als virtualisatie gebruiken we qemu/kvm met virt-manager. We virtualiseren niet alles maar houden vrij veel dicht op het metaal. Als een server maar 1 taak heeft, dan zie ik niet perse het nut ervan om er een extra laag tussen te stoppen.

[zwittrooper]

Dank voor je reactie, helemaal mee eens inderdaad. Nog een vervolgvraag: Volgens mij gaf je in de video aan dat jullie ceph gebruiken voor de opslag? Maken jullie dan ook gebruik van synchrone replicatie naar de backup locatie via ceph? Of doen jullie dit alleen op applicatie niveau? (bv via mysql replicatie). Ben voor onze eigen Backup locatie momenteel aan het kijken naar de beste opties.

[Kees]

Wij hebben een behoorlijk lage latency tussen de twee locaties (via een gebundelde dark fiber van 2x10Gbits). Wij repliceren ceph dus 'gewoon' over die link en het is dus 1 cluster. Dat houd wel in dat een eventuele failover als 1 locatie helemaal wegvalt iets lastiger is, maar dat je die data dan wel lokaal al beschikbaar hebt.

[DarkWoesel]

Hoe makkelijk en snel gaat het proces van alle data pakken van de webwinkels en hoe scannen jullie op nieuwe producten bij de webwinkels?

[Kees]

Wij halen elke ochtend alle lijsten op (webwinkels geven ons een url), ongeacht of ze veranderd zijn en laden die prijzen in de database. Daar beginnen we om 5:00 mee, en om 5:13 is alles verwerkt. Dat is zo'n 5,5G aan data en 42 miljoen regels. Vervolgens halen we een prijslijst alleen op als de server aan de andere kant zegt dat hij geupdated is ('last-modified'). Dan halen we hem binnen en verwerken hem nog een keer. Dat doen we elke 15 minuten

Nieuwe producten zijn 'simpel', die staan dan nog niet in onze database en zijn dus nieuw. Die zetten we dan eerst in de unsorted pricewatch waarop ons Pricewatch Content team die producten bekijken en eventueel specificaties en afbeeldingen toevoegen en in de pricewatch zetten.

Ook kunnen we zelf producten toevoegen, bijvoorbeeld als nvidia de 50xx-series uitbrengt dan zal een redacteur dat product vast aanmaken met specificaties die op dat moment bekend zijn. Later voegen we ook 'sku' en 'ean'-identfiers toe waardoor we een koppeling kunnen leggen met de producten in de prijslijsten van winkels

[CPV]

Ik heb in het verleden begrepen, dat de webwinkels zelf hun info op Tweakers updaten.
Klopt dat?

[don_jorg]

Ik kan niet over Tweakers praten, maar ik heb bij een andere vergelijkingssite gewerkt. Daar werd 1 of 2 keer per dag een XML-bestand opgehaald bij de webwinkels, met daarin de prijzen/levertijd/etc.

[Eagle Creek]

Gelukkig kunnen we wel over Tweakers praten, want dé Kees in kwestie heeft dit afgelopen week zelf besproken.

Daarnaast hebben we nog een aantal behoorlijk zware taken die elk kwartier draaien van 6:00 tot 24:00, namelijk de prijslijsten van de winkels importeren voor de pricewatch. Dat is een vrij constante load.

Uit Kees in 'Dit is hoe we Tweakers hosten - 1320 cores, 5 TB ram en 364TB opslag'

[don_jorg]

Goede! De vraag blijft alleen of het het verwerken van door winkels geplaatste prijslijsten is, of dat het bij de winkels wordt opgehaald. Is een detail, ik weet het.

[moonlander]

de winkels leveren zelf de lijsten aan, dit scrapen ze dus niet.

[don_jorg]

Ik zie nu de reactie van Kees hieronder, vandaar m'n edit: Tweakers haalt ze dus ook bij de webwinkels op.

[moonlander]

De winkels leveren zelf een xml lijst oid aan tweakers, die tweakers vervolgens moet downloaden en kan importeren/updaten.

[weasel]

Is het naast je werk ook je hobby, heb je bijvoorbeeld thuis ook hardware draaien?

[Kees]

Het was eerst mijn hobby en toen is het mijn werk geworden. In '99 woonde ik in een studentenhuis en hadden we een server nodig. Dat was in de tijd dat je kabelinternet maar op 1 computer mocht aansluiten van @home. Maar wij waren met 4 man, en hadden 4 computers en wilden allemaal counterstrike spelen. Dus eerst had ik een windows 98 computer gebruikt om het internet te verdelen, maar al snel heb ik die vervangen door een linux server met iptables erop om het verkeer te verdelen. Vervolgens had ik er een webserver op gezet en ging ik websites bouwen (wat nooit verder kwam dan de design fase). Wel leerde ik daardoor webservers en databases en dat vond ik best leuk om te doen en mee te knutselen.

Toen in 2001 de toenmalige serverbeheerder van Tweakers stopte vroeg hij mij of ik het wilde over nemen als studentenbaan.

Het is nog steeds mijn hobby, maar ik heb thuis niet een server rack staan met servers erin. Wel heb ik recent een minisforum MS-01 gekocht die ik als router/nas/speeltuin gebruik (waardoor het modem van KPN ergens stof ligt te verzamelen in een kast).

[Llopigat]

Goede vraag, bij mij is dat zeker zo, ik heb een heel thuislab.

Tegenwoordig is het zelfs helaas een vereiste geworden. Ze zijn erg overboord gegaan met beveiliging op het werk waardoor we bijvoorbeeld geen ISO's meer op USB sticks kunnen 'branden' (die we nodig hebben voor testservers het lab op het werk). Of bepaalde sites bezoeken die we nodig hebben met informatie voor ons werk.

Als ik dan aangeef dat er een manier moet zijn om dat toch te doen dan halen ze hun schouders op van '80/20 regel, dit is de 20% daar geven we niet om, zoek het maar uit, waarom doe je het niet thuis?'. Nieuwe servers kopen waar bijvoorbeeld iets als iLO op zit willen ze natuurlijk ook niet. Beetje idioot want soms heb je gewoon zulke dingen nodig om je werk te kunnen doen. En ik vind dat mijn werkgever daarin moet voorzien. Mijn thuislab is bijvoorbeeld ook helemaal niet ingericht op de standaarden van het werk, want ik gebruik dat voor mijn eigen ontwikkeling en die is veel breder dan de zeer beperkte ("alles microsoft") visie van mijn werkgever. Terwijl ik prive juist enorm veel insteek op alles in eigen beheer draaien en FOSS.

[Reactie gewijzigd door Llopigat op 3 januari 2025 10:17]

[simple.]

in het oorspronkelijke artikel heb ik deze vragen gesteld maar zie nu een Q&A, dus ik stel ze opnieuw, mocht het andere topic niet meer beantwoord worden:

1. hoe is jullie ransomware bescherming geregeld? natuurlijk zien we firewalls en zullen er meerdere lagen aan security zijn, maar over de back-up is niet veel gezegd, is het een 3-2-1-0 back-up waarbij 0 air-gapped is? ik las wel iets over dat je met S3 bezig bent? waarom dan geen tape of immutable NAS/linux repo?

2. zou je bij een refresh van de firewalls meteen weer Fortinets kiezen of heb je al iets anders op het oog? ik zie zeer regelmatig kritieke exploits voorbij komen bij de Fortinets

3. beheer je alles zelf? hoe ben jij "redundant" gemaakt? ik kom zelf als systeembeheerder vaak als kritiek 'single point of failure' uit de audits. hoe is de taakverdeling, zijn er collega's bij Tweakers die je versterken of vervangen wanneer je bijv. op vakantie gaat? (systeem architect, systeembeheerder, netwerkbeheer, security beheer) en/of leggen jullie (gedeelde)verantwoordelijkheid bij externe partijen?

4. waarom zijn er zoveel dedicated servers? wij hadden dat zelf ook maar zijn over gegaan naar volledig gevirtualiseerd op 2 redundante hypervisors

5. waarmee houd jij je kennis op pijl?

[Kees]

1a. We draaien een falcon sensor op alle servers en vm's en veel uitgaand verkeer van de servers gaat via Zscaler naar buiten. En we proberen steeds meer 'dark' te gaan.

1b. Qua backups slaan we eerst lokaal een serie op, en die syncen we offsite (naar ons kantoor). Daar wil ik nog een derde stap aan toevoegen met immutable backups.

immutable NAS/linux repo?

Dat klinkt interesant, heb je daar voorbeelden van?

2. Niet perse, onze firewall is behoorlijk simpel en alle hardware appliances zijn 'next-gen' tegenwoordig terwijl wij gewoon een simpele packetfilter zoeken die verkeer van buiten tegenhoud. Bij een refresh zullen we daar ook goed naar kijken. De exploits die ik langs zie komen zitten meestal aan de 'achterkant' in het management deel of in de vpn oplossing van Fortinet dus daar maak ik mij niet al teveel zorgen over.

3. Ik beheer veel zelf inderdaad. Voor het netwerk hebben we nog wel een derde partij die daar meehelpt, maar de servers doe ik grotendeels zelf met hulp van 2-3 collega's die ook kunnen ingrijpen.

4. Een aantal zaken zijn zo groot of vreten zoveel resources dat we ze vroeger altijd op hun eigen servers hadden. Dat kan wellicht tegenwoordig wat minder, maar ik blijf dan nog wel altijd een aantal servers over houden, met 2 kom ik er niet.

5. Door veel zelf te doen en nieuwe zaken uit te proberen maar niet altijd meteen met de laatste hype mee te gaan.

[simple.]

bedankt voor je antwoorden!


zelf sta ik ook voor de keuze om een air-gapped/immutable back-up aan te schaffen.
prijs zal een bepalende factor zijn vermoed ik, net als restore snelheid:
ik denk dat mijn huidige opties zijn(wij gebruiken Veeam voor de 3-2-1 back-up omgeving):
1. https://www.veeam.com/blo...-hardened-repository.html (lijkt goed ondersteund met Veeam)
2. tape lto-10 (echt air-gapped en relatief goedkoop)
3. https://kb.synology.com/n..._is_an_immutable_snapshot (ondersteuning vanuit Veeam lijkt minder)
4. cloud back-up (vaak erg prijzig en restoretijd zal beperkt worden door de 1gbit lijn)

ik ben erg benieuwd welke afweging jij hierin zou maken en welke zaken je meeweegt.

ps. leuk om te lezen dat je erg pragmatisch naar oplossingen zoekt
(niet klakkeloos met de cloud hype mee, KISS security, zero trust ook al kan dat wrijving met collega's geven)

[DeBazaar]

Vraagje voor Mr. DevOps! Tegenwoordig beseft men steeds meer dat security vroeg in de ontwikkelcyclus al een belangrijk onderdeel is, wil je dat verderop in de keten (productie) de boel veilig blijft draaien. 'DevSecOps' en 'shift left' dus. Hoe kijk jij naar software supply chain security?

Subvragen: Hoe vertrouw je software die anderen voor je geschreven hebben, hoe garandeer je kwaliteit, en hoe controleer je of die code ook daadwerkelijk op je systeem draait? Lig je weleens wakker van de bekende 'Reflections on Trusting Trust' attack, of backdoors in veelgebruikte software zoals XZ Utils (liblzma)?

[Kees]

We gebruiken Snyk om op vulnerabilities in onze code en dependancies te scannen, daarnaast gebruiken we RenovateBot om alle dependencies up-to-date te houden, want updaten blijft nog altijd de beste verdediging.

Verder gebruiken we statische analyse tools zoals Psalm om de code te scannen zodat ongewenste flows in de code minder voorkomen. En als de code live komt, dan kan iedereen bij Intigriti lekken melden

Als we code van anderen gebruiken dan zal dat in het algemeen open-source code zijn, maar soms schrijft een extern iemand wel eens iets voor ons. Als iemand iets voor ons schrijft dan moet het aan onze standaarden voldoen, en zelfs dan nog huren we vaak een simpele vps om het ergens buiten ons netwerk te hosten. Maar wij schrijven vrijwel alles zelf (met uizondering van externe libraries)

We hebben in het verleden ook wel eens gehad dat iemand ons vroeg om een een wordpress plugin te instaleren (op een side-project). En nadat we de code ervan bekeken hadden, die vol zat met sql-injectes en xss, hebben we daar vriendelijk voor bedankt.

En ja, ik denk wel eens na over fouten in gebruikte libraries zoals de xz-backdoor. Maar ik kan daar weinig aan veranderen en door gewoon alles up-to-date te houden hoop ik dat het meevalt (en soms zit het tegen en zijn alleen recent uitgebrachte versies vatbaar...).

Maar wij zijn zeker een target, bijvoorbeeld toen 'log4j' losbarste kregen wij binnen een uur de eerste scans al binnen op onze servers en dat liep al snel op naar miljoenen pogingen per dag. Gelukkig houd ik dat soort nieuws ook wel in de gaten, en had ik dezelfde dag al een scan gedaan op de servers en blockte ik scans in de firewall. Maar de weken erna heb ik heel wat spreadsheets in moeten vullen

[GeroldM]

Hoe vertrouw je software die anderen voor je geschreven hebben

Onafhankelijke audits van de aangeleverde code die de software-makende partij heeft gestald bij een neutrale partij (vaak een notaris) die de software leverancier en opdrachtgever zijn overeengekomen. Daar is zelfs een specifieke term voor, maar die is me even ontschoten en de ChatGPT/Phind/Gemma2/Tabby LLMs waar ik toegang tot heb, geven me steeds antwoorden die het gehele proces omschrijven.

hoe garandeer je kwaliteit

Er zijn genoeg bedrijven welke alleen maar software audits doen. Deze huren personeel in met bewezen staat van dienst op het gebeid van programmeren. De software die wij leveren wordt jaarlijks op deze manier geaudit.

De programmeur-auditers kunnen contact opnemen met de programmeur van de code, mocht er enige uitleg worden vereist. Nu valt dat bij ons best wel mee, wij documenteren goed in de code zelf. Ook hebben de auditers inzage in de software issue-tracker, voor de periode dat deze bezig zijn met de audit. Dat geeft ook al een heel goed beeld over de kwaliteit van code, de snelheid waarmee een oplossing (of workaround) is geimplementeerd en vooral waarom er voor die specifieke oplossing (of workaround) is gekozen.

Zo zijn er al een paar keer auditers geweest, welke contact opnamen met de opmerking erbij dat ze blij waren weer eens C++ code te zien, i.p.v. de gebruikeleijke talen van tegenwoordig. En ons ook belonenen met opmerkingen over de goede tot zeer goede kwaliteit van die C++ codebase. Want ja, ook in C++ is het echt mogelijk degelijke software te schrijven die bij lange na niet zo onveilig hoeft te zijn als dat een heleboel programmeertalen je willen laten geloven.

Helaas is het armoe troef met de software waarmee je nog goede, degelijke C++ software kan schrijven. Embarcadero is zo'n stuk software, maar is erg duur. Daarnaast loopt het vaak toch achter feiten aan, zeker als je moet troubleshooten in een productie omgeving waar je je lokale IDE alleen via tijdelijke remote toegang aan de draaiende software mag koppelen vanwege zeer strikte restricties in zo'n omgeving. Want ja, er zijn helaas meer dan genoeg bedrijven, waarbij hun acceptatie-omgeving amper correleert met hun productie-omgeving. Vooral cloud-draaiende bedrijven zijn gauw geneigd om de acceptatie-omgeving niet al te ruim opzetten vanwege de hoge maandelijkse kosten de productie-omgeving, alsmede de acceptatie-omgeving.

Embarcadero is duidelijk aan stagnatie onderhevig en wordt het daarom alsmaar moeilijker om hun almaar hoger wordende licentiekosten nog te verantwoorden. C# heeft daar veel minder last van, dus zijn we begonnen met het stukje bij beetje omzetten van C++ naar C#.

Hoe controleer je of die code ook daadwerkelijk op je systeem draait?

Met Git is het redelijk makkelijk om te 'diff'en tussen de software die daadwerkelijk draait op het systeem en code die bij die 3e partij is gestald. Van een stuk vertrouwen in de gekozen leveranciers is ook sprake. Zeker als alles met vlag en wimpel door eerdere audits heen is gerold, en er geen vreemde zaken zijn voorgekomen bij de huidige audit en hoe deze tot stand is gekomen, dan kun je wel over een stukje vertrouwen spreken. Is het niet in de leverancier(s), danwel in de procedure die tussen alle partijen is overeengekomen.

'Diff'en is wel een stuk gemakkelijker met script-talen, zoals Python, javascript, Tyepscript, enz. Draai je nog steeds met executables, dan zijn er mogelijkheden om de die executables van de goedgekeurde code-base te bouwen, dan van elke executable een SHA-256 hashcode te generereren en dan van dezelfde executables in test-/acceptatie-omgeving ook een SHA-256 hashcode te genereren. Komen de hashcodes overeen, dan is het een vrij veilige aanname dat de software die draait bij de klant, dezelfde software is die de auditers voor ogen hebben gekregen.

Lig je weleens wakker van backdoors in veelgebruikte software zoals XZ Utils (liblzma)?

Dit blijft ten alle tijden een afweging. Het haakt ook in op de 'waarom'-redenen achter keuzes die zijn gemaakt. En met een software-leverancier die tijdig kan en wil reageren, is de kans groot dat je als software-koper niet heel lang (heel veel) risico loopt.

Hangt ook af hoe serieus de test-/acceptatie-/productie-omgevingen zijn opgezet, welke maatregelen van veiligheid zijn toegepast in die omgevingen, de mate van ernst van de backdoor, enz. Daar is echter elk stuk software gevoelig voor. En Linux is niet veiliger dan Mac of Windows hierin, alle besturingsystemen zijn door mensenhanden geschreven, dus kan je er donder op zeggen dat er altijd iemand is die slim/"gelukkig" genoeg is om een backdoor te ontdekken in welke combinatie van software en besturingssysteem dan ook.

LLM's zijn getraind op code die door mensen is geschreven. Is op zich niet zo'n slechte zaak, maar code die een LLM produceert is daardoor ook niet compleet veilig en/of zonder backdoors. Misschien dat het wat veiliger zou kunnen zijn dan code die door een persoon in elkaar is geknutseld, maar de kans daarop is dus niet geheel naar nul te krijgen.

[digitalnova]

Onafhankelijke audits van de aangeleverde code die de software-makende partij heeft gestald bij een neutrale partij (vaak een notaris) die de software leverancier en opdrachtgever zijn overeengekomen. Daar is zelfs een specifieke term voor, maar die is me even ontschoten en de ChatGPT/Phind/Gemma2/Tabby LLMs waar ik toegang tot heb, geven me steeds antwoorden die het gehele proces omschrijven.

Is de term die je zocht escrow?

[Inspector]

Still going strong Kees! Geweldig om te zien hoe het serverpark en het beheer ervan evolueert door de jaren heen. Heel tof dat Tweakers niet meegaat in "alles naar de cloud" maar "ouderwets" zelf zijn hardware in beheer houd

[Kees]

Het schijnt zelfs weer hip te zijn tegenwoordig om het weer zelf te doen, dus de circel is weer rond

En we proberen wel mee te gaan met moderne technieken als we er een usecase voor zien en het nuttig is, maar we waaien niet met alle winden mee (anders waren we nu druk bezig om alles in de laatste hypetaal om te schrijven )