Hard disk di rete isolato

[nengistelle]

Salve, nell'azienda in cui lavoro, hanno da poco messo un hard disk di rete per fare il backup dei dati.Ora mi è venuto un dubbio : se 1 o + pc prendono un virus e questo si diffonde in rete, anche l'hard disk di rete potrebbe infettarsi, e quindi i backup potrebbero avere dei problemi.
C'è un modo per evitare che possa succedere uan cosa del genere?
Se l'hard di rete lo metto su un'altro gruppo di lavoro?

[teo180]

Se è un nas con sistema operativo su base Linux non ha possibilità di essere infettato come un Windows.
L'unica cosa è che se fa un backup con file già corrotti, per forza di cose i file vengono copiati anche nel backup se non si fa in tempo ad accorgersene.
Anche se fosse i backup degli altri pc rimarrebbero intatti.

[nengistelle]

No , non è un nas,ma un semplice hard disk di rete

[Kaya]

Come già risposto, il disco di rete per il backup deve essere accessibile solo dal server dei backup. Siccome è difficile che il server prenda un virus, questo è abbastanza protetto.
Chiaramente se come nel tuo caso usano RDP per accedere al server, le difficoltà aumentano.
Consiglio spassionato:
due hard-disk tra loro scambiati settimanalmente
Togli la condivisione del disco agli utenti RDP

[nengistelle]

Anche io avevo pensato agi hard disk scambiati, però è una soluzione poco pratica ,in quanto servirebbe una persona apposta che unn volta a settimana ti viene a cambaire gli hard disk .

[Kaya]

Originariamente inviato da nengistelle

Anche io avevo pensato agi hard disk scambiati, però è una soluzione poco pratica ,in quanto servirebbe una persona apposta che unn volta a settimana ti viene a cambaire gli hard disk .

Non serve una persona apposta, basta uno dei dipendenti che venga istruito.
Il punto è sempre quello: che valore (economico) dai ai tuoi dati?

[nengistelle]

Ti farei conoscere i dipendenti della farmacia.Il più risoluto non sa neanche riavviare il pc, e non scherzo !!

[Tasslehoff]

Aspetta, dipende molto anche da come viene fatto questo backup.
Se si tratta di una semplice copia dei file su share di rete e un client si becca una schifezza (es cryptolocker o in generale qualche ransomware) allora anche i file backuppati hanno buona probabilità di finire criptati e persi o cmq esposti al malware.
Se invece il backup è fatto in modo sensato (basta anche solo un file compresso, un tar, o un archivio magari criptato, insomma un formato non suscettibile alla corruzione da parte del malware) allora con una opportuna retention puoi recuperare tutto.
Se ad esempio usi il semplice ed efficacissimo duplicati (o duplicity se usate gnu/linux) puoi stare relativamente tranquillo senza usare tecniche bislacche e inefficaci (perché dipendenti da intervento umano) come lo swap dei dischi

[nengistelle]

in teoria, un virus non potrebbe attaccare anche un file compresso e renderlo inaccessibile?

[Dane]

Originariamente inviato da nengistelle

in teoria, un virus non potrebbe attaccare anche un file compresso e renderlo inaccessibile?

i "virus" vengono presi dagli utenti, e quindi girano con i privilegi degli utenti.

Non c'è nessun motivo per il quale gli utenti abbiano accesso ai backup. Sia in lettura che in scrittura/modifica.

[nengistelle]

ok, ma se 1 pc prende un virus, questo poi si puo diffondere su tutta la rete.come successo una volta.
puo capitare che anche l'amministraore ha il suo pc con un virus e non se ne accorge.
Anche se solo l'amministartore ha la possibilità di leggerli e modificarli, li rende immuni dai dipendenti ma non dai virus.Penso, mi sembrerebbe troppo facile.

[Dane]

Originariamente inviato da nengistelle

ok, ma se 1 pc prende un virus, questo poi si puo diffondere su tutta la rete.come successo una volta.
puo capitare che anche l'amministraore ha il suo pc con un virus non se ne accorge.

Si.
Può anche essere che hai già da tempo un malware che srutta una vulnerabilità 0-day della quale non te ne accorgerai finchè non ci sarà un'esplosione termonucleare del disco di backup...

Ma se non dai mai privilegi amministrativi agli utenti, se per attività amministrative gli amministratori usano un'utenza dedicata, credimi che è molto più difficile avere problemi.

[nengistelle]

appunto, proprio per quelo sto cercando un modo per mettere al riapro i backup.
Anche se li faccio compressi e poi criptati, non penso che sia difficile per un virus rendere gli archivi illeggibili o comunque danneggiarli, anche con permessi vari.

[Dane]

Se il virus gira con i privilegi utente "limitato", e tale utente non ha alcun tipo di accesso ai backup allora si: è difficile e improbabile che riesca a fare privilege escalation in completa autonomia.

Se poi decidi di mettere i backup su un disco esterno è meglio, ma ciò non ti risolverà in automatico diversi problemi. Devono esserci apposite utenze anche sul disco di rete. Il processo di backup deve girare con un'utenza a parte. Gli utenti non devono aver alcun accesso alla configurazione del processo di backup.

Meglio ancora se fai dei backup di tipo pull, ovvero il disco di rete (dei backup) inizia il backup, si collega sul server con i dati da backuppare e infine lo fa.
Ma, sempre in ottica di attacco termonucleare, se vuoi prevenire di perdere tutti a causa di uno sbalzo di tensione (che ti fa fuori tutto il server e tutto il disco di rete) dovresti avere un'altro disco di rete, configurato in maniera identica, che alterni settimanalmente o mensilmente.



Secondo me devi decidere quanto puoi permetterti di perdere, nella peggiore delle ipotesi.
Se si tratta di un mese (spesso è sufficiente) usi tre dischi per i backup:
- A disco backup mensili
- B disco backup mensili - secondario
- C disco backup "correnti" (totali+differenziali/incrementali.)

Ogni giorno fai un backup differenziale/incrementale sul disco C.
Una volta al mese viene fatto un backup completo, sempre sul disco C.
Quando viene fatto il backup completo, questo viene copiato sul disco A. Se non c'è abbastanza spazio cancella il più vecchio.
Quando finisce manda una mail alla persona più diligente che hai a disposizione. Questa è istruita a togliere il disco A con il B. Il disco A va in un'altro posto.
Il mese successivo stessa procedura. Vengono scambiati disco B con il disco A.

Se hai un server con hotswap non è necessario nemmeno avere un disco di rete.
E' più importante che la rotazione venga fatta sempre, da una persona che stacca il disco corretto. :-)

[nengistelle]

Ripeto, i dipendenti sono totalmente incapaci, quindi toccherebbe a me fare questi spostamenti, e conoscendo il titolare ("el tirchios"), magari mi mette 1 euro lordo in + sulla busta paga (non scherzo).Pensa che quando prendo delle medicine per me mi fa pagare il prezzo pieno, e una volta gli ho comprato un switch di rete nuovo, pagato 104 euri, mi ha dato 105 e gli ho ridato 1 euro di resto.Quindi gli dico che l'unica soluzione è fare il backup su un cloud,poi se la vedesse lui.
Tutto è nato perchè un'altra farmacia ha preso il virus che cripta i dati. e quidni lui voleva sapere se cìera una soluzione-
grazie a tutti

[Tasslehoff]

Originariamente inviato da nengistelle

appunto, proprio per quelo sto cercando un modo per mettere al riapro i backup.
Anche se li faccio compressi e poi criptati, non penso che sia difficile per un virus rendere gli archivi illeggibili o comunque danneggiarli, anche con permessi vari.

Assolutamente, anche se a onor del vero è una casistica decisamente remota.
La compromissione di file ad opera di malware viene fatta per sfruttare la vittima, o per avere un riscatto (cryptolocker e ransomware vari) oppure per usarla come veicolo di spam o diffusione del malware stesso.
Compromettere un file binario (come può essere un archivio criptato) non avrebbe molto senso, perchè con la stessa logica i malware potrebbero attaccare un binario chiave del sistema operativo; la conseguenza sarebbe un client KO, che non servirebbe ne a ottenere un riscatto ne a diffondere il malware.
Non a caso i ransomware vanno a colpire file vitali per i dati che contengono, non per il funzionamento del sistema operativo o di una applicazione.

A prescindere da ciò può comunque succedere che un backup venga colpito se non protetto adeguatamente.
Proprio per questo si tiene uno storico dei backup (e nei migliori scenari anche copie multiple su repository diversi) ma soprattutto i backup vanno testati facendo prove periodiche di restore.

Un backup può essere compromesso, l'importante è rendersene conto e operare di conseguenza.

Originariamente inviato da Dane

E' più importante che la rotazione venga fatta sempre, da una persona che stacca il disco corretto. :-)

Io è su questo che ho delle perplessità, per carità potrò anche essere smentito da qualche operatore molto diligente, però in linea di principio imho non può essere ritenuta affidabile una linea che preveda un qualsiasi intervento manuale.
Per quanto mi riguarda il backup:
- deve essere fatto
- deve essere automatizzato e non dipendente dal fattore umano
- deve essere testato con restore periodici
- deve inviare notifiche automatiche solo in caso di errore

[conzi]

Originariamente inviato da Tasslehoff

Compromettere un file binario (come può essere un archivio criptato) non avrebbe molto senso, perchè con la stessa logica i malware potrebbero attaccare un binario chiave del sistema operativo; la conseguenza sarebbe un client KO, che non servirebbe ne a ottenere un riscatto ne a diffondere il malware.
Non a caso i ransomware vanno a colpire file vitali per i dati che contengono, non per il funzionamento del sistema operativo o di una applicazione.

A prescindere da ciò può comunque succedere che un backup venga colpito se non protetto adeguatamente.
Proprio per questo si tiene uno storico dei backup (e nei migliori scenari anche copie multiple su repository diversi) ma soprattutto i backup vanno testati facendo prove periodiche di restore.

Un backup può essere compromesso, l'importante è rendersene conto e operare di conseguenza.

Io è su questo che ho delle perplessità, per carità potrò anche essere smentito da qualche operatore molto diligente, però in linea di principio imho non può essere ritenuta affidabile una linea che preveda un qualsiasi intervento manuale.
Per quanto mi riguarda il backup:
- deve essere fatto
- deve essere automatizzato e non dipendente dal fattore umano
- deve essere testato con restore periodici
- deve inviare notifiche automatiche solo in caso di errore

ci sono versioni di cryptolocker che criptano praticamente qualsiasi cosa.
Ho visto criptare i files da 1,5Gb di drivesnapshot.
Da ora in poi solo backup su nas via ftp, con share di rete disabilitati.

[Tasslehoff]

Originariamente inviato da conzi

ci sono versioni di cryptolocker che criptano praticamente qualsiasi cosa.
Ho visto criptare i files da 1,5Gb di drivesnapshot.
Da ora in poi solo backup su nas via ftp, con share di rete disabilitati.

Ah si si su questo sono assolutamente d'accordo, network share Windows e samba devono sparire, idem per lo storage DAS (es dischi usb), a prescindere che si parli di backup o altro.
Non a caso i semplici tool che ho descritto in un mio precedente post possono (e devono imho) usare ben altri protocolli, es ftp o sftp.

[nengistelle]

Salve, riprendo questo topic.
Un'altra farmacia della nostra zona ha preso sto cavolo di crypto virus, e quando il mio titolare ha saputo che il gestore della rete e del server per ripristinare tutto ha chiesto 5.000 euri, ora mi sta tartassando per trovare una soluzione.
Posso mettere il nas in una sorta di sotto rete, così da renderlo esterno alla rete principale?
Purtroppo l'idea di fare il backup su un cloud, che è la migliore soluzione, è impossibile in quanto l'upload è troppo lento.Per inviare 1 gb di dati ci vogliono 6 ore.

[nanotek]

Backup su nas via ftp e hai risolto.
Finora nessun cryptolocker si è spinto a criptare i file su ftp.

Per stare più sicuro compra un secondo nas e fai il backup del primo nas sul secondo. Non sincronizzazione, backup.