none
Server fuori dominio RRS feed

  • Discussione generale

  • Buongiorno,

    descrivo brevemente la situazione. Ho un utente che non ha difese perimetrali adeguate. Per sua responsabilità (dopo i primi attacchi da cui si è salvato per miracolo avevo fatto un progetto completo di Firewalling),ha continuato a tergiversare sull'adozione di opportune protezioni, finchè non ha subito un grave attacco a seguito del quale gli sono stati criptati una quindicina di server fra fisici e virtuali.

    Ora, dopo la batosta subita, vuole fare tutto ed anche l'inutile.

    La cosa più grave, e quì vengo al motivo di questa discussione, quei criminali gli hanno cancellato completamente le unità di backup (cancellate, non criptate).

    Dopo una riunione con la proprietà un consulente esterno che io non conosco ha consigliato in prima battuta quanto segue:

    1. Togliere dal dominio il server che gestisce i backup;
    2. Modificarne le credenziali;
    3. Metterlo su una vLan creata ad hoc, configurata in modo che possa accedere alla rete ma la rete non possa accedere a lui.

    Non vi sono problemi a realizzare quanto richiesto, ma ho dei dubbi sull'efficacia di tale soluzione e che si possa mettere al riparo il server di backup e gli storage associati da futuri attacchi. Ho come l'impressione di proteggere questa struttura con una staccionata per cavalli, ma da cui si possa entrare scavalcando le traverse.

    Mi interesserebbe conoscere il Vostro parere e le Vostre considerazioni.

    Grazie a tutti per l'aiuto che vorrete darmi.

    Ovviamente si procede a questo punto con la messa in sicurezza dell'intera rete.

    Saluti cordiali.


    Gaetano

    giovedì 22 marzo 2018 07:18

Tutte le risposte

  • Ciao. 

    Puoi descrivere le strategie di backup che utilizzava il cliente e nel dettaglio gli elementi del backup. 

    Perché come lo hai descritto può andar bene per file e cartelle. 

    Ma i backup delle macchine virtuali etc etc come ti ha detto che vuole gestirlo? Mia curiosità :-)

    Marco

    giovedì 22 marzo 2018 08:55
  • Certamente Marco,

    Il salvataggio, sia dei server fisici che di quelli virtuali, avviene di notte tramite un software molto noto di backup che mediante appropriati piani salva ogni intera macchina su uno storage in iscsi di opportune dimensioni.

    Ovviamente i piani sono organizzati con criteri specifici per FULL-INCREMENTALE-DIFFERENZIALE e con retention calibrate.

    Ora non capisco se quanto consigliato da quel "consulente" può proteggermi da attacchi che portano alla cancellazione dei NAS.

    Io penso che non serva a niente, ma forse mi sbaglio.

    Cordiali saluti


    Gaetano

    giovedì 22 marzo 2018 09:33
  • Io la vedo così .. poi correggimi se sbaglio. 

    L'attacco che ha avuto il cliente non è un semplice cryptovirus che è stato lanciato per sbaglio.

    Hanno bucato il sistema di protezione, hanno avuto accesso alla struttura e da lì hanno fatto quello che dovevano fare per poi cryptare il tutto per non lasciare tracce. 

    Hanno cancellato i backup, le shadow copy, etc etc.

    Va bene salvaguardare i backup ma prevenire l'attacco è  meglio che curare.

    Marco

    giovedì 22 marzo 2018 09:58
  • Se bucano i server e su questi server c'è uno storage iscsi collegato allora proprio non va bene: ci mettono un attimo a cancellarvi i backup. Quello che ha detto in consulente ci può stare, bisogna solo capire (e riprendo la frase)

    1. Metterlo su una vLan creata ad hoc, configurata in modo che possa accedere alla rete ma la rete non possa accedere a lui.

    Il software di backup supporta questa soluzione? Non è che ha bisogno di una comunicazione "bi-direzionale" per funzionare correttamente?

    Altra soluzione potrebbe essere salvare i backup su un NAS, creare un utente ad hoc dentro al NAS dove SOLO LUI ha accesso alla cartella dei backup e poi impostare questo utente per il backup. In questo modo i backup andranno (a livello di servizio o applicativo) con questo specifico utente, ma gli utenti di dominio non hanno accesso alla cartella dei backup.

    Queste sopra sono la soluzione "economica".

    A mio avviso comunque la soluzione più sicura e semplice è fare il backup in Cloud. Vista la struttura del cliente immagino che abbia anche una buona connettività (o che comunque se la possa permettere). Noi ad esempio ai nostri clienti forniamo una soluzione che fa il backup locale e replica in cloud con tanto di virtualizzazione sia locale che cloud.

    Questa sopra è la soluzione "intermedia".

    Altrimenti ancora soluzioni di Iperconvergenza per avere una "vera" business continuity e protezione contro ransomware ecc. Di soluzioni ce ne sono diverse.

    Questa è la soluzione "più costosa".



    giovedì 22 marzo 2018 10:09
  • Ora non so come era configurata precedentemente questa rete, ma per arrivare a tanto secondo me c'erano anche evidenti errori di configurazione nel dominio (ad esempio backup con utente di dominio amministrativo, utenti "normali" con account amministrativi a livello di dominio, server non aggiornati, privilegi errati sulle condivisioni, accessi esterni RDP, FTP o altro non opportunamente protetti eseguiti sempre con utenze di dominio).
    Quindi non è l'inserire i server in dominio la causa del problema ma come questo è stato configurato.
    Per come vedo io la cosa, oltre che ripensare le sole politiche di backup, dovresti rivedere proprio l'intera infrastruttura altrimenti qualsiasi intervento non sarebbe efficace (una rete "isolata" per il backup lascia il tempo che trova, così come il lasciare il NAS di backup fuori dominio. In caso di compromissione dell'account utilizzato per i backup non risolvi comunque il problema perché se questo account può scrivere nella condivisione i file di backup può tecnicamente anche crittografarli o in alcuni casi eliminarli).
    Una volta rivista l'intera infrastruttura si può poi pensare di incrementare la sicurezza, ad esempio attraverso un proxy, delle policy che bloccano l'esecuzione dei file nelle cartelle AppData  o antivirus appositi.
    Anche una politica di archiviazione dei backup offline potrebbe risultare efficace.


    giovedì 22 marzo 2018 12:14
    Moderatore
  • Grazie per i feedback.

    Cerco di rispondere un pò a tutti.

    Come ho già detto il cliente aveva già subito qualche tentativo di attacco (soprattutto RDP), da cui ci si è salvati per miracolo.

    Tutto nasceva dal fatto che la protezione perimetrale era affidata ad uno specifico provider che forniva e gestiva anche i firewall e questi erano dei veri e propri colabrodi.

    Feci pressione quindi perchè venissero chiuse tutte le porte e bloccato il bloccabile.

    Nel frattempo, dopo analisi accurata, proposi una soluzione completa e senza compromessi di firewalling perimetrale proprietario (per interderci su tecnologia CP).

    E fin quì tutto ok; ma subito nascono i problemi. Il decision manager, prendendo spunto dal mio progetto, ha incominciato a chiedere offerte e quotazioni a cani e porci e le cose si sono trascinate per mesi fino allo sfascio.

    Contemporaneamente a questo progetto, sottoposi un progetto per backup che rispettasse la regola del 3 o quantomeno del due (NAS e Cloud). 

    Progetto regolarmente bocciato dal decision manager (Ma ci serve proprio?)

    Ora sto valutando anche soluzioni di Data Protection EMC.

    Questo nell'ottica che spesso i clienti vogliono chiudere le stalle solo quando i buoi sono scappati.

    Ma ritornando alla mia domanda iniziale, io resto dell'idea che la soluzione prospettata dal consulente lasci il tempo che trova e che bisogna invece adoperarsi per un backup meno economico e che dia garanzie di business continuity.

    Ogni ulteriore commento è gradito.

    Ciao a tutti.


    Gaetano

    giovedì 22 marzo 2018 12:24
  • Ciao a tutti, mi inserisco anche io per portare un contributo...tra le altre cose mi pagano per bucare le reti altrui quindi qualcosina ho estrapolato nel corso del tempo. Per prima cosa il firewall non ti ferma gli attacchi dei ransomware. Ad oggi di piattaforme UTM che stoppano i crypto non ce ne sono. Analizzano magari il traffico e riescono a volte a trovare hives nocive e le cassano, magari hanno degli IDS ed IPS che bloccano i bruteforce, i port scanning e tutto quello che ne tiene dietro, ma non ci si può affidare al firewall per bloccare il ransomware perchè non è il suo lavoro. La cosa più sicura a quel livello è avere un IPS\IDS attivo ed una VPN per la connessione ai servizi, se hai rdp aperta al mondo..paghi dazio prima o poi.

    Quindi firewall ok, ma con la giusta cautela. Per il resto, backup in cloud od in locale non cambia molto, l'importante è 

    - non usare ISCSI sulle macchine come dischi di backup (come dice Victor giustamente)

    - usare delle share con accessi autorizzati solo ad un utente di backup per i salvataggi (può essere anche un utente di AD, ma personalmente evito, faccio un utente locale sul NAS, se mi bucano l'AD quello non compare da nessuna parte

    - usare macchine dedicate per i backup magari virtuali in cui il sw di backup abbia le credenziali criptate per l'accesso alle share ed una console con accesso user e pwd.

    - usare un sw di backup che abbia un fastrecovery o fast start sulle VM (non è essenziale, ma se mi sono protetto e mi bucano lo stesso almeno che io possa riprendermi in fretta)

    con questi accorgimenti sei blindato al 99%. Il 100% non l'hai mai. Tieni conto che un salvataggio in cloud è tanto comodo quanto scomodo se ti tocca ripristinare 15 server: ci mette un botto di tempo. Me lo terrei semmai come backup secondario perchè oltre a costare di più, è molto più veloce un bel NAS a 4 NIC sulla rete locale. Il discorso VLAN, DMZ ecc se hai configurato bene il tuo backup non ha senso, vai a far viaggare ulteriori livelli di traffico sulla rete per nulla (capiamoci, nei datacenter lo fanno...ma con 15 server non ha senso..)

    Non sono a conoscenza di crypto che bucano NAS e cancellano i backup se ci sono utenti dedicati e con password strong...quello fa parte delle leggende che seguono il ransomware.

    My two cents.

    ciao a tutti.

    A.

    giovedì 22 marzo 2018 14:52
    Moderatore
  • La risposta di Alessandro è piuttosto illuminante.

    Posso solo aggiungere che a complicare le cose ci sono i vari vendor, che spacciano come la panacea universale le loro soluzioni di firewalling.

    E non sono solo quelli che hanno prodotti di basso livello, ma anche quelli più quotati come CP, PA etc (uso solo le sigle e spero abbiate capito). A loro parere, dando anche il software completo come varie blade, dovremmo dormire sonni tranquilli sia per quanto riguarda le minacce note che quelle non note con in più anche la completa compliance con GDPR (va molto di moda e sentivamo proprio la mancanza di questa ulteriore complicazione).

    Boh, io non sarei così sicuro; spesso confondono le idee anche a me che me ne occupo per mestiere, figurarsi al cliente!

    Per non parlare di quei rivenditori senza scrupoli (che pur di portare a casa il contratto) si inventano di ogni.

    Grazie a tutti comunque per le interessanti considerazioni.


    Gaetano

    venerdì 23 marzo 2018 06:11
  • Ancora una cosa, c'è da qualche parte una sorta di elenco di MVP o MCC Partners in modo da trovare qualcuno che risieda nella mia zona e abbia voglia di collaborare con me a dei miei progetti?

    Grazie


    Gaetano


    • Modificato Nick2005 venerdì 23 marzo 2018 06:16
    venerdì 23 marzo 2018 06:16
  • Ciao

    https://mvp.microsoft.com/en-us/MvpSearch

    venerdì 23 marzo 2018 07:16
  • Forse sul portale MVP non sono regionalizzati, ti consiglio eventualmente di usare Linkedin, li trovi sia gli MVP che altrettanti professionisti validi del settore.

    ciao.

    A.

    venerdì 23 marzo 2018 08:35
    Moderatore
  • Di che zona sei Gaetano?
    venerdì 23 marzo 2018 09:54
  • Brescia

    Gaetano

    venerdì 23 marzo 2018 13:49
  • Vorrei che mi spiegaste un pò meglio perchè non va bene un iscsi.

    Mi spiego meglio.

    Il cliente aveva una san netgear (costata parecchi soldi) usata come storage per VM.

    Dopo neppure un anno e mezzo Netgear ci dice che questo dispositivo non supporta più le release più recenti dell'hypervisor; quindi delle due l'una, o non aggiornare più l'ypervisor o cambiare la san.

    Si è preferita questa seconda soluzione, cambiando sia modello che brand.

    Il cliente, a questo punto, per non buttare via l'apparecchiatura precedente ha pensato di utilizzarla per i backup.

    Ora vorrei capire perchè è pericoloso usarla per questa attività, fermo restando che comunque passeremo ad altre tecnologie e metodiche di data protection.

    Grazie per gli eventuali chiarimenti.


    Gaetano

    sabato 24 marzo 2018 06:32
  • Iscsi è un disco fisico attaccato alla macchina, soggetto quindi all'username  password di quella macchina. Se ti viene bucata da un crypto la macchina dei backup ti criptano anche tutto l'iscsi. Ecco il motivo.

    Una share di rete è invece potenzialmente non bucabile a meno che il sw di bakup non si tenga le credenziali in chiaro, ma sarebbe una cosa vecchia di mille anni.

    A livello prestazioni sono identiche, passano sempre per lo stesso bocchettone di rete.

    A livello di ripristino in caso di disaster devo rifare una vm, rimettere l'iscsi agganciato, e far partire il recovery. Se una share lo lanci diretto e basta.

    Quindi per i backup meglio le share. 

    ciao.

    A.

    sabato 24 marzo 2018 07:40
    Moderatore
  • Ciao Alessandro. 

    Mi permetto di aggiungere anche questo articolo, datato ma illuminante.

    https://blogs.technet.microsoft.com/larryexchange/2016/01/10/iscsi-or-smb-direct-which-one-is-better/

    Marco

    sabato 24 marzo 2018 09:09
  • - non usare ISCSI sulle macchine come dischi di backup (come dice Victor giustamente)

    - usare delle share con accessi autorizzati solo ad un utente di backup per i salvataggi (può essere anche un utente di AD, ma personalmente evito, faccio un utente locale sul NAS, se mi bucano l'AD quello non compare da nessuna parte

    - usare macchine dedicate per i backup magari virtuali in cui il sw di backup abbia le credenziali criptate per l'accesso alle share ed una console con accesso user e pwd.

    - usare un sw di backup che abbia un fastrecovery o fast start sulle VM (non è essenziale, ma se mi sono protetto e mi bucano lo stesso almeno che io possa riprendermi in fretta)

    Mi consola vedere che, nel mio piccolo (i miei clienti hanno al massimo 2 o 3 server in VM) ho optato proprio per una soluzione del genere: backup su NAS protetto da credenziali locali, note solo al programma di backup. Condivisioni NAS nascoste a chi non ha permessi.

    Dai clienti "facoltosi" uso una suite a pagamento che consente il recovery pressoché immediato (test ultimo DR: VM nuove su in 15 minuti).

    Dai clienti meno danarosi uso la versione free dello stesso prodotto (solo agent installato sui singoli server) che chiaramente non consente tante cose, ma la funzione base ce l'ha

    sabato 24 marzo 2018 23:12
  • I miei clienti usano tutti suite a pagamento (soprattutto la 12.5 adv di AC). Tu quale usi, per mia curiosità?

    Gaetano

    domenica 25 marzo 2018 06:50
  • Non comparerò le suite dei vendor. Ma che arrivi al FastRecovery di Veeam non c’è nulla. Comunque Sky, usiamo la stessa cosa. Se vuoi un backup che non baglia mai un colpo li devi andare...è un punto di riferimento. Ciao! A. PS ho alcuni clienti che hanno l’instant replication, il recovery delle vm avviene sotto il minuto! Ma li sono soldoni...
    domenica 25 marzo 2018 08:44
    Moderatore
  • Veeam.

    La suite Backup&Replication per i clienti "danarosi" (la licenza supera i 1000€ e non tutti percepiscono i vantaggi di tale prodotto, anche se glieli si spiega bene).

    L'Endpoint Free per gli altri (che però, per esempio, può essere installato solo da WinServer 2008R2 in su perché necessita di Dot.Net 4.7)

    martedì 27 marzo 2018 16:31
  • Sky, devi prendere la Essentials! È fino a 6 hosts, ma costa meno ed ha le stesse funzionalità, l’hanno fatta apposta. Ciao! A.
    martedì 27 marzo 2018 18:53
    Moderatore
  • Grazie, ho visto
    martedì 27 marzo 2018 20:34
  • Ciao a tutti,

    giusto per completare la discussione.

    Dal momento che debbo fare il backup di soli server e non di client, mi è stato consigliato di utilizzare come protocollo NFS e non SMB.

    Vorrei essere sicuro che sia la scelta giusta.

    Cosa ne pensate.

    Grazie a tutti.


    Gaetano

    martedì 3 aprile 2018 06:04
  • Consigliato da chi? Un linuxiano? :-) Il dato deve essere salvato, fine. Puoi usare anche rsync od ftp od il protocollo più sconosciuto del mondo basta che poi tu possa averne accesso. Chiaro ci sono differenze, ma se il tuo sw di backup ragiona SMB usa SMB.

    ciao.

    A.

    martedì 3 aprile 2018 07:30
    Moderatore