Skip to content

Reinstallare dopo una compromissione del root?

Ciao, abbiamo trovato la soluzione a quello che stai cercando, scorri verso il basso e lo vedrai di seguito.

Soluzione:

Soluzione 1:

Una decisione sulla sicurezza è in ultima analisi una decisione aziendale sul rischio, proprio come una decisione su quale prodotto immettere sul mercato. Se inquadrata in questo contesto, la decisione di non eliminare e reinstallare ha senso. Se la si considera da un punto di vista strettamente tecnico, non ha senso.

Ecco che cosa si fa di solito in questa decisione commerciale:

  • Quanto ci costerà il tempo di inattività in termini misurabili?
  • Quanto ci costerà potenzialmente quando dovremo rivelare ai clienti il motivo del fermo macchina?
  • A quali altre attività dovrò sottrarre le persone per effettuare la reinstallazione? Qual è il costo?
  • Abbiamo le persone giuste che sanno come ripristinare il sistema senza errori? In caso contrario, quanto mi costerà la risoluzione dei problemi?

E quindi, quando si sommano costi come questi, si può ritenere che continuare con un sistema "potenzialmente" ancora compromesso sia meglio che reinstallare il sistema.

Soluzione 2:

Basata su un post che ho scritto secoli fa, quando ancora mi prendevo la briga di scrivere sul blog.

Questa domanda continua a essere posta ripetutamente dalle vittime di hacker che si sono introdotti nel loro server web. Le risposte cambiano molto raramente, ma le persone continuano a porre la domanda. Non sono sicuro del perché. Forse alle persone non piacciono le risposte che hanno visto quando hanno cercato aiuto, oppure non riescono a trovare qualcuno di cui si fidano che dia loro un consiglio. O forse le persone leggono una risposta a questa domanda e si concentrano troppo sul 5% del motivo per cui il loro caso è speciale e diverso dalle risposte che possono trovare online, perdendo il 95% della domanda e della risposta in cui il loro caso è quasi uguale a quello che hanno letto online.

Questo mi porta alla prima importante informazione. Apprezzo molto il fatto che siate un fiocco di neve unico e speciale. Apprezzo anche il fatto che il vostro sito web lo sia, in quanto è un riflesso di voi e della vostra attività o, per lo meno, del vostro duro lavoro per conto di un datore di lavoro. Ma per chi guarda dall'esterno, sia che si tratti di una persona che si occupa di sicurezza informatica per cercare di aiutarvi, sia che si tratti dell'aggressore stesso, è molto probabile che il vostro problema sia identico almeno al 95% a tutti gli altri casi che ha esaminato.

Non prendete l'attacco sul personale e non prendete sul personale le raccomandazioni che seguono o che ricevete da altre persone. Se state leggendo queste righe dopo essere stati vittime di un attacco a un sito web, mi dispiace davvero e spero che possiate trovare qui qualcosa di utile, ma non è il momento di lasciare che il vostro ego ostacoli ciò che dovete fare.

Avete appena scoperto che i vostri server sono stati violati. E adesso?

Non fatevi prendere dal panico. Non agite assolutamente in fretta e non cercate di far finta che le cose non siano mai accadute e non agite affatto.

Primo: capire che il disastro è già avvenuto. Non è il momento di negare; è il momento di accettare ciò che è accaduto, di essere realistici e di prendere provvedimenti per gestire le conseguenze dell'impatto.

Alcuni di questi passi faranno male e (a meno che il vostro sito web non contenga una copia dei miei dati) non mi interessa se ignorate tutti o alcuni di questi passi, ma alla fine le cose andranno meglio. La medicina potrebbe avere un sapore sgradevole, ma a volte bisogna ignorarlo se si vuole che la cura funzioni davvero.

Impedire che il problema diventi più grave di quanto non sia già:

  1. La prima cosa da fare è scollegare i sistemi interessati da Internet. A prescindere dagli altri problemi, lasciare il sistema connesso al web non farà altro che permettere all'attacco di continuare. Intendo dire questo in senso letterale; fate in modo che qualcuno visiti fisicamente il server e scolleghi i cavi di rete se è necessario, ma scollegate la vittima dai suoi rapinatori prima di provare a fare qualsiasi altra cosa.
  2. Cambiate le password di tutti gli account su tutti i computer che si trovano sulla stessa rete dei sistemi compromessi. No, davvero. Tutti gli account. Tutti i computer. Sì, avete ragione, potrebbe essere eccessivo; d'altra parte, potrebbe non esserlo. Non sapete né l'una né l'altra cosa, vero?
  3. Controllate gli altri sistemi. Prestate particolare attenzione agli altri servizi connessi a Internet e a quelli che contengono dati finanziari o altri dati sensibili dal punto di vista commerciale.
  4. Se il sistema contiene i dati personali di qualcuno, informate subito tutti i potenziali interessati. So che questo è difficile. So che questo farà male. So che molte aziende vogliono nascondere questo tipo di problema sotto il tappeto, ma temo che dobbiate affrontarlo.

Esita ancora a fare quest'ultimo passo? Lo capisco, davvero. Ma vedetela così:

In alcuni luoghi potreste avere l'obbligo legale di informare le autorità e/o le vittime di questo tipo di violazione della privacy. Per quanto i vostri clienti possano essere infastiditi dal fatto che voi li informiate di un problema, saranno molto più infastiditi se non glielo dite e lo scopriranno solo dopo che qualcuno avrà addebitato merci per un valore di 8.000 dollari utilizzando i dati della carta di credito che hanno rubato dal vostro sito.

Ricordate cosa ho detto in precedenza? La cosa brutta è già successa. L'unica domanda ora è quanto bene la affronterai.

Comprendere appieno il problema:

  1. NON rimettete in linea i sistemi interessati prima che questa fase sia stata completata, a meno che non vogliate essere la persona il cui post è stato il punto di svolta che mi ha fatto decidere di scrivere questo articolo. Non sto linkando il post per farvi fare una risata a buon mercato, ma per mettervi in guardia dalle conseguenze di una mancata esecuzione di questo primo passo.
  2. Esaminate i sistemi "attaccati" per capire come gli attacchi siano riusciti a compromettere la vostra sicurezza. Fate ogni sforzo per scoprire da dove sono "venuti" gli attacchi, in modo da capire quali problemi avete e dovete affrontare per rendere il vostro sistema sicuro in futuro.
  3. Esaminate nuovamente i sistemi "attaccati", questa volta per capire dove sono andati a finire gli attacchi, in modo da comprendere quali sistemi sono stati compromessi nell'attacco. Assicuratevi di seguire tutte le indicazioni che suggeriscono che i sistemi compromessi potrebbero diventare un trampolino di lancio per attaccare ulteriormente i vostri sistemi.
  4. Assicurarsi che i "gateway" utilizzati in tutti gli attacchi siano pienamente compresi, in modo da poter iniziare a chiuderli correttamente. (Ad esempio, se i vostri sistemi sono stati compromessi da un attacco di SQL injection, non solo dovrete chiudere la particolare linea di codice difettosa da cui sono entrati, ma dovrete anche controllare tutto il vostro codice per vedere se lo stesso tipo di errore è stato commesso altrove).
  5. Capire che gli attacchi possono avere successo a causa di più di una falla. Spesso gli attacchi non riescono a trovare un bug importante in un sistema, ma a mettere insieme diversi problemi (a volte minori e banali di per sé) per compromettere un sistema. Ad esempio, utilizzando attacchi di SQL injection per inviare comandi a un server di database, scoprendo che il sito web/applicazione che si sta attaccando è in esecuzione nel contesto di un utente amministrativo e utilizzando i diritti di tale account come trampolino di lancio per compromettere altre parti di un sistema. O come gli hacker amano chiamarlo: "un altro giorno in ufficio approfittando degli errori comuni che le persone commettono".

Preparate un piano per il ripristino e per riportare il vostro sito web online e attenetevi ad esso:

Nessuno vuole rimanere offline più a lungo del necessario. Questo è un dato di fatto. Se il sito web è un meccanismo che genera entrate, la pressione per riportarlo online rapidamente sarà intensa. Anche se l'unica cosa in gioco è la vostra reputazione o quella della vostra azienda, questo genererà comunque molta pressione per rimettere le cose in piedi rapidamente.

Tuttavia, non cedete alla tentazione di tornare online troppo velocemente. Piuttosto, muovetevi il più velocemente possibile per capire cosa ha causato il problema e per risolverlo prima di tornare online, altrimenti sarete quasi certamente vittime di un'intrusione ancora una volta, e ricordate, "essere hackerati una volta può essere classificato come una sfortuna".e; essere hackerati di nuovo subito dopo sembra una negligenza" (con le scuse di Oscar Wilde).

  1. Presumo che abbiate compreso tutti i problemi che hanno portato al successo dell'intrusione prima ancora di iniziare questa sezione. Non voglio esagerare, ma se non l'avete fatto prima, allora dovete davvero farlo. Mi dispiace.
  2. Non pagate mai i soldi del ricatto o della protezione. Questo è il segno di un bersaglio facile e non volete che questa frase venga usata per descrivervi.
  3. Non siate tentati di rimettere online gli stessi server senza una ricostruzione completa. Dovrebbe essere molto più veloce costruire una nuova scatola o "bombardare il server dall'orbita e fare un'installazione pulita" sul vecchio hardware che controllare ogni singolo angolo del vecchio sistema per assicurarsi che sia pulito prima di rimetterlo online. Se non siete d'accordo con questa affermazione, probabilmente non sapete cosa significhi veramente garantire che un sistema sia completamente pulito, oppure le vostre procedure di implementazione del sito web sono un pasticcio. Probabilmente disponete di backup e di implementazioni di prova del vostro sito che potete utilizzare per costruire il sito live, e se non lo fate, l'hacking non è il vostro problema principale.
  4. Fate molta attenzione a riutilizzare dati che erano "vivi" nel sistema al momento dell'hack. Non vi dirò "non fatelo mai e poi mai" perché mi ignorereste, ma francamente credo che dobbiate considerare le conseguenze di mantenere i dati quando sapete di non poterne garantire l'integrità. L'ideale sarebbe ripristinare i dati da un backup effettuato prima dell'intrusione. Se non potete o non volete farlo, dovreste fare molta attenzione a quei dati perché sono contaminati. In particolare, dovreste essere consapevoli delle conseguenze per gli altri se questi dati appartengono a clienti o visitatori del sito piuttosto che direttamente a voi.
  5. Monitorate attentamente il sistema (o i sistemi). Dovreste decidere di farlo come processo continuo in futuro (più avanti), ma dovrete essere particolarmente vigili nel periodo immediatamente successivo al ritorno online del vostro sito. Gli intrusi torneranno quasi certamente e se riuscite a individuarli mentre tentano di introdursi di nuovo, sarete sicuramente in grado di capire rapidamente se avete davvero chiuso tutte le falle che hanno usato in precedenza e quelle che hanno creato da soli, e potreste raccogliere informazioni utili da trasmettere alle forze dell'ordine locali.

Ridurre il rischio in futuro.

La prima cosa da capire è che la sicurezza è un processo da applicare durante l'intero ciclo di vita della progettazione, dell'implementazione e della manutenzione di un sistema rivolto a Internet, non qualcosa che si può applicare in un secondo momento sul codice come una vernice scadente. Per essere adeguatamente sicuri, un servizio e un'applicazione devono essere progettati fin dall'inizio tenendo conto di questo aspetto come uno degli obiettivi principali del progetto. Mi rendo conto che è noioso e che l'avete già sentito dire e che "non mi rendo conto della pressione che c'è nel portare il vostro servizio web2.0 (beta) in stato di beta sul web, ma il fatto è che questo continua a essere ripetuto perché era vero la prima volta che è stato detto e non è ancora diventato una bugia.

Non si può eliminare il rischio. Non si dovrebbe nemmeno provare a farlo. Ciò che dovreste fare, invece, è capire quali rischi per la sicurezza sono importanti per voi e capire come gestire e ridurre sia l'impatto del rischio che la probabilità che il rischio si verifichi.

Quali misure potete adottare per ridurre la probabilità di successo di un attacco?

Per esempio:

  1. La falla che ha permesso di entrare nel vostro sito era un bug noto nel codice del fornitore, per il quale era disponibile una patch? In caso affermativo, è necessario ripensare il proprio approccio al modo in cui vengono applicate le patch alle applicazioni sui server rivolti a Internet?
  2. La falla che ha permesso di entrare nel vostro sito era un bug sconosciuto nel codice del fornitore, per il quale non era disponibile una patch? Non sono certo favorevole a cambiare fornitore ogni volta che si verifica un problema del genere, perché tutti hanno i loro problemi e, se si adotta questo approccio, si finisce per esaurire le piattaforme nel giro di un anno al massimo. Tuttavia, se un sistema vi delude costantemente, dovreste migrare verso qualcosa di più robusto o, come minimo, riarchitettare il vostro sistema in modo che i componenti vulnerabili rimangano avvolti nell'ovatta e il più lontano possibile da occhi ostili.
  3. La falla era un bug nel codice sviluppato da voi (o da un appaltatore che lavora per voi)? Se è così, dovete ripensare il vostro approccio al modo in cui approvate il codice da distribuire al vostro sito live? Il bug avrebbe potuto essere individuato con un sistema di test migliore o con modifiche allo "standard" di codifica (ad esempio, sebbene la tecnologia non sia una panacea, è possibile ridurre la probabilità di successo di un attacco SQL injection utilizzando tecniche di codifica ben documentate).
  4. La falla è dovuta a un problema di distribuzione del server o del software applicativo? In caso affermativo, state utilizzando procedure automatizzate per costruire e distribuire i server, ove possibile? Queste sono di grande aiuto per mantenere uno stato "di base" coerente su tutti i vostri server, riducendo al minimo la quantità di lavoro personalizzato che deve essere fatto su ciascuno di essi e quindi, si spera, riducendo al minimo l'opportunità di commettere un errore. Lo stesso vale per il deployment del codice: se si richiede di fare qualcosa di "speciale" per distribuire l'ultima versione della propria applicazione web, si cerca di automatizzarlo e di assicurarsi che venga fatto sempre in modo coerente.
  5. L'intrusione avrebbe potuto essere colta prima con un migliore monitoraggio dei vostri sistemi? Naturalmente, un monitoraggio 24 ore su 24 o un sistema di "reperibilità" per il vostro personale potrebbero non essere economicamente vantaggiosi, ma ci sono aziende che possono monitorare i vostri servizi web per voi e avvisarvi in caso di problemi. Potreste decidere di non potervelo permettere o di non averne bisogno, e va bene così.ma prendetelo in considerazione.
  6. Utilizzate strumenti come tripwire e nessus, se necessario, ma non usateli alla cieca perché ve lo dico io. Prendetevi il tempo necessario per imparare a usare alcuni buoni strumenti di sicurezza adatti al vostro ambiente, teneteli aggiornati e usateli regolarmente.
  7. Considerate la possibilità di assumere esperti di sicurezza per "controllare" regolarmente la sicurezza del vostro sito web. Anche in questo caso, potreste decidere di non potervelo permettere o di non averne bisogno, e va bene così.ma prendetelo in considerazione.

Quali misure potete adottare per ridurre le conseguenze di un attacco riuscito?

Se decidete che il "rischio" di allagamento del piano inferiore della vostra casa è alto, ma non abbastanza da giustificare un trasloco, dovreste almeno spostare gli insostituibili cimeli di famiglia al piano superiore. Giusto?

  1. È possibile ridurre la quantità di servizi direttamente esposti a Internet? È possibile mantenere una sorta di distanza tra i servizi interni e quelli rivolti a Internet? In questo modo, anche se i sistemi esterni vengono compromessi, le possibilità di utilizzarli come trampolino di lancio per attaccare i sistemi interni sono limitate.
  2. State memorizzando informazioni che non avete bisogno di memorizzare? State conservando tali informazioni "online" quando potrebbero essere archiviate altrove. Questa parte ha due aspetti: il primo è che non si possono rubare informazioni che non si possiedono e il secondo è che meno informazioni si archiviano, meno si deve mantenere e codificare e quindi ci sono meno possibilità di infiltrare bug nel codice o nella progettazione dei sistemi.
  3. State utilizzando i principi del "minimo accesso" per la vostra applicazione web? Se gli utenti devono solo leggere da un database, assicuratevi che l'account che l'applicazione web utilizza per servire questo database abbia solo accesso in lettura, non consentitegli l'accesso in scrittura e certamente non l'accesso a livello di sistema.
  4. Se non siete molto esperti in qualcosa e non è centrale per la vostra attività, prendete in considerazione la possibilità di esternalizzarla. In altre parole, se gestite un piccolo sito web che parla di scrittura di codice per applicazioni desktop e decidete di iniziare a vendere piccole applicazioni desktop dal sito, considerate di "esternalizzare" il sistema di ordini con carta di credito a qualcuno come Paypal.
  5. Se possibile, fate in modo che il recupero pratico dei sistemi compromessi faccia parte del vostro piano di Disaster Recovery. Questo è probabilmente solo un altro "scenario di disastro" che potreste incontrare, semplicemente uno con una propria serie di problemi e questioni che si distinguono dal solito "la stanza del server ha preso fuoco"/"è stata invasa da giganteschi pelosi mangiatori di server". (modifica, per XTZ)

. E infine

Probabilmente ho tralasciato un sacco di cose che altri considerano importanti, ma i passi sopra descritti dovrebbero almeno aiutarvi a iniziare a sistemare le cose se siete abbastanza sfortunati da cadere vittima degli hacker.

Soprattutto: Non fatevi prendere dal panico. Pensate prima di agire. Agite con fermezza una volta presa una decisione e lasciate un commento qui sotto se avete qualcosa da aggiungere al mio elenco di passi.


Soluzione 3:

Sempre bombardarlo dall'orbita. È l'unico modo per essere sicuri.

alt text
(fonte: flickr.com)

La maggior parte dei sistemi sono entità olistiche che hanno una fiducia interna, implicita. Fidarsi di un sistema compromesso significa dichiarare implicitamente che ci si fida di chi ha violato il sistema. In altre parole:

Non ci si può fidare. Non preoccupatevi della pulizia. Scollegate e isolate immediatamente la macchina. Capire la natura della violazione prima di procedere, altrimenti si invita a ripetere la stessa cosa. Se possibile, cercate di ottenere la data e l'ora della violazione, in modo da avere un quadro di riferimento. Questo è necessario perché se si ripristina da un backup, bisogna essere sicuri che il backup stesso non contenga una copia della violazione. Pulite prima di ripristinare, non prendete scorciatoie.


Soluzione 4:

In pratica, la maggior parte delle persone non lo fa perché pensa che ci voglia troppo tempo o che sia troppo dispendioso. Ho avvisato innumerevoli clienti della probabilità che i problemi continuino, ma una reinstallazione viene spesso rifiutata da un responsabile per uno di questi motivi.

Detto questo, sui sistemi in cui sono sicuro di conoscere il metodo di accesso e l'entità del danno (solidi log fuori dalla macchina, in genere con un IDS, forse SELinux o qualcosa di simile che limita la portata dell'intrusione), ho fatto una pulizia senza reinstallazione senza sentirmi troppo in colpa.


Soluzione 5:

Molto probabilmente non hanno una routine di disaster recovery sufficientemente testata per sentirsi sicuri di eseguire una ricostruzione, oppure non è chiaro quanto tempo ci vorrebbe o quale sarebbe l'impatto.o i backup sono inaffidabili o i loro analisti del rischio non comprendono la portata di un sistema compromesso. Mi vengono in mente molte ragioni.

Direi che per lo più si tratta di qualcosa che non funziona nelle routine e nelle politiche di base e che non si vuole ammettere apertamente - e invece si assume una posizione difensiva. Almeno io non riesco a vedere o a difendere la mancata cancellazione di un sistema compromesso, da qualsiasi angolazione lo si guardi.

Ricorda che hai la possibilità di aggiungere una valutazione corretta se necessario.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.