Home   2026-10-22 19:56:51

←

Mijn.host: storing van deze week kwam door beveiligingsincident

Original article

De storing bij mijn.host van de afgelopen week draaide niet alleen om een hardwarestoring, maar om een beveiligingsincident. Het is nog steeds niet duidelijk wat er precies gebeurd is, maar volgens mijn.host gaven onbevoegden opdracht om data te wissen.

Dat schrijft de provider in een reactie op het Tweakers-forum. Mijn.host had eerder deze week last van een storing toen bleek dat een cluster met dataopslag was uitgevallen. Daardoor kon een deel van de klanten niet bij gedeelde hostingdiensten of virtuele servers.

Aanvankelijk verklaarde het bedrijf alleen dat de clusters waren uitgevallen, maar nu zegt het dat dit kwam door 'een beveiligingsincident'. "Toen de storing ontstond, zagen we in eerste instantie dat de opslag was uitgevallen, en dat hebben we op onze statuspagina gemeld. Onze eerste prioriteit was om alle diensten zo snel mogelijk te herstellen, wat veel tijd kostte. Tegelijkertijd hebben we onderzocht hoe de uitval kon ontstaan", schrijft mijn.host via zijn bedrijfsaccount.

Het bedrijf zegt verder: "Na intensief onderzoek bleek dat via de beheerinterface (iDRAC, of Integrated Dell Remote Access Controller, red.) van de serverhardware een wisopdracht was gegeven voor de opslag van deze servers, zonder onze toestemming. Daardoor viel de opslag uit en ontstond de storing. Vervolgens hebben we de logbestanden grondig nagelopen om zeker te weten wat er wel en niet is gebeurd, zodat we iedereen volledig en juist konden informeren. We hebben tevens besloten juridische maatregelen te treffen tegen de verantwoordelijke."

Veel meer details over dat incident geeft mijn.host niet. Wel zegt het bedrijf dat er in ieder geval geen aanwijzingen zijn dat er gegevens zijn gestolen. In de meeste gevallen zijn de servers hersteld vanuit een back-up die diezelfde nacht nog was gemaakt.

Cloud/servers. Bron: Jason Marz/Moment/Getty Images
Beeld ter illustratie. Bron: Jason Marz/Moment/Getty Images

Door Tijs Hofmans

Nieuwscoördinator

Feedback • 16-10-2026 19:02
44 • submitter: EDIT

16-10-2026 • 19:02

44

Submitter: EDIT

Reacties (44)

Is dit weer een nieuwe term die de wereld ingebracht moet worden i.p.v gehackt; "veiligheidsincident" Na de Odido hack durft niemand het meer hack te noemen?
Gezien de bewoording lijkt dit geen hack maar een medewerker met slechte bedoelingen. “We hebben tevens besloten juridische maatregelen te treffen tegen de verantwoordelijke.” Klinkt alsof ze weten wie het is.
Of extreme incompetentie*, of kwade bedoelingen.


*Ja je mag verwachten dat juniors tegen zichzelf beschermd worden, dit gaat bij de meeste bedrijven wel vaak op het "erewoord". Maar ook in de IT is er een verschil tussen medewerkers die fouten maken, naar eer en geweten**, en iemand die domweg roekeloos is en beter zou moeten weten.


**Ik herinner me nog als de dag van gisteren, de junior die zenuwachtig kwam vragen: "als ik commit heb gedaan na mijn SQL delete-opdracht op de produktie-database, hoe draai ik dat dan terug?"

[Reactie gewijzigd door Keypunchie op 16 oktober 2026 19:36]

Ghehe, dit is exact waarom ik geen geautomatiseerde deploys doe.

Ik krijg daar veel kritiek op omdat zogenaamd automatisch altijd beter is, maar ik voel me ergens wel veiliger dat er een héél bewust controle en deploymoment is ipv alles automatisch...
Als je het met de hand doet kun je juist fouten maken, elke keer weer. Als je het automatiseert kun je het eerst op een test en/of acceptatie omgeving uitvoeren en daarna op productie. Als de automatische vorm op test/acceptatie werkt kun je er vanuit gaan dat het ook goed gaat op productie (nog meer als je begint vanaf een productie kopie). Als je elke keer met de hand allemaal losse commando's aan het uitvoeren bent (intypen of knippen/plakken) is juist de kans groot dat je ooit een keer een fout maakt op productie (typo, commando vergeten/overslaan, ...).
Ik deploy niet handmatig, ik trigger de deploy handmatig. Naar productie vereist overigens een hardwarekey dus dat kan ook niet per ongeluk.
Er is verschil tussen handmatig en handmatig.

Ook in een automatisering is het fijn om een of meerdere "gates" te hebben, waar jijzelf of een collega kan controleren.

Zelf werk ik nu in een GitOps workflow waar op meerdere punten (accepteren van de wijziging naar de produktie-branch, uploaden naar deployment orchestrator en dan daadwerkelijk uitrollen) een handmatige aktie is vereist. Dat is 3x een druk op de knop als het wel snor zit, maar ook 3x een kans om nog even goed te kijken of je geen foute aanname hebt gemaakt.

(En ja, soms vangt 1 van die gates zelfstandig ook een misconfiguratie af, of een menselijke fout).

Ik zou niet van die gates afwillen, ook al is het soms wat omslachtig.

[Reactie gewijzigd door Keypunchie op 16 oktober 2026 20:48]

Als ik hier tussen de regels door lees gaat het om een actie van iemand met toegang.
Da's geen hack...

[Reactie gewijzigd door Polderviking op 16 oktober 2026 19:39]

Er staat alleen vermeld dat er een beheer opdracht via iDRAC is gegeven. Dat kan zijn door iemand die al beheerrechten had, maar ook door iemand die deze niet had horen te hebben maar toch heeft verkregen. Ik geef je gelijk dat er tussen de regels door te lezen is dat het mogelijk om iemand met toegang gaat (zoals bijvoorbeeld een beheerder), maar het is zo vaag dat het dus net zo goed ook tal van andere oorzaken kan hebben.
Dat verkrijgen kan ook zijn dat iemand de inlog van een collega heeft gebruikt welke uit goed vertrouwen bv onderling bekend was.
Discussie was dat iemand stelde dat het vermoedelijk geen hack zou zijn. Ik wijs er alleen op dat er heel veel mogelijkheden zijn en een hack niet valt uit te sluiten. Het kunnen noemen hoe het allemaal geen hack zou kunnen zijn is nmm niet zo relevant. Het lijkt me veel relevanter dat het bedrijf zsm duidelijkheid geeft hoe ddit gebeurde, maar vooral waarom ze dit niet voorkomen hebben. Want of het nu een hack te noemen is of een beveiligingsincident, het bedrijf had die gegevens moeten beschermen tegen verlies en onbeschikbaarheid. Dat is ze duidelijk niet gelukt.
Ze hebben geleerd van de communicatieafdeling van AH. Een geluk bij een ongeluk / bij ongelukken.
Los van hoe je het duidt is mijn.host tot nu toe telkens transparant en informeren ze netjes en met nuance. Beetje flauw om dan over de gebruikte term te vallen terwijl er heel wat bedrijven zijn die bij dit soort zaken het aanzienlijk minder goed doen.
Welkom op Tweakers. Ik ben het volledig met je eens hoor, maar zodra je bij Tweakers de eerste reactie voorbij bent zijn het voornamelijk alleen nog maar reacties om te laten zien wie de grootste heeft. Verspilde moeite overigens want ik die heb ik.
Ik ben wel blij dat ze afstappen van het woord "hack" en voor veiligheidsincident etc. gaan. Als ik zeg dat ik wel eens hack, word ik als crimineel aangekeken. Ga jij maar eens in het Engelse taalgebied zeggen dat je tweaker bent }> , dan word je ook op een bepaalde manier aangekeken.

Dus prima dat ze het nu eindelijk anders gaan noemen. Hier hebben belangenorganisaties jaren voor gestreden!
ik denk dat daarom de juristen erbij gehaald worden. Inside job.
Denk zodra je überhaupt weet dat het een cyberincident betreft dat je een jurist laat aanhaken ivm de AP en de communicatie, los of het van binnen of buiten komt. Je wilt sowieso aangifte doen bij de politie ivm verzekering, ga ik van uit
Het bedrijf zegt verder: "Na intensief onderzoek bleek dat via de beheerinterface (iDRAC, of Integrated Dell Remote Access Controller, red.) van de serverhardware een wisopdracht was gegeven voor de opslag van deze servers, zonder onze toestemming.
Hoe kan het dat iemand van buitenaf instaat is om bij de IPMI interfaces te komen van je interne servers?
We hebben tevens besloten juridische maatregelen te treffen tegen de verantwoordelijke.
Heel cryptisch dit. Wraak van ontslagen medewerker? Onzorgvuldige medewerker gehacked? Maw: dus een insider?

Voor mijn gevoel wordt niet het hele verhaal hier eerlijk verteld over wat er écht is gebeurd en dat vind ik altijd een slecht teken.

[Reactie gewijzigd door Q op 16 oktober 2026 19:10]

Zo cryptisch vind ik het allemaal niet, iDRAC komt je idd niet zomaar bij van buiten, mag je rustig van uit gaan, en ze weten kennelijk kennelijk wie het is want anders zijn juridische stappen tegen de verantwoordelijke lastig.

Kan dus eigenlijk alleen maar van binnenuit komen, van iemand met gewoon toegang.

[Reactie gewijzigd door Polderviking op 16 oktober 2026 19:18]

iDRAC komt je idd niet zomaar bij van buiten, mag je rustig van uit gaan.
iDRAC is, net als alle andere netwerk services, niet spontaan ontoegankelijk van het internet. Net als het niet spontaan goede beveiliging heeft in een bedrijfsnetwerk.Voor beveiliging moet genoeg moeite worden gedaan en dat is helaas niet vanzelfsprekend. Fouten in configuraties, fouten bij bekabeling, slechte beveiligingskeuzes in netwerkscheiding, beveiliging tijdelijk uitschakelen, er zijn zoveel redenen dat je er maar beter niet rustig van uit kan gaan dat het op orde was.
ze weten kennelijk kennelijk wie het is want anders zijn juridische stappen tegen de verantwoordelijke lastig.
Aangifte doen is ook een juridische stap. Kan je al doen als je rechten geschonden zijn en geen benul hebt wie de dader is. Maar daarmee ben je wel een verdachte (bekend of onbekend) verantwoordelijk aan het houden.

Daarbij is het stellen dat je juridische stappen neemt ook een vorm van duidelijk maken dat je (ook) iemand anders verantwoordelijk wil houden. Dat is een recht, maar het neemt niet weg dat het bedrijf dit wettelijk zelf had moeten voorkomen. Daarom is het zo belangrijk dat er behoorlijke transparantie is over de omstandigheden die gaan over wat het bedrijf nagelaten heeft maar dit had kunnen voorkomen.
iDRAC is, net als alle andere netwerk services, niet spontaan ontoegankelijk van het internet. Net als het niet spontaan goede beveiliging heeft in een bedrijfsnetwerk.Voor beveiliging moet genoeg moeite worden gedaan en dat is helaas niet vanzelfsprekend. Fouten in configuraties, fouten bij bekabeling, slechte beveiligingskeuzes in netwerkscheiding, beveiliging tijdelijk uitschakelen, er zijn zoveel redenen dat je er maar beter niet rustig van uit kan gaan dat het op orde was.
We gaan een beetje muggenziften nu maar ik zei niet dat hun security op orde was, alleen dat ik het onwaarschijnlijk acht dat hun iDRAC interfaces zomaar van buitenaf te benaderen zou zijn.
Poorten van internet doorknopen naar je iDrac interface moet je doorgaans echt wel bewust doen. Dat is niet even een oeps met een kabel.
En iedereen die langer dan 5 minuten in de ICT heeft gezeten weet dat dat een boutplan is.
Aangifte doen is ook een juridische stap. Kan je al doen als je rechten geschonden zijn en geen benul hebt wie de dader is. Maar daarmee ben je wel een verdachte (bekend of onbekend) verantwoordelijk aan het houden.
Ik kan niet tegenspreken dat dit kan maar dan vind ik de gekozen bewoording bijzonder. Doorgaans heb je als je het niet weet gewoon over aangifte doen.
Als mijn fiets gejat wordt doe ik ook aangifte, en dat noem ik dan geen juridische stappen tegen de verantwoordelijke.
Daarom is het zo belangrijk dat er behoorlijke transparantie is over de omstandigheden die gaan over wat het bedrijf nagelaten heeft maar dit had kunnen voorkomen.
Helaas scheelt het wel vaker aan transparantie waar iedereen wat van zou kunnen leren, bij incidenten waar data de ether in gaat.

[Reactie gewijzigd door Polderviking op 16 oktober 2026 20:06]

Wat mij betreft geef je een prima verduidelijk van wat je bedoelde. Mijn reactie gaat er niet om dat je zou stellen dat de beveiliging maar op orde zou zijn. Het lijkt me alleen veel verstandiger om er niet zomaar vanuit te gaan dat het maar bewust of lastig is voordat een iDRAC service bereikbaar is. Uit hoe het bedrijf het brengt valt niet op te maken dat ze behoorlijke processen en configuraties hadden om netwerken te scheiden. Het feit dat mensen in het algemeen moeite moeten doen om een netwerk te configureren zegt niets over de beveiliging of voorkomen van fouten. Eerder dat moeite doen niet zomaar voor belemmeren van toegang zorgt en we daar nmm maar beter van uit kunnen gaan tot het tegendeel is bewezen.

Ik ben het er mee eens dat het bijzonder te noemen is en het niet duidelijk over aangifte doen gaat. Ja dan kan het dus ook gaan om juridische maatregelen willen treffen omdat een medewerker of leveranciers overeenkomsten zouden hebben geschonden. Mij valt op dat het niet gaat om daadwerkelijk juridische maatregelen nemen maar om het noemen dat ze een besluit genomen hebben. En aangezien lang niet ieder bedrijf aangifte doet zie ik er in dat het dus net zo goed om aangifte doen kan gaan. Persoonlijk hoop ik vooral dat de toezichthouder hier juridisch eens goed naar gaat kijken. Want dat een bedrijf besluit juridische maatregelen te willen nemen is niet zomaar in het belang van de klanten en andere slachtoffers.
Poorten van internet doorknopen naar je iDrac interface moet je doorgaans echt wel bewust doen. Dat is niet even een oeps met een kabel.
En iedereen die langer dan 5 minuten in de ICT heeft gezeten weet dat dat een boutplan is
Een ssh verbinding hoort ook niet zomaar op het internet te zitten. En toch zijn er miljoenen.

[Reactie gewijzigd door nullbyte op 16 oktober 2026 21:42]

Er is niet gezegd dat dit van buitenaf kwam.
Moet wel inside job zijn dit. Iemand van binnenuit. Ze ondernemen ook juridische stappen "tegen de veranwoordelijke". Ze weten dus ook wie het is, klaarblijkelijk.
Je hebt drivers en tools om op Windows IPMI commando's te geven, je hoeft geen toegang te hebben tot the speciale IPMI interface..
Handig voor beheer dat je er zonder vpn bij kunt....

Niet dus, dit soort zaken hoort toch echt in een apart vlan achter een firewall te zitten en zeker niet direct toegankelijk te zijn
"Handig voor beheer dat je er zonder vpn bij kunt...."

Bijzonder uitspraak.

Als je bedrijf wordt gehacked zit je toch als insider altijd achter de VPN? Anders ben je namelijk niet gehacked 👀
Misschien ligt het aan jouw gevoel.
Dit zijn niet-retorische vragen in een mogelijke richting, dus geen aannames. Juist van uit de hoek van Justitie zou ik zulke vragen verwachten, maar dat lijkt niet aan de orde.

Dat deze vragen opkomen snap ik. Aangezien er juridische stappen ondernomen gaan worden snap ik ook dat niet alle details naar buiten wordt gebracht. Mijn.host gaat de gedaagde(n) en diens advocaat(/mv) natuurlijk niet op voorhand wijzer maken dan ze al zijn.

Persoonlijk (en ik ben op geen enkele manier betrokken bij het bedrijf) vind ik hun openbare reactie erg netjes en dat ze klanten willen helpen bij eventuele AVG-problemen extra netjes.
Hij stelt gewoon vragen. Hij beweert niets. Geen paniek.
Welnee dat zijn geen vragen, dat zijn aannames
Volgens mij veronderstel je hier zelf de bedoeling van de vraag die gezien die uit meerdere opties bestaat en vraagtekens bevat daardoor dus niet een aanname is.
Hij stelt vragen met de bedoeling iets te insinueren.
Volwassen reactie hoor.
Toetsenbordridder.
Als iemand inside toegang geeft en je kan op een drac of ilo kaart inloggen dan ben je wel f...ked.

Maar wat onduidelijk is als je inlogt op een ilo of drac en de array wist van een server (dus mensen die niet weten wat dat is, je mikt de partities weg) dan staat dit in een log, dat klopt. Maar je kan die log gewoon wissen. Enige wat je ziet is een entry dat de log is gewist maar niet wie er heeft ingelogd.

Als ze extern die drac kaart loggen (wat kan) dan zou de insider wel heel onhandig zijn geweest om ook die entrys niet te wissen. Ik vind daarom ook dat er aardig wat duidelijke info ontbreekt om wat meer inzicht te geven in deze zodat het nieuws artikel wat beter gewicht geeft in deze tweakers.
Mogelijk iets met een recente CVE van Dell storage apparatuur met een behoorlijke hoge score...
Helaas ben ik hier ook een slachtoffer van, mijn mailbox was verdwenen en tot op heden is er weinig hersteld, ondanks een ticket? Mijn conclusie moet mijn homelab op de achtergrond mee laten lopen, zo dat ik geen data weer verlies? erg knullig dit, vooral dat ik tot op heden nog geen oplossing heb gekregen laat staan een sorry mailtje.
Ik was ook 1 van de gedupeerden. Gisteren een e-mail ontvangen van mijn.host met dezelfde inhoud als wat op het mijn.host ervaringen topic op het forum is gepost door het bedrijf. Ondertussen is alles netjes afgehandeld en heb ik zelf oplossingen gevonden die me in de toekomst beter beschermen. Als je slachtoffer bent, wordt er dus contact met je opgenomen als het goed ia.

Om te kunnen reageren moet je ingelogd zijn