Gelukkig was de patch in februari 2021 beschikbaar, dus inmiddels twee jaar geleden al uitgebracht. Zeer ruim de tijd gehad om de patches door te voeren. Er zou in principe geen enkel excuus mogen zijn als dit nog niet is gedaan in een organisatie.

Ik heb die patch wel geinstalleerd maar het patchen van ESXi is meestal nogal een gedoe dus niet iets wat bedrijven
maandelijks doen... zeker als je het maar kleinschalig gebruikt en dus niet een hele farm hebt waar je je VMs over heen
en weer kunt verplaatsen.

Ik snap dat het lastig is om zaken te patchen ( lees, kost tijd en geld ) maar na 2 jaar is dit echt geen excuus meer. Natuurlijk hangt het er helemaal van af wat je exact op de ESXi hebt draaien maar als dit bedrijfskritische systemen zijn dan moet je dit onder controle hebben.

Het uitfaseren of upgraden van een Linux distributie is vaak ook lastig....

Het verschil tussen een server en een ESXi host is dat je die laatste alleen kunt patchen door eerst alle VMs te shutdownen,
en de host in maintenance mode te brengen. Dat is niet "kost tijd en geld" maar het is een grote service onderbreking
die je meestal niet in productie uren wilt doen, en het op afstand doen is een zeker risico dat de boel niet meer op komt
en je er fysiek bij moet zijn om het te fixen. Kortom je moet een bezoek in de nacht of in het weekend inplannen, wat een
hoop gedoe is. En ALS het misgaat zit je diep in de problemen. Dat het allemaal zo achterlijk lang duurt helpt ook niet mee.
Het zou al beter gaan als VMware het patchen op een wat handiger manier zou regelen, bijv dat je (supported) je patches
kunt downloaden en aanbrengen op een draaiende machine, zodanig dat ze actief worden bij de volgende reboot.

Het aantal jaren is geen bepalende factor, waar het om gaat is de ernst van de patch die er is en of je het er voor over
hebt om die toestanden overhoop te trekken. Ik kan me best voorstellen dat veel kleinschalige installaties, zelfs als ze
hun VM's zelf wel uptodate houden, het patchen van het ESXi platform laten verwateren.

Dit kan gewoon. Ook op een "ghetto ESXi" host met een gratis licentie. Zie bijvoorbeeld https://esxi-patches.v-front.de

Ik weet dat je het "gewoon kunt doen" en ik HEB dat ook wel eens gedaan zonder problemen, maar het is niet "supported".
Dwz als je de aanwijzingen op de VMware site volgt dan moet je EERST de host in Maintenance mode brengen VOOR je
de patches aanbrengt (waar je ze ook vandaan hebt), en DAT betekent weer EERST alle VM's shutdownen.
Niet fijn als je bijvoorbeeld je router hebt draaien als een VM! En je beheer van ESXi loopt via een VPN op die router.
Dan kun je het niet op afstand doen. En het beheer netwerk direct op internet zetten, dat is nou niet zo handig. Dat blijkt keer op keer door dit soort issues.

Ik doe dit toch echt zonder. Al is het wel beter om alle VM's te shutdownen en de host in MA mode zetten.

Maar dan nog, dan weet je dit ook, vanuit de eigenschappen van dit licentie type.

Je hebt dus eigenlijk infrastructuur draaien die niet bij je business requirements passen?
ILO/ DRAC, dit is in 2023 echt geen excuus meer. Dit behoord gewoon standaard aanwezig te zijn op je servers.
Nee hoor, zoals vermeld ILO / DRAC. We patchen hier gewoon ESXi servers die aan de andere kant van de wereld staan. Rebuilden kunnen we via dat soort remote tooling ook gewoon doen.
Iets wat je eigenlijk dus nu ook al gewoon kunt doen?
Maar cool wat je adviseert. Dan vergeet je een keer te rebooten, en reboot je wegens andere omstandigheden, en dan komt mogelijk je ESXi machine niet in de lucht.
Klinkt als een erg professioneele oplossing..... Maar hij is er al, je kunt gewoon via de CLI patchen en later rebooten.

Vaak wordt ESXi gewoon ergens neer gezet inderdaad. Patchen komt later wel een keer...... Om inderdaad de eigenschappen die jij ook aangeeft.
Eigenschap kan wel zijn, je kunt de management interface van ESXi natuurlijk wel in een afgeschermd netwerk segment hangen. Dat scheelt veel problemen en gevaar.

Patchen van esxi doen wij in ieder geval elk kwartaal en in het geval van een kritische patch die een lek repareert doen we dit sneller. Daar zijn technieken als clusters en vMotion voor ontwikkeld.

Het is een advies wat al jaren geldt. Zorg voor een patchbeleid en patch je omgeving!

Nah zelf nos.nl intikken lukt ook nog nadat er een cobra in je hand is ontploft. Maar ik link er toch maar effies naar:

https://nos.nl/artikel/2462701-grootschalige-aanval-met-gijzelsoftware-op-duizenden-servers-wereldwijd

Ik kan wel trots zeggen dat mijn servertjes het nog altijd doen. Maar zeker niet om neerbuigend te doen, of hahaha te zeggen. Of ik wist al hoe stom de rest was want ik was slim. Het grootste security risico is namelijk denken dat je slim bent. Dus ik zit hier ook even een paar waxinelichtjes aan te steken dat het mij gelukkig niet gebeurd is. En hopelijk ook nooit zal gebeuren, want om eerlijk te zijn, ik klooi ook af en toe maar wat aan.

Momenteel denk ik dus dat cynisch zijn over wie er allemaal in de teil zitten niet zo relevant is. En lief al helemaal niet.

Zitten er nog guppies in het aquarium hier met een ideetje. Ik zie mezelf ook als zo een guppie, niet meer dan dat, beetje out of the box of aquarium guppie ook. Maar zwemt nog. En ik heb ook nog een vingertje, niet om te wijzen maar om in de dijk te steken. En er is bij mij ook wel eens wat ontploft. Maar ik heb al mijn vingers nog en mijn piano doet het ook nog. Duizenden servers gefukt. En die decryptie sleutels liggen ergens. Bij mensen die denken dat ze slim zijn. Hoe pikken we die sleutels terug. In mijn eentje zou ik het niet weten. Ik ben al blij dat die waxinelichtjes naast mijn xterm nog branden. Maar misschien is er wat samen te bedenken. Iets constructiefs. Dat je er dus ook wat aan hebt naast gelijk.

Dat is natuurlijk gewoon een k*t smoes om je werk niet te doen. Tijdens de setup fase van het platform worden keuzes gemaakt en een van die keuzes is: Hoeveel downtime krijgen we als we moeten patchen?
Als je geen downtime wilt moet er meer ijzer tegenaan en als de kosten belangrijk zijn en er dus geen failover gedaan kan worden krijg je automatisch downtime.

Er mag nooit een excuus zijn om geen patches te installeren.

Lees het nog een keer goed: ik heb die patch wel geinstalleerd, maar ik kan me VOORSTELLEN dat er heel veel
plekken zijn waar dit niet zo consequent gebeurt. Je manier van redeneren (en die van anderen hierboven) sluit ook
niet erg aan bij de praktijk van de kleinschalige installaties, dat kan ik je wel vertellen.

Ik ben jaren lang VMware beheerder geweest (VCP 3 t/m 6 certificeringen gehaald) en als iets makkelijk is in een Enterprise omgeving dan is het patchen van VMware. Dat gaat met een paar klikken volledig automatisch zonder onderbreking van de dienstverlening. Hoe makkelijk wil je het hebben.

Ik beheerde naast honderden servers bijv. ook 800+ virtuele werkplekken, via een thinclient maakte je daar verbinding mee. Vrij cruciaal dus voor de dagelijkse gang van zaken. Die 20 ESXi hosts werden in een middag voorzien van nieuwe patches zonder dat iemand daar last van had met een paar klikjes.

Zolang je een Enterprise omgeving draait, lees meerdere hosts met de juiste licenties, en je geen exoten hebt zoals VM's die maar op 1 host kunnen draaien, is updaten het makkelijkste wat er is.

Punt is wel even hoe je het verkoopt, de beheerders waar ik nu werk (doe zelf geen technisch beheer meer) houden vol dat het patchen van een handje vol hosts toch echt 2 weken tijd kost... Managers hier laten zich gewoon voor de gek houden.

Hypervisor en vcenter horen in een apart vlan te staan! Daarnaast kan je de VM's live wegmigreren van de server anders koop je geen VMWare maar gebruik je een Linux met KVM.
Daarom geloof ik het NCSC niet. Ze lullen maar wat voor de bühne.

Niet over jou persoonlijk maar ik kan me dus niet voorstellen dat iemand een jaar ;ang geen updates installeert, dan ben je gewoon niet geschikt voor dit werk.

KVM is erg matig als je het vergelijk met VMware, alle hypervisors zijn matig vergeleken met VMware. Je kunt wat tegen commerciële producten hebben maar feit blijft dat het gewoon een kwalitatief goed product is.

En geloof het NCSC maar niet als je dat niet wilt maar ze melden gewoon het nieuws van andere bronnen, niet meer en niet minder.

In een Enterprise omgeving ja. Maar in een kleinschalige omgeving niet.

Nee hoor je geeft geen een argument waarom kvm matig zou zijn. Ik werk met allebij. Doe mij maar kvm. Alles er op en er aan en nog gratis ook. Zie ook: www.ovirt.org Vooral op mijn desktop superieur. Ik draai een heel datacenter met geneste virtualisatie. Hypervisors zelf ook gevirtualiseerd werkend met live migratie van VM's

Je komt redelijk over, als iemand die niet begrijpt hoe sommige bedrijven bepaalde processen moeten volgen of hoe een bepaald bedrijf werkt.

Het kan inderdaad heel snel vanuit de techniek, maar dat wil niet zeggen dat je dat je dit ook overal zomaar zo snel kunt doen.

Leuk bij grote bedrijven, maar overduidelijk heb jij geen kaas gegeven van beheer.

Niet alle bedrijven hebben een apart Beheer VLAN, maar een VLAN zegt ook niet zoveel, je wilt een afgeschermd stukje netwerk hebben, wat alleen toegankelijk is voor beheer. Dat kan een apart VLAN zijn, maar eventueel ook gewoon een apart switch. Zonder verdere afscherming heb je daar bijvoorbeeld op een locatie ook niet zoveel aan.

Ik heb nog eigenlijk ook KVM in een enterprise tegen gekomen, tenzij het een specifieke omgeving is. Is er geen ESX dan is het HyperV of eventueel XenServer.

NCSC heeft blijkbaar wel meer kennis, dan jij hier laat zien. Je praat groot, maar je kennis en kunde is matig.

NCSC laat helemaal niets zien behalve waarschuwen voor iets wat niemand doet nl VMware aan het internet hangen. Ze hadden beter kunnen waarschuwen om vcenters en hypervisors niet in een vlan te stoppen die ook toegankelijk is vanaf het windows netwerk!
Wij gebruiken ook KVM (Openshift en RHEV enterprise) (met 0 incidenten) voor veel VM's. VMware gebruiken we voor diverse overheidsinstanties met ook weinig incidenten. Hyperv gebruiken we voor een gemeente met heel veel incidenten, vooral na het patchen. Dat is echt geen professioneel platform). Xen gebruiken we ook voor een oude applicatie (te maken met gecertificeerd platform zijn).
LifeCycle Management (OTAP) doen we met Redhat Satellite (goed geïntegreerd met KVM en VMware. HyperV wordt niet ondersteund) We moeten alleen nog vcenter naar Linux migreren.