Mijnhostingpartner is ruime week na malwareaanval nog steeds bezig met herstel

Hostingbedrijf Mijnhostingpartner is anderhalve week na een omvangrijke ddos- en ransomware-aanval nog steeds bezig om zijn servers te herstellen. Technische medewerkers van het bedrijf zijn de servers een voor een aan het herstellen.

De problemen voor Mijnhostingpartner begonnen anderhalve week geleden. De technici van het bedrijf dachten op zondagavond 6 januari dat het herstel de 'gehele nacht' zou duren, blijkt uit de lijst met updates die het bedrijf op Facebook bijhoudt. Een dag later moest het bedrijf toegeven dat het om een aanval ging van een omvang die het nog niet was tegengekomen en dat de reparaties langer zouden duren dan gedacht.

Mijnhostingpartner kreeg in de daaropvolgende dagen veel opmerkingen van getroffen klanten dat ze duidelijkheid wilden over de toedracht van de storingen. "Het antwoord hierop is dat we afgelopen zondag een ongelofelijk zware aanval te verduren hebben gehad, waarbij kwaadwillenden de kans hebben gezien om in te breken op de kern van ons netwerk en onze servers", zo laat het bedrijf op Facebook weten aan klanten die vragen wat er bekend is en hoe de problemen konden ontstaan.

De kwaadwillende slaagden er onder andere in om ransomware te injecteren bij mysql- en mssql-servers, waaronder de back-up-servers. Ook wisten ze Exchange-databases lam te leggen. Het duurde enkele dagen voordat de eerste servers weer operationeel waren, maar omdat het herstel zeer tijdrovend bleek, schakelde Mijnhostingpartner zaterdag twee externe bedrijven in die gespecialiseerd zijn het decrypten van ransomware. Met name de mssql 8-server bleek flink te zijn getroffen.

Woensdag zijn minstens vijf servers van het bedrijf nog geheel, dan wel deels onbereikbaar. De hoster adviseert gedupeerden om, in afwachting tot de servers weer online komen, lokale back-ups van databases terug te plaatsen, door te verwijzen naar bijvoorbeeld Facebook, een tijdelijk pagina te publiceren of een nieuwe site te bouwen en die te plaatsen.

Mijnhostingpartner kreeg flink wat kritiek van klanten, met name vanwege de gebrekkige communicatie. Zo is er op de eigen status-updatepagina niets te vinden. Het bedrijf verontschuldigt zich en zegt zoveel mogelijk vragen via tickets, mail en chats te beantwoorden, maar meldt daarbij ook dat het zich tegelijkertijd op het herstel van de systemen moet richten. Het is onbekend hoeveel klanten getroffen zijn door de problemen en wanneer deze definitief verholpen zijn.

Reacties (107)

[DennusB]

Oeps... die backups zijn niet helemaal in orde geweest vrees ik.

[MrFancyPantss]

In het artikel staat dat ook de backup servers getroffen bleken niet zo'n goede backup policy me dunkt

[bbob]

Als alles in hetzelfde bedrijf zit en je bent getroffen is natuurlijk de kans groot dat men tot alle systemen inclusief backup toegang heeft.

Klanten zouden eigenlijk zelf een backup van de backup dan lokaal moeten hebben.
Mijn website krijgt iedere dag ook backup van de proivder naar ftp. Backup van laatste 7 dagen.
Echter met synology nas trek ik dan iedere ochtend ook weer de backup van de provider en heb dan lokaal een backup. Mocht er een probleem met de provider zijn heb ik dus altijd een backup.
Als de backups geencrypt worden download ik die ook maar heb dan lokaal nog steeds backups van voor de encryptie.

Helaas vertrouwen de meeste bedrijven op een hostingprovider en als het misgaat zoals nu heeft men dus een probleem.

[xDiglett]

De 3-2-1 regel: Bewaar altijd drie back-ups van je data. Sla deze back-ups op twee verschillende media op, bijvoorbeeld op een tape of een disk of twee verschillende disk-systemen. En bewaar de back-ups altijd op minimaal één andere locatie dan waar je productie-data zich bevindt, zoals bij een cloud-aanbieder, een remote locatie of op tape.

[totaalgeenhard]

+Reken niet op je leverancier.

Maak een plan waarbij je buiten je provider.online kunt komen met.je website.

Als het niet offline mag gaan dual vendor policy.

[Tarij]

Het probleem is niet dat de backup encrypted wordt. Het probleem is dat je encrypted data aan het backuppen bent. Daar kom je pas achter als de sleutel weg wordt gekieperd. Al schuif je hem 50x door naar een andere locatie.

[bbob]

Klopt maar zoals ik zeg als je zeg iedere dag of week een backup makt van de backup van je provider dan het je nog steeds een backup van vlak voor de encryptie. De backups bij je provider zullen allemaal encrypted en dus waardeloos zijn.

[RGAT]

Als je een retentie hebt die hoog genoeg staat wel ja, bij websites zal dat voor de meesten mee vallen maar alsnog telt het flink op als je overal een backup van maanden moet bijhouden...

[SuperDre]

Is dus weer afhankelijk van hoe lang de ransomware al op de servers draaien, als die al weken draaien voordat het ontdekt wordt, dan ben je mogelijk alsnog weken aan data kwijt (wat voor doorsnee bedrijven natuurlijk rampzalig is). Bij SQL kun je dan als extra backup dus beter rechtstreeks de data uit de database zelf laten komen ipv een backup van de database datafile (met natuurlijk een controle er in die bepaalde tabellen controleert of de data niet versleuteld is.

[curkey]

En dan, zeg database content van 30 dagen oud. Voor een webshop de laatste maand aan data missen is net zo goed als geen shop hebben. Al je lopende zaken zijn dus pleite.

[bbob]

Tja als je hoster gehackt is en ook de backupdate encrypted is, dan heb je idd een probleem.
Maar misschien zegt dat dan ook iets over de beveiliging bij de hoster.

[HoeZoWie]

Backup en/of MS SQL waarschijnlijk niet in een 'eenrichting communicatie' DMZ geplaatst vermoed ik.
Weer een goede les voor ons, vrees ik.
Het drukt de neus weer eens op de feiten.

[MADG0BLIN]

Of je zit met het probleem dat ze al maanden binnen waren en de back-ups ook encrypted zijn. Dan heb je een nog groter probleem.

[DennusB]

Dan was je firewall niet op orde, dus hoe je t wend of keert, ze hebben flink lopen kl*ten daar...

[totaalgeenhard]

Firewall werkt niet tegen sql injecties.

[Dracozirion]

Dat werkt wel hoor. Bij ons op het werk draait een Fortigate die zulke zaken netjes afhandelt door herkenning van aanvallen via signatures. Daarnaast vermoed ik dat deze backup server ook gewoon in het domein heeft gestaan waarbij aanmelden met domein credentials mogelijk is.

[totaalgeenhard]

Ik ken fortigate producten niet.

Maar sql injections vinden plaats omdat meestal er geen input controle plaatsvind.

Een query die een record update met gelijkende gegevens houd je ook niet met een content filter tegen. Als je treshold van update per tijd weet kun je aanval finetunen dat je alle records update.

Alleen als je monitoring op temperatuur/resource gebruikt die notificatie af geeft indien het abnormaal is dan zul je daar achterkomen.

Maar dan heb je waarschijnlijk al een SIEM omgeving van vele tonnen.

[Anoniem: 1322]

Dit! Trek je dit soort comments ook niet aan want de meeste mensen praten gewoon de verkoper van de firewall na. Net of een off-the-shelf product (Forti, Cisco, Cisco, whatever) perfect weet welke queries normaal zijn en welke niet..

Ik maak het wel vaker mee, zelfs een klant die een patiëntenportaal vol gaten aan het internet wou hangen via een L7 "slimme" firewall... Ik loop dan maar gewoon snel weg...

[totaalgeenhard]

Het is toevallig mijn vakgebied en security sales engineers van grote partijen vroegen (toen ik me nog detacheerde) regelmatig aan project- en/of teamleiders of ik bij meeting aanwezig moest zijn.

Want er worden inderdaad veel bullshit verkocht en dat komt met name door schaapjes die in theorie wel weten hoe e.a. zit, maar niet de praktijk kennen.

Overigens ook in SOC (SIEM monitoring afdeling) zijn ze vaak clueless, zeker indien ze niet bij implementatie betrokken zijn geweest. Er zijn mensen bij die geen SNMP kunnen spellen, laat staan weten per device/server welke gegevens je kunt onttrekken en waarom je dat wilt weten.

Het idee is dat je engineers hebt die het neer gooien en vervolgens met goedkoper personeel het kunt beheren, maar als je niet weet naar wat je kijkt, dan maakt het ook niets uit, zeker indien aanvalsvector juist rekening houd met SIEM.

Overigens managers willen ivm compliance en hun verantwoordelijkheid te verleggen kiezen voor makkelijkste oplossing. Het oplossen van structurele problemen, is dan te lastig en dan zijn ze ijverig om appliance die niet helpt te kopen, de verkoper heeft boter op zijn hoofd. Het is gewoon misdadig. Maar goed sigaretten en alcohol verkopen is ook normaal...

Maar ik zou ook trachten zo een organisatie te overtuigen van dat ze een ander probleem hebben dan wat ik ze wil verkopen, maar uiteindelijk oplossing waar ze naar vroegen niet verkopen, naast risico achteraf, voornamelijk eer en geweten.

[SuperDre]

Dat is toch wel heel naief, zeker als je aan komt met 'herkenning van aanvallen via signatures' wat dus betekent dat die alleen aanvallen herkent die al bekend zijn.. Het is natuurlijk wel weer een extra muur waar doorheen moet worden gebroken, maar het maakt het niet 100% veilig (want dat kan nooit).

[d3burt]

Fortigate's Intrusion Prevention heeft zowel false positives als false negatives. Met beide zou ik kunnen leven, maar daarnaast zijn er ook nog bugs die zonder enige vorm van logging één op de zoveel connecties slopen.

Ik heb een keer een echt brakke Joomla website in leven gehouden tot de rewrite in Python klaar was, door er een Apache ModSecurity WAF voor te zetten. Toen hij weer uit kon een jaar later zaten er 138 uitzonderingen op de standaard "veilige" OWASP regels in, maar was de server nul keer meer gehackt (terwijl zonder de WAF er meerdere keren per dag een succesvolle exploit was, doorgaans van script kiddies die niet eens in de gaten haden dat de exploit succesvol zou zijn als ze even zouden doorpakken). Als ik mijn uren commerciëel had moeten berekenen zou het beheer in deze periode 14000 Euro hebben moeten kosten.

Als je de software goed up to date houdt en een goede hoster hebt kan je best een website in Joomla/WordPress/Drupal in leven houden, maar de praktijk is dat de meeste sites eenmalig in elkaar worden gehobbied en nooit geüpdatet. Ik raad dan ook echt mensen aan om te kijken naar statische websites, en die met bijvoorbeeld forestry.io+gitlab te beheren (voor bonuspunten: laat Jekyll meteen je JavaScript en CSS files samenvoegen en minifyen). 99 van de 100 websites hebben geen "bewegende delen" nodig behalve misschien commentaren of een e-mail form, en voor allebei zijn goedkope of gratis services, zoals Discus of FormSpree. En wordt je hoster gepakt: nieuwe hoster zoeken, nieuw FTP of SSH adres in Gitlab zetten, op de Publish knop drukken in Forestry, en klaar is Clara!

[Turdie]

Sommige firewalls hebben ook een ingebouwde IDS/IPS functie tegenwoordig, die kunnen wel SQL injecties afvangen een voorbeeld daarvan is de Barracuda Web Application Firewall:
https://www.barracuda.com/glossary/sql-injection

https://www.youtube.com/watch?v=XfN7zelvwao

[Reactie gewijzigd door Turdie op 22 juli 2024 23:11]

[Anoniem: 1322]

Die vangen alleen de meest voorkomende simpele scriptkiddie zaken af voor de meest bekende software waarvan bekend is dat deze exploited worden... Dus ja, enkel een klein percentage.. Fijn als je daarop vertrouwd...

[totaalgeenhard]

Heb je gelezen wat ik heb geschreven voordat je die pagina hebt gelezen?

Aanvalsvector die ik beschrijf helpt dat niet tegen. (even LETTERLIJK lezen wat ik omschreef en dan LETTERLIJK lezen wat er op die website staat).

[MADG0BLIN]

Dan ben ik wel met je eens. Ik heb mijn DNS er draaien voor mijn domein, dat functioneert tot op heden nog wel gelukkig.

[bArAbAtsbB]

ik neem aan dat er geen helpdesk medewerkers de servers ah herstellen zijn, dus het excuus dat ze bezig zijn met herstellen slaat natuurlijk nergens op! maarja zo zie je maar weer dat een backup alleen een echte backup is als hij niet meer connected is.

[Anoniem: 1128097]

Maar de status constant opvragen aan de herstellers is toch wel vervelend.

[RGAT]

Daarom vraagt de helpdesk elke zoveel tijd een update/geven de herstellers die update zelf als er iets groots veranderd en geven ze dat antwoord aan alle klanten die bellen/mailen/...
Daarom heb je een eerstelijns, om juist die lading eraf te halen.

[Tjidde]

Bandje voor dat je iemand aan de lijn krijgt.

Met iets kijk op mhp.nl/storing Als je dit of dit ondervind

[Anoniem: 1128097]

Ja true, maar wie zegt dat dat gedaan word. En ik snap dat ze zeggen bel maar niet, want anders krijg je mensen die pissed worden omdat ze en geen hosting hebben en uren in de wachtrij staan. Das dubbel op.

[Inspired]

Heb niet de indruk dat hier 100+ man werken. Dus kan goed zijn dat iemand meerdere rollen heeft. Ook gezien het veelvuldig gebruik van "ik" bij de facebook updates. Geen team van 10 man.

[Zenomyscus]

4 of 5 man uit mijn hoofd.

[RVervuurt]

"Ze" is in dit geval natuurlijk gewoon het bedrijf, niet die specifieke helpdeskmedewerker die het schrijft...

[bArAbAtsbB]

dan nog steeds zijn de helpdeskmedewerkers geen servers ah herstellen toch? waarom dan niet de klanten fatsoenlijk te woord staan?

[vosManz]

Ik ken het bedrijf zelf niet, maar als het een klein bedrijfje is zou het kunnen zijn dat de helpdeskmedewerkers ook direct de technische mensen zijn. Een klein bedrijf heeft vaak niet een apart team voor de helpdesk, die taak komt er gewoon bij de overige medewerkers bij.

[RVervuurt]

Ah, op die manier.

[hotabibber]

De hoster adviseert gedupeerden om, in afwachting tot de servers weer online komen, lokale back-ups van databases terug te plaatsen, door te verwijzen naar bijvoorbeeld Facebook, een tijdelijk pagina te publiceren of een nieuwe site te bouwen en die te plaatsen.

Wie is er verantwoordelijk voor mis gelopen inkomsten? Wie is er verantwoordelijk voor kosten c.q. uren die in een eventuele nieuwe website gestoken moet worden?

En ze menen toch echt niet dat klanten nog bij zo'n bedrijf blijven die zo'n slechte communicatie geeft naar zijn klanten toe.

Hun makkelijk praten maar de klanten zitten er wel mee. Gelukkig geen klant aldaar.

[himlims_]

leuke vraagstukken; daarvoor is een SLA

[Psycho_Mantis]

Misschien wel een “best effort” SLA.

[hotabibber]

Hier heb je inderdaad de SLA voor. Maar dis SLA hoeft niet bindend te zijn, zou niet weten hoe het juridisch geregeld is.

[StephanVierkant]

Artikel 17 lid 1 van de algemene voorwaarden voor bedrijven bedrijven:

Behalve op de in artikel 10 genoemde restitutie kan de consument geen aanspraak maken op enige vergoeding door MijnPartnerGroep.nl van welke geleden schade dan ook ontstaan door het uitblijven van de levering van de diensten.

Wel gek dat ze van 'consument' spreken. Een bedrijf is natuurlijk geen consument. Als ik de Algemene Voorwaarden zo lees is dat het betere knip- en plakwerk geweest.

[totaalgeenhard]

Algemene voorwaarden geldt niet indien je structureel gebrek hebt.

[tweaknico]

Dat is het voordeel van hosting....
Als de hoster verkeerd getroffen wordt is de schade van de "buren" ook jouw schade.

Dat kan andere hosters ook overkomen en individuele bedrijven ook.
Alleen bij individuele bedrijven is de aanspraakelijkheid wat duidelijker.

[PeterElzinga]

Gezien de prijzen die ze rekenen op hun voorpagina verwacht ik dat vergoeding gevolgschade uitgesloten is. Als je dat wil moet je een SLA afsluiten, en dan heb je het over hele andere bedragen.

[MuddyMagical]

De communicatie is echt niet goed. Alleen op Facebook staat er een bericht maar voor de rest nergens waaronder ook niet op hun status pagina of Twitter zoals gemeld.
Daarnaast reageren ze nogal giftig op reacties van klanten die klagen over de gebrekkige communicatie wat het niet beter maakt.
Onderstaande is 24 uur na begin van het probleem gepost op hun Facebook. Let wel, dat was de enige plek waar werd gecommuniceerd dat 'er een storing gaande was'

Even een noot aan alle ongeduldige mensen: Wij begrijpen jullie frustratie en irritatie. Jullie zullen ongetwijfeld begrijpen dat ook wij hier niet op zitten te wachten en dat er alles aan gelegen is om de diensten weer zo snel mogelijk up and running te krijgen. Hier negatieve reacties plaatsen dragen daar echt niet aan bij. Dit werkt niet productief en voelt als een steek naar de mensen die hier al non-stop vanaf gisteren 17:30 mee bezig zijn. Het is een storing / aanval die we nog niet eerder zo hebben meegemaakt en we doen er echt alles aan om de services zo snel mogelijk weer werkend te krijgen. We vragen jullie vriendelijk om jullie begrip en geduld. Alvast heel erg bedankt.

Gezien de vele problemen en de klachten zal het me niets verbazen als ze hier veel klanten mee verliezen.

[Reactie gewijzigd door MuddyMagical op 22 juli 2024 23:11]

[Rob]

Een verre van professionele reactie van mijnhostingpartner.
Als ze geen negatief commentaar willen krijgen, dan moeten ze een nette statuspagina neerzetten en deze goed bijhouden. Het commentaar verdwijnt dan naar Twitter, dat laten we maar achterwege

[tonkie_67]

Een status pagina is bijna altijd afhankelijk van werkende databases/SQL servers - laten die nou allemaal om zeep zijn....
Maar na een week paar uur zouden ze toch (desnoods door een ingeschakelde derde) , een externe (evt eenvoudige) status pagina kunnen hebben opgezet; tenzij ze ook de controle over hun eigen dns servers kwijt zijn...

[Reactie gewijzigd door tonkie_67 op 22 juli 2024 23:11]

[Sieb2]

Nou lijkt het mij dat je een status pagina voor klanten sowieso zo min mogelijk op je eigen netwerk wilt hebben. Zodat als je eigen netwerk plat ligt je nog wel een status update kunt doen.

(Atleast dat is mijn policy dan)

[Reactie gewijzigd door Sieb2 op 22 juli 2024 23:11]

[Rob]

Precies dat!
Het is voldoende om een HTML pagina bij een grote cloudprovider te plaatsen. Voor een tientje per maand ben je klaar

[ralph075]

Oei, die is niet best...
Cursusje communicatie is wel op zijn plaats daar

[Sikro]

Al jaren tevreden klant. Altijd vriendelijke klantenservice en problemen waren vaak binnen een dag opgelost. Als huis tuin en keuken website bouwer is deze host met lage prijzen prima. Dat dit zo mis is gegaan heeft voor mij weinig impact. Voor de mensen met webwinkels en professionele sites is het uiteraard minder prettig. Maar ook erg naief. Voor zo'n prijs kan je niet op de eerste rang zitten, en een SLA is zeker geen overbodige luxe.

Dat dit heeft kunnen gebeuren is belachelijk. Maar om de kosten op MHP te verhalen zonder SLA contract lijkt me onmogelijk.

[Bender]

Mijn ervaring binnen de hosting wereld is hoe minder mensen betalen, hoe meer ze er van verwachten.

Bedrijfskritische zaken op low-budget hosting providers zetten is gewoon een no-go, dan neem je jezelf ook niet serieus als ondernemer.

[Sikro]

Exact. En het argument 'ik ben een leek en geef het gewoon uit handen' heeft ook grensen. Precies wat je zegt over bedrijfskritische zaken op low budget providers...

[EDIT]

Nieuwe HDD/SSDs plaatsen en de backup van de vorige dag terug zetten was blijkbaar geen optie?
Dan kan je je daarna rustig richten op eventuele decryptie mocht het voor bepaalde klanten echt een halszaak zijn om de data van één dag te missen.

[Dionysos1]

"De kwaadwillende slaagden er onder andere in om ransomware te injecteren bij mysql- en mssql-servers, waaronder de back-up-servers."

Gok dat er dus niks fatsoenlijks meer terug te plaatsen was

[EDIT]

Dus ze zijn binnengekomen via een mysql/mssql injectie op een backup server? Wat doet die software in 's hemelsnaam op een backupserver?

[vosManz]

Dat staat er niet. Er staat dat er ransomware geïnjecteerd is op mysql-, mssql- servers, waaronder de back-up-servers, niet dat er SQL-injectie plaats heeft gevonden direct op de back-up servers. Als je via een webserver bent binnengekomen, kun je mogelijk ook ransomware plaatsen op de andere servers binnen het netwerk zonder daar direct SQL voor nodig te hebben.

Waarom er SQL software op de back-up-server draait? Misschien ging het om een fallback-server die in een master-slave opstelling draait, dan moet er op de slave natuurlijk ook SQL software draaien. Als er geen verdere back-up oplossing is (master-slave is eerder fallback voor een crash o.i.d., niet echt back-up), is dat natuurlijk wel kwalijk, maar dat is niet te zeggen als we de situatie niet exact weten. Misschien draait de back-up server helemaal geen SQL software, maar noemen ze het alleen zo om de klanten niet te veel te verwarren met moeilijke praat. Waar ze precies door zijn binnengekomen wordt zo te zien ook niet genoemd, dus zolang we dat niet weten kunnen we daarover ook alleen maar aannames maken.

[Yalopa]

De catalog van de backup bijhouden. De meeste backup software gebruikt hiervoor een DB. Dikwijls zijn die snel mee geïnstalleerd met de software en daarna nooit meer onderhouden.

Je kan argumenteren dat dat op een centrale / aparte SQL Server zou moeten, maar als je die SQL kwijt bent (en je dus moet restoren) is dat een stuk complexer (en trager) zonder de catalog. Er valt dus iets voor te zeggen om de DB van de backup software op de backup server te hebben. maar dan moet je het ding natuurlijk wel onderhouden.

[HKLM_]

Offsite back-up zal wel te duur geweest zijn

[vosManz]

Onsite of offsite, om een back-up te maken moeten de server en back-up server contact met elkaar kunnen maken. Er moet dus ergens een verbinding zijn met de back-up server. Als er ergens een lek zit (wat hier dus het geval blijkt te zijn), kun je daarmee dus mogelijk ook aan de back-up server komen, ongeacht of die offsite of onsite zit. De locatie van een server maakt via een internetkabeltje niet uit.

Offsite is voornamelijk verstandig i.v.m. brand, (fysieke) inbraak, stormschade etc., niet direct bij digitale inbraak.

[Yalopa]

Vandaar dat we ook wel eens over offline backup spreken. Die media (bvb tapes) zijn niet verbonden....

[vosManz]

Snap ik, maar HKLM_ had het over offsite, niet over offline

[HamuNaptra]

Ik zie niet direct de reden waarom een server en backup server in contact moeten kunnen staan met elkaar.
Er zijn genoeg backup scenario te verzinnen waarin dit niet nodig is en waar beiden servers gescheiden van elkaar kunnen leven.

Voor mij is het zelfs een best practice om deze gescheiden te houden. Maar we zien teveel dat er te makkelijk naar een degelijke backup infra wordt opgekeken, ofwel door kennis/ervaring tekorten, budget tekorten of evenwel management beslissingen. Indien je management dit kan bepalen zou ik trouwens als enterprise architect maken dat ik bij een andere firma zat...

[vosManz]

Als gegevens van plek A (main server) naar plek B (back-up server) moeten, zal er ergens toch contact moeten zijn. Teleporteren is volgens mij ook in de digitale wereld nog niet mogelijk. Ze kunnen dus inderdaad fysiek gescheiden van elkaar leven, maar er zal wel altijd een verbinding tussen beide moeten zijn, al staan de servers aan de andere kant van de wereld. In de ideale situatie kan de back-up server alleen de gegevens back-uppen, en kan de main server verder niets op de back-up server schrijven en zeker niet uitvoeren. Maar contact zal er dus ergens moeten zijn, anders komen de gegevens niet van plek A naar plek B. Als daar ergens een gaatje in zit (bug, backdoor, verkeerde configuratie, ..) kan er dus in potentie misbruik gemaakt worden van de back-up server, en kan daar dus ransomware op geïnstalleerd worden.

[HamuNaptra]

Nogmaals, servers kunnen perfect worden gebackuped zonder gedeelde netwerk link, zonder gedeelde accounts etc.
Ofwel was het onwetenheid of een budget/management beslissing waardoor de backup servers konden geinfecteerd worden. Je backup servers mogen niet op hetzelfde lan segment leven als andere servers en mogen nooit benaderbaar zijn met dezelfde accounts, maw in windows op een andere AD etc.
Een geïndustrialiseerde oplossing kan dit allemaal makkelijk voorzien, een houwtje-touwjte oplossing in de trend van "het werkt toch??" mag voor mij geen backup worden genoemd...

[Loggedinasroot]

Het probleem zit hem erin dat je vaak niet precies weet wanneer ze binnen zijn gekomen.
Misschien zaten ze al een jaar lang binnen.

[EDIT]

In dat geval zouden ze dus niet regelmatig een controle gedaan hebben of de backups wel correct opgeslagen zijn.

[Loggedinasroot]

Hoe bedoel je dat precies?
Stel je hebt een Windows server draaien.. Die wordt geinfecteerd, vervolgens back je die up.. Na een jaar restore je de backup. Dan ben je alsnog geinfecteerd, en er is niks mis gegaan met het backuppen?

[fantafriday]

En de volgende dag ben je weer klaar want het gat in je beveiliging zit er nog steeds?

[EDIT]

Aangezien ze spreken over injecties, mag ik hopen dat ze weten waar het vandaan is gekomen en daar maatregelen op getroffen hebben.

[curkey]

Nee want je weet niet wat in je infrastructuur “tainted” is of hoe lang. Na een systeemcrash is een restore simpel, maar na zo’n infectie kun je dus niks vertrouwen.

[Anoniem: 710428]

De hoster adviseert gedupeerden om, in afwachting tot de servers weer online komen, lokale back-ups van databases terug te plaatsen, door te verwijzen naar bijvoorbeeld Facebook, een tijdelijk pagina te publiceren of een nieuwe site te bouwen en die te plaatsen.

Even een nieuwe site bouwen....

[MartijnHavinga]

Heb jij geen backup van je site? Wat nou als je hosting partner crashed, wat doe je dan? Is wel een beetje slecht van je vind ik
-edit typo (kut smartphone)

[Reactie gewijzigd door MartijnHavinga op 22 juli 2024 23:11]

[Anoniem: 710428]

Heb jij geen backup van je site? Ja dagelijks
Wat nou als je hosting partner crashed, wat doe je dan? Mijn website bij andere hosting plaatsen.
Is wel een beetje slecht van je vind ik. Tja dat kan. maar wat is dan slecht? Ik zit 1. niet bij deze partij, 2. ik heb geen waardevolle site. 3. Niet in mijn comment geplaatst dat ik gedupeerd ben.

Btw ik citeer hier een stuk uit het artikel, ik vond het wel een mooie antwoord van diegene. Je bouwt schijnbaar een website alsof het niets is. Dus wacht maar af tot de servers online komen als je dat niet snapt of bouw er gewoon eentje.

[MartijnHavinga]

Ah zo, excuses, ik vatte het sentiment verkeerd op.
Ik dacht dat je sarcastisch omdat het bouwen van een site lang duurt. Maar dat is inderdaad juist het punt, als je zelf goeie backups hebt is het opnieuw optuigen van je site (evt. bij een andere hosting partij) een kwestie van een paar minuten werk.

[mocean]

Als je 2.09 euro p.m. betaald, dan zet je daar geen gevoelige / unieke bedrijfsdata neer zou ik zeggen!

Regel ook zelf backup van je site (Wordpress) etc, op een eigen locatie!

[Anoniem: 1128097]

Dat is een flinke aanval. Slecht opgezet(qua backups blijkbaar wel) en/of mol?

[laser50]

Kan iemand mij uitleggen waarom alle backups/backupsystemen überhaupt verbonden warenmet de rest van je systemen? Sure, handig overzetten die data maar leuk dat al je data ook nog online staat en toegankelijk is Lijkt mij juist handiger om je backups op de een of andere manier op een offline storage te zetten..

[draadloos]

De tendens is al enkele jaren om alle backups op hdd storage te maken, want dat is veel goedkoper en sneller. Daarom zweer ik nog steeds bij een tape library.... Ook al is die verbonden met de backupserver, ransomware zal niet de tapes overschrijven.

[Trommelrem]

En waarom zou ransomware geen tapes overschrijven? De vorige generatie ransomware overschrijft gewoon 6 maanden lang backups voordat het zich openbaart. Succes met je klanten vertellen dat je nog backups hebt van 7 maanden terug.

[RGAT]

Omdat de ransomware niet zomaar de tapelibrary opdrachten kan gaan geven...
Daarnaast kunnen sommige libraries ook zelf retentie bijhouden waarmee ransomware vrolijk achteraan mag aansluiten en zolang de data nog niet verlopen is er niet aan kan komen, dus zelfs als de ransomware de tapelibrary kan aanspreken en compatibel is met de gebruikte driver en de picker niet locked is door de backup applicatie....
Als je een veilige backup wilt is tape wel een van de beste opties als het in je (zakelijke) budget past.

[draadloos]

Precies dat. Daarom adviseer ik klanten nog steeds een tapestreamer etc.

[SuperDre]

Uhm.. Hoe is tape nu veiliger als ransomware de data zelf die gebackuped is heeft encrypted? DAT is wat er vaak gebeurd, veel ransomware draait al weken voordat het zich toont daarmee dus alle data die je inmiddels gebackuped hebt versleuteld. Enige waarvoor het zou helpen is dus instant ransomware die je backups zelf zou versleutelen als die op de harddisk zouden staan.

[RGAT]

Punt is dat tape offline is, als je ransomware of andere malware weken of langer zijn gang laat gaan helpt niets je meer (hoewel er meestal met tape wel data van maanden terug nog bestaat, of die na zoveel maanden nog relevant is wisselt natuurlijk per bedrijf).
Daarom goed risico's inperken, maar mocht het dan toch mis gaan helpt tape (offline) wel een stuk beter dan disks (online) die direct kunnen worden besmet.

[Helixon]

Omdat de tapes dan niet fysiek in de machine zitten, en daardoor dus niet overschreven worden!?