Hacker verwijdert alle data van broncode-hoster Code Spaces

De dienst Code Spaces, dat een opslagplatform voor broncode aan ontwikkelaars biedt, sluit zijn deuren. Dat gebeurt nadat een hacker toegang tot het Amazon Web Service-account had verkregen en vrijwel alle data, waaronder back-ups, heeft verwijderd.

Code Spaces was een webbased-git- en subversion-hoster, die op zijn beurt gebruikmaakte van Amazon Web Services. De dienst maakt op zijn website bekend afgelopen dinsdag onder vuur te hebben gelegen van een ddos-aanval. Dat gebeurde vaker, maar dit keer constateerde de dienst dat een onbevoegd persoon toegang had gekregen tot zijn Amazon EC2-beheerderspaneel en daar verzoeken had achtergelaten om contact op te nemen. Het bleek om een afpersingspoging te gaan: Code Spaces zou moeten betalen om de ddos-aanval te laten beëindigen.

De beheerders van de hostingdienst wijzigden daarop het wachtwoord voor het beheerderspaneel, maar de hacker bleek hierop voorbereid te zijn. Via back-up-logins kreeg hij opnieuw toegang, waarna hij Amazon Elastic Block Store-snapshots en -instances, Simple Storage Service-buckets en virtuele machines begon te verwijderen. "Samenvattend: het meeste van onze data, backups, machine-configuraties en offsite backups zijn gedeeltelijk, dan wel volledig verwijderd", somt Code Spaces op.

De dienst heeft de handdoek in de ring gegooid vanwege de te verwachten kosten en omdat de betrouwbaarheid te grabbel is gegooid. Het platform adverteerde juist met de claim dat een 'full recovery plan' aanwezig was. Code Spaces zegt klanten te ondersteunen bij het exporteren van overgebleven data.

De laatste maanden worden meer diensten afgeperst door ddos-ers. Ook Feedly en Evernote kampten onlangs met dergelijke aanvallen.

Reacties (213)

Zo'n offsite backup heeft blijkbaar alleen nut als het om fysieke schade gaat. Bij een offline backup hadden de hackers er niet bij gekund en zou er in ieder geval nog een backup hebben bestaan.
De kunst is om de boel niet zo automatisch te hebben lopen, dat hackers direct of indirect ook bij de backups kunnen.

Edit: ik zie dat Kackar me voor is.

[Reactie gewijzigd door Timfonie op 19 juni 2014 12:03]

En de beste optie die ik hierin zie is een fysieke dataopslag te hebben welke alleen handmatig is te bereiken, en waar dus alleen d.m.v. een externe schijf, data opgezet kan worden.

Euh... Wij gebruiken een assymetrische sleutel voor de backup en een SFTP jail (die je met één config regeltje instelt) om de dagelijkse backup te posten. Simpel cron jobje om de backup te verplaatsen en klaar.

No way dat de backup user toegang heeft tot meer dan zijn dagelijkse werkdata en no way dat de backup te decrypten is met dezelfde sleutel als waar ie mee is gemaakt.

Onze ervaring is dat externe schijven vergeten worden / niet werken / kwijtraken etc en dat dat een veel groter risico is, dan een goed ingerichte offsite - online backup.

Wat inhoudt dat iemand zich hiermee moet bezig houden en dus handmatig de disk moet aan- en loskoppelen... dat werkt misschien nog net voor een KMO maar niet voor een wat groter bedrijf. Bedrijven verwachten tegenwoordig ook wel real-time (cloud) backups.

Een betere oplossing is om je offsite backups naar een derde partij te kopiëren (een cloud dienst) waar je kan instellen dat bestanden niet meteen verwijderd worden en je ze bv. nog 30 dagen kan terughalen (shadow copies). Een hacker kan dan wel je offsite backups weggooien maar dan zijn ze nog niet écht weg... of hij moet ook dat bedrijf gaan hacken (risicofactor = verwaarloosbaar).

Edit:
Je kan daarnaast natuurlijk ook dagelijks of wekelijks een offline backup maken op een externe schijf. Bovenstaande is meer voor een geautomatiseerde offsite / offline oplossing om zoveel mogelijk real-time data veilig te stellen.

Ook door je offsite backups te "pullen" minimaliseer je een aantal risico's doordat je dan ook niet automatisch ook toegang hebt tot het backupplatform.

[Reactie gewijzigd door WhiteDog op 19 juni 2014 12:39]

Een backup maken mag best online zijn, maar een backup verwijderen of terugzetten nooit, zou ik zeggen.

[Reactie gewijzigd door ATS op 19 juni 2014 17:08]

Een back maken mag best online zijn, maar een backup verwijderen of terugzetten nooit, zou ik zeggen.

Daar zat dan inderdaad een groot beveiligingsgat: De locatie die de backups ontving had geen 'write-only' toegang maar was blijkbaar gewoon een netwerkschijfje waar je met een root-account alles op kan. Dat is natuurlijk gewoon mispoes.

Bij een beetje fatsoenlijke backup-server kun je er wel data naartoe sturen, al dan niet met een manifest van welke bestanden er gewijzigd/verwijderd zijn, maar wordt de inhoud van je lokale schijf niet gelijk 1 op 1 gemirrord zonder mogelijkheid tot terughalen.

Het kan ook zijn dat de hacker met zijn root-account de backups expliciet heeft gewist, daar is dan weinig aan te doen behalve een aparte set credentials voor de backup-machines (en dan liefst nog via een ander bedrijf cq. andere managementlaag)

Meteen support aan de lijn pakken in zulke situaties. Zeker bij afpersing dan is er nog tijd om te reageren.

Laat hun eerst alle IAM accounts verwijderen in AWS. Of alle rechten policies revoken en de hoofd account blokkeren en dan repareren.

En bij een manuele recovery. 't Is niet dat deze dingen heel ver weg staan. (IAM > Users > User Actions > Delete User)

Best wel heel dom dit had perfect voorkomen kunnen worden.

@Passkes inderdaad het is heel leuk om offline je spullen bij te houden. Het spijtige van deze zaak is dat AWS zeer graag zijn spullen binnen hun eco systeem wilt houden en dit ook financiël sterk aanmoedigt.

Zo zijn bijvoorbeeld data verkeer binnen bepaalde services gratis. Neem bijvoorbeeld de communicatie tussen Glacier en S3, deze is compleet gratis. Tevens zoals de traffiek van EC2 naar S3 binnen dezelfde regio.
Als je dan een S3 backup naar een offline machine wilt verplaatsen, dan zal de rekening volgen van data out ~$0.120/GB (US regio).
Dan kan ik begrijpen dat men deze keuze niet gemaakt heeft. Een backup van 1TB kost zo al gauw een 120 dollar.

[Reactie gewijzigd door enira_net op 19 juni 2014 13:13]

Als iets duur is, betekent het niet automatisch dat je het niet moet doen.

Beter gezegd, als dit de enige manier is om een fatsoenlijke/veilige/offsite backup te maken.
Heb je dan wel voor het juiste product gekozen............

Volgens mij zijn er wel andere manieren om een fatsoenlijke/veilige/offsite backup te maken. Ja het kost misschien wat geld. maar dan heb je ook wat.

Er zullen wel backups geweest zijn, daar twijfel ik niet over. En deze backups van AWS liggen waarschijnlijk ook ergens offline.

En in 99% van alle gevallen was je gecovered. Behalve als die ene hacker je hele console account overneemt en een spoor van vernietiging achterlaat.

Spijtige zaak

Je kan het van 2 kanten bekijken. In dit geval is gebruik gemaakt van Amazon voor zowel de Productie als de back-up omgeving. Dat in eerste instantie al niet aan te raden is. Dan is het ook nog zo dat waarschijnlijk de rechten niet goed zijn toegekend en ze gebruik maakten van het beheerders account. Wat al een absolute don' t is bij computersystemen van deze grote.

Maar je kan natuurlijk ook zien dat er een aantal beveiligingssystemen bij Amazon zijn die hebben gefaald. Omdat de authenticatie wel beter zou moeten zijn. En dat het zomaar kan gebeuren dat de hele omgeving weggegooid kan worden zonder dat daar iemand van op de hoogde wordt gebracht, of dat er wordt gevraagd om verificatie van de systeembeheerders middels een mailtje of sms' je.

Al met al vind ik het een fout van beide kanten. Omdat Code Spaces niet voor de juiste omgeving heeft gezorgd en alles klakkenloos bij Amazon heeft gedropt. Onvoldoende gebruik heeft gemaakt van de beschikbare rechten systemen en te langzaam heeft gereageerd. En ook omdat Amazon niet de juiste beveiliging in plaats heeft om dit soort scenario's te voorkomen. En het niet in staat is geweest de beloofde beveiligingssystemen juist te laten functioneren.

Wow. Ik snap niet waarom je zoiets doet. Wat heb je hier aan? 't Is niet alsof de afperser nu nog zijn geld gaat zien, en je irriteert andere mensen hier alleen maar mee. Hoe kwam hij überhaupt aan de inlog gegevens?

Tenzij hij natuurlijk een concurrent is.

Wij gebruiken ook AWS en ook bij ons is de login gejat, door Amazon te overtuigen dat de MFA uitgeschakeld moest worden! Dus juist dat beveiligingsmechanisme wat dit soort dingen moet voorkomen kon met wat gegevens plus een telefoontje naar AWS Support uitgeschakeld worden. Ze hebben bij ons geen snapshots gewist, feitelijk weinig kunnen aanrichten. Ze konden ook niet inloggen op onze servers. Het duurde wel twee dagen voordat ze niet meer konden inloggen, want blijkbaar kon Amazon ze niet uitloggen. Veel gedoe, veel werk. Wij maken ook een backup naar een lokale server, maar nu ik dit lees moet die procedure toch maar eens nagekeken worden.

Mooi he, alles in de cloud. Zelf niet meer de baas zijn over je eigen spullen. Tegen de tijd dat ik op die manier moet werken begin ik denk ik maar een souvenirs winkeltje of zo.

Wat ik lees, is dat Amazon zijn zaakjes niet op orde heeft.
Het is veel te gemakkelijk om beveiligingsmechanismes uit te schakelen of te omzeilen.

Dus Amazon moet hier iets aan doen (en zou verantwoordelijk gesteld kunnen worden).

Of een ex-medewerker met rancunes? Het lijkt me sterk dat je zomaar de dingen kan doen zoals beschreven zonder dat je inside informatie hebt.

Het kan wel. Lees mijn commentaar hieronder.

Dat is toch heel duidelijk waarom hij het doet? Hij wou geld of anders. En als je dan niet invulling geeft aan die 'of anders' dan neemt niemand je ooit serieus en zal nooit iemand in gaan op je afpersingspogingen.

De eerst volgende keer dat hij ergens zit en die persoon hiervan weet (of misschien op de hoogte wordt gebracht door de hacker) zal die persoon twee keer nadenken voordat hij het negeert (of een halve oplossing toepast).

Wel heel triest en jammer dat iets zo moet eindigen. Ik hoop dat ze die gast te pakken krijgen.

Nee de afperser krijgt zijn geld vast niet nee, maar geeft wel een duidelijk signaal af naar anderen wat er gebeurd/kan gebeuren als je niet betaald

En daar hebben ze nu Two Factor Authentication voor uitgevonden..
http://aws.amazon.com/iam/details/mfa/

Wat met de juiste gegevens (laatste nummers creditcard en nog wat algemene info) telefonisch weer uitgeschakeld kan worden. Dit is bij ons gebeurd.

En hoe komen ze aan de laatste cijfers van je CC?

Social engineering, oud papier doorsnuffelen, schaduwen van personen, inbreken.... verzin het maar.

Wat ik doe is eens bellen naar PayPal, Amazon en enkele andere belangrijke sites die ik gebruik en ik vraag om in de notities van mijn account te plaatsen dat de helpdesk mij moet bellen + mij moet vragen naar een extra veiligheidsvraag. Op die manier is het nog eens moeilijker. Bij echt grote klanten zoals Code Spaces kan het toch niet dat ze niet extra uitkijken om dit soort problemen te voorkomen?

Het is inderdaad huidig veel te eenvoudig om 2-step authentication uit te schakelen. Al ligt het misschien ook deels aan de helpdesk medewerker die gewoon het boekje volgt.

Wat ik doe is eens bellen naar PayPal, Amazon en enkele andere belangrijke sites die ik gebruik en ik vraag om in de notities van mijn account te plaatsen dat de helpdesk mij moet bellen

been there done that, maar de eerste keer dat men probeerde een <insert telecom partner> (zakelijk) abonement af te sluiten, was men wel mooi vergeten om mij even te bellen... ja het stond in de aantekeningen naar geen enkele persoon in de keten had de tijd genomen die te lezen... uiteindelijk hebben we dat nummer weer laten ontbinden en zelfs de gemaakte telefoonkosten niet betaald, (als service omdat ze zich er nogal voor schaamden), maar de uren die daar in staken.. pffoooeeeeh...

*namens een bedrijf met ongeveer 500simkaartjes en vaste telefonie...
dit was een jaar of 3 terug...

Als jij denkt dus dat Two factor authentication zo veilig is, dan ben je toch wel heel erg naief... Maar het is natuurlijk wel weer een extra barierre...

[Reactie gewijzigd door SuperDre op 19 juni 2014 13:49]

Zéér spijtig voor het bedrijf!
Heerlijk artikel in mijn verdediging om ons datacenter in house te houden en niet in de cloud te steken.

Dat helpt zeker, maar waarschijnlijk is jullie datacenter ook via bepaalde wegen van buitenaf toegankelijk, bijv. via een VPN. Weet je zeker dat er geen accounts zijn die toegang hebben tot vrijwel alle systemen, of zichzelf hier toegang toe kunnen geven?

Het is volgens mij meer een les dat men niet moet vergeten privileges te scheiden. Het is maar al te makkelijk om alle admins een account te geven die alle rechten heeft. Juist AWS heeft via het IAM systeem veel mogelijkheden om toegang te beveiligen, maar dat maakt het natuurlijk omslachtiger in dagelijks gebruik. Ook multi-factor authenticatie wordt nog veel te weinig gebruikt.

<>

[Reactie gewijzigd door moreasy op 19 juni 2014 20:48]

Om een bedrijf zo tengronde te richten ben je wel heel erg zielig bezig.

Ja dat is zo.
Echter dat een bedrijf hier niet op voorbereid is, is natuurlijk ook wel zielig bezig!

hoe wil je hierop voorbereiden?

Ik heb ook op de zaak voornamelijk Back-up to Disk ipv Tape.. Dus een Hacker zou ook zomaar al mijn VM's en zooi weg kunnen gooien mits deze toegang zou hebben tot de systemen..

Met gevolg dat ik sowieso naar minimaal een maand terug kan, maar ook weken bezig zal zijn om alles opnieuw op te bouwen.. Kan zomaar tonnen aan geld gaan kosten.. Voor het herbouwen en de productie die stilvalt..

Dan kan je wel een uitwijk hebben. Maar zit een hacker al zover in je systeem dan is die ook niet veilig meer!!

Wij hebben een backup-to-tape-to-the-bank-vault backup

Er is GEEN andere veilige manier om backups te nemen.
Als je als bedrijf geen backups op offline media neemt én deze niet op een geografisch gespreidde plaats stockeert, ben je een AMATEUR.
Security guidelines van 1960 nota bene...

Liefst had ik ook nog een backup-to-tape-to-the-bank-vault-in-armored-trucks-with-armored-personel.

[Reactie gewijzigd door ? ? op 19 juni 2014 14:28]

Wij hebben een backup-to-tape-to-the-bank-vault backup

Er is GEEN andere veilige manier om backups te nemen.
Als je als bedrijf geen backups op offline media neemt én deze niet op een geografisch gespreidde plaats stockeert, ben je een AMATEUR.
Security guidelines van 1960 nota bene...

Het is alleen zo'n enorm karwei om een backup-to-tape van de nodige terabytes te maken en die naar een bankkluis te verschepen. Dat lukt met een aantal GB aan supergevoelige data misschien nog wel, maar als je dat met de inhoud van een heel datacenter moet doen, dan heeft een team van 6 man er een full-time dagtaak aan. Niet elke hoster kan dat bekostigen, al helemaal niet als de schaal van het datacenter groter wordt.

Mwa,
een TSM (Tivoli Storage Manager) server en een goede taperobot en je bent al een heel eind.
Als je het goed inricht heb je er vrij weinig werk aan, zeker niet 6 man full time.

Mwa,
een TSM (Tivoli Storage Manager) server en een goede taperobot en je bent al een heel eind.
Als je het goed inricht heb je er vrij weinig werk aan, zeker niet 6 man full time.

Dat is dus een geautomatiseerde oplossing die ook aan een netwerk hangt, en dus... kan ie worden gehackt.

Een taperobot kun je ook de instructie geven 'deze tapes hebben we niet meer nodig'. Als iemand dus op je TSM inbreekt dan is het nog altijd foetsie backups.

Wil je het echt veilig doen, dan moet je dat ongeautomatiseerd doen met mensen die je vertrouwt. Want zelfs dan kunnen er tapes in de versnipperaar eindigen of in de tas van een collega mee naar huis worden gesleept.

Tapes hoef je niet in een taperobot te laten zitten.

Gewoon dagelijks/wekelijks/regelmatig een setje tapes laten maken door TSM, en die dan via koerier/medewerker naar bank/uitwijkcentrum/ander filiaal brengen.

IT Audit regel 2:

Worden de tapes geverifieerd en wordt het terugzetten van data vanaf tapes geoefend.

Ik snap niet wat er zo moeilijk aan is. 6TB past er op zo'n cassette van HP. Als je geen backups neemt ben je gewoon achterlijk en niet amateuristisch.

Je vult als bedrijf toch ook je belastingen in? "Ach ja, het was zoveel werk en we wilden ons concentreren op ons echte werk" gaat je niet ver brengen...

Wat kost dat?

Daar sluit ik me bij aan.
Met 'replication' and 'full fall over' kun je een heel eind komen met grootte hoeveelheden data.
Maar als je je dan wilt beschermen tegen inbraak waarbij alles gestolen of open gebroken wordt vervolgens net als in dit geval verwijdert moet je dus een keer een offline backup maken en op een fysiek andere locatie gaan leggen.

Maar ga maar dat maar eens regelen met een paar 100 TB aan data.
Moet je bijna een mobiele server hebben die je eraan hangt en weer los koppelt of hele grootte tape drives hebben en die met de hand gaan verwisselen. Want alles wat dan geautomatiseerd is kan ook weer gehackt worden en vernield.

Commvault bied bijv. Incremental Forever aan: een keer een full backup en dan altijd enkel incremental.

Tapjes wel goed opslaan

Ook backup-to-disk kan je offsite doen, denk bijvoorbeeld aan backup-to-cloud. Commvault heeft hier in ieder geval verschillende oplossingen voor, en hebben ook voorbeeld setups van complete data centers met offsite backup...

Onmogelijk? Nee, omslachtig? Eigenlijk hoeft dat ook niet zo te zijn....

Bij Bacula/Bareos kun je in ieder geval met disk van incremental automatisch een full laten genereren. Dit kun je ook op een ander medium laten opslaan, bijvoorbeeld een aparte disk of tape.
Naar aanleiding van dit incident denk ik erover na om exact dit te gaan doen. 2 nassen of andere disk-array's labelen en om en om meenemen naar een andere locatie als "poor mans off-site back-up".

Dat is leuk voor een middelgroot bedrijf, maar voor bedrijfjes met een paar man zal dat niet zo snel gebeuren. Backups worden meestal gemaakt voor falende hardware, niet rechtstreeks voor geraffineerde hackeraanvallen.

Om iemand gelijk weer voor amateur uit te maken gaat me persoonlijk wel erg ver. Er zijn overal wel een guidelines voor, zelfs om je kont af te vegen, wil niet zeggen dat je ze allemaal kan onthouden, laat staan kan implemeteren als klein bedrijfje door tijd of geld gebrek. Een bedrijf runnen bestaat niet alleen op het focussen van veiligheid en afwegingen moeten worden gemaakt. Heel soms heb je dikke pech, hoort erbij helaas.

Dat is leuk voor een middelgroot bedrijf, maar voor bedrijfjes met een paar man zal dat niet zo snel gebeuren. Backups worden meestal gemaakt voor falende hardware, niet rechtstreeks voor geraffineerde hackeraanvallen.

Backups worden gemaakt voor verlies van kostbare of gevoelige data. De grootte van het bedrijf of de oorzaak van het verlies doen er niet toe. Je data is belangrijk dus heb je een backup nodig. En wel eentje met een acceptabele garantie waardoor alle online diensten direct afvallen. Dat zijn bedrijven die kunnen komen en gaan. Zo kom je als je het mij vraagt nog steeds uit bij een fysieke offline backup in eigen beheer. Maar die hadden ze dus niet.

"backups worden gemaakt voor falende hardware" Is een leuke stelling, maar niet waar.

Denk aan:
-Per ongeluk 1 file weggooien. (user error)
-Per ongeluk een deel uit je systeem weggooien ( data uit je applicatie)
-Medewerker die express data kapot maakt.
-Test systeem dat backup data bevat.

Data snel en effectief ter kunnen halen vanuit je backup en kunnen bekijken, zonder je productie systeem per ongeluk te overschrijven is een essentieel onderdeel van je backup plan.

Goede vraag die je je moet stellen, wat gebeurd er als je vandaag je laptop/server uit het raam gooit. Hoe groot is dan je probleem. Als je zaak dan over de kop gaat dan mag je je backup strategy eens goed bekijken.

Dikke pech hoort erbij, maar dikke pech en over de kop gaan zijn 2 dingen.

hoe wil je hierop voorbereiden?

Je zegt het zelf al:

Ik heb ook op de zaak voornamelijk Back-up to Disk ipv Tape

Wel back-up to Tape gaan doen dus. Het is heel simpel eigenlijk. Een back-up-plan zonder off-line & off-site onderdeel mag geen back-up-plan heten.

Pff, lekker zeg. Daar ben je als ontwikkelaar dan afhankelijk van, en -niet- blij mee.

Als ik heel eerlijk ben heb ik het gevoel dat men "de cloud" grof onderschat, zowel MKB als particulier. Niet om ouderwets vast te willen houden aan fysieke back-ups maar "de cloud" is overal toegangelijk, maar evenwel vergangelijk.

Van velen hoor ik dat ze inmiddels al complete documentbibliotheken uitsluitend op DropBox, SkyDrive of soortgelijk hebben staan. Dat lijkt leuk, zo'n online back-up, maar wat men vaak vergeet is dat die online back-up lokaal een kopie heeft. En dat als alles online verwijderd wordt (per ongeluk of moedwillig), dit bij de eerstvolgende synchronisatie ook gebeurt.

Daarmee is het niet inherent onveiliger dan een enkele lokale schijf die kan crashen maar zeker niet automatisch veiliger. Hier blijkt dat de primaire data en back-up vanaf dezelfde locatie benaderbaar en beheerbaar waren. Daarmee loop je dus altijd een risico van "een grote wipe-actie". Ik begrijp wel dat Amazon geen backup-dienst aanbiedt op het Azure-platform maar het is absoluut van belang dat men zich goed realiseert waar de data is, waar de back-ups zijn en hoe het herstel plaats moet vinden in geval van disaster.

Overigens, meer direct op het artikel reagerend, vraag ik mij af of Amazone deze back-ups niet terug kan halen. Een soort schaduwfunctie van X dagen voor permanente verwijdering?

Edit
@ mathijs_kok hieronder:

Maar bij een goede cloud service (in elk geval bij Dropbox) is dat geen probleem omdat je die verwijderde file gewoon terug kan halen. Klik gewoon op Show Deleted Files en je probleem is opgelost.

Wat jij noemt is uitsluitend en alleen een functionele - en dus kwetsbare - oplossing. Als de techniek daarachter faalt, op welke manier dan ook, kun je NIET bij je bestanden. Het is absoluut valse veiligheid om te denken dat doordat Dropbox een history-functie heeft, je bestanden dus super veilig zijn.

[Reactie gewijzigd door Eagle Creek op 19 juni 2014 13:31]

Van velen hoor ik dat ze inmiddels al complete documentbibliotheken uitsluitend op DropBox, SkyDrive of soortgelijk hebben staan. Dat lijkt leuk, zo'n online back-up, maar wat men vaak vergeet is dat die online back-up lokaal een kopie heeft. En dat als alles online verwijderd wordt (per ongeluk of moedwillig), dit bij de eerstvolgende synchronisatie ook gebeurt.

Maar bij een goede cloud service (in elk geval bij Dropbox) is dat geen probleem omdat je die verwijderde file gewoon terug kan halen. Klik gewoon op Show Deleted Files en je probleem is opgelost. Ik zie files die ik in 2010 verwijderd heb en kan je terug halen. Dropbox bewaard zelfs verschillende versies.

Amazon kan dat zeker maar zal daar geld voor vragen. Deze broncode hoster was gewoon niet erg professioneel.

[Reactie gewijzigd door Anoniem: 120693 op 19 juni 2014 13:03]

Amazon kan dat zeker maar zal daar geld voor vragen. Deze broncode hoster was gewoon niet erg professioneel.

Maar is het niet zo dat er eigenlijk bij Amazon is ingebroken, ik kan het verkeerd begrijpen natuurlijk.
Als dat zo is zou het vreemd zijn dat Amazon geld vraagt voor het oplossen van hun eigen fout.

Nee, de hacker is in het systeem gekomen via login en password, da's dus geen fout van Amazon (zoals ik het begrijp iig) maar van Code Spaces zelf.

Dat van die 'backup' login snap ik dan weer even niet maar ok...

Maar bij een goede cloud service (in elk geval bij Dropbox) is dat geen probleem omdat je die verwijderde file gewoon terug kan halen. Klik gewoon op Show Deleted Files en je probleem is opgelost. Ik zie files die ik in 2010 verwijderd heb en kan je terug halen. Dropbox bewaard zelfs verschillende versies.

maar als je nog steeds bij je verwijderde items kan dan zijn ze toch niet verwijderd?

en daar kan je ook op permanently delete file drukken, en dan is het alsnog echt weg. dat is dus, in ieder geval bij een hacker aanval, geen substitutie voor een off-line back-up.

Pff, lekker zeg. Daar ben je als ontwikkelaar dan afhankelijk van, en -niet- blij mee.

Ben eigenlijk wel benieuwd wie nu wat echt kwijt is. Ik zie dat ze GIT en Sub Version hosten. Er zit daar een enorm verschil tussen.

Als een ontwikkelaar GIT gebruikt dan heeft hij vast op zijn eigen systeem een werk kopie. Nu is GIT altijd een volledige set, inclusief alle historie. Als ik als ontwikkelaar bijvoorbeeld een clone van de Linux Kernel GIT repository ophaal dan bevat mij lokale GIT repository precies het zelfde als de officiële repository. Kortom, de werk kopie kan master worden en je hebt alles nog, inclusief historie.

Als een ontwikkelaar Sub Version gebruikt dan is hij de sjaak. SVN is centraal beheer van versies en een eventuele werk kopie is 1 versie en kan ook maar een deel van het product zijn. Je SVN repository missen is een enorme aderlating.

Ben benieuwd of dit nog gaat mee spelen in de fall-out van dit incident. Het verschil tussen centraal en decentraal versiebeheer wordt in zo'n geval wel heel pijnlijk duidelijk. Natuurlijk kun je ook met GIT al je data verliezen, maar het is wel een heel veel moeilijker, zeker voor projecten waar nog volop aan het ontwikkeld wordt.

Als jij een cloud dienst gebruikt voor je backup, en de cloud dienst blijkt zijn data kwijt (met wat voor reden dan ook), dan ben je klaar, en maakt dat technische detail niet meer uit.

Je moet dus altijd een plan B hebben als de cloud dienst kapt met zijn dienst of omvalt.

Als je een Cloud dienst gebruikt voor backup is er niets aan de hand. Een backup is een reserve kopie, als je een reserve kopie kwijt raakt heb je altijd het origineel nog. Uiteraard ben je dan wel het vertrouwen kwijt en moet je als de bliksem een nieuw backup regelen, maar je bent op dat moment nog niets kwijt.

Wat jij bedoeld is bewaren in de cloud. Dan heb je dus zelf niet het origineel en is dat je enige versie. Zoals sommige bij Mega hadden toen die in beslag genomen werd. Dan ben je dus je data kwijt als er iets met die opslag gebeurt.

Maar ook daar moet je niet alle services op één hoop gooien. Bijvoorbeeld Microsoft Azure heeft altijd 2 life kopieën die in sync worden gehouden en 2 backup kopieën. En als je er voor betaald in 2 verschillende data centers op verschillende locaties. Daar durf ik wat dat betreft best mijn data op te bewaren. Alleen jammer van de NSA met die lange vingers die nergens van af kunnen blijven, maar dat is een ander verhaal.

Bij veel cloud services staat de data veiliger dan in je eigen gehuurd server in een data centre of eigen storage.

Maak je maar meer zorgen over MS zelf. Er zijn gevallen Waar microsoft een account heeft geblokkeerd. (false positeive?) waar je vervolgens niet door de support heen komt. Alles achter 1 account gooien (ook al staat het in 2 data centers) is dus niet verstandig.

Dat is precies waar het met dit bedrijf fout gegaan is. Alles was op Amazon gezet, toen het account daar gehackt was ging het bedrijfje over de kop.

Edit
@ mathijs_kok hieronder:

[...]

Wat jij noemt is uitsluitend en alleen een functionele - en dus kwetsbare - oplossing. Als de techniek daarachter faalt, op welke manier dan ook, kun je NIET bij je bestanden. Het is absoluut valse veiligheid om te denken dat doordat Dropbox een history-functie heeft, je bestanden dus super veilig zijn.

Inderdaat, als je de geschiedenis van de geschiedenis ook verwijderd, dan is je data gewoon simpelweg weg.

.. "de cloud" is overal toegangelijk, maar evenwel vergangelijk.

Wellicht heet het daarom ¨cloud¨.. Kan zomaar verdampen.

hoe wil je hierop voorbereiden?

Ik heb ook op de zaak voornamelijk Back-up to Disk ipv Tape.. Dus een Hacker zou ook zomaar al mijn VM's en zooi weg kunnen gooien mits deze toegang zou hebben tot de systemen..

Daarom is het ook geen Backup maar een kopie. Backup is off-line en off-site. Opgeslagen in een geconditioneerde omgeving.

Met de huidige technologie kan er veel. Maar on-line "backup's" zijn geen backups maar snapshots, restorpoints, replica's van bestaande data. Handig voor een snelle restore. Maar een fysieke backup ligt op een andere locatie en is alleen te benaderen doormiddel van fysieke toegang.

Sorry, als je goed kijkt om je heen. en zeker de wat grotere bedrijven. Hebben die amper meer back-ups naar Tape..

Back-up is gewoon een kopie van data, of het nou op een tape staat of op hardeschijven of in de cloud..

Back-up naar disk is net zo veilig als naar tape.. Daarnaast heb ik vaak meegemaakt dat een tape toch net te beschadigd was voor het restoren van DATA..

Ja ik ben het met je eens dat je een goede back-up strategie nodig hebt voor bveiliging van je data.. Zoals niet alles op 1 locatie opslaan..

Back-up's zijn meer dan alleen naar Tape of Disk, er komt meer bij te kijken. Maar om nou te zeggen dat alles naar Tape opslaan de oplossing zou zijn geweest? Leuk je hele sharepoint omgeving inc DBA enz naar Tape opslaan als je 1000 sites hebt en honderden TB aan data hebt staan.. dan heb je het nog niet eens over mail servers en andere data. Dan is opslaan naar Tape echt niet te doen en zeker niet meer te handelen. naar Disk opslaan in een secondaire datacenter toch een stuk efficiënter en goedkoper..

Ik ken nog genoeg bedrijven waar alles op tape gaat en daarna geheel fysiek offsite. Met de huidige technologie worden er tegenwoordig vaak snaps gemaakt naar een tweede SAN welke op een andere locatie staat. Voordeel is dat je op je hoofdsite bijvoorbeeld maximaal een uur terug hoeft en op de uitwijklocatie bijvoorbeeld 4 uur (afhankelijk hoe je het wilt en hoe veel geld je wilt besteden). Met NetApp bijvoorbeeld werkt dit perfect. Daarnaast wordt gewoon iedere dag een een backup op tape gezet van bijvoorbeeld de laatste snap van een dag. Die tapes gaan off-site en komen pas na 4 weken of langer weer on-site, zo kan je gewoon met maximaal 1 dag dataverlies terug van snap of tape. Daarnaast hebben een aantal sectoren de verplichting om jaarbackup's nog ten minste 7 tot 9 jaar te bewaren. Met tape gaat dat perfect.

Voor een aantal (grote) zorginstellingen hebben ze (persoonlijk ingericht) de volgende situatie:
1 uur onsite (maximale dataverlies),
2 uur tweede site (maximale dataverlies),
dag tape (maximaal 4 weken terug),
maand tapes (tot 12 maanden terug),
kwartaal tapes (tot 48 maanden terug),
jaar tapes (tot 9 jaar terug).

Een backup op tape is namelijk meer dan alleen recovery. Het wordt ook gebruikt om bijvoorbeeld bij een controle een boekhouding van 5 jaar geleden terug te zetten, die je normaliter niet meer on-line hebt maar wel op andere media. Daarnaast komt het met professionele tape systemen voor dat een backup van 8 jaar oud niet is terug te zetten, als je goedkope meuk gebruikt, zoals DDS in het verleden ja, dan heb je een probleem, maar heb zelf nog DLT's van meer dan 10 jaar oud waarvan de tapes te lezen en te beschrijven zijn, even als oude Exabyte media van meer dan 10 jaar.

Boekhouding op tape-only is erg gevaarlijk. Ik heb genoeg tapes gehad die het niet meer deden na zeg 2 jaar..

Een tape is een back-up geen data opslag. Je probeert met een back-up zo min mogelijk data verlies te hebben na een disaster.

Boekhouding moet voor bedrijven min 5 jaar terug te halen zijn. je zult dus altijd 5 jaar aan boekhouding bij de hand moeten hebben. En niet dat je achteraf nog eens opzoek moet gaan naar tapes als de belasting die met een onaangekondigde controlle ineens op je stoep staat!

Maar wat ik zeg.. Belangrijke data mag nooit en nimmer alleen op 1 medium staan.. op Tape en disk of disk en disk kans is kleiner dat 2 mediums tegelijk defect raken dan 1 medium.

Voordeel van san naar san op andere locatie is dat de data op 2 plekken staat, en snel bij je data kan komen! andere manier is van Disk naar disk en wekelijks nog een tape. dan heb je de data nog steeds op disk staan. gaat het back-up cabinet (san) defect. kan je altijd terug vallen op tape..

"hoe wil je hierop voorbereiden? "

Door bijvoorbeeld ook werkelijk de beloofde off-site backups te maken...
Ze hebben blijkbaar niet helemaal begrepen wat een off-site back up is of hebben helemaal geen off site back ups gemaakt.

Off Site backup hoeft niet te betekenen offline backup.

Via Amazone kan je perfect een offline backup hebben aan de andere kant van de wereld. Enige nadeel, alles wordt nog steeds vanuit 1 management console beheerd en kan dus gemakkelijk verwijderd worden.

Je hebt gelijk. Denk dat ik in de war was met vroegah toen de enige manier voor grote bedrijven (met veel data) om een off-site back up te maken was door hun opslag fysiek te kopieren en met een vrachtwagen naar een off-site locatie te verschepen. Dat was dan per definitie off-line.

Het grote voordeel van een echte offline backup is dan natuurlijk dat deze door niemand kan worden overschreven. Een backup offsite maar wel online is makkelijk, snel en simpel, maar dus ook door iedereen met admin rechten te benaderen en te verwijderen. Dat was met tapes niet gebeurd...

Terug naar dit bedrijf - het is natuurlijk sneu dat een hacker hun volledige business om zeep helpt. Aan de andere kant wordt zo wel het kaf van het koren gescheiden. Bij brand was wellicht hetzelfde gebeurd: er is over nagedacht, maar het backup plan is nooit echt getest...

Bij brand niet cloud he als de gehele wereld in de fik staad of de zon red giant wordt.

Brand fik is locaal. Moet amazon wereld wijd tot de bunkers affikken.

Dit is een hacker met nogal admin rechten had en dat is het probleem.

Hoe kan je dit voorkomen nou eigenlijk niet. En voor klanten heb je al afgedaan als je broncode publiekerlijk in bezit zijn van een hacker.
Maar wissen van alles tot backups aan toe ivm afpersing. Daar kan wel iets aan gedaan worden.

Door offline backup zoals tapes ( externe USB opslag kan ook ) in vault opgeslagen.
Voor brand is een andere lokatie belangrijk.
Wan mijden een directe verbinding met de andere lokatie.

Beide lokaties moeten van WAN gescheiden zijn dat nog beter. Wan helemaal mijden.

Wan deel en offline netwerk met tapes.

Lekker veilig maar je maak het gemak van netwerk te niet.

Ten eerste heb je ook werk personeel die moeten googelen met tapes door het berdijf en andere locaties.

VPN is tussen oplossing.

Zelfs vond ik het vroeger veel fijner dat je voor bankzaken met je telefoon modem inbeld bij de bank.
Nu via internet geeft mij toch wat minder veilige gevoel.
En doe het liever op ipad. Dan op mijn PC.

TurtoiseSVN wil ik servertje locaal gebruiken niet in de cloud.
Heb windows server 2012 R2 essential. Als WHS.

Zoals ik begrepen heb is voor veiligheid belangrijk dat je minstens je zooi op 3 backups hebt.
Ook op minstens twee locaties en gescheiden apparatuur.

En met zulke afpersende cyber crimies ook offline.

Voor thuis gebruik is cloud wel te doen als buiten locatie backup.
Meer voor brand. Een stoelendans met paar externe tapes.

Maar ja deze cybercrimies gaan voor bedrijven die soms wel grote afpers bedragen kunnen betalen.
Home netwerken zijn niet zo interresant.

Dan is het dus niet off-site. Of in ieder geval niet afdoende. Off-site betekent niet alleen 'niet op dezelfde fysieke locatie' maar ook 'niet (of alleen read-only) in hetzelfde netwerk als de originele data'

Een goede backup betekent voor mij dat:

1) De backup op een fysiek andere locatie staat.
2) Er een geschiedenis bewaard wordt om bij fouten niet de (enige) backup te vernietigen.
2) NIET benaderbaar is vanuit de te beschermen omgeving.

Dit laatste punt klinkt vreemd en tegenstrijdig maar is heel gemakkelijk te bereiken door de backup server de backup te laten initiëren bij het origineel en niet andersom. Op deze manier heb je voldoende bescherming tegen zowel fouten als kwade wil...

2) of eigenlijk 3 (moeilijk he tellen ; ) )

Door de zelfde persoon.....

Als 1 persoon dezelfde bij dezelfde produktie gegevens kan, en alle backups, en die kan deze op het zelfde moment affikken, dan heb je hetzelfde probleem als in het artikel.

Door het archiveren van de backups bij iemand anders te beleggen(dat kan heel goed een operator zijn), is dat al afgevangen, zolang niet iedereen de sleutel van de kluis weet te vinden.

"hoe wil je hierop voorbereiden? "

Door bijvoorbeeld ook werkelijk de beloofde off-site backups te maken...
Ze hebben blijkbaar niet helemaal begrepen wat een off-site back up is of hebben helemaal geen off site back ups gemaakt.

De enige manier waarop je dat tegen kan gaan is door werkelijk offline backups te maken, dus met media die niet automatisch kan worden gewisseld. Een tape-robot is dus niet genoeg, je zal een mannetje nodig hebben die de tapes zelf uit de drive trekt en ze in een kluis opslaat. Of gebruik maken van write-once media zoals DVD-R's.

Zolang het systeem op afstand toegankelijk is om te beheren, is het ook op afstand te wissen. Een tape-robot kan ook de opdracht krijgen om alle backups te wissen.

Ja, je hebt gelijk. Was wat in de war met off-site off-line backups waarbij er off-line media off-site bewaard wordt.

Als je files off-site in de cloud staan is de juiste wijze daarvan een lokale versie te hebben die niet door dezelfde mechanismen gecontroleerd worden.

ofline-backups misschien, komaan dit is gewoon kinderlijk slecht bedacht en uitgevoerd.

verder weet je de motieven hier niet van, stel dat er gestolen broncode stond, of of of...
dan nog is het niet goed te praten, maar als je zo zwak bent uitgerust verdien je het gewoon...

Ahaa, dus:

• Als jij de mensen niet in dienst hebt
• De kunde niet hebt
• De middelen niet hebt
• Het niet in je huidige plaatje past van liggende architectuur
• Je de urgentie er op elk gegeven moment niet van in zag
• Je dienst zo hard groeide dat bovenstaande nog niet aan de orde is gekomen
• Je voor een onverwachte enorme opgave komt te staan waarin je zelfs met al dit bovenstaande niet in staat bent om een oplossing te verzinnen

Mag van jou een dienst gewoon omvallen.

Ik zal je zeggen, dat als we jou 'plan' aan zouden houden er bar, maar dan ook BAR weinig bedrijven over zouden blijven.

De mensen niet hebben én de kunde niet hebben én de urgentie er niet van inzien, klinkt mij als een behoorlijk prutsbedrijf, zeker als het faalt op exact de dienst die het claimt aan te bieden! Terecht dus dat dit bedrijf omvalt.

We weten ni hoe ze zijn binnen geraakt. Dat ze de mensen of kunde niet hebben is dus al foutief. De urgentie hebben ze ook ingezien daar ze onmiddelijk hun logins veranderd hebben, maar blijkbaar was zelfs dat onvoldoende (God weet waarom).

Tegen een DDOS kan je niet veel beginnen, en als je probleem diep in je systeem zit haal je de fout er ook niet zomaar uit.

Het werk waar je veel tijd in gestoken hebt zo zien verloren gaat kan alleen maar veel pijn doen volgens mij. En ik wens dat niemand toe.

Wie weet is het gewoon een ex/medewerker die van binnen alles naar de kl*te heeft gebracht. Je kan alles super gedaan hebben, maar als je een rotte appel in je team heb zitten kan dat allemaal voor niets geweest zijn.

Laten we voorop stellen, dat hacken strafbaar is gesteld en in dit geval zelfs als misdrijf. Daarbij komt nog afpersing. (een heel misselijk misdrijf)
Nu leef ik echt wel in 2014, maar het in natuurlijk van de ratte, dat je je als bedrijf aan alle kanten super moet beveiligen, zodat criminelen niet de kans krijgen je bedrijf om zeep te helpen.

Je woont in een huis wat meer dan gemiddeld is beveiligd. Moet je het dan ook maar "een knappe kunst vinden" als je hele inboedel wordt weggehaald, als je een dag weggaat?
Een hacker hoe slim dan ook zal ik ten alle tijden verachten. Net als andere criminelen.

Niek

Inderdaad.
Dat ik niet met een M4, dragon armor, een bom vest en een chastity belt rondloop betekent toch niet dat ik maar mag accepteren dat ik op elk moment aangevallen kan worden en het loodje leg.

Hetzelfde geld voor een bedrijf. Je moet een reële inschatting van je risico's maken en daar op acteren. In deze context lijkt mij dat dit bedrijf dat niet heeft gedaan, maar wederom vindt ik het van de zotte dat:
A -> dit schijnbaar nodig is, dat je je daar tegen indekt.
B-> dat het bedrijf om valt daarom ongeacht hoe de bedrijfsvoering was gewoon omvalt door zo iets.

Kijk als ik nu Rusland of Noord Korea binnen loop en allerlei dingen ga scanderen en ga dreigen mag ik verwachten dat er iets gaat gebeuren. Maar als ik toch een bedrijfje start met mijn beste bedoelingen, het internet op ga en toch zeker wel wat zaken heb gedaan om te proberen mijn bedrijfsvoering deugdelijk op te bouwen. Mag ik toch zeker wel verwachten dat ik gewoon door kan gaan en mijn klanten kan bedienen.

De mensen niet hebben én de kunde niet hebben én de urgentie er niet van inzien, klinkt mij als een behoorlijk prutsbedrijf, zeker als het faalt op exact de dienst die het claimt aan te bieden! Terecht dus dat dit bedrijf omvalt.

En daar ben ik het dus totaal niet mee eens. Je moet toch ergens mee beginnen? Je kunt toch niet alles vanaf dag 1 op orde hebben. Je begint toch met een idee, een hobby, een visie. Dan koop je een servertje. Gaat daar op verder. En gaande weg kom je toch ergens?

In jou filosofie, zou elk startend bedrijf meteen zowel vanuit industrieel, medisch en militair oogpunt zowel veilig, stabiel en bekwaam moeten zijn dat dit soort dingen niet kunnen gebeuren.

Ik zal je uit de droom helpen. Zelfs al heb je all het geld van de wereld en alle knappen koppen. Er is maar 1 gram zand nodig om alles te verknallen. 1 Klein dingetje wat finaal mis gaat en zoveel schade veroorzaakt dat je bedrijf gewoon om valt.

En naar mijn mening moet je je tegen dat risico beschermen en niet proberen alles af te dekken. Je bedrijfsvoering afdekken zodat het als je een gedeelte verliest verder kunt.

Daarin is dit bedrijf in mijn aanzien nalatig geweest. Wederom vindt ik echt jammer dat ze om vallen en dat klanten hier ook de dupe van worden. Het is ook jammer voor een opkomende technologie als Cloud, want het creëert banen en mogelijkheden.

Maar als dit soort zaken vaker voor komen zul je zien dat deze gloednieuwe markt word verpest omdat men nog steeds met de angst zal leven dat techniek zo lastig is, duur is, gevaarlijk is en onbetrouwbaar is.

Inderdaad onkunde mag omvallen en het betere bedrijf overleven. Alhoewel dit soort zaken vaak meer te maken lijken hebben met "commerciële oorlogsvoering" en dat hackers ingehuurd worden om concurrenten en potentiële concurrenten uit de weg te ruimen.

Maar ik denk dat dit maar weer een mooi voorbeeld is van de nadelen van alles-in-één cloudservices. Alles wat je zelf niet in de hand hebt, heb je dus ook daadwerkelijk niet zelf in de hand en ben je volledig een speelbal van de services van de provider. Je zult zelf over dingen moeten nadenken om dit te voorkomen.

Amazon zelf is niet gehacked. Ik heb zelf genoeg 'meegemaakt' om hier niet schijnheilig Code Spaces te beschuldigen, maar in principe is een VM redelijk analoog aan een fysieke machine. Als je daar op de 'verkeerde' plek binnen bent kun je ook aardig wat schade aanrichten.
Amazon zal hoogstwaarschijnlijk wel de mogelijkheid hebben om back-up omgevingen qua beveiliging compleet los te trekken van de live omgeving. Maar..

Via back-up-logins kreeg hij opnieuw toegang

Dit lijkt dus ook het geval te zijn, waardoor de aanvaller waarschijnlijk een (ex-) beheerder is, of de credentials daarvan te pakken heeft gekregen.
Ik moet bekennen dat tapes in een offsite kluis veiliger zijn, maar er AFAIK maar weinig bedrijven die dat nog doen.

[Reactie gewijzigd door thegve op 19 juni 2014 22:19]

Ze bieden boden een veilige data-storage dienst aan met een redundantieplan (proven to work!)... Als je dan dit laat gebeuren ben je toch echt wel slecht bezig.

[Reactie gewijzigd door Cilph op 19 juni 2014 12:10]

Veilig in welke vorm? Tegen hardware falen of hackers? Dat zijn twee totaal verschillende dingen. Aangezien je het hebt over een redundantieplan lijkt het me te gaan om hardware falen (oftewel, dataverlies door schade of uitval). Moedwillig alle data wissen valt daar niet onder lijkt me. Want een offline backup zou lang niet zoveel mogelijkheden bieden als je echte zekerheid en realtime data wilt hebben. Maar een online backup is mogelijk toegankelijk als je systeem gehackt wordt. Dilemma's!

Al hun backups waren bij Amazon ondergebracht.

Lijkt me ook niet zo vreemd. Je bied een webdienst aan en plaatste je backups in de cloud waar ze veilig staan tegen hardware falen. Het enige waar ze niet veilig tegen zijn is een hacker die achter je login gegevens komt. Die kan gewoon alles wissen wat hier gebeurd is. Om dat tegen te gaan moet je ofwel op alle diensten andere login gegevens gaan gebruiken danwel voor offline backups zorgen.

Offline backups zijn wel aan te raden inderdaad. Zeker in een cloud omgeving waar je allemaal niet weet wat er kan gebeuren. Helaas laten niet alle cloud diensten toe dat je je data op een handige manier backupt. Maar hier moet het geen probleem geweest zijn. Slordig.

Ik snap ook niet dat Amazone geen retentie heeft na het verwijderen van een Back-up.. Zodat de data nog 2 weken ergens wordt geparkeerd..

Daarnaast is het vreemd dat een externe toegang heeft kunnen krijgen tot de amazone wachtwoorden. ook na het aanpassen van het wachtwoord.. Ik zou persoonlijk dan op een andere machine mn wachtwoord aanpassen dan achter mijn eigen productie machine die misschien niet zo veilig meer zo is. Ook contact opnemen met amazone lijkt dan op de plaats om dingen te bevriezen!! zoals wegnemen van alle admin rechten en overdragen naar een ander account...

Heeft Amazon dan zelf geen fail safe tegen hackers als ze de beheer console binnen zijn dat binnen de een bepaalde termijn altijd een backup is van de klant ?

Ik heb ook op de zaak voornamelijk Back-up to Disk ipv Tape.. Dus een Hacker zou ook zomaar al mijn VM's en zooi weg kunnen gooien mits deze toegang zou hebben tot de systemen..

Nou, dan heb je je zaken dus niet voor elkaar.

Maar het geeft niet. Er zijn wel meer mensen die 'offsite' en 'offline' door elkaar halen.

Maar 'offline backups' zijn toch vele malen veiliger tegen wissen omdat de hacker het niet zomaar even vanaf zijn zolderkamertje kan doen. Hij zal er toch echt langs moeten gaan om de offline storage media mee te nemen en te vernietigen.

Er zijn wel meer mensen die de virtuele wereld en de werkelijke wereld niet helemaal goed uit elkaar kunnen houden.

Er zijn zat manieren om je hierop voor te bereiden. Als iemand letterlijk alles kan verwijderen dan is je systeem niet veilig genoeg en vang je niet alles goed op. Zelfs onze (lees:bedrijf waar ik werk) core-zaak is niet eens data, en toch is ons gehele systeem 10x beter dan dit bedrijf waar data alles betekend.
Als je dan letterlijk alles kunt verwijderen, en je hebt nergens iets meer staan dan is dat een zeer trieste zaak.

Je moet er per definitie uitgaan dat iemand in je systeem kan komen. Vanuit dit punt moet je gaan beredeneren hoe je dit gaat afvangen. Hier zijn dan weer zat oplossingen voor, iets wat dit bedrijf niet goed heeft geregeld en nu zijn ze failliet.
Los van dat is het gewoon bizar dat iemand zo ver in je systeem kan komen... Ik weet niet eens waar ik moet beginnen over hoe of wat, maar zover ik het nu kan zien heb ik zelfs voor mijn VPS een dikkere beveiliging erop zitten...

Als je backup to disk hebt, waarom dan geen backup to tape erbij? Denk aan een incremental forever, kost je amper tapes, maar geeft je wel een volledige recovery van tape...!

Zeker voor een belangrijke omgeving lijkt mij dit toch wel een must have....

redundencie, reguliere pentests, forensics readiness scans?

2 way authentication.
Dedicated login IP's.
goede security policy -> maarja het is bekend dat bedrijfen niet willen/kunnen investeren hierin.

Good old off-site off-line backups: tapes in een kluis.

Het blijkt hier heel mooi dat je met welke online-tool dan ook heel veel kan controleren maar zo af en toe een offline backup is zo slecht nog niet,

Prive heb ik 2 externe disks en draai ik zo af en toe (okee.. 2 keer per jaar) een backup naar een disk die daarna offline bij mijn schoonmoeder in de kast gaat. De disk die daar tot dan toe lag, komt terug, krijgt ee update en gaat als off-line on-site backup aan de andere kant van het huis.

Vrij simpel: een backup-systeem waar je productie-servers enkel backups kunnen pushen, en niet verwijderen/veranderen/overschrijven/ophalen/etc.

Een dergelijke basisconstructie was hier blijkbaar niet eens aanwezig.

Je hebt als host gewoon meerdere contingency plans. Hardware falen, aanvaller van buiten het systeem, aanvaller van binnen het systeem (om kort door de bocht te zijn). Dit bedrijf was blijkbaar niet voorbereid op een aanvaller binnen het systeem. Verschrikkelijk omdat Code Spaces juist een soort backup was voor de code van heel veel projecten. Hopelijk hebben de gebruikers zelf wel een soort van contingency plan.

Verder vraag ik me ook af wat zij met off-site back-ups bedoelen? Alleen hun Amazon account was compromised. Hadden zij via Amazon op een andere locatie ook back-ups? (De term off-site is dan questionable aangezien het om cloud services gaan die sowieso niet echt een locatie hebben).

Amazon bied standaard de mogelijkheid om diensten af te nemen in verschillende datacentra binnen 1 region ( bijvoorbeeld Europa, Azië ) of in verschillende regions.
Daar koop je alleen weinig voor in dit geval als je daar met dezelfde credentials bij kunt of als alle credentials in het bezit van de aanvaller zijn.

waarom zou een backup systeem 24/7 aan het internet moeten hangen ??.. sorry hoor maar dan vraag je der ook zelf om...

waarom niet gewoon om de week / maand zelf een netwerkje in je bedrijf leggen en nee niet verbonden via het internet en dan gewoon ffe snel de gegevens overzetten en de netwerkje weer afschakelen en laat ieders zn ding doen beetje jammer hoor eigen schuld zeg ik dan maar...

Men had al aangetoond dat ze in de console konden, door daar een bericht achter te laten voor contact op te nemen. Als je dan als grote firma gewoonweg enkel je paswoord wijzigt, ben je gewoon dom en is het 99% je eigen schuld.

Men had de allerlei zaken kunnen doen op dat moment, maar dat deden ze niet.

Wat moet je dan doen? Je project gewoon offline halen? Als je niet weet hoe ze zijn binnen geraakt is het verdomd moeilijk je er tegen te wapenen. Als men dan, voordat je de oplossing hebt, heel je dienst gewoon onderuit haalt dan is dat einde verhaal.

Als het je tonnen kan gaan kosten moet je eens gaan nadenken over een betrouwbaarder backup systeem. MIsschien toch maar offline backups dan.

Gescheiden backup? Inderdaad kinderachtig hackers actie, maar als bedrijf nog dommer om de backups niet te scheiden van de realtime data. Zeker als je daar mee adverteert....

Offline backup.
Dat doe ik thuis zelfs.
Op werk backup in de kluis of mee naar huis en thuis in de kluis.
Zo simpel is het mensen.

Amateurisme ten top.

Als ze mazzel hebben kan amazon nog wat tevoorschijn toveren.

In principe ligt het probleem hier bij amazon. Hun toegang schijnt niet goed beveiligd te zijn. Hoe anders kan zo'n hacker toegang krijgen tot die login gegevens (dat ligt toch echt bij amazon). En DDoS is in principe ook iets dat bij het datacenter dan wel de cloud hoster voorkomen moet worden. Zij adverteren er dan ook vaak mee dat je veilig bent voor dat soort aanvallen. Ook daar kon het bedrijf dus moeilijk weinig aan doen

Het uiteindelijke probleem is het ontbreken van een back-up. Je weet dat er een moment komt dat je wordt gehacked, of je eea nou uitbesteedt of niet.

Soms is je data te groot om te backuppen.

Oracle T10000D tape drive, 8.5TB native op een tape. Compressie er overheen, ergens tussen de 13 en 16TB op een tape. Wat nou te groot??

12 stuks en je hebt 100TB+ simultaan :-)

En tape gaat langer mee dan de drives ;-) Nothing beats tape

Ok, misschien wel (al geloof ik er niets van)

Maar communiceer dat dan ook naar je klanten, en verzeker hen zeker niet van het tegendeel.

Te groot om te back-uppen betekent gewoon dat je een andere opslag oplossing nodig hebt.
Of denk je dat Microsoft en Google niet aan back-ups doen?

Gewoon een kwestie van juiste media en parallellisatie van het maken van een backup. Er zijn tape systemen waarbij je gewoon TIG-TB's op tape blaft in redelijke tijd. Wanneer je werkt met een snapshot/clone/replica die je op een andere storage array zet. Dan kan je die rustig op tape gooien gedurende de komende 24 uur. Daarnaast voldoende drives en je zet 100+ TB in 24 uur op Tape. En die Tape sla je in een kluis op.

Neen, het kan wel niet waardevol genoeg zijn om te backuppen.

Hoezo niet goed beveiligd: multi-factor authenticatie is bij AWS echt wel standaard in te stellen.

Ook kun je beheerders verschillende rechten gaan geven, zodat ze niet aan alles aan kunnen.

Ik vraag me wel af hoe ze binnengekomen zijn...

AWS biedt uitgebreide mogelijkheden om authenticatie heel nauwkeurig in te stellen en te beveiligen, maar het is niet verplicht. multi-factor is beschikbaar, evenals de mogelijkheid aparte gebruikerslogins en API-keys te maken voor zeer specifieke delen van de API en Console. (zie http://aws.amazon.com/iam/)

Extra authenticatie maakt het natuurlijk omslachtiger om operationele werkzaamheden uit te voeren dus zijn er helaas veel bedrijven en individuen die het niet zo nauw nemen met het scheiden van verantwoordelijkheden. Pas als het mis gaat is het gevaar plots duidelijk.

Je kan meerdere API keys maken die elk maar bepaalde rechten hebben. Je kan dan voor backup een andere api key gebruiken die geen toegang biedt tot productie systemen.
Het was prima te voorkomen.

Ja dat is zo.
Echter dat een bedrijf hier niet op voorbereid is, is natuurlijk ook wel zielig bezig!

Helaas loop je altijd achter de feiten aan. Je kan je ergens pas tegen beveiligen als je weet dat het een gevaar is.

Om een bedrijf zo tengronde te richten ben je wel heel erg zielig bezig.

Klopt, maar al je eieren in 1 mandje leggen is nooit een goed plan. Offsite
backups had hier de redding kunnen zijn. Ik vraag me af of dit een acceptabel
risico was bij Code Spaces, of dat hier nooit over is nagedacht.

En als bedrijf in 2014 moet je toch eens serieus gaan nadenken over mogelijke mitigatie
tegen DDOS aanvallen als je een groot doelwit bent.

"en offsite backups zijn gedeeltelijk, dan wel volledig verwijderd"

Hiermee ben je natuurlijk wel tegen bijv een datacenter brand beveiligd, maar als diezelfde backups nog steeds via dezelfde interface beheerd worden, kun je ook die verwijderen natuurlijk...Dan zou je dus op een fysiek andere locatie met andere credentials op moeten slaan...en dan maar hopen dat die credentials niet op dezelfde wijze toch achterhaald kunnen worden...

Dit soort hackers verdient inderdaad een plkje in de hel...zelf niks mee opgeschoten en tig anderens (levens)werk verpesten...en financieel duperen

"Dit soort hackers verdient inderdaad een plkje in de hel...zelf niks mee opgeschoten en tig anderens (levens)werk verpesten...en financieel duperen "

Meh, dit soort hackers zijn een noodzakelijk kwaad om de brakheid van netwerkbeveiliging bloot te leggen.
Wij gaan als maatschapij veel te gemakkelijk om het het gegeven computernetwerken.
Eigelijk wil iedereen 'dat het gewoon werkt' zodat ze hun dingetje kunnen doen maar de werkelijkheid is veel comlpexer. Niemand wil die werkelijkheid in de ogen kijken en een groot deel van het internet opereert onder het mom van 'Het gaat goed zolang het goed gaat en als het misgaat dan zien we dat dan wel weer'.
En dan is het dus niet zo gek dat de 1 na de ander neergehaal wordt.

Nee, het is niet noodzakelijk om bedrijven af te persen en backups weg te gooien om aan te tonen dat de beveiliging niet op orde is. Dat is echt bullshit. Dat is niet noodzakelijk, dat is gewoon een misdrijf met een potentieel enorme impact.

Ja, mee eens dat het een misdrijf is.
Maar helaas maakt dit juist duidelijk wat de gevolgen zijn van onze netwerksamenleving en hoe slecht wij geneigd zijn om te gaan met het fenomeen beveiliging.
Ik vind code spaces hier deels voor medeverantwoordelijk. Als ook amazon.

Het probleem is dat de put niet wordt gedempt als er niet opzichtelijk een kalf verdronken is. Verdrinkt er een klaf maar wordt het niet groots door de media opgepakt dan wordt er vaak liever gekozen om het voorval onder het kleed te schuiven in plaats van het probleem op te lossen want dat scheelt weer centjes.
Er moet dus te vaak eerst een groot genoeg incident plaatsvinden voordat er wordt nagedacht over de beveiliging.
En daarom vind ik, hoe ongelukkig ook, deze hack enigzins een goede zaak.
Nu weten mensen tenminste beter wat ze wel of niet kunnen vertrouwen.

Met zo'n instelling moet elke woning voortaan met gewapend glas, 3 puntssloten en alarmsysteem uitgerust worden en als je dat niet hebt is het je eigen schuld dat er is ingebroken...zo werkt de wereld niet natuurlijk he...degene die het misdrijf begaat is nog steeds fout, niet degene die de medemens (te veel) vertrouwd...alleen werkt het digitaal wel bijna omgekeerd en is dat maatschappelijk geaccepteerd en krijgt degene die een inbraak niet succesvol heeft weten te voorkomen de schuld (terwijl dat eigenlijk altijd achter de feiten aanlopen is met lekken)...blijft toch een aparte redenatie al zie ik de noodzaak er wel van in...maar uitspraken als "dit soort hackers zijn een noodzakelijk kwaad om de brakheid van netwerkbeveiliging bloot te leggen." slaan nergens op...jij doelt op iemand die de moeite had genomen het bedrijf zelf in te lichten en eventueel verbeteringen had aangedragen.

"Met zo'n instelling moet elke woning voortaan met gewapend glas, 3 puntssloten en alarmsysteem uitgerust worden en als je dat niet hebt is het je eigen schuld dat er is ingebroken..."

Nee, want de echte wereld werkt niet zoals computers.
En voor de duidelijkheid, ik praat het criminele gedrag van de hacker niet goed. Ik zeg alleen dat het hopelijk een voorval is die mensen ertoe beweegt beter met veiligheid om te gaan.

En blijkbaar is het nodig want de mensen bij code spaces beweerden dat wat nu is gebeurt niet kon gebeuren.

Als je dit al met huizen wilt vergelijken, ze beweerden bij code spaces dat bij hun niet ingebroken kan worden. En nu is hun huis door een dief uitegruimd...
Het gaat mij er dus vooral om dat bedrijven structureel hun eigen veiligheid als beter verkopen dan het werkelijk is.

"jij doelt op iemand die de moeite had genomen het bedrijf zelf in te lichten en eventueel verbeteringen had aangedragen. "

Alleen als dat tot gevolg zou hebben dat die bedrijven dat ook gingen fixen. Maar helaas opereren bijna alle bedrijven onder het mom van 'de put wordt pas gedempt als het kalf al verdronken is'.

"Agressieve criminelen zijn een noodzakelijk kwaad om de noodzaak van vuurwapens bloot te leggen"

We hebben het hier niet over vuurwapens maar over informatie.
Informatie heeft heel andere eigenschappen dan de spullen in onze fysieke wereld en vereist een andere manier van omgaan.
Dit terwijl de meeste gebruikers het liefst willen dat alles wat met computers te maken heeft zo veel mogelijk op onze real-world beleving lijkt.
Dit kan gewoon niet en informatie behandelen alsof het een fysiek goedje is is onjuist. Alleen moeten de meeste mensen op aarde dit nog gaan begrijpen.
Tot die tijd zullen er altijd bedrijven zijn die 'veiligheid' kunnen verkopen alsof het hangsloten zijn en blijven mensen vergelijkingen maken tussen huizen en netwerkbeveiligingen...

Dit soort hackers verdient inderdaad een plkje in de hel...zelf niks mee opgeschoten en tig anderens (levens)werk verpesten...en financieel duperen

Ik ben het eens dat dit soort hackers een plekje in de hel mogen hebben.

Maar het soort profiteurs, verkopers van lucht, als Code Spaces, mag ook best een plekje in de hel krijgen.

Maar Code Spaces heeft dan tenslotte toch nog iets goeds gedaan: alle bedrijven die op dezelfde manier te werk gaan, dwz. meer beloven dan ze waar maken, denken nu wel twee keer na.

Aan de andere kant. Vaak zijn de eigenaars toch wel van die lui die dan denken: "well, het was leuk, maar ik ben met niks begonnen en heb toch in de tussentijd kunnen leven. Op naar de volgende.".

Dat is dan leuk voor hen, maar hun slachtoffers kunnen vast niet zo makkelijk met hun verlies omgaan.

Ik neem aan dat de hosting in Amazon hun plan was om DDoS aanvallen af te wenden.
Dat ze geen offsite backup hadden is zeer slecht, maar ze hebben waarschijnlijk gedacht dat Amazon's hosting niet zomaar offline kan, en hun backups daar dus veilig waren, dat iemand het systeem in zou komen door gewoon in te loggen zal niet zijn bedacht...

Wel uitzonderlijk triest om een bedrijf zo te vernietigen, ik hoop dat de eigenaar ze aanklaagt en de volle kosten en het failisement op de daders kan verhalen, dat afpersen met een DDoS moeten we nu direct de kop in drukken en gigantisch hard afstraffen voordat meer bedrijven en later ook personen slachtoffer worden...

daar ben je crimineel voor.. Dit soort hackers zouden door de politie opgespeurd moeten worden.

En gewoon voor een jaartje of 10 in de bak gooien. Ze hebben dan wel geen levens beëindigd. Maar wel grote economische schaden aangericht.. Veel kleine en grotere bedrijven zijn misschien wel voor xx weken aan code kwijt..

Dus ja paar jaar achter de tralies en sowieso verbannen tot enig computer gebruik,,

Moord in nld is 6-8jr (gemiddeld) dan vind ik 10jr wel buitensporig lang

//edit; duur is gebaseerd op ervaring uit directe omgeving (goedgedrag/verzachtendeomstandigheden)

[Reactie gewijzigd door himlims_ op 19 juni 2014 12:52]

Moord is een hele andere misdaad en die word in Nederland te mild aangepakt, maar 10 jaar voor hacken vind ik te veel aangezien hier niemand door dood is gegaan. Ik vind wel dat desbetreffende persoon of personen achter de tralies moeten en een flinke schade vergoeding moeten betalen.

Gelukkig zijn die hackers altijd miljardair.......zodat je die vergoeding ook daadwerkelijk krijgt.
Een half jaar cel, een kopje thee, een vermanende opgestoken vinger en 1 miljard schadevergoeding lijkt mij ook beter en veel redelijker.

En nu terug naar de echte wereld.........
Waar je berooid achterblijft en je levensdroom vernietigd is en je hem eigenlijk ook levenslang toewenst, net zoals jij kreeg door hem.
Die vergoeding krijg je natuurlijk nooit van die kale kip.

[Reactie gewijzigd door Teijgetje op 19 juni 2014 13:00]

Waar je berooid achterblijft en je levensdroom vernietigd is en je hem eigenlijk ook levenslang toewenst, net zoals jij kreeg door hem.

Ergens in het hele verhaal vermoed ik dat er ook nog een beetje eigen schuld in zit.

Ik weet het niet helemaal. Maar als je jezelf vele malen groter en beter voorstelt dan je in werkelijkheid bent, dan voel ik dat daar ook iets van 'proberen slapend rijk te worden' in zit.

Code spaces heeft meer beloofd dan ze waar hebben gemaakt. Gebluft en verloren, dus. Erg jammer, maar de baas van Code Spaces had ook een offline backup systeem kunnen plaatsen. Desnoods gewoon bij hem thuis, en dan iedere dag een backupje op tape draaien.

Of desnoods iedere dag even bij de ISP langs om de tape te wisselen.

Jammer, Code Spaces, dat je nou niet even deed wat je beloofde.

Beetje simpel gesteld hoor.
Iemand/iets wordt vernietigd omdat het kan door een hacker die ter kwader trouw is en wiens afperspraktijkje niet lukt......en het nog min of meer goedkeuren ook omdat de backups offsite online staan ipv hard copies???? Eigen schuld????

Ik zeg aanpakken zulke malloten en nooit meer vrij ipv goedkeuring omdat ze blijkbaar het adminwachtwoord wisten te kraken.

Natuurlijk kan het altijd nog veiliger en beter want hackers worden slimmer en krijgen meer rekenkracht, dat blijkt wel hier,
Van mij mag dit soort cybercrime onredelijk zwaar bestraft (20x levenslang of zo) als voorbeeld.

Dit is niet gewoon "hacken", dan kun je net zo goed zeggen "10 jaar voor te hard rijden is belachelijk!" terwijl dat hard rijden een tool was om een klas kinderen de dood in te jagen. Ja, ja ik weet het er zijn hier geen levens verloren, ik chargeer een beetje natuurlijk... maar dit is gewoon afpersing en grootschalige vernieling van eigendommen, eigenlijk kun je dit gewoon net zo bestraffen als het opblazen van een gebouw of zoiets.

maar dit is gewoon afpersing en grootschalige vernieling van eigendommen, eigenlijk kun je dit gewoon net zo bestraffen als het opblazen van een gebouw of zoiets.

Ik vind het wel een beetje belachelijk dat je de economische schade van een paar honderd mensen die een paar weekjes werk kwijt zijn, durft te vergelijken met een paar duizend doden omdat een gebouw door een bomontploffing is ingestort.

Je bent niet helemaal bij je verstand,

To assume makes an ass out of u and me...
Wie zegt dat in mijn hypothetische situatie er mensen in dat gebouw aanwezig waren? Ik heb het nog gedacht, ik moet er bij zeggen dat het een leeg gebouw is anders komt er weer een moraalridder aan, maar ja...

@theuberdude,

waar leg je de grens dan? Als ik nou eens een pensioenbedrijfje opricht en klanten voor miljarden oplicht dan heb ik niemand vermoord en zou 2 jaar voldoende moeten zijn ofzo?

De gemiddelde bejaarde denkt daar waarschijnlijk heel anders over. Die was waarschijnlijk liever dood dan met torenhoge kosten voor zorg met nog geen half inkomen te moeten doen. Zeker op die leeftijd is op een houtje kauwen niet zo prettig meer, zoveel tanden hebben ze niet meer .

Dood kan wel degelijk beter zijn dan de rest van je leven ergens de gevolgen van moeten ondervinden zonder het recht te kunnen zetten. En compensatie kun je die 2 jaar dat ik dan zou zitten ook niet noemen - daar hebben die mensen geen hol aan.

kregen ze maar twee jaar
De meeste prutsers in de financiele sector krijgen een bonus mee!
Nou ja, niet helemaal hetzelfde als de moedwilligheid uit jouw voorbeeld,maar ik neem aan dat voor grootschalige fraude inderdaad een jaar of twee voor staat?

Voor moord kreeg je in 2011 in Nederland al gemiddeld 14,7 jaar cel. Inmiddels is dat mogelijk alweer hoger geworden. Daar komt in redelijk wat gevallen nog TBS voor onbepaalde tijd bovenop. Daarmee valt Nederland in de categorie met relatief zware straffen vergeleken met veel andere Europese landen.

Het lijkt me dat je in de war bent met een ander land of dat je cijfers een paar decennia verouderd zijn. Steeds zwaarder straffen is in Nederland al bijna vijftig jaar een trend.

[Reactie gewijzigd door Maurits van Baerle op 19 juni 2014 13:09]

6-8jr (gemiddeld) is dan nog aardig kort voor een moord als je het mij vraagt. De na bestaande verliezen iemand levenslang, terwijl de moordenaar er na 6-8 jaar weer opnieuw
zijn gang kan gaan.

Misschien bedoel je dat 6 tot 8 jaar voor moord buitensporig kort is ?

Veel kleine en grotere bedrijven zijn misschien wel voor xx weken aan code kwijt..

Ja, maar.... die bedrijven hebben zelf *ook* de verantwoordelijkheid om backups te maken van hun code. 100% vertrouwen op je 'aanbieder in de cloud' is natuurlijk ook niet heel erg slim. Dus als iedereen een beetje slim bezig is geweest, heeft dit geen consequenties voor hun klanten, alleen voor het bedrijf zelf en dat is hun eigen schuld.

Hoewel ik zeker vind dat dit soort crackers achter de tralies mogen belanden is er ook genoeg wat dit bedrijf te verwijten valt, ze hebben immers gelogen tegen hun klanten over de backups en het lijkt er sterk op dat ze geen 2 factor authentication hebben gebruikt (of andere mogelijkheden) om dit soort zaken te voorkomen.

de minister van economische zaken heeft wel meer economische schade veroorzaak, het hele kabinet rutte heeft mega miljarden schades veroorzaakt, als ik jouw straf maat door zou trekken is er maar 1 oplossing. standrechtelijke executie

dan weet je gelijk wat er mank gaat aan je beargumentering...

[Reactie gewijzigd door i-chat op 19 juni 2014 12:25]

Zekers. Want dood is het ergste niet.

Je bent sowieso zielig bezig als je gaat dossen.....

Yep, maar ja, niemand die er echt iets aan doet. Zeker als kleine partij / particulier kun je hier weinig tegen beginnen.

Maar om je backups via dezelfde ingang bereikbaar te maken is zwaar nalatig!
Als ze de backups fysiek op een andere plek hadden gehad dan was sluiting niet nodig geweest

Als ze de backups fysiek op een andere plek hadden gehad dan was sluiting niet nodig geweest

Er staat duidelijk in het artikel dat ook offsite backups vernietigd zijn. Offsite, in een cloud-omgeving, kan bijvoorbeeld betekenen dat het wel bij de hoster aanwezig is maar "fysiek" in een ander datacenter of een SAN op een andere fysieke lokatie.

Er is verschil tussen fysiek 'off site' en werkelijk 'geisoleerd'.

Als ik mijn backup opsla in een datacenter aan de andere kant van het land dan is dat fysiek 'off site' en zijn de backups beschermd wanneer er bijvoorbeeld een vliegtuig op de hoofdlocatie valt.

Maar als er dan tussen mijn hoofdlocatie en de backuplocatie een verbinding loopt zodat de beide locaties in hetzelfde netwerk zitten dan is de backup niet geisoleerd en kan een hacker die toegang heeft tot de hoofdlocatie dus ook de backup verwijderen.

Maar als er dan tussen mijn hoofdlocatie en de backuplocatie een verbinding loopt zodat de beide locaties in hetzelfde netwerk zitten dan is de backup niet geisoleerd en kan een hacker die toegang heeft tot de hoofdlocatie dus ook de backup verwijderen.

Het grote nadeel van airgaps en fysiek geïsoleerde backups is dat het niet meer mogelijk is om automatisch backups te maken, dat zul je dan met de hand moeten doen. Juist omdat je wil beschermen tegen inbraken van buitenaf, kunnen automatische tools er ook niet bij.

Bijkomend nadeel is dat je downtime na een storing een stuk groter wordt, terwijl je met online (maar offsite) backups een directe failover hebt.

Als de inbreker de bestanden op een 'legitieme' manier verwijdert net zoals een gebruiker dat bewust zou doen, dan kan het backupsysteem ook weinig worden verweten, want die neemt gewoon over wat er op de hoofdserver staat.

Online backups heb je om storingen af te vangen, niet om acties van hackers of domme gebruikers te kunnen rollbacken.

Hmm...

Men neme:

1) Goed dichtgetimmerde Linux server met dikke storage. Off site natuurlijk.
2) rsnapshot met dagelijks/wekelijks/maandelijks/jaarlijks retentie
3) Backups dagelijks initieren VANUIT de backup server middels SSH en een authorized RSA key, uiteraard nog extra beveiligd door alleen het IP van de backup server te accepteren EN de key alleen rsync te laten aanroepen in server mode en bovendien login shells en dergelijken te weigeren.

Opgezet binnen 4 uurtjes, en knappe jongen die je backup dan nog kan verklooien. Zo moeilijk is het dus helemaal niet. Als je met Windows werkt ben je natuurlijk verder van huis, maar ook hier is vast een (duurbetaalde) goede oplossing...

[Reactie gewijzigd door Delgul op 19 juni 2014 20:09]

Tja, elk voordeel heeft zijn nadeel.
Je kunt natuurlijk ook beiden doen, maar dat kost weer meer.

Ergens is het ook wel gek dat je bij Amazon zomaar je offsite backups weg kunt gooien uit een beheerpaneel zonder dat iemand het door heeft? Ik bedoel, naast de betrouwbaarheid van deze dienst kun je je ook afvragen wat Amazon hieraan had kunnen doen.

Ik snap al niet dat een admin account via de normale portal bij OFFSITE meuk kan maar dat zal wel weer aan mij liggen.....

Meeste bedrijven die ik kende hadden daar apparte logins voor.

Ik vind dit ook vrij bijzonder.

Ik vind het bijzonder walgelijk dat iemand een bedrijf dusdanig hard pakt dat het helemaal dicht kan. Zeker aangezien ze er zelf helemaal niets aan hebben.

Maar de systeembeheerders hebben hier ook schuld. Je backups zo organiseren dat het bereikbaar is via je normale systemen gaat tegen alle regels in. Dit is op z'n minst dom en op z'n sterkst mismanagement. Als ik klant was zou ik ook zeker juridische stappen overwegen.

Laat dit een les zijn voor alle beheerders: backups GOED organiseren is NOOIT eenvoudig. Als het wel eenvoudig is loop je risicos die toenemen naar mate je organisatie meer afhankelijk is van ICT. Is het je core-business dan ben je zeker verkeerd bezig als je een makkelijke oplossing denkt te hebben.

Zou verwachten dat je zo'n functie had dat je backups dan na 24 uur oid pas definitief verwijderd worden...
Maar two-factor authenticatie was ook geen overbodige luxe geweest, zeker niet in een beheerpanel...

"Samenvattend: het meeste van onze data, backups, machine-configuraties en offsite backups zijn gedeeltelijk, dan wel volledig verwijderd"

Hoe goed zijn je "offside" backups dan wel niet

Je offsite backups kunnen nog zo goed zijn als je wil, zolang het online (en dan heb ik het niet alleen over 'aan het internet') backups zijn zijn ze niet veilig voor iemand die blijkbaar aan jouw logingegevens gekomen is en zo alles gewoon kan wissen.

met die backups was vast niets mis...de toegang er naartoe was helaas niet goed (genoeg) beveiligd...aka met verschillende accounts werken met verschillende clearance

Hoe goed zijn je "offside" backups dan wel niet

Dat is aan de scheidsrechter om te beslissen