Questa è una domanda canonica sulla sicurezza del server - Risposta agli eventi di violazione (hacking)
Vedi anche:

• Suggerimenti per la protezione di un server LAMP
• Reinstalla dopo un compromesso di root?

Versione canonica
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 posso 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?

Versione originale

02/01/2011 - Sono in procinto di lavorare alle 21.30 di domenica perché il nostro server è stato compromesso in qualche modo e stava causando un attacco DOS al nostro provider. L'accesso ai server a Internet è stato chiuso, il che significa che oltre 5-600 siti dei nostri clienti sono ora inattivi. Ora questo potrebbe essere un hack FTP, o qualche debolezza nel codice da qualche parte. Non sono sicuro finché non ci arrivo.

Come posso rintracciarlo rapidamente? Ci occuperemo di molte controversie se non riesco a riavviare il server il prima possibile. Qualsiasi aiuto è apprezzato. Stiamo eseguendo Open SUSE 11.0.

---

03.01.2011 - Grazie a tutti per il vostro aiuto. Fortunatamente non ero l'unica persona responsabile di questo server, solo il più vicino. Siamo riusciti a risolvere questo problema, anche se potrebbe non applicarsi a molti altri in una situazione diversa. Descriverò in dettaglio cosa abbiamo fatto.

Abbiamo scollegato il server dalla rete. Stava eseguendo (tentando di eseguire) un attacco Denial Of Service su un altro server in Indonesia, e anche la parte colpevole aveva sede lì.

In primo luogo abbiamo cercato di identificare da dove proveniva il server, considerando che abbiamo oltre 500 siti sul server, ci aspettavamo di essere al chiaro di luna per qualche tempo. Tuttavia, con l'accesso SSH ancora, abbiamo eseguito un comando per trovare tutti i file modificati o creati nel momento in cui sono iniziati gli attacchi. Fortunatamente, il file offensivo è stato creato durante le vacanze invernali, il che significa che non molti altri file sono stati creati sul server in quel momento.

Siamo stati quindi in grado di identificare il file offensivo che si trovava nella cartella delle immagini caricate all'interno di un sito Web ZenCart .

Dopo una breve pausa di sigarette, abbiamo concluso che, a causa della posizione dei file, doveva essere stato caricato tramite una funzione di caricamento dei file non protetta in modo adeguato. Dopo aver cercato su Google, abbiamo scoperto che c'era una vulnerabilità di sicurezza che consentiva il caricamento dei file, nel pannello di amministrazione di ZenCart, per un'immagine per una casa discografica. (La sezione che non ha mai utilizzato), la pubblicazione di questo modulo ha appena caricato un file, non ha controllato l'estensione del file e non ha nemmeno verificato se l'utente era connesso.

Ciò significava che qualsiasi file poteva essere caricato, incluso un file PHP per l'attacco. Abbiamo protetto la vulnerabilità con ZenCart sul sito infetto e rimosso i file offensivi.

Il lavoro era finito e io ero a casa per le 2 del mattino

---

The Moral : applica sempre patch di sicurezza per ZenCart o qualsiasi altro sistema CMS. Come quando vengono rilasciati aggiornamenti di sicurezza, tutto il mondo viene a conoscenza della vulnerabilità. - Eseguire sempre i backup e eseguire il backup dei backup. - Impiega o organizza qualcuno che sarà presente in tempi come questi. Per impedire a chiunque di fare affidamento su un post di panico su Server Fault.

È 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 fatevi prendere dal panico

Per prima cosa, non ci sono "soluzioni rapide" oltre a ripristinare il sistema da un backup eseguito prima dell'intrusione, e questo ha 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, quantomeno, 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 seguire i consigli che seguono qui o che ricevi personalmente 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 i tuoi server sono stati hackerati. 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, dipende da te. Ma seguirli correttamente renderà le cose migliori alla fine. 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 delle merci 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.

Comprendere completamente il problema:

1. NON rimettere in linea i sistemi interessati fino a quando questa fase non è completamente completa, a meno che tu non voglia essere la persona il cui post è stato il punto di svolta per me, in realtà, decidere 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 certi di avere il controllo del sistema è ricostruire il sistema. Mentre 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 rattoppare gli exploit che hanno usato loro stessi, per salvaguardare il "loro" nuovo computer da altri hacker, nonché per installare il loro rootkit).

Fai un piano per il recupero e per riportare il tuo sito 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 che 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 davvero 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.

Ridurre il 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 un appaltatore 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 potrebbe non essere conveniente, 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 di lancio 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 come parte del 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.

Sembra che tu sia leggermente sopra la testa; va bene. Chiama il tuo capo e inizia a negoziare un budget di risposta alla sicurezza di emergenza. $ 10.000 potrebbero essere un buon punto di partenza. Quindi devi chiamare qualcuno (un PFY, un collega, un manager) per iniziare a chiamare le aziende specializzate nella risposta agli incidenti di sicurezza. Molti possono rispondere entro 24 ore e talvolta anche più velocemente se hanno un ufficio nella tua città.

Hai anche bisogno di qualcuno per valutare i clienti; Senza dubbio, qualcuno lo è già. Qualcuno deve essere al telefono con loro per spiegare cosa sta succedendo, cosa viene fatto per gestire la situazione e per rispondere alle loro domande.

Quindi, devi ...

1. Stai calmo. Se sei responsabile della risposta agli incidenti, ciò che fai ora deve dimostrare la massima professionalità e leadership. Documenta tutto ciò che fai e mantieni informato il tuo manager e il team esecutivo delle principali azioni che intraprendi; questo include lavorare con un team di risposta, disabilitare i server, eseguire il backup dei dati e riportare le cose online. Non hanno bisogno di dettagli cruenti, ma dovrebbero avere tue notizie ogni 30 minuti circa.

2. Sii realista. Non sei un professionista della sicurezza e ci sono cose che non conosci. Va bene. Quando si accede ai server e si guardano i dati, è necessario comprendere i propri limiti. Cammina delicatamente. Nel corso dell'indagine, assicurati di non calpestare informazioni vitali o modificare qualcosa che potrebbe essere necessario in seguito. Se ti senti a disagio o stai indovinando, è un buon posto dove fermarsi e far assumere un professionista con esperienza.

3. Ottieni una chiavetta USB pulita e dischi rigidi di riserva. Raccoglierai prove qui. Fai un backup di tutto ciò che ritieni possa essere rilevante; comunicazione con il proprio ISP, discariche di rete, ecc. Anche se le forze dell'ordine non sono coinvolte, in caso di azione legale si vorranno queste prove per dimostrare che la propria azienda ha gestito l'incidente di sicurezza in modo professionale e appropriato.

4. La cosa più importante è fermare la perdita. Identificare e interrompere l'accesso a servizi, dati e macchine compromessi. Preferibilmente, dovresti tirare il loro cavo di rete; se non è possibile, quindi tirare il potere.

5. Successivamente, è necessario rimuovere l'attaccante e chiudere i fori. Presumibilmente, l'attaccante non ha più accesso interattivo perché hai estratto la rete. Ora è necessario identificare, documentare (con backup, schermate e le proprie note di osservazione personali; o preferibilmente anche rimuovendo le unità dai server interessati e facendo una copia completa dell'immagine del disco), quindi rimuovere qualsiasi codice e processo che ha lasciato alle spalle . Questa parte successiva farà schifo se non si dispone di backup; Puoi provare a districare a mano l'attaccante dal sistema, ma non sarai mai sicuro di avere tutto ciò che ha lasciato. I rootkit sono viziosi e non tutti sono rilevabili. La migliore risposta sarà quella di identificare la vulnerabilità che ha usato per entrare, fare copie delle immagini dei dischi interessati, quindi cancellare i sistemi interessati e ricaricarli da un backup valido noto. Don' t fidati ciecamente del tuo backup; verificalo! Riparare o chiudere la vulnerabilità prima che il nuovo host si colleghi nuovamente alla rete, quindi portarlo online.

6. Organizza tutti i tuoi dati in un rapporto. A questo punto la vulnerabilità è chiusa e hai un po 'di tempo per respirare. Non essere tentato di saltare questo passaggio; è persino più importante del resto del processo. Nel rapporto, devi identificare cosa è andato storto, come ha risposto il tuo team e i passi che stai intraprendendo per evitare che questo incidente si ripeta. Sii il più dettagliato possibile; questo non è solo per te, ma per la tua gestione e come difesa in una potenziale causa legale.

Questa è una recensione alle stelle su cosa fare; la maggior parte del lavoro consiste semplicemente nella gestione della documentazione e del backup. Non farti prendere dal panico, puoi fare quella roba. Consiglio vivamente di ottenere un aiuto professionale per la sicurezza. Anche se riesci a gestire quello che sta succedendo, il loro aiuto sarà inestimabile e di solito vengono forniti con attrezzature per rendere il processo più semplice e veloce. Se il tuo capo si oppone al costo, ricordagli che è molto piccolo rispetto alla gestione di una causa.

Hai le mie consolazioni per la tua situazione. In bocca al lupo.

CERT ha un documento Procedura per il ripristino da un compromesso di sistema UNIX o NT che è buono. I dettagli tecnici specifici di questo documento sono in qualche modo obsoleti, ma molti consigli generali si applicano ancora direttamente.

Un breve riepilogo dei passaggi di base è questo.

• Consultare la propria politica di sicurezza o gestione.
• Ottieni il controllo (porta il computer offline)
• Analizza l'intrusione, ottieni i log, calcola cosa è andato storto
• Riparare cose
  • Installa una versione pulita del tuo sistema operativo !!! Se il sistema è stato compromesso, non ci si può fidare, punto.
• Aggiorna i sistemi in modo che ciò non accada di nuovo
• Riprendi le operazioni
• Aggiorna la tua politica per il futuro e il documento

Vorrei indicarti specificamente la sezione E.1.

E.1. Tenere presente che se una macchina fosse compromessa, qualsiasi cosa su quel sistema avrebbe potuto essere modificata, inclusi kernel, file binari, file di dati, processi in esecuzione e memoria. In generale, l'unico modo per confidare che una macchina sia libera da backdoor e modifiche da intrusi è reinstallare il funzionamento

Se non disponi già di un sistema come Tripwire, non è possibile che tu sia sicuro al 100% di aver ripulito il sistema.

1. Identifica il problema. Leggi i registri.
2. Contenere . Hai disconnesso il server, quindi è fatto.
3. Sradicare . Reinstallare il sistema interessato, molto probabilmente. Non cancellare il disco rigido di quello compromesso, tuttavia, utilizzare uno nuovo. È più sicuro e potresti aver bisogno di quello vecchio per recuperare brutti hack di cui non è stato eseguito il backup e fare analisi forensi per scoprire cosa è successo.
4. Recuperare . Installa tutto ciò che è necessario e ripristina i backup per mettere online i tuoi clienti.
5. Follow-up . Scopri qual è stato il problema e impedisci che si ripeta.

La risposta di "amara pillola" di Robert è precisa ma completamente generica (beh, come è stata la tua domanda). Sembra che tu abbia un problema di gestione e abbia un disperato bisogno di un amministratore di sistema a tempo pieno se hai un server e 600 client, ma questo non ti aiuta ora.

Gestisco una società di hosting che offre un po 'di mano in questa situazione, quindi mi occupo di molte macchine compromesse, ma mi occupo anche delle migliori pratiche per conto nostro. Diciamo sempre ai nostri clienti compromessi di ricostruire a meno che non siano assolutamente sicuri della natura di un compromesso. Non esiste altra via responsabile a lungo termine.

Tuttavia, quasi sicuramente sei solo la vittima di uno script kiddy che voleva una piattaforma di lancio per attacchi DoS o buttafuori IRC o qualcosa di completamente estraneo ai siti e ai dati dei tuoi clienti. Pertanto, come misura temporanea durante la ricostruzione, è possibile prendere in considerazione la creazione di un firewall in uscita pesante sulla confezione. Se riesci a bloccare tutte le connessioni UDP e TCP in uscita che non sono assolutamente necessarie per il funzionamento dei tuoi siti, puoi facilmente rendere inutilizzabile la tua scatola compromessa per chiunque la stia prendendo in prestito da te e ridurre a zero l'effetto sulla rete del tuo provider.

Questo processo potrebbe richiedere alcune ore se non l'hai mai fatto prima e non hai mai preso in considerazione un firewall, ma potrebbe aiutarti a ripristinare il servizio dei tuoi clienti con il rischio di continuare a dare all'aggressore l'accesso ai dati dei tuoi clienti . Dal momento che dici di avere centinaia di clienti su un unico computer, immagino che stai ospitando piccoli siti web di brochure per piccole imprese e non 600 sistemi di e-commerce pieni di numeri di carta di credito. In tal caso, ciò potrebbe rappresentare un rischio accettabile per te e riportare il tuo sistema online più rapidamente rispetto al controllo di 600 siti alla ricerca di bug di sicurezza prima che tu riporti qualcosa. Ma saprai quali dati ci sono e quanto ti sentiresti a tuo agio a prendere quella decisione.

Questa non è assolutamente la migliore pratica, ma se non è quello che è successo al tuo datore di lavoro finora, scuotendo il dito verso di loro e chiedendo decine di migliaia di sterline per un team SWAT per qualcosa che potrebbero ritenere sia colpa tua (per quanto ingiustificato! ) non sembra l'opzione pratica.

L'aiuto del tuo ISP qui sarà abbastanza cruciale: alcuni ISP forniscono un server console e un ambiente di avvio di rete (plug, ma almeno sai quale tipo di struttura cercare) che ti consentirà di amministrare il server mentre sei disconnesso dalla rete. Se questa è un'opzione, chiedila e usala.

Ma a lungo termine dovresti pianificare una ricostruzione del sistema basata sul post di Robert e un controllo di ciascun sito e della sua configurazione. Se non riesci ad aggiungere un amministratore di sistema al tuo team, cerca un accordo di hosting gestito in cui paghi il tuo ISP per un aiuto di amministratore di sistema e una risposta di 24 ore per questo tipo di cose. In bocca al lupo :)

Devi reinstallare. Salva ciò di cui hai veramente bisogno. Ma tieni presente che tutti i tuoi file eseguibili potrebbero essere infetti e manomessi. Ho scritto quanto segue in python: http://frw.se/monty.py che crea somme MD5 di tutti i tuoi file in una determinata directory e la prossima volta che lo esegui, controlla se qualcosa è stato cambiato e quindi genera cosa i file sono cambiati e cosa è cambiato nei file.

Questo potrebbe essere utile per te, per vedere se i file strani vengono cambiati regolarmente.

Ma l'unica cosa che dovresti fare ora è rimuovere il tuo computer da Internet.

NOTA: questa non è una raccomandazione. Il mio specifico protocollo di risposta agli incidenti probabilmente non si applicherebbe non modificato al caso di Grant unwin.

Nelle nostre strutture accademiche abbiamo circa 300 ricercatori che eseguono solo calcoli. Hai 600 client con siti Web, quindi il tuo protocollo sarà probabilmente diverso.

I primi passi nel nostro Quando un server ottiene un protocollo compromesso sono:

1. Identificare che l'attaccante è stato in grado di ottenere il root (privilegi elevati)
2. Scollegare i server interessati. Rete o alimentazione? Si prega di consultare una discussione separata .
3. Controlla tutti gli altri sistemi
4. Avvia i server interessati da un cd live
5. (opzionale) Prendi le immagini di tutte le unità di sistema condd

6. Inizia a fare le analisi forensi post mortem. Guarda i log, scopri il momento dell'attacco, trova i file che sono stati modificati in quel momento. Prova a rispondere al Come? domanda.

   • Parallelamente, pianifica ed esegui il tuo recupero.
   • Reimpostare tutte le password di root e utente prima di riprendere il servizio

Anche se "tutte le backdoor e i rootkit vengono ripuliti", non fidarti di quel sistema: reinstalla da zero.

Nella mia esperienza limitata, i compromessi di sistema su Linux tendono ad essere più "completi" di quanto non lo siano su Windows. I kit di root hanno molte più probabilità di includere la sostituzione dei file binari di sistema con codice personalizzato per nascondere il malware e la barriera all'hot-patch del kernel è leggermente più bassa. Inoltre, è il sistema operativo di casa per molti autori di malware. La guida generale è sempre quella di ricostruire il server interessato da zero, ed è la guida generale per un motivo.

Formatta quel cucciolo.

Ma, se non riesci a ricostruire (o i-poteri-che-essere non ti permetteranno di ricostruirlo contro la tua fervida insistenza sul fatto che ne abbia bisogno), cosa cerchi?

Dal momento che sembra che sia passato un po 'di tempo da quando è stata scoperta l'intrusione ed è stato fatto un ripristino del sistema, è molto probabile che le tracce di come sono state introdotte siano state calpestate nello stampede per ripristinare il servizio. Sfortunato.

Il traffico di rete insolito è probabilmente il più facile da trovare, in quanto ciò non comporta l'esecuzione di alcunché sulla scatola e può essere fatto mentre il server è attivo e fa qualunque cosa. Presumendo, ovviamente, i tuoi dispositivi di rete consentono lo spanning delle porte. Ciò che trovi può essere o non essere diagnostico, ma almeno sono informazioni. Ottenere traffico insolito sarà una prova evidente del fatto che il sistema è ancora compromesso e deve essere appiattito. Potrebbe essere abbastanza buono per convincere TPTB che un riformattato merita davvero i tempi di inattività.

In caso contrario, prendi una copia dd delle tue partizioni di sistema e montale su un'altra scatola. Inizia a confrontare i contenuti con un server allo stesso livello di patch di quello compromesso. Dovrebbe aiutarti a identificare ciò che sembra diverso (di nuovo quei md5sums) e potrebbe puntare ad aree trascurate sul server compromesso. Questo è un sacco di setacciatura attraverso directory e binari e sarà piuttosto laborioso. Potrebbe anche essere più laborioso di quanto non sarebbe un riformattare / ricostruire, e potrebbe essere un'altra cosa per far saltare TPTB sul fare effettivamente il riformattato di cui ha davvero bisogno.

Direi che @Robert Moir, @Aleksandr Levchuk, @blueben e @Matthew Bloch sono tutti molto chiari nelle loro risposte.

Tuttavia, le risposte di diversi poster differiscono: alcune sono più di alto livello e parlano delle procedure da attuare (in generale).

Preferirei separarlo in più parti separate 1) Triage, AKA Come trattare con i clienti e le implicazioni legali e identificare dove andare da lì (Elencato molto bene da Robert e @blueben 2) Mitigazione dell'impatto 3 ) Risposta all'incidente 4) Analisi forensi post mortem 5) Elementi di riparazione e modifiche dell'architettura

(Inserire qui la dichiarazione di risposta certificata SANS GSC della piastra di cottura) In base alle esperienze passate, direi quanto segue:

Indipendentemente da come stai gestendo le risposte dei clienti, le notifiche, i piani legali e futuri, preferirei concentrarmi sul problema principale a portata di mano. La domanda originale del PO riguarda solo direttamente il n. 2 e il n. 3, in sostanza, come fermare l'attacco, riportare i clienti online al più presto nel loro stato originale, che è stato ben coperto dalle risposte.

Le altre risposte sono eccellenti e coprono molte best practice identificate e modi per impedire che ciò accada in futuro e per rispondere al meglio.

Dipende molto dal budget del PO e dal settore industriale in cui si trovano, qual è la loro soluzione desiderata ecc.

Forse hanno bisogno di assumere una SA in loco dedicata. Forse hanno bisogno di una persona di sicurezza. O forse hanno bisogno di una soluzione completamente gestita come Firehost o Rackspace Managed, Softlayer, ServePath ecc.

Dipende davvero da cosa funziona per la loro attività. Forse la loro competenza principale non è nella gestione dei server e non ha senso cercare di svilupparli. O forse sono già un'organizzazione piuttosto tecnica e possono prendere le giuste decisioni di assunzione e portare a tempo pieno un team dedicato.

Dopo esserci messi al lavoro e aver dato un'occhiata al server siamo riusciti a capire il problema. Fortunatamente, i file offensivi sono stati caricati sul sistema di domenica, quando l'ufficio è chiuso e non è necessario creare file, a parte i registri e i file della cache. Con un semplice comando shell per scoprire quali file sono stati creati quel giorno li abbiamo trovati.

Tutti i file offensivi sembrano essere stati all'interno della cartella / images / su alcuni dei nostri siti zencart precedenti. Sembra che ci sia stata una vulnerabilità di sicurezza che ha permesso (usando l'arricciatura) a qualsiasi idiota di caricare non immagini nella sezione di caricamento delle immagini nella sezione di amministrazione. Abbiamo eliminato i file .php offensivi e risolto gli script di caricamento per impedire il caricamento di file che non sono immagini.

In retrospettiva, era abbastanza semplice e ho sollevato questa domanda sul mio iPhone mentre andavo al lavoro. Grazie per tutto il vostro aiuto ragazzi.

Per il riferimento di chiunque visiti questo post in futuro. Vorrei non raccomandare tirando la spina di alimentazione.

Ho poco per contribuire alle ampie risposte tecniche, ma per favore prendi nota di queste:

Azioni non tecniche:

• Segnala l'incidente internamente.
  Se non si dispone già di un piano di risposta agli incidenti che potrebbe apparire una tecnica CYA, ma il reparto IT non è l'unico e spesso nemmeno il posto migliore per determinare l' impatto aziendale di un server compromesso.
  I requisiti aziendali possono superare le tue preoccupazioni tecniche. Non dire "Te l'ho detto" e che la priorità delle preoccupazioni aziendali è il motivo per cui hai questo server compromesso in primo luogo. (" Lascialo per il rapporto post-azione. ")

• Coprire un incidente di sicurezza non è un'opzione.

• Segnalazione alle autorità locali.
  ServerFault NON è il luogo per la consulenza legale, ma questo dovrebbe essere incluso in un piano di risposta agli incidenti.
  In alcune località e / o industrie regolamentate è obbligatorio segnalare (determinati) incidenti di sicurezza alle forze dell'ordine locali, agli enti regolatori o informare i clienti / utenti interessati.
  Indipendentemente da ciò, né la decisione di riferire né il rapporto effettivo vengono prese esclusivamente nel reparto IT. Prevedere il coinvolgimento dei dipartimenti di gestione e comunicazione (marketing) legali e aziendali.
  Probabilmente non dovresti aspettarti troppo, Internet è un grande luogo in cui i confini hanno poco significato, ma i dipartimenti di criminalità informatica che esistono in molti dipartimenti di polizia risolvono i crimini digitali e possono consegnare i colpevoli alla giustizia.

Penso che tutto si riduce a questo:

Se apprezzi il tuo lavoro, è meglio che tu abbia un piano e lo riveda regolarmente.

Non riuscire a pianificare sta pianificando di fallire, e non è altrove che nella sicurezza dei sistemi. Quando <redacted> colpisce il fan, è meglio essere pronti a gestirlo.

C'è un altro detto (un po 'cliché) che si applica qui: prevenire è meglio che curare .

Ci sono stati un certo numero di raccomandazioni qui per convincere gli esperti a controllare i tuoi sistemi esistenti. Penso che questo stia ponendo la domanda nel momento sbagliato. Questa domanda avrebbe dovuto essere posta quando il sistema è stato messo in atto e le risposte documentate. Inoltre, la domanda non dovrebbe essere "Come possiamo impedire alle persone di entrare?" Dovrebbe essere "Perché le persone dovrebbero essere in grado di irrompere?" Il controllo di una serie di buchi nella rete funzionerà solo fino a quando non verranno individuati e sfruttati nuovi buchi. D'altra parte, le reti progettate da zero per rispondere solo in certi modi a determinati sistemi in una danza accuratamente coreografata non beneficeranno affatto di un audit e i fondi saranno uno spreco.

Prima di mettere un sistema su Internet, chiediti: è necessario che sia al 100% di fronte a Internet? Altrimenti no. Considera di metterlo dietro un firewall in cui puoi decidere cosa vede Internet. Ancora meglio, se detto firewall ti consente di intercettare le trasmissioni (tramite un proxy inverso o un filtro pass-through di qualche tipo) cerca di usarlo per consentire che si verifichino solo azioni legittime.

Ciò è stato fatto - esiste (o c'era) una configurazione di Internet Banking da qualche parte che ha un proxy di bilanciamento del carico di fronte a Internet che avrebbero usato per allontanare gli attacchi dal loro pool di server. L'esperto di sicurezza Marcus Ranum li ha convinti ad adottare l'approccio opposto, utilizzando il proxy inverso per consentire solo gli URL validi conosciuti e inviare tutto il resto a un server 404 . Ha superato la prova del tempo sorprendentemente bene.

Un sistema o una rete basata sul permesso predefinito è destinato a fallire quando si verifica un attacco che non si prevedeva. Default deny ti dà un controllo molto maggiore su ciò che entra e cosa no, perché non lascerai che nulla dall'interno sia visto dall'esterno a meno che non sia dannatamente necessario .

Detto questo, tutto ciò non è un motivo per essere compiacenti. Dovresti comunque avere in atto un piano per le prime ore dopo una violazione. Nessun sistema è perfetto e gli umani commettono errori.

Un simpatico onliner mi ha aiutato di recente a scoprire come un attaccante potrebbe compromettere un sistema. Alcuni cracker provano a nascondere le loro tracce forgiando il tempo di modifica sui file. Modificando il tempo di modifica, il tempo di modifica viene aggiornato (ctime). puoi vedere il tempo con stat.

Questa riga di elenco elenca tutti i file ordinati per ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Quindi, se conosci approssimativamente l'ora del compromesso, puoi vedere quali file vengono modificati o creati.