Door karma4: Door Anoniem: zucht... mr google maar wat weer... malware/cryptoware op client komt via server desondanks nog steeds op die SAN. dat is ook logisch want als client 100% absoluut geen manier had om op SAN te komen, dan was er ook geen SAN mogelijk want dan hadden block devices / files ook niet via server aangeboden kunnen worden op client: geen bit van client naar SAN <=> geen bit van SAN naar client <=> een SAN waar je niets aan hebt.
Het is de intro hoe je storagemanagement inricht in grote omgevingen. Je moet het gezien hebben om die link te vinden.
Nu geen google maar wat om iets te vinden maar google naar een link voor jou en de anderen.
De bediening en systemen blijven volledig gescheiden. Die apparatuur hoort overal buiten te blijven.
Je kan wat zien aan de hoeveelheid data en wat er veranderd. Prima om vreemd gedrag te zien en de boel op een signaal te stoppen. Of ze hebben deze aanpak niet of ze hebben dit deel toch aan het intern gehangen.
Je redenering dat de apparatuur de data transporteert en daarom besmet is, klopt niet.
Dan zou elk apparaat ofwel het hele internet dat transport doet besmet zijn. Ook een data diode valt daar dan onder.
En nee ook dat deel heeft weinig van doen dat het in een NTFS drive of ZFS driver zou zitten. Het zit aan de andere kant.
zucht... twee tegen voorbeelden om je stelling (a la "gebruik een SAN en no-more-crytpo-ellende") te ontkrachten:
1) de cryptoware zit in de windows clients en de data gaat encrypted van die bron af (via je servers, over smb) je SAN in.
2) de server gebruikt SAN en heeft een NTFS op die SAN, client wordt gehakt via phising, toegang to server wordt verkregen na tijd / social enginering en NTFS EFS wordt misbruikt => encrypted block device in je SAN [of je nu een disk in een server hebt via SAS/SATA of dat je SAN devices gekoppeld hebt via iSCSI of LUNs doet er niet toe].
dan nu omgekeerd, met je gestelde absoluutheid van je oplossing als startpunt in de logica.
dan komt je weer uit op: geen bit van client naar SAN <=> geen bit van SAN naar client <=> een SAN waar je niets aan hebt.
een paradox => een onjuist startpunt => het gebruiken van een SAN kan in zijn absolute zin dus niet een oplossing zijn tegen cryptoware.
eigenlijk alleen continue monitoring van integriteit van data in de gehele keten tesamen met regelmatig data off-line dupliceren kan je helpen tegen cryptoware. je hebt dan enkel en alleen een DETECTOR waarop je zult MOET acteren als ie af gaat. je weet dat er iets mis is, maar echt voorkomen lukt je niet.
je kunt wel damage control methodiek toepassen:
je kunt het met een goede data infra architectuur wel iets moelijker maken snelle detectie te omzeilen door bijv geen MS met NTFS op storage servers te ontsluiten naar MS clients. als storage backend ander OSen zijn met andere FSen dan clients, dan moet een hacker vanuit een client twee typen OSen pownen en FSen een loer draaien. als je dan ook nog eens 2FA op je backend gebruikt wordt dat nog extra lastiger, maar again, als de data vanaf de client (de bron) meteen al cryptoware ridden je backend in gaat, dan heb je er niets aan gehad. het andere wat je dan kan helpen is niet alles op een hoop willen zodat het pownen van een client pool niet de data opslag van onafhankelijke data pools beinvloed. dit gaat echter weer tegen de alles-centraal-is-beter-want-dan-hebben-we-overzicht visie die in IT ook heerst als een dogma.
maar er is geen silver bullet.