Amerikaanse e-mailprovider VFEmail raakt alle mails kwijt door digitale aanval

De Amerikaanse e-mailaanbieder VFEmail is alle mails kwijtgeraakt door een digitale inbreker. De digitale infrastructuur en alle back-ups zijn verwijderd. Waarom alle mails zijn verwijderd is niet duidelijk, de eigenaar zegt dat er geen losgeld is geëist.

De eigenaar betrapte de inbreker toen die de back-upserver aan het formatteren was, schrijft de eigenaar op Twitter. "Op dit moment heeft de aanvaller alle schijven op iedere server geformatteerd", zegt hij in zijn tweet. "Iedere virtuele machine, file- en back-upserver is gewist." Alleen de server die de inbreker net aan het formatteren was zou nog gered kunnen worden, het is onbekend hoeveel data hierop stond.

Op zijn persoonlijk Twitteraccount deelt eigenaar Rick Romero meer details. Zo schrijft hij dat er verschillende wachtwoorden en beveiligingsmaatregelen waren en het om een geavanceerde aanval gaat. Hij weet niet wie er achter de aanval zit. Het ip-adres van de aanvaller is afkomstig van een Bulgaars hostingbedrijf.

Volgens Romero is dit waarschijnlijk het einde van de maildienst. Inmiddels zijn mailboxen weer online, maar zijn alle berichten en filters verloren gegaan. VFEmail is juist op privacy en beveiliging gericht en begon in 2001 na het ILoveYou-virus, waarna het antivirussystemen met een e-mailclient combineerde. Een account aanmaken is gratis, maar betaalde abonnementen met extra's als meer bandbreedte en opslag zijn er ook.

Reacties (94)

[mmjjb]

"VFEmail is juist op privacy en beveiliging gericht"

Nouja ze hebben zojuist bewezen dat ze de beveiliging blijkbaar niet voldoende op orde hadden.
Ze zijn ook erg van de tijd met hun website: https://www.vfemail.net/

x-powered-by: PHP/5.4.45-0+deb7u14

[Reactie gewijzigd door mmjjb op 23 juli 2024 00:43]

[StephanVierkant]

Dat is inderdaad vrij ernstig. Voor diegene die niet alle versienummers van PHP paraat hebben: PHP 5 is al lang verouderd. PHP 5.4 is zelfs al End of Life (EOL) vanaf 3 september 2015 (!). Dat betekent dat er sindsdien al geen updates meer uitkomen, zelfs niet security patches:

A release that is no longer supported. Users of this release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.

[Dorank]

PHP 5.4 is zelfs al End of Life (EOL) vanaf 3 september 2015 (!). Dat betekent dat er sindsdien al geen updates meer uitkomen, zelfs niet security patches:

Je statement is niet juist. Het gaat hier om een debian versie: 5.4.45-0+deb7u14
Het Debian Security Team heeft deze gereleased op 2018-05-09 18:27, de debian maintainers willen over het algemeen wel enige moeite stoppen in het backporten van security fixes zelfs als de upstream de specifieke versie in een LTS release niet meer support. Deze fix is zelf doorgevoerd nadat Debian 7 (wheezy) al niet meer supported was door Debian.
Zie:
http://security-cdn.debia...pool/updates/main/p/php5/
en
https://wiki.debian.org/LTS/

En daarom vind ik Debian zo'n mooi platform om op te bouwen.

[Douweegbertje]

Dat is wel enig, maar in 2019 aankomen met argumenten over PHP 5.4 is gewoon een no-go.
Je hoort, als je security en voortgang enigszins serieus neemt, op PHP 7.1 te zitten. Beter nog 7.2, en 7.0 kan nog net.

Ik zou php 5.6 die volledig is door gepatched nog kunnen begrijpen, hoewel het ook nog niet de gewenste situatie is.

Daarnaast ben je ook nog afhankelijk van overige packages. Goed ik verdiep mij niet in zulke oude packages maar zover ik weet kan je de PHP5 branche niet compilen met de OpenSSL 1.1 variant. En zo zullen er vast meer dingen zijn.

Maar laten we dan "agree to disagree"; het is veilig;
Het geeft wel exact weer dat er een onderliggend probleem is dat zoiets banaals als PHP op zo'n versie draait. Wat houdt dat in voor de overige services en applicaties die er draaien? Eindstand is dat heel dat bedrijf is weggevaagd. Laten we dat even niet vergeten als argument

[Jerie]

Dat het bedrijf is weggevaagd komt niet door PHP maar door gebrek aan offsite backups plus een destructieve blackhat

[Douweegbertje]

Ik geef aan dat als er zoiets simpels al niet goed gaat, dat de kans bestaat dat het over de gehele linie niet goed was ingeregeld. Nergens geef ik aan dat PHP de veroorzaker was.

[Bensimpel]

We weten niet of het een inside job was, of iemand die van buiten moest komen. Maar even alles op een rijtje.

*Oude PHP versie
*Geen offline back up
*Hele datacenter dat vrij makkelijk onderuit te halen was
* Geen goede monitoring (ze kwamen er echt laat achter)

Blijkt haast wel een amateur club

Eerlijk ben ik juist dankbaar dat ze zo hard onderuit gegaan zijn. (Niet dat ik dit gedrag goed praat). Maar hopelijk is dit een harde les om voortaan beter je zaken op orde te hebben.

[tonkie_67]

Inside job? Toko komt over als een eenmanszaakje, de eigenaar/oprichter was degene die de inbreker live actief zag (& dus waarschijnlijk zelf systeembeheer doet) klinkt het niet 123 als een toko met veel medewerkers.

[Jerie]

En je punt is niet accuraat want dat kun je zoals @Dorank al zei niet adhv een versie doen wanneer er Debian bij die versie staat. Wanneer dat een Debian versie is welke nog patches krijgt (dat weet ik in dit geval niet) dan is die versie ogenschijnlijk nog veilig.

[Ventieldopje]

Die wel eerst binnen moet komen

[Ventieldopje]

Klopt, het is om vele redenen een no-go maar er zijn wel degelijk commerciele partijen die security patches door voeren aan PHP 4 en 5. Voor kritische applicaties is dat maar goed ook.

Je kan dus niet gelijk zeggen "onveilig!" maar ja, de kans is groot 🙈

[gjmi]

Nieuwer is niet altijd beter. Misschien juist wel meer kans op nieuwe nog niet ontdekte bugs dan een oudere versie met allerlei security fixes.

[Amasik]

Dat is hetzelfde als zeggen dat windows XP veiliger is dan windows 10 omdat er voor windows XP al meer security fixes zijn uitgebracht.

[gjmi]

Ik gebruik de woorden "niet altijd" en "misschien" om aan te geven dat het niet in alle gevallen zo hoeft te zijn.

[Reactie gewijzigd door gjmi op 23 juli 2024 00:43]

[Gomez12]

Je begrijpt blijkbaar niet hoe Debian (en enkele andere security bedrijven) erin zitten.

In theorie :
Debian en consorten die volgen juist intensief alle bugfixes en security fixes die na windows XP zijn uitgekomen. En diegene die van toepassing kunnen zijn voor windows XP die worden gebackport naar windows XP.

Zodat je theoretisch een windows XP hebt met minimaal hetzelfde security level als windows 10. En waarschijnlijk zelfs beter, omdat je alle mogelijke security bugs in het nieuwe startmenu etc niet hebt omdat je die features gewoon niet hebt.
Theoretisch is dan je security level gelijk, alleen de attack surface is veel kleiner omdat het geen nieuwe niet goed geteste onderdelen kent.

Bij een Windows is dit ook een redelijke onmogelijkheid omdat MS geen open boekje geeft wat er in een security patch zit. Maar bij Debian etc hebben ze gewoon de source en kunnen ze in theorie alles backporten.

[Amasik]

mijn reactie was niet inhoudelijk hoe Debian er mee om gaat, maar de algemene stelling zoals verwoord door gjmi.

Ik ben niet bekend met Debian, en als ik de rest van de reacties hier lees komt het overeen met jouw uitleg. Maar dat is niet wat gjmi stelt, als hij meteen ook uitgelegd had waarom oud en gepatched beter is dan nieuw dan was zijn reactie veel beter geweest. Mjin reactie op zijn stelling was een voorbeeld hoe zijn totale reactie geïnterpreteerd kan worden. Wat waarschijnlijk niet de bedoeling was.

Jij maakt dezelfde stelling en onderbouwd hem dan, veel beter

Overigens zou het best nog een interessante discussie kunnen zijn of Debian met oude software met alle fixes echt veiliger zou zijn. Er is natuurlijk ook een reden dat bedrijven stoppen met het oneindig backporten van security fixes. Het lijkt me onmogelijk dat ze elke fix uit een nieuwe versie volledig 1op1 kunnen terugporten. Waarbij dus weer een extra risico optreedt als je een bugfix eigenlijk opnieuw moet ontwikkelen/aanpassen voor een oudere versie.

[cadsite]

Die site is ongelooflijk.
Dat doet me denken aan mijn eerste stapjes op het net, zo'n 20 jaar geleden.

[tonkie_67]

Wellicht had hij een oude (offline) backup van 20 jaar terug gevonden en die teruggezet

[3raser]

Volgens de wayback machine zag de website er vorige week (voor de hack) al net zo uit. Dus dit zal geen oude backup betreffen.

[Compunologist]

alle back-ups zijn verwijderd

Dan had je de zaken inderdaad niet voor elkaar.

Die slogan op hun website kan nu ook verwijderd worden:

Making email safe for the masses

[Reactie gewijzigd door Compunologist op 23 juli 2024 00:43]

[SCS2]

Die slogan op hun website kan nu ook verwijderd worden:
Making email safe for the masses

Hoezo? Geen veiligheidsdienst die nu nog bij die mailtjes kan

[Reactie gewijzigd door SCS2 op 23 juli 2024 00:43]

[MadMarky]

Voor degenen die niet zo bekend zijn met PHP versies: de beheerder van VFEmail loopt, pak hem beet, 4-5 jaar achter met zijn software updates. Versie 5.4 dateert uit 2012 en support liep af in september 2015. In internet jaren is dat oeroud en onvergeeflijk als je ook maar iets om veiligheid geeft

[bilbob]

plus je backups online hebben.

[Reptile209]

Je kan (moet?) wel een online backup hebben, maar zeker bij een dienst van deze omvang blijkt een hele regelmatige offline backup ook wel nuttig . En dan misschien nog niet eens voor een kwaadwillende hacker, maar ook voor brand, diefstal, blikseminslag en andere grote onheilen.

[Bensimpel]

Hopenlijk dat de eigenaar zijn (dure) les geleerd heeft, dit bewijst maar weer eens hoe belangrijk back ups wel niet zijn.

[Amasik]

Bijna al die argumenten zijn niet van toepassing als je een online backup naar een ander datacenter doet dat 2000 km verwijderd is van je primaire datacenter. Dan heeft blikseminslag, vliegtuigcrash, overstromingof diefstal niet zo'n grote kans in een keer de hele omgeving te vernietigen.

Blijft uiteraard de offline backup wel noodzakelijk voor hackers en andere kwaadwillenden. Een cryptolocker maakt het ook niet of een server 2 meter of 2000 km verderop staat.

[Bensimpel]

En geen tape/offline back up? Wel slecht dan zeg!

Ik denk dat dit inderdaad wel het einde is, van de naam dan. Waarschijnlijk gaan ze onder een andere naam verder?

[Trommelrem]

Ik vraag mij af hoe Microsoft dit eigenlijk doet met Office 365. Volgens mij is het simpelweg niet te doen om dat allemaal offline te backuppen als alleen al je changes enkele terabytes per seconde zijn.

[Rolfie]

Dat is simpel... Die hebben ze niet. Data staat gewoon over meerdere datacenters, en wil je offsite backups hebben, dan regel je daar zelf iets voor. Das het mooie van cloud.

[Bensimpel]

Speciale trucks, 100 petabyte data past er wel in.

Amazon doet het zo:
https://techcrunch.com/20...cloud-with-an-18-wheeler/

Volgens mij heeft Microsoft gewoon een CDN, mocht er 1 offline gaan kunnen andere data centers het tijdelijk overnemen. Failsafe 1.

Maar je kunt prima tape robots backups laten trekken en iedere dag een vrachtwagen laten rijden. Zo doen de meeste enterprises dat.

[Verwijderd]

Onzin. Die truck is om data van een klant juist naar AWS te brengen, aangezien het te groot is om over het netwerk te doen. Het omgekeerde van een offsite backup dus.

[Bensimpel]

Natuurlijk wel, mocht een dc plat gaan en moeten ze alles recoveren naar een punt hebben ze vast wel een truck om snel data over te pompen. (dit wil je niet met tapes).

Staat vast wel in een continuity plan.

[Verwijderd]

Natuurlijk niet, het is duidelijk dat je maar wat gokt en dingen aanneemt zonder daadwerkelijk iets van Amazon AWS af te weten.

AWS heeft altijd meerdere data centers in een availability zone staan. In dezelfde stad met hooguit enkele tientallen kms ertussen. Als er dus een dc plat gaat, wordt de ander recovered over het netwerk, een heel erg dik netwerk. Op die manier wordt ook voortdurend gerepliceerd.

[Bensimpel]

Lees mijn eerdere post nog eens, ik had het over Microsoft die ook een CDN heeft in de vorm zoals jij omschrijft. Maar mocht zelfs het CDN netwerk falen staat er vast wel een plan om bijvoorbeeld ouderwets data te transferen. Die trucks van Amazon zijn daar erg geschikt voor.

[Terrestrial]

Ik denk dat je is moest weten hoeveel bedrijven en cloud aanbieders hun offline backups niet (op orde) hebben. Besef ook dat het heel veel geld kost en het vaak voor kleine bedrijfjes niet rendabel is. En je kunt je kop in het zand steken en denken dat gemiddelde aanbieder dit wel goed voor mekaar heeft, totdat blijkt dat het niet zo is. En praktisch niemand zegt dat ze offline-backups hebben op hun website. Er staat gewoon "backups" en dat is bijna altijd een online-backup.

[Reactie gewijzigd door Terrestrial op 23 juli 2024 00:43]

[WillySis]

Meestal gaat het gelukkig wel om backups op een andere locatie, maar die wel via het beheer panel bereikbaar is. Een goede backup met tapes of harde schijven in een kluis op een andere locatie is zeldzaam. Zeker bij kleine bedrijven is een backup nog steeds een stiefkindje wat vaak vergeten wordt. Het is riskant leven, maar zolang het goed gaat is er niets aan de hand.
Mijn baas vond backups ook maar gedoe en niet zo belangrijk. Nu werk ik vanuit huis en heb ik toch maar een extra servertje thuis neergezet. Netjes elke nacht een back-up en het verbaast me hoe vaak iemand nog een bestandje terug vraagt wat per ongeluk is weggegooid (meestal niet goed gezocht overigens). Na het instorten van de server (8 jaar oud) dacht de baas ineens heel anders over een backup.

[Teleluvr]

Ik zou als baas ook niet heel blij zijn als mijn werknemers thuis backup servers gaan draaien, ongevraagd...

[WillySis]

Niet ongevraagd natuurlijk. Netjes in overleg een backup server aangeschaft, op kosten van de baas.

[Bensimpel]

Ik ga er vanuit dat je als jezelf op privacy en beveiliging richt. Dat je dan ook dan ook wel aan offline back ups doet.

Blijk van geen goede risk assessment, schijnbaar was de risk dus best groot om alles te verliezen. Het klopt wat je zegt dit dit geld kost, maar een goede risk assement zou dit voorkomen hebben.

[hackerhater]

In mijn eigen geval met een hostingbedrijfje:
De servers staan in de buurt van Amsterdam en hebben een hot backup die een paar uur oud is.
Daarnaast wordt elke nacht een copie getrokken naar ons thuiskantoor dat geografisch iets van 100KM verderop ligt.

Het moet wel een grote ramp zijn om beide kwijt te raken

[Terrestrial]

Het gaat er juist om dat bij een hack dit weinig uithaalt als de hacker toegang verkrijgt tot alle netwerken en als nog alles wist. Daarom wil je juist die offline-backup. Maar nogmaals ik besef heel goed dat dit voor kleine hosting bedrijfjes bijna niet te doen is.

[hackerhater]

Het is niet mogelijk om vanuit de servers aan die offsite backup te komen
De offsite-server maakt de verbinding en die verbinding is dicht als ie niet het backuppen is.

[royduin]

Als ik naar de website kijk gok ik dat alles een paar updates achterliep en iemand met iets als SQL injection binnen is gekomen.

[WokeBroke]

Het PHP en MySQL gedeelte staat toch meestal los van het email?

[DutchKevv]

Hoeft natuurlijk niet. E-mails kunnen opgeslagen worden in MySQL net als hun 'filters'. Of er staan niet/slecht gehashte wachtwoorden in vanwege luiheid wat hem verder toegang gaf. Wellicht draaide er een admin gedeelde waar die zo bij kon.
etc etc etc

Voor jou als developer die email verstuurd kan het wel los staan. Maar e-mails zullen toch ergens opgeslagen moeten worden

[Hatsjoe]

Met SQL injection kan je praktisch niks bij een goed ingerichte webserver. Er zullen dus wel meer zaken niet op orde geweest zijn.

Het is nu puur speculeren tot dat VFEMail zelf naar buiten brengt wat de oorzaak was.

[Gyzome]

Een goed ingerichte webserver draait ook niet op PP5.4.

Waarschijnlijk werd helemaal niet zo voorzichtig omgesprongen met beveiliging, en waren de servertaken niet voldoende verdeeld.

[Marctraider]

Mja, toch de (offline) backupjes niet op orde he.

De kans hierbij is groter met zo'n onbekende provider.

[Reactie gewijzigd door Marctraider op 23 juli 2024 00:43]

[Iblies]

Kan goed een inside-job zijn van een werknemer met wrok die precies wist hoeveel back-ups er waren en hoe die te benaderen.

Praat het natuurlijk nog steeds niet goed,
maar dit lijkt me te onwaarschijnlijk voor een hacker van buitenaf, lijkt me totaal niet interessant om op deze wijze te werk te gaan.

[zenlord]

Ik heb nu mijn backup-routine omgezet naar een 3-2-1 strategy met borgbackup: volledig ge-encrypteerd en append-only (toch minstens de offsite backup). Tenzij dus de hacker niet alleen mijn server hackt, maar ook nog eens toegang heeft tot mijn (admin) accountgegevens bij de offsite backupdienst, kan ik mijn gegevens nooit kwijt raken.
Nu ik erover denk - die gegevens zouden bij een inside job wel bij iemand (en vermoedelijk bij dezelfde persoon) moeten zitten...

[tweaknico]

En je encryptie keys..... hoe veilig en separaat zijn die opgeslagen?....

[zenlord]

Mijn sleutels staan uiteraard op de server waarop de brondata aanwezig zijn, maar ze zitten ook in een beveiligd TAR-archief op mijn persoonlijke laptop. Dit TAR-archief maakt deel uit van een andere, private backup-job naar een andere doel-locatie met andere encryptie-sleutels.
Nu, net omdat mijn offsite backup append-only staat ingesteld, zou een hacker (als die toegang heeft tot mijn sleutels) wel data kunnen decrypteren en misbruiken, maar hij/zij zou de gegevens nooit kunnen wegmaken. Daarvoor heeft hij/zij toegang nodig tot mijn admin-account bij de provider.
Maar... terechte opmerking!

[tweaknico]

Immers encryptie keys kwijt is de snelste data verwoesting die gerealiseerd kan worden.
Er is over nagedacht, dat is al iets...

[NiGeLaToR]

En iemand die echt wil gijzelt je cavia en laat je gewoon zelf alles deleten. Enzovoorts. Tis kansberekening.

Er bestaat geen 100% veiligheid.

[Dorank]

Mijn sleutels staan uiteraard op de server waarop de brondata aanwezig zijn,

Dit klinkt heel erg fout. De machine met de bron data heeft alleen de public key nodig. De private key dient niet in de buurt van de bron of bestemming te komen totdat je iets wilt restoren. Ik hoop dan ook dat je bedoelt dat je meerdere keypairs hebt en het over meerder specifeke publieke sleutels hebt.

[gjmi]

Als je je data veilig wil houden, zou je er beter aan doen niets over je methodes te vertellen. Je geeft nu allerlei aanknopingspunten weg voor een hacker.

[GeroldM]

Kan er nog een opmerking aan toevoegen.

Heb je de gemaakte backup daadwerkelijk getest (op een andere machine) om te zien of het goed werkt?
Een ongeteste backup is hetzelfde als geen backup. Denken dat je een backup hebt, maar als puntje bij paaltje komt blijkt de backup niet of onvoldoende te werken. Dat is een les die je niet wil leren.

[tonkie_67]

En als je morgen tegen een boom rijdt kan niemand er meer bij? Wellicht prima voor prive data, maar niet voor een bedrijf. Denk aan die offline cold wallet van die coin-exchange waarvan eigenaar blijkbaar onverwacht is overleden in thailand oid (ben naam ff kwijt nu, maar was vorige week in t nieuws)

[livePulse]

Klinkt alsof je óf heel veel te verbergen hebt, óf hele gevoelige data hebt...

[Bensimpel]

Beste is nog gewoon ouderwets op tapes en in een kluis. (Het liefsts nog op een andere locatie). Daarmee maak je het een kwaadwillende erg moeilijk.

[zenlord]

Je hebt volledig gelijk. Anderzijds is security (met inbegrip van het maken van backups) altijd een tradeoff tussen 'het beste' en 'het meest haalbare'. Die keuze moet afhangen van de data waarover het gaat, en in het geval van een emailprovider die uitpakt met 'privacy en beveiliging' als onderscheidend kenmerk, zouden offline tapes misschien inderdaad wel de enige aanvaardbare oplossing geweest zijn.

[Jerie]

Er is in dit geval geen enkele offsite backup beschikbaar. Kleine provider of niet, dat is onverantwoord.

[Rolfie]

Die was er wel, maar ook gewist...

[terracide]

Haha een off-site backup die gewist is. Was deze hacker bij de eigenaar thuis aan het werk?

[Jerie]

Die was er wel

Not really...

En als-ie er volgens jouw definitie wel was, dan was het een slechte implementatie...

[Rolfie]

Volgens de designs was die er wel. Echter de vraag is hoe goed die afgeschermd is/was van de rest van de infrastructuur.
https://www.vfemail.net/design.php

En offisite hoeft niet te betekenen offline. Maar een ZFS replicatie werkt mooi, maar is een push technologie. Dat betekend dat de backup client altijd al een SSH verbinding moet hebben richting de backup server, wat al gaten met zich mee brengt. Een pull technologie werkt vaak al een stuk beter. De backup server zet dan de verbinding op naar de te backupen client. En kan dus volledig inkomende verbindingen geblockeerd hebben.

Maar zelfs dan... Als iemand echt de tijd heeft, kan hij het complete netwerk volledig doorgronden en alle zwakke punten vinden.

[Reactie gewijzigd door Rolfie op 23 juli 2024 00:43]

[Jerie]

En daarom moet je een offline backup maken die je offsite houdt (in geval van brand/natuurramp). ZFS heeft daar sinds jaar en dag prima ondersteuning voor via zfs send. Die stdout kun je vervolgens pipen daar een ander programma; zelfde principe als cpio. Dit heeft deze provider niet iedere dag gedaan. Ze hebben het ook niet iedere week gedaan. En ook niet iedere maand. Zelfs niet eens per jaar. Nee, nooit. En dat laatste is het kwalijke aan deze zaak.

[Iblies]

...
Nu ik erover denk - die gegevens zouden bij een inside job wel bij iemand (en vermoedelijk bij dezelfde persoon) moeten zitten...

Juist.

Het ontgaat me elke logica om het als proof-of-concept te toetsen zonder er een bedrag tegenover te vragen.
Eindejaarsopdracht van een student van school of hacking in bulgarije lijkt me ook te ver gezocht.

Het zijn vermoedens, maar het lijkt me wel wat als eerst getoetst moet worden.

[latka]

Backup doe je offsite en niet gekoppeld aan je productie systeem. Ouderwets met tapes en een kluis enzo.

[SunnieNL]

Mjah, je denkt toch niet dat MS alle mails in Exchange online op tape zet?
Een 3 tier storage over geografisch gescheiden systemen werkt ook prima, mits je je data doorvoer (1 richting verkeer pull) en beveiliging (meerdere account of beter just intime just enough rights)maar goed regel.

[Trommelrem]

Tapes kunnen de hoeveelheid wijzigingen niet eens bijhouden er gaan echt petabytes per seconde doorheen.

Ook vraag ik mij het nut af van offline backups. Data die twee dagen oud is, is eigenlijk al nutteloos.

[core_dump]

Nutteloos? Ik denk dat meneer Romero op dit moment erg gelukkig zou zijn met een backup van 2 dagen oud...

[latka]

Offline maar vooral offsite ivm. de Boeing test.

[SinergyX]

Geen offsite backup? Pijnlijk.

Misschien hebben de gebruikers wel basis ICT 1.0 gedaan en van hun eigen mail een backup gemaakt, kunnen ze hun gebruikers vragen voor stukjes van de backup terug te zetten

Lijkt me dan eerder een geval van semi-insider, als je zo gericht en zo 'makkelijk' nagenoeg alles kan laten verwijderen.

[Rolfie]

Wel Offsite maar geen Offline backup. En een nadeel van Offsite, is dat het met Email erg snel verouderd is.
Maar iets is beter dan niets....

Maar zelfs met een Offsite backup kan het nog steeds heel goed gaan. Echter je moet het wel heel goed inrichten en blijkbaar is daar hier duidelijk iets fout gegaan.
Als ik het design zie, dan gebruikt het ZFS Send, heel mooi, maar dat betekend dat de client al verbinding moet hebben met SSH tot de backup server. En dat is een risico. Je kan veel beter een pull vanuit de backup server hebben. Als die backup server dan volledig afgeschermd is, zijn dit soort issues catastrofale wipes een stuk lastiger uit te voeren. Immers de backup server is geïsoleerd van de rest van het netwerk......

[Sfynx]

Je kan veel beter een pull vanuit de backup server hebben. Als die backup server dan volledig afgeschermd is, zijn dit soort issues catastrofale wipes een stuk lastiger uit te voeren. Immers de backup server is geïsoleerd van de rest van het netwerk......

Pull model bij backups moet sowieso inderdaad, juist tegen hackers die je servers wissen.
ZFS send/receive kan ook prima als pull model, gewoon overal de public key van de backup server neergooien en de backup server de SSH-verbinding laten maken en de zfs snapshot + zfs send commando's remote uitvoeren. Bestaan ook genoeg tools/scripts voor die dat voor je afhandelen incl. pruning van oude backups, denk aan zfs_autobackup e.d.

[Reactie gewijzigd door Sfynx op 23 juli 2024 00:43]

[Hardwareseller]

Wat mij benieuwd is hoe ze toch 'inbreken' in die nodes, ik werk 40 uur per week als Linux systeembeheerder en heb tot nu toe maar een grote inbraak meegemaakt door een verouderde kernel. Is het dan dat er een SSH key gelekt is, een wachtwoord gelekt is, achterstallig onderhoud, oude OS, lekken in gebruikte software, inside job (medewerker die ontslagen is en er is een backdoortje of wachtwoorden die niet veranderd zijn?). Dat vertellen ze dan weer niet.

[zordaz]

Bij 80% van dit soort incidenten zijn eigen medewerkers betrokken. Het is speculeren, maar dat lijkt me hier ook het meest voor de hand liggend.

[Jerie]

80%... Bron?

[Bruin Poeper]

80%... Bron?

Waarom wil je 'een bron'? Dit is zo'n gemakkelijke tegenvraag, alsof het niet aannemelijk is.
Ik geloof die speculatie.

Het hele gedoe met bv Digid + 2FA lijkt me er een bewijs van. Het zijn niet de burgers die knoeien maar de mensen die bij vertrouwelijke informatie kunnen: medewerkers in organisaties.

[Jerie]

Waarom wil je 'een bron'?

Een blackbox aanval komt van buitenaf en is daarmee realistischer. Red teaming is stukken minder populair dan pentesting. Daarnaast is een aanval dankzij inside knowledge veel lastiger om je tegen te verdedigen. Het lijkt mij nuttiger wanneer men eerst de beveiliging van buitenaf op orde heeft (blackbox dus). Dat is realistischer, en de attack surface ligt hoger.

Het hele gedoe met bv Digid + 2FA lijkt me er een bewijs van.

Welk gedoe?

[Bruin Poeper]

[...]


Een blackbox aanval komt van buitenaf en is daarmee realistischer. Red teaming is stukken minder populair dan pentesting. Daarnaast is een aanval dankzij inside knowledge veel lastiger om je tegen te verdedigen. Het lijkt mij nuttiger wanneer men eerst de beveiliging van buitenaf op orde heeft (blackbox dus). Dat is realistischer, en de attack surface ligt hoger.


[...]
Welk gedoe?

Het gedoe is dubbel inloggen namelijk 1x, en dan nog een 2e x met/via een ander apparaat.
En dat is vooral om te voorkomen dat interne medewerkers er niet bij kunnen.
Ik moet er sowieso voor zorgen dat een ander niet buiten mij om bij mijn gegevens kan. Raar dat iemand anders (een instantie) buiten mij om dan een extra beveiliging wil, die ik niet wil vanwege de onhandigheid. Kortom ik moet extra lasten ondervinden omdat men intern bedreigd wordt.

Dus: zorg maar eerst dat je de beveiliging van binnen op orde hebt en val mij niet lastig met je interne problemen.

[Reactie gewijzigd door Bruin Poeper op 23 juli 2024 00:43]

[Jerie]

Welke groepen interne medewerkers?

Voor mij is 2FA niet onhandig. Het (complexe) wachtwoord staat namelijk toch in een wachtwoordmanager. Enige opmerkelijke is dat de token non-standard is (4 characters, en ogenschijnlijk 26 mogelijkheden).

[Bruin Poeper]

Dat jij er geen probleem mee hebt is prima.

Ik heb er wel een probleem mee, en daarom ben ik tegen. Mensen zijn nou eenmaal verschillend. OK?
Ik wordt strontziek van dingen die om de haverklap anders (en complexer!) moeten.
Daar moet de mattenklopper over.

https://www.youtube.com/watch?v=R-yBDHs3BJE

[Jerie]

Ik vind het prima dat 2FA wordt afgedwongen. Dat er mensen zijn die dat vervelend vinden vind ik nietszeggend; die mensen heb je altijd. Deze security laag is nuttig omdat mensen geen goed wachtwoord kunnen kiezen.

[Bruin Poeper]

Bij Digid hebben ze een hele waslijst van eisen waaraan je moet voldoen kwa wachtwoord.
Jij stelt dus feitelijk dat zij hun beveiliging niet op orde hebben.

Door er 2FA overheen te leggen zadelen zij mij met dubbelwerk op.
Ondertussen blijkt dat ook al niet perfect. Als dit zo door gaat is een kwestie van tijd dat ze komen met 3FA, 4FA, 5FA....

Ik heb af en toe meegemaakt dat ik bij mensen aanbelde, en dat je dan een hele rits deursloten en grendels hoort rammelen voordat de deur open gaat... Moet je eens zien wat politie/brandweer met zo'n deur doen: ze stampen er dwars door heen.

Wat ik wil zeggen is dat 1 goede beveiliging meer is dan 10 die niet deugen.
Ik heb een bankpas, een IDkaart en een rijbewijs met allemaal chips er in. Alle 3 die kaarten zijn grondig afgevinkt op correctheid bij de aanvraag. Waarom wordt daar niets mee gedaan? Die kaarten zitten zo langzamerhand voor joker in mijn portemonnee...

[Rolfie]

Als je maar tijd genoeg hebt, en langzaam naar binnen gaat, lukt alles. Menig bedrijf is zo tegenwoordig al gehacked. Gewoon stapje voor stapje doen en vooral niet te snel willen gaan.

[cracking cloud]

Ik vind het een beetje een dubieus verhaal.

Dit kan niet het hele verhaal zijn.

[Reactie gewijzigd door cracking cloud op 23 juli 2024 00:43]

[AlainG]

Ben ik met je eens. Dat je binnen geraakt, maar alle servers formatteren? En ook aan de backup kunnen? Zonder chantage? Waarom dan ?

[Jonathan-458]

Damn, dit is vrijwel zeker een gerichte aanval met als doel het bedrijf kapot te maken.

Ik denk dat men het moet zoeken bij disgruntled former employees, maintainance company of competitor.

[Reactie gewijzigd door Jonathan-458 op 23 juli 2024 00:43]

[Nature]

Of iemand die een mail naar de verkeerde persoon heeft gestuurd of spijt had van een mail, en dit de enige manier was om het ongedaan te maken.

[bussie66]

Prutsers!

Je moet ook backups op tape oid hebben die losgekoppeld zijn.