Reinstalla dopo un compromesso di root?

Dopo aver letto questa domanda su un compromesso del server , ho iniziato a chiedermi perché le persone continuino a credere di poter ripristinare un sistema compromesso utilizzando strumenti di rilevamento / pulizia o semplicemente riparando il foro utilizzato per compromettere il sistema.

Date tutte le varie tecnologie di root kit e altre cose che un hacker può fare, la maggior parte degli esperti suggerisce di reinstallare il sistema operativo .

Spero di avere un'idea migliore del perché un numero maggiore di persone non decollerà e colpirà il sistema dall'orbita.

Ecco un paio di punti che vorrei vedere affrontati.

• Esistono condizioni in cui un formato / reinstallazione non pulisce il sistema?
• In quali condizioni ritieni che un sistema possa essere pulito e quando devi eseguire una reinstallazione completa?
• Quale ragionamento hai per fare una reinstallazione completa?
• Se scegli di non reinstallare, quale metodo utilizzi per essere ragionevolmente sicuro di aver pulito e impedito che si verifichino ulteriori danni.

Una decisione sulla sicurezza è in definitiva una decisione aziendale in merito al rischio, così come una decisione sul prodotto da immettere sul mercato. Quando lo inquadra in quel contesto, la decisione di non livellare e reinstallare ha senso. Se lo consideri rigorosamente dal punto di vista tecnico, non lo fa.

Ecco cosa succede in genere in quella decisione aziendale:

• Quanto ci costeranno i nostri tempi di fermo in quantità misurabile?
• Quanto ci costerà potenzialmente quando dovremo rivelare un po 'ai clienti il ​​motivo per cui eravamo giù?
• Quali altre attività devo allontanare le persone per eseguire la reinstallazione? Quanto costa?
• Abbiamo le persone giuste che sanno come far apparire il sistema senza errori? In caso contrario, quanto mi costerà risolvere i bug?

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

Sulla base di un post che ho scritto anni fa , quando potevo ancora essere disturbato dal blog.

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, quanto meno, 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 faranno male 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 farlo 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 chiunque, fai una divulgazione completa e schietta a chiunque sia potenzialmente interessato in una sola volta. So che questo è difficile. So che questo farà male. So che molte aziende vogliono risolvere questo tipo di problema sotto il tappeto, ma temo che dovrai affrontarlo.

Stai ancora esitando a fare questo ultimo passo? Capisco, lo so. Ma guardalo così:

In alcuni casi potresti avere l'obbligo legale di informare le autorità e / o le vittime di questo tipo di violazione della privacy. 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 sto collegando al post in modo che le persone possano farsi una risata economica; Ti sto collegando per avvertirti delle conseguenze della mancata osservanza di questo primo passo.
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".

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 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 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 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. (modifica, per XTZ)

... 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.

Nuotalo sempre dall'orbita. È l'unico modo per esserne sicuri.

_{(fonte: flickr.com )}

La maggior parte dei sistemi sono entità olistiche che hanno una fiducia interiore, implicita. Fidarsi di un sistema compromesso è un'affermazione implicita di cui ti fidi, per cominciare, chiunque abbia commesso la violazione del sistema. In altre parole:

Non puoi fidarti. Non preoccuparti della pulizia. Scollegare e isolare immediatamente la macchina. Comprendi la natura della violazione prima di procedere, altrimenti inviti nuovamente la stessa cosa. Cerca, se possibile, di ottenere la data e l'ora della violazione, in modo da avere un quadro di riferimento. Ne hai bisogno perché se esegui il ripristino dal backup, devi assicurarti che il backup stesso non abbia una copia del compromesso su di esso. Pulisci prima di ripristinare: non prendere scorciatoie.

In pratica, la maggior parte delle persone non lo fa perché pensa che ci vorrà troppo tempo o sarà troppo dirompente. Ho informato innumerevoli clienti della probabilità di problemi continui, ma una reinstallazione viene spesso annullata da un decisore per uno di questi motivi.

Detto questo, sui sistemi in cui sono fiducioso di conoscere il metodo di immissione e l'entità completa del danno (registri off-machine solidi, in genere con un IDS, forse SELinux o qualcosa di simile che limita l'ambito dell'intrusione), I hanno fatto una pulizia senza reinstallare senza sentirsi troppo in colpa.

Molto probabilmente non hanno una routine di ripristino di emergenza che è stata testata abbastanza per sentirsi sicuri nel fare una ricostruzione, o non è chiaro quanto tempo ci vorrebbe o quale impatto sarebbe ... o i backup non sono affidabili o i loro analisti del rischio non capisco l'ambito di un sistema compromesso. Posso pensare a molte ragioni.

Direi che è soprattutto qualcosa che non va nelle routine e nelle politiche di base e che non è qualcosa che vorresti ammettere apertamente - e invece prendi una posizione difensiva. Almeno non riesco a vedere o difendere non cancellare un sistema compromesso, non importa quale sia l'angolazione.

In precedenza non ho modificato il sistema in modo tale da poter fare qualche analisi del vettore su cui sono entrati e successiva anayisi dell'uso e vedere dove sono arrivati ​​all'interno.

Una volta che sei stato rootato, hai un honeypot live e può offrire molto di più di un semplice hack. - specialmente per la polizia.

• Detto questo, sono stato prevenuto per essere in grado di ottenere un sistema pulito in stand-by caldo e di essere in grado di offrire una sicurezza di rete avanzata e veloce per isolare il box rootato.