it-swarm.dev

Come gestisco un server compromesso?

Sospetto che uno o più dei miei server siano compromessi da un hacker, un virus o un altro meccanismo:

  • Quali sono i miei primi passi? Quando arrivo sul sito dovrei disconnettere il server, conservare "prove", ci sono altre considerazioni iniziali?
  • Come posso ottenere i servizi online?
  • Come evitare che la stessa cosa accada di nuovo immediatamente?
  • Esistono best practice o metodologie per l'apprendimento da questo incidente?
  • Se volessi mettere insieme un piano di risposta agli incidenti, da dove iniziare? Questo dovrebbe far parte del mio Disaster Recovery o della pianificazione della continuità operativa?

Questo dovrebbe essere un post canonico per questo argomento. Originariamente da serverfault .

165
Lucas Kauffman

Originariamente da serverfault.Grazie a Robert Moir (RobM)

È difficile dare consigli specifici da ciò che hai pubblicato qui, ma ho alcuni consigli generici basati su un post che ho scritto anni fa quando potevo ancora essere disturbato dal blog.

Non farti prendere dal panico

Innanzitutto, non esistono "correzioni rapide" oltre a ripristinare il sistema da un backup eseguito prima dell'intrusione e ciò presenta almeno due problemi.

  1. È difficile individuare quando si è verificata l'intrusione.
  2. Non ti aiuta a chiudere il "buco" che ha permesso loro di rompere l'ultima volta, né a gestire le conseguenze di eventuali "furti di dati" che potrebbero anche aver avuto luogo.

Questa domanda continua a essere posta ripetutamente dalle vittime di hacker che irrompono 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 semplicemente non piacciono le risposte che hanno visto quando cercano aiuto, o non riescono a trovare qualcuno di cui si fidano per dare loro consigli. O forse le persone leggono una risposta a questa domanda e si concentrano troppo sul 5% del perché il loro caso è speciale e diverso dalle risposte che possono trovare online e perdono il 95% della domanda e rispondono dove il loro caso è abbastanza vicino lo stesso come quello che leggono online.

Questo mi porta alla prima importante pepita di informazioni. Apprezzo davvero che tu sia un fiocco di neve unico e speciale. Apprezzo che anche il tuo sito web sia, in quanto riflesso di te e della tua attività o almeno del tuo duro lavoro da parte di un datore di lavoro. Ma per qualcuno dall'esterno che guarda dentro, sia che una persona della sicurezza informatica guardi il problema per cercare di aiutare te o anche l'attaccante stesso, è molto probabile che il tuo problema sia identico almeno al 95% rispetto a tutti gli altri casi che hanno mai guardato.

Non prendere l'attacco personalmente e non prendere personalmente i consigli che seguono qui o che ricevi da altre persone. Se stai leggendo questo dopo essere appena diventato vittima di un hack del sito web, mi dispiace davvero e spero davvero che tu possa trovare qualcosa di utile qui, ma non è questo il momento di lasciare che il tuo ego si frapponga a ciò di cui hai bisogno fare.

Hai appena scoperto che il tuo server è stato violato. E adesso?

Niente panico. Assolutamente non agire in fretta, e assolutamente non cercare di far finta che le cose non siano mai accadute e di non agire affatto.

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

Alcuni di questi passaggi sono dannosi e (a meno che il tuo sito web non contenga una copia dei miei dati) non mi interessa davvero se ignori tutti o alcuni di questi passaggi, ma alla fine migliorerai le cose. La medicina potrebbe avere un sapore terribile, ma a volte devi trascurarlo se vuoi davvero che la cura funzioni.

Impedisci che il problema peggiori di quanto non sia già:

  1. La prima cosa da fare è disconnettere i sistemi interessati da Internet. Qualunque altro problema tu abbia, lasciare il sistema connesso al web permetterà solo che l'attacco continui. Intendo questo letteralmente; convincere qualcuno a visitare fisicamente il server e scollegare i cavi di rete se è quello che serve, ma scollegare la vittima dai suoi rapinatori prima di provare a fare qualsiasi altra cosa.
  2. Modifica tutte le password per 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ì, hai ragione, questo potrebbe essere eccessivo; d'altra parte, potrebbe non esserlo. Non sai in entrambi i modi, vero?
  3. Controlla i tuoi altri sistemi. Prestare particolare attenzione ad altri servizi che si affacciano su Internet e a quelli che detengono dati finanziari o altri dati commerciali sensibili.
  4. Se il sistema detiene i dati personali di qualcuno, informa immediatamente la persona responsabile della protezione dei dati (se non sei tu) e richiedi una divulgazione completa. So che questo è difficile. So che questo farà male. So che molte aziende vogliono eliminare questo tipo di problema sotto il tappeto, ma l'azienda dovrà affrontarlo - e deve farlo con un occhio su tutte le leggi sulla privacy pertinenti.

Per quanto infastiditi, i tuoi clienti potrebbero avere il fatto che tu gli parli di un problema, saranno molto più infastiditi se non glielo dici, e lo scoprono da soli dopo che qualcuno ha addebitato un valore di $ 8.000 di beni usando i dettagli della carta di credito che hanno rubato dal tuo sito.

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

Comprendi a fondo il problema:

  1. NON rimettere in linea i sistemi interessati fino a quando questa fase non sarà completamente completa, a meno che tu non voglia essere la persona il cui post è stato il punto di svolta per me, decidendo davvero di scrivere questo articolo. Non collegherò a quel post in modo che le persone possano ridere a buon mercato, ma la vera tragedia è quando le persone non riescono a imparare dai loro errori.
  2. Esamina i sistemi "attaccati" per capire come gli attacchi sono riusciti a compromettere la tua sicurezza. Fai ogni sforzo per scoprire da dove "provengono" gli attacchi, in modo da capire quali problemi hai e che devi affrontare per rendere sicuro il tuo sistema in futuro.
  3. Esamina nuovamente i sistemi "attaccati", questa volta per capire dove sono andati gli attacchi, in modo da capire quali sistemi sono stati compromessi nell'attacco. Assicurati di seguire tutti i suggerimenti che suggeriscono che i sistemi compromessi potrebbero diventare un trampolino di lancio per attaccare ulteriormente i tuoi sistemi.
  4. Assicurati che i "gateway" utilizzati in tutti gli attacchi siano completamente compresi, in modo da poter iniziare a chiuderli correttamente. (ad es. se i tuoi sistemi sono stati compromessi da un attacco SQL injection, non solo devi chiudere la particolare riga di codice difettosa da cui sono entrati, ma vorrai controllare tutto il tuo codice per vedere se lo stesso tipo di errore è stato realizzato altrove).
  5. Comprendi che gli attacchi potrebbero avere successo a causa di più di un difetto. Spesso, gli attacchi riescono non trovando un bug importante in un sistema, ma mettendo insieme diversi problemi (a volte minori e banali da soli) per compromettere un sistema. Ad esempio, utilizzando gli attacchi SQL injection per inviare comandi a un server di database, scoprire il sito Web/l'applicazione che si sta attaccando è in esecuzione nel contesto di un utente amministrativo e utilizzare 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 la gente fa".

Perché non semplicemente "riparare" l'exploit o il rootkit che hai rilevato e rimettere il sistema online?

In situazioni come questa il problema è che non hai più il controllo di quel sistema. Non è più il tuo computer.

L'unico modo per essere certo che hai il controllo del sistema è ricostruire il sistema. Anche se c'è molto valore nel trovare e correggere l'exploit usato per irrompere nel sistema, non puoi essere sicuro di cos'altro è stato fatto al sistema una volta che gli intrusi hanno acquisito il controllo (in effetti, non è inaudito per gli hacker che reclutano sistemi in una botnet per patchare gli exploit che hanno usato loro stessi, per salvaguardare il "loro" nuovo computer da altri hacker, nonché per installare il loro rootkit).

Prepara un piano per il recupero e per riportare il tuo sito web online e attenersi ad esso:

Nessuno vuole rimanere offline più a lungo di quanto deve essere. Questo è un dato. Se questo sito Web è un meccanismo che genera entrate, la pressione per riportarlo online rapidamente sarà intensa. Anche se l'unica cosa in gioco è la reputazione della tua/tua azienda, questo genererà ancora molta pressione per rimettere le cose rapidamente.

Tuttavia, non arrenderti alla tentazione di tornare online troppo velocemente. Invece, muoviti il ​​più velocemente possibile per capire cosa ha causato il problema e per risolverlo prima di tornare online oppure rimarrai quasi sicuramente vittima di un'intrusione ancora una volta, e ricorda, "essere hackerati una volta può essere classificato come sventura; essere hackerato subito dopo sembra disattenzione "(con scuse a Oscar Wilde).

  1. Suppongo che tu abbia capito tutti i problemi che hanno portato al successo dell'intrusione prima ancora di iniziare questa sezione. Non voglio esagerare con il caso, ma se non lo hai fatto prima, devi davvero farlo. Scusate.
  2. Non pagare mai denaro per ricatti/protezione. Questo è il segno di un segno facile e non vuoi che quella frase sia mai stata usata per descriverti.
  3. Non essere tentato di rimettere online gli stessi server senza una ricostruzione completa. Dovrebbe essere molto più veloce costruire una nuova scatola o "cancellare il server dall'orbita e fare un'installazione pulita" sul vecchio hardware piuttosto che controllare ogni singolo angolo del vecchio sistema per assicurarsi che sia pulito prima di rimetterlo di nuovo online. Se non sei d'accordo, probabilmente non sai cosa significhi realmente garantire che un sistema sia completamente pulito, o le procedure di distribuzione del tuo sito Web sono un disastro. Presumibilmente hai backup e test di distribuzioni del tuo sito che puoi semplicemente usare per costruire il sito live e, se non lo fai, allora essere hackerato non è il tuo problema più grande.
  4. Fai molta attenzione a riutilizzare i dati "attivi" sul sistema al momento dell'hacking. Non dirò "mai e poi mai" perché mi ignorerai, ma francamente penso che tu debba considerare le conseguenze della conservazione dei dati quando sai che non puoi garantirne l'integrità. Idealmente, è necessario ripristinarlo da un backup effettuato prima dell'intrusione. Se non puoi o non lo farai, dovresti stare molto attento con quei dati perché sono contaminati. Dovresti in particolare essere consapevole delle conseguenze per gli altri se questi dati appartengono ai clienti o ai visitatori del sito piuttosto che direttamente a te.
  5. Monitorare attentamente i sistemi. Dovresti decidere di farlo come un processo in corso in futuro (più sotto), ma ti preoccupi di essere vigile durante il periodo immediatamente successivo al ritorno del tuo sito online. Gli intrusi torneranno quasi sicuramente, e se riesci a individuarli mentre tentano di entrare di nuovo, sarai sicuramente in grado di vedere rapidamente se hai davvero chiuso tutti i buchi che hanno usato prima più quelli che hanno fatto per se stessi, e potresti raccogliere utili informazioni che è possibile trasmettere alle forze dell'ordine locali.

Riduzione del rischio in futuro.

La prima cosa che devi capire è che la sicurezza è un processo che devi applicare durante l'intero ciclo di vita di progettazione, distribuzione e manutenzione di un sistema che si affaccia su Internet, non qualcosa che puoi schiaffeggiare dopo pochi strati sul tuo codice come economico Dipingere. Per essere adeguatamente sicuri, un servizio e un'applicazione devono essere progettati fin dall'inizio tenendo presente questo come uno degli obiettivi principali del progetto. Mi rendo conto che è noioso e hai già sentito tutto prima e che "semplicemente non mi rendo conto della pressione dell'uomo" di portare il tuo servizio beta web2.0 (beta) nello stato beta sul web, ma il fatto è che questo mantiene essere ripetuto perché era vero la prima volta che è stato detto e non è ancora diventato una bugia.

Non puoi eliminare il rischio. Non dovresti nemmeno provare a farlo. Quello che dovresti fare comunque è capire quali rischi per la sicurezza sono importanti per te e capire come gestire e ridurre sia l'impatto del rischio che la probabilità che il rischio si verifichi.

Quali passi puoi prendere per ridurre la probabilità che un attacco abbia successo?

Per esempio:

  1. Il difetto che ha permesso alle persone di entrare nel tuo sito era un bug noto nel codice del fornitore, per il quale era disponibile una patch? In tal caso, è necessario ripensare il proprio approccio al modo in cui si applicano le patch ai server rivolti a Internet?
  2. Il difetto che ha permesso alle persone di entrare nel tuo sito era un bug sconosciuto nel codice del fornitore, per il quale non era disponibile una patch? Sicuramente non propongo di cambiare fornitore ogni volta che qualcosa del genere ti morde perché hanno tutti i loro problemi e rimarrai senza piattaforme al massimo in un anno se segui questo approccio. Tuttavia, se un sistema ti delude costantemente, allora dovresti migrare verso qualcosa di più robusto o, almeno, riprogettare il tuo sistema in modo che i componenti vulnerabili rimangano avvolti in cotone idrofilo e il più lontano possibile da occhi ostili.
  3. Il difetto è stato un bug nel codice sviluppato da te (o da qualcuno che lavora per te)? In tal caso, devi ripensare il tuo approccio al modo in cui approvi il codice per la distribuzione sul tuo sito live? È possibile che il bug sia stato rilevato con un sistema di test migliorato o con modifiche al codice "standard" (ad esempio, mentre la tecnologia non è una panacea, è possibile ridurre la probabilità di un attacco con iniezione SQL riuscito utilizzando tecniche di codifica ben documentate ).
  4. Il difetto era a causa di un problema con la distribuzione del server o del software applicativo? In tal caso, stai usando procedure automatizzate per costruire e distribuire server ove possibile? Questi sono di grande aiuto nel mantenere uno stato di "base" coerente su tutti i server, riducendo al minimo la quantità di lavoro personalizzato che deve essere fatto su ciascuno e quindi sperando minimizzando l'opportunità di fare un errore. Lo stesso vale per la distribuzione del codice: se hai bisogno di qualcosa di "speciale" da fare per distribuire la versione più recente della tua app web, cerca di automatizzarla e assicurarti che sia sempre eseguita in modo coerente.
  5. L'intrusione potrebbe essere stata rilevata in precedenza con un migliore monitoraggio dei sistemi? Ovviamente, il monitoraggio 24 ore su 24 o un sistema "su chiamata" per il tuo personale potrebbero non essere convenienti, ma ci sono aziende là fuori che possono monitorare i tuoi servizi web per te e avvisarti in caso di problemi. Potresti decidere di non potertelo permettere o di non averne bisogno e va bene ... prendilo in considerazione.
  6. Usa strumenti come tripwire e nessus dove appropriato - ma non usarli solo alla cieca perché l'ho detto. Prenditi il ​​tempo per imparare a utilizzare alcuni buoni strumenti di sicurezza adeguati al tuo ambiente, mantieni questi strumenti aggiornati e usali su base regolare.
  7. Prendi in considerazione l'assunzione di esperti di sicurezza per "controllare" la sicurezza del tuo sito Web su base regolare. Ancora una volta, potresti decidere di non potertelo permettere o di non averne bisogno e va bene ... prendilo in considerazione.

Quali passi puoi prendere per ridurre le conseguenze di un attacco riuscito?

Se decidi che il "rischio" del piano inferiore della tua inondazione domestica è alto, ma non abbastanza alto da giustificare lo spostamento, dovresti almeno spostare i cimeli familiari insostituibili al piano di sopra. Giusto?

  1. Puoi ridurre la quantità di servizi direttamente esposti a Internet? Riesci a mantenere una sorta di divario tra i tuoi servizi interni e i tuoi servizi rivolti a Internet? Questo assicura che anche se i tuoi sistemi esterni sono compromessi, le possibilità di utilizzarlo come trampolino per attaccare i tuoi sistemi interni sono limitate.
  2. Stai memorizzando informazioni che non hai bisogno di memorizzare? Stai memorizzando tali informazioni "online" quando potrebbero essere archiviate altrove. Ci sono due punti in questa parte; il più ovvio è che le persone non possono rubarti informazioni che non hai, e il secondo punto è che meno memorizzi, meno è necessario conservare e codificare, e quindi ci sono meno possibilità che i bug scivolino dentro il tuo codice o la progettazione dei sistemi.
  3. Stai utilizzando i principi di "accesso minimo" per la tua app web? Se gli utenti devono solo leggere da un database, assicurati che l'account utilizzato dall'app Web per eseguire la manutenzione abbia solo accesso in lettura, non consentire l'accesso in scrittura e certamente non l'accesso a livello di sistema.
  4. Se non hai molta esperienza in qualcosa e non è fondamentale per la tua attività, considera l'outsourcing. In altre parole, se gestisci un piccolo sito Web che parla della scrittura del codice dell'applicazione desktop e decidi di iniziare a vendere piccole applicazioni desktop dal sito, considera la possibilità di "esternalizzare" il tuo sistema di ordini con carta di credito a qualcuno come Paypal.
  5. Se possibile, fai pratica di recupero da sistemi compromessi nel tuo piano di Disaster Recovery. Questo è probabilmente solo un altro "scenario di disastro" che potresti incontrare, semplicemente uno con una propria serie di problemi e problemi che sono distinti dalla solita 'sala server presa fuoco'/'è stato invaso da un server gigantesco che mangiava cose del genere.

... E infine

Probabilmente non ho lasciato fine a cose che gli altri considerano importanti, ma i passaggi precedenti dovrebbero almeno aiutarti a iniziare a sistemare le cose se sei abbastanza sfortunato da cadere vittima di hacker.

Soprattutto: non fatevi prendere dal panico. Pensa prima di agire. Agisci con fermezza dopo aver preso una decisione e lascia un commento qui sotto se hai qualcosa da aggiungere al mio elenco di passaggi.

151
Lucas Kauffman

Rendere un file "undeletable" in Linux è fatto con attributi, in particolare l'attributo "immutabile". Vedi lsattr per vedere gli attributi, chattr per cambiarli.

Tuttavia, questo risponde solo alla causa prossimale. La cosa importante è che la tua macchina è stata sottoposta a controllo ostile e che il dirottatore ha installato cose per i suoi obiettivi subdoli. In particolare, molto probabilmente ha installato un rootkit per tenere aperta la voce nonostante i tentativi di pulizia come quello che stai cercando di fare. I rootkit potrebbero aver modificato il kernel e/o i file binari del sistema in modi che non saranno visibili dalla macchina stessa e che ne impediranno la rimozione. La linea di fondo è che la tua macchina non può essere salvata; non è possibile in modo affidabile pulire nuovamente la macchina, salvare riformattando il disco e reinstallandolo da zero.

Salva te stesso da preoccupazioni e mal di testa futuri; annulla il sistema dall'orbita .

13
Tom Leek

Come stavo dicendo nella risposta al cross-post di ServerFault. Che è una buona spiegazione. Inoltre, dipende certamente dal tipo di attacco; si spera o sfortunatamente, questo attacco è abbastanza rumoroso da riconoscerlo come un attacco in corso. Oppure, in quello che puoi essere ragionevolmente certo che sono le prime fasi di un attacco, direi che questo ordine di operazioni è un buon progetto da seguire.

Tuttavia, esiste la possibilità che gli indicatori di compromesso di cui sei a conoscenza, potrebbero non dipingere l'intera immagine dell'infezione e disconnettere il PC potrebbe non essere nel tuo interesse fino a quando non capisci l'estensione, sostengo che potrebbe essere meglio scoprirlo punti di ingresso e di quali sistemi potresti non avere il controllo prima di iniziare a rimuovere dalla rete eventuali sistemi/dispositivi interessati.

La verità della questione potrebbe essere che quegli attori sono stati nei tuoi sistemi più a lungo di quanto pensassi e mostrando la tua mano troppo presto (cioè ho finalmente notato che sei seduto nei miei sistemi) potrebbe rendere molto più difficile l'eradicazione.

Non esiste una vera risposta facile, ma quella fornita da RobM è un punto di partenza più che adeguato. Con tutte le pressioni, ci sono più risposte giuste che potrebbero anche essere risposte sbagliate. Quasi come si applica il principio di incertezza, non sai se la risposta sarà esatta fino a quando non la proverai.

Anche la (PDF) NIST Computer Security Guida alla gestione degli incidenti dovrebbe essere rivista.

8
M15K

La metodologia è soggetta all'esatto scenario del mondo reale, ma di seguito sarebbe un possibile approccio.

Quali sono i miei primi passi? Quando arrivo sul posto dovrei disconnettere il server, conservare "prove", ci sono altre considerazioni iniziali?

Ans: Naturalmente, è necessario scollegare il server dalla rete ma non è necessario spegnere/arrestare il server, poiché potrebbe essere necessario eseguire delle analisi forensi per comprendere la situazione, l'impatto dell'incidente e conservare le prove ( i dati nella memoria potrebbero essere cancellati se si arresta il server).

Gestione delle crisi e comunicazione - Se si dispone di una politica di gestione delle crisi e DR/BCP seguire le procedure indicate. Questo è di nuovo soggetto allo scenario in questo caso potrebbe trattarsi di una propagazione del virus, quindi potrebbe essere necessario seguire il processo.

Come posso ottenere di ripristinare i servizi online?

Ans: Come indicato sopra, seguire le istruzioni per la gestione delle crisi/DR/BCP. Questo può variare a seconda della situazione.

Ad esempio, se questo virus era una bomba a orologeria o si attivava con qualche azione sul server e un attacco Ransomware, è meglio non far apparire immediatamente il tuo DR (questo potrebbe innescare un altro malware diffuso dal tuo server DR). Il metodo migliore sarebbe valutare l'impatto dell'incidente sulla rete e quindi intraprendere le azioni necessarie per ripristinare i servizi.

Come posso impedire che la stessa cosa accada di nuovo immediatamente?

Ans: La causa principale dell'incidente deve essere determinata al più presto per evitare che lo stesso incidente si ripeta. Come indicato nella risposta sopra, in uno scenario Ransomware potrebbe essere necessario assicurarsi che il malware non venga propagato al DR/Backup.

Se l'incidente si è verificato a causa di una vulnerabilità nella rete (ad esempio, una porta del firewall è stata aperta in modo errato e l'attacco è arrivato attraverso questa porta, sono necessarie azioni immediate per chiudere la vulnerabilità conosciuta/identificata per evitare che si verifichi nuovamente l'incidente.

Esistono best practice o metodologie per l'apprendimento da questo incidente?

Ans: Sì, ogni incidente potrebbe essere unico in natura. Quindi, aggiorna le tue procedure di gestione delle crisi/DR/BCP per riflettere l'apprendimento di tali incidenti.

Si consiglia sempre di disporre di un monitoraggio proattivo/identificazione degli incidenti in atto per evitare/il rilevamento precoce di tali incidenti. Ad esempio, è possibile distribuire strumenti SOC (Security Operations Center) o SIEM (Security Incident Event Management).

Se volessi mettere insieme un piano di risposta agli incidenti, da dove iniziare? Questo dovrebbe far parte del mio Disaster Recovery o della pianificazione della continuità operativa?

Ans: Questo dovrebbe essere parte del tuo piano BCP/DR e di solito coperto dalla gestione delle crisi (parte del piano BCP).

0
Sayan

Esegui il backup di tutto - in modo da poter condurre attraverso la medicina legale in un ambiente di tipo sandbox.

Quindi - inizia da 0 - sì da NIENTE.

Nuovo O/S - completamente patchato. Applicazioni: file di dati aggiornati correnti .... dai tuoi backup (prima di quando eri compromesso, se possibile). In caso contrario, è necessario eseguire la scansione di TUTTI i contenuti e le autorizzazioni.

Quindi conduci una revisione dettagliata di come sono entrati gli hacker e assicurati che non accada più.

Quando scopri cosa è successo, fai in modo che non si verifichi più e pubblica (internamente e/o esternamente) ciò che hai trovato (puoi scegliere di omettere le contromisure).

Se non impari da questo, subirai di nuovo lo stesso destino.

0
Tim Seed