Skip to content

Come gestire un server compromesso?

Fai del tuo meglio per comprendere bene il codice prima di utilizzarlo nel tuo lavoro e se vuoi contribuire con qualcosa puoi condividerlo con noi.

Soluzione:

Soluzione 1:

È difficile dare consigli specifici da ciò che avete postato qui, ma ho alcuni consigli generici basati su un post che ho scritto secoli fa, quando potevo ancora prendermi la briga di scrivere sul blog.

Non farti prendere dal panico

Prima di tutto, non ci sono "soluzioni rapide" se non il ripristino del sistema da un backup effettuato prima dell'intrusione, e questo comporta almeno due problemi.

  1. È difficile individuare il momento in cui è avvenuta l'intrusione.
  2. Non aiuta a chiudere il "buco" che ha permesso l'intrusione l'ultima volta, né a gestire le conseguenze di un eventuale "furto di dati".

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 speciale e unico. 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 è questo 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 di fretta e non cercate di far finta che le cose non siano mai successe 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, dipende da voi. Ma se li seguite correttamente, alla fine le cose andranno meglio. La medicina può 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 rivolti a Internet e a quelli che contengono dati finanziari o altri dati sensibili dal punto di vista commerciale.
  4. Se il sistema contiene dati personali di qualcuno, informate immediatamente la persona responsabile della protezione dei dati (se non siete voi) e sollecitate una divulgazione completa. So che questo è difficile. So che questo farà male. So che molte aziende vogliono nascondere questo tipo di problema sotto il tappeto, ma l'azienda deve affrontarlo e deve farlo tenendo conto di tutte le leggi sulla 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 se lo scoprono da soli solo dopo che qualcuno ha 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? Il male è già accaduto. L'unica domanda da porsi è quanto bene lo affronterete.

Comprendere appieno il problema:

  1. Non rimettete in linea i sistemi interessati fino a quando questa fase non sarà completamente 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 ho intenzione di linkare quel post per farvi fare una risata a buon mercato, ma la vera tragedia è quando le persone non imparano dai propri errori.
  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".

Perché non "riparare" l'exploit o il rootkit individuato e rimettere il sistema online?

In situazioni come questa il problema è che non avete più il controllo del sistema. Non è più il vostro computer.

L'unico modo per essere certi di avere il controllo del sistema è ricostruire il sistema. Se da un lato è molto utile trovare e correggere l'exploit utilizzato per entrare nel sistema, dall'altro non si può essere sicuri di cos'altro sia stato fatto al sistema una volta che gli intrusi ne hanno ottenuto il controllo (in effetti, non è raro che gli hacker che reclutano sistemi in una botnet applichino le patch agli exploit che hanno utilizzato loro stessi, per salvaguardare il "loro" nuovo computer da altri hacker, oltre a installare il loro rootkit).

Preparate un piano per il recupero 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; ma 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, dovete essere consapevoli delle conseguenze per gli altri se questi dati appartengono a clienti o visitatori del sito piuttosto che direttamente a voi.
  5. Monitorare 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 cercano di entrare 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, per lo meno, 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? Se sì, 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 la distribuzione del codice: se si richiede di fare qualcosa di "speciale" per distribuire l'ultima versione della propria applicazione web, si cerca di automatizzarla e di assicurarsi che sia sempre eseguita 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 da qualche altra parte. Questa parte ha due aspetti: il più ovvio è 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 della 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. Si tratta probabilmente di un altro "scenario di disastro" in cui potreste imbattervi, semplicemente con una serie di problemi e questioni diverse dal solito "la stanza del server ha preso fuoco"/"è stata invasa da giganteschi pelosi mangiatori di server".

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

Sembra che siate in una situazione leggermente superiore alle vostre possibilità.ead; non c'è problema. Chiamate il vostro capo e iniziate a negoziare per ottenere un budget per le emergenze di sicurezza. 10.000 dollari potrebbero essere un buon punto di partenza. Poi devi chiedere a qualcuno (un PFY, un collega, un manager) di iniziare a chiamare le aziende specializzate nella risposta agli incidenti di sicurezza. Molte possono rispondere entro 24 ore, e a volte anche più velocemente se hanno un ufficio nella vostra città.

Avete anche bisogno di qualcuno che si occupi del triage dei clienti; senza dubbio qualcuno lo sta già facendo. Qualcuno deve essere al telefono con loro per spiegare cosa sta succedendo, cosa si sta facendo per gestire la situazione e per rispondere alle loro domande.

Poi, è necessario.

  1. Mantenere la calma. Se siete responsabili della risposta agli incidenti, quello che fate ora deve dimostrare la massima professionalità e leadership. Documentate tutto ciò che fate e tenete informati il vostro manager e il team esecutivo delle principali azioni intraprese.e; Questo include la collaborazione con un team di risposta, la disattivazione dei server, il backup dei dati e la rimessa in linea. Non hanno bisogno di dettagli cruenti, ma dovrebbero sentirvi ogni 30 minuti circa.

  2. Siate realistici. Non siete professionisti della sicurezza e ci sono cose che non sapete. Va bene così. Quando accedete ai server e guardate i dati, dovete capire i vostri limiti. Siate delicati. Nel corso della vostra indagine, assicuratevi di non calpestare informazioni vitali o di non modificare qualcosa che potrebbe essere necessario in seguito. Se vi sentite a disagio o state tirando a indovinare, è il caso di fermarsi e rivolgersi a un professionista esperto.

  3. Procuratevi una chiavetta USB pulita e dischi rigidi di riserva. Qui raccoglierete le prove. Eseguite backup di tutto ciò che ritenete possa essere rilevante: comunicazioni con il vostro ISP, dump di rete, ecc. Anche se le forze dell'ordine non vengono coinvolte, in caso di causa legale vorrete queste prove per dimostrare che la vostra azienda ha gestito l'incidente di sicurezza in modo professionale e appropriato.

  4. La cosa più importante è fermare le perdite. Identificate e tagliate l'accesso ai servizi, ai dati e alle macchine compromessi. Di preferenza, dovreste interrompere il cablaggio di rete.e; se non è possibile, togliere la corrente.

  5. Successivamente, è necessario rimuovere l'aggressore e chiudere le falle. Presumibilmente, l'aggressore non ha più accesso interattivo perché è stata tolta la rete. Ora è necessario identificare, documentare (con backup, screenshot e note di osservazione personali; o preferibilmente anche rimuovendo le unità dai server interessati e facendo una copia completa dell'immagine del disco) e quindi rimuovere qualsiasi codice e processo che ha lasciato. Questa parte successiva fa schifo se non si dispone di backup; si può provare a districare l'aggressore dal sistema a mano, ma non si avrà mai la certezza di aver recuperato tutto ciò che ha lasciato. I rootkit sono pericolosi e non tutti sono rilevabili. La risposta migliore consiste nell'identificare la vulnerabilità utilizzata per entrare, fare copie immagine dei dischi interessati, quindi cancellare i sistemi interessati e ricaricarli da un backup noto e valido. Non fidatevi ciecamente del vostro backup; verificatelo! Riparate o chiudete la vulnerabilità prima che il nuovo host sia di nuovo in rete e poi portatelo online.

  6. Organizzare tutti i dati in un report. A questo punto la vulnerabilità è chiusa e avete un po' di tempo per respirare. Non siate tentati di saltare questo passaggio: è ancora più importante del resto del processo. Nel rapporto, dovete identificare cosa è andato storto, come il vostro team ha risposto e le misure che state adottando per evitare che l'incidente si ripeta. Siate il più dettagliati possibile; questo non è solo per voi, ma anche per il vostro management e come difesa in una potenziale causa legale.

Si tratta di un'analisi molto dettagliata delle cose da fare; la maggior parte del lavoro consiste semplicemente nella documentazione e nella gestione dei backup. Non fatevi prendere dal panico, potete farlo. I fortemente vi consiglio di richiedere l'aiuto di un professionista della sicurezza. Anche se siete in grado di gestire ciò che sta accadendo, il loro aiuto sarà inestimabile e di solito sono dotati di attrezzature che rendono il processo più facile e veloce. Se il vostro capo si oppone al costo, ricordategli che è molto basso se paragonato alla gestione di una causa legale.

Le faccio le mie consolazioni per la sua situazione. Buona fortuna.


Soluzione 3:

Il CERT ha un buon documento intitolato Steps for Recovering from a UNIX or NT System Compromise. I dettagli tecnici specifici di questo documento sono un po' datati, ma molti dei consigli generali sono ancora direttamente applicabili.

Un rapido riassunto dei passi fondamentali è il seguente.

  • Consultare la politica di sicurezza o la direzione.
  • Ottenere il controllo (mettere il computer offline)
  • Analizzare l'intrusione, ottenere i log, capire cosa è andato storto.
  • Riparare le cose
    • Installare una versione pulita del sistema operativo!!! Se il sistema è stato compromesso non ci si può fidare, punto.
  • Aggiornate i sistemi in modo che questo non possa accadere di nuovo
  • Riprendere le operazioni
  • Aggiornare la politica per il futuro e documentare

Vorrei indicarvi in modo specifico la sezione E.1.

E.1.
Tenete presente che se una macchina è
compromesso, qualsiasi cosa su quel sistema
sistema potrebbe essere stato modificato, compresi
il kernel, i file binari, i file di dati,
processi in esecuzione e la memoria. In
in generale, l'unico modo per essere sicuri che una
macchina sia priva di backdoor e
modifiche da parte di un intruso è reinstallare
il sistema operativo

Se non si dispone di un sistema già attivo come tripwire, non c'è modo di essere certi al 100% di aver ripulito il sistema.


Soluzione 4:

  1. Identificare il problema. Leggere i registri.
  2. Contenere. Avete scollegato il server, quindi è fatta.
  3. Sradicare. Reinstallare il sistema interessato, molto probabilmente. Non cancellate però il disco rigido di quello violato, ma usatene uno nuovo. È più sicuro e potrebbe essere necessario quello vecchio per recuperare gli hack brutti che non sono stati salvati e per fare le indagini forensi per scoprire cosa è successo.
  4. Recupero. Installate tutto ciò che è necessario e recuperate i backup per mettere online i vostri clienti.
  5. Follow-up. Scoprite qual è stato il problema e impedite che si ripeta.

Soluzione 5:

La risposta di Robert, "pillola amara", è precisa ma completamente generica (come la vostra domanda). Sembra che abbiate un problema di gestione e che abbiate bisogno di un sysadmin a tempo pieno se avete un server e 600 client, ma questo non vi aiuta ora.

Gestisco un'azienda di hosting che fornisce un po' di assistenza in questa situazione, quindi ho a che fare con molti computer compromessi, ma mi occupo anche delle migliori pratiche per i nostri. Diciamo sempre ai nostri clienti compromessi di ricostruire, a meno che non siano assolutamente sicuri della natura della compromissione. Non c'è altra strada responsabile nel lungo termine.

Tuttavia, quasi certamente siete solo la vittima di uno script kiddy che voleva un trampolino di lancio per attacchi DoS, o IRC bouncer, o qualcosa di completamente estraneo ai siti e ai dati dei vostri clienti. Pertanto, come misura temporanea mentre si ricostruisce, si potrebbe prendere in considerazione l'installazione di un firewall in uscita pesante sul proprio sistema. Se riuscite a bloccare tutte le connessioni UDP e TCP in uscita che non sono assolutamente necessarie per il funzionamento dei vostri siti, potete facilmente rendere il vostro box compromesso inutilizzabile per chiunque lo prenda in prestito da voi, e ridurre a zero l'effetto sulla rete del vostro provider.

Questo processo potrebbe richiedere qualche ora se non l'avete mai fatto prima e non avete mai considerato un firewall, ma potrebbe aiutarvi a ripristinare il servizio dei vostri clienti. con il rischio di continuare a dare all'aggressore l'accesso ai dati dei clienti. Dal momento che dite di avere centinaia di clienti su un'unica macchina, immagino che stiate ospitando piccoli siti web di brochure per piccole aziende e non 600 sistemi di e-commerce pieni di numeri di carte di credito. Se è così, questo potrebbe essere un rischio accettabile per voi e far tornare il vostro sistema online più velocemente che controllare 600 siti alla ricerca di bug di sicurezza. prima prima di riportare in vita qualcosa. Ma voi saprete quali dati sono presenti e quanto sarete tranquilli nel prendere questa decisione.

Questa non è assolutamente la prassi migliore, ma se non è quello che è successo finora presso il vostro datore di lavoro, agitare il dito contro di loro e chiedere decine di migliaia di sterline per una squadra SWAT per qualcosa che potrebbero ritenere colpa vostra (per quanto ingiustificata!) non sembra un'opzione pratica.

L'aiuto del vostro ISP in questo caso sarà fondamentale: alcuni ISP forniscono un server console e un ambiente di avvio della rete (plug, ma almeno sapete che tipo di struttura cercare) che vi permetterà di amministrare il server mentre siete disconnessi dalla rete. Se questa è un'opzione, chiedetela e usatela.

Ma a lungo termine dovreste pianificare una ricostruzione del sistema basata sul post di Robert e una verifica di ogni sito e della sua configurazione. Se non riuscite ad aggiungere un sysadmin al vostro team, cercate un accordo di hosting gestito in cui pagate il vostro ISP per l'aiuto del sysadminning e la risposta in 24 ore per questo tipo di cose. Buona fortuna 🙂

Commenti e valutazioni del tutorial



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.