Scoprire come è stato violato un server compromesso


11

Stavo solo navigando nel sito e ho trovato questa domanda: il mio server è stato violato EMERGENCY . Fondamentalmente la domanda dice: il mio server è stato violato. Cosa dovrei fare?

La risposta migliore è eccellente, ma ha sollevato alcune domande nella mia mente. Uno dei passaggi suggeriti è:

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.

Non ho fatto alcun lavoro di amministratore di sistema, quindi non ho idea di come avrei iniziato. Quale sarebbe il primo passo? So che potresti guardare nei file di registro del server ma come attaccante la prima cosa che farei sarebbe quella di cancellare i file di registro. Come "capiresti" come sono riusciti gli attacchi?


Ho visto alcuni server "hackerati" e nessuno di loro aveva cancellato i log; So che succede spesso però. L'attaccante di solito ha un obiettivo primario (rubare dati o utilizzare il server come proxy / intermediario comunemente) e oscurarne l'ingresso è un obiettivo secondario.
Chris S,

IMHO sarebbe meglio chiedersi come proteggere meglio un server e come controllarlo correttamente.
dal

Al giorno d'oggi i server "hackerati" provengono spesso da strumenti di script per bambini automatizzati che raramente cancellano i registri, facendo spesso pochi tentativi di nascondersi.
Sirex,

Risposte:


11

Inizierò dicendo questo, se NON hai FILE DI LOG , allora ci sono buone probabilità che non capirai MAI dove o come è riuscito l'attacco. Anche con file di registro completi e corretti, può essere estremamente difficile comprendere appieno chi, cosa, dove, quando, perché e come.

Quindi, sapendo quanto sono importanti i file di registro, inizi a capire quanto devi tenerli al sicuro. Questo è il motivo per cui le aziende fanno e dovrebbero investire in sicurezza informazioni e gestione degli eventi o in breve SIEM.

SIEM

In breve, correlare tutti i file di registro in eventi specifici (basati sul tempo o meno) può essere un'attività estremamente scoraggiante. Dai un'occhiata ai syslog del firewall in modalità debug se non mi credi. E questo è solo da un apparecchio! Un processo SIEM inserisce questi file di registro in una serie di eventi logici che rendono molto più facile capire cosa è successo.

Per iniziare a comprendere meglio come, è utile studiare le metodologie di penetrazione .

È anche utile sapere come viene scritto un virus . O come scrivere un rootkit .

Può anche essere estremamente utile impostare e studiare un honeypot .

Aiuta anche ad avere un parser di log e diventare esperto con esso.

È utile raccogliere una base per la rete e i sistemi. Qual è il traffico "normale" nella tua situazione rispetto al traffico "anormale"?

CERT ha un'eccellente guida su cosa fare dopo che il tuo computer è stato violato, in particolare (che riguarda direttamente la tua domanda specifica) la sezione "Analizza l'intrusione":

  • Cerca le modifiche apportate al software di sistema e ai file di configurazione
  • Cerca modifiche ai dati
  • Cerca strumenti e dati lasciati dall'intruso
  • Rivedere i file di registro
  • Cerca i segni di uno sniffer di rete
  • Controlla altri sistemi sulla tua rete
  • Verificare la presenza di sistemi coinvolti o interessati in siti remoti

Ci sono molte domande simili alle tue che sono state poste su SF:

  1. Come eseguire un post mortem di un hack del server
  2. Strani elementi nel file host e Netstat
  3. è un tentativo di hacking?
  4. Come posso imparare Linux dal punto di vista della pirateria informatica o della sicurezza

Questo può essere un processo estremamente complicato e coinvolto. La maggior parte delle persone, me compreso, assumerebbe solo un consulente se fosse coinvolto più di quanto i miei apparecchi SIEM potrebbero mettere insieme.

E, a quanto pare, se mai vuoi capire COMPLETAMENTE come sono stati hackerati i tuoi sistemi, devi passare anni a studiarli e rinunciare alle donne.


+1 per porre le basi prima che accada con SIEM
Rob Moir,

Scusate. La mia risposta è un po 'ovunque in questo momento. Ho iniziato a scriverlo alle 04:00 e il mio caffè IV non è ancora stato messo in atto.
GregD,

2

La risposta a quel poco può essere larga un milione di miglia e alta, e deselezionare ciò che è accaduto a un server compromesso può essere quasi una forma d'arte tanto quanto qualsiasi altra cosa, quindi di nuovo darò punti di partenza ed esempi piuttosto che un set definitivo dei passi da seguire.

Una cosa da tenere a mente è che, una volta affrontata un'intrusione, è possibile controllare il codice, l'amministrazione / configurazione dei sistemi e le procedure con la consapevolezza che vi è sicuramente un punto debole. Ciò aiuta a guidare la motivazione più che a cercare una debolezza teorica che potrebbe essere o meno presente. Molto spesso le persone mettono le cose online pur sapendo che il codice avrebbe potuto essere verificato un po 'più difficile, se solo avessimo avuto il tempo; o il sistema si è bloccato un po 'più saldamente, se non fosse stato così scomodo; o procedure rese un po 'più restrittive, se non fosse stato un tale fastidio per il capo ricordare lunghe password. Sappiamo tutti dove sono i nostri punti deboli più probabili, quindi inizia con quelli.

In un mondo ideale avrai i log archiviati su un server syslog diverso (speriamo non compromesso) , non solo dai server ma da qualsiasi firewall, router, ecc. Che registra anche il traffico. Ci sono anche strumenti come Nessus disponibili che possono analizzare un sistema e cercare punti deboli.

Per software / framwork di terze parti, ci sono spesso guide sulle migliori pratiche che è possibile utilizzare per controllare la distribuzione, oppure è possibile prestare maggiore attenzione alle notizie sulla sicurezza e ai programmi di patching e scoprire alcuni buchi che potrebbero essere stati utilizzati.

Infine, la maggior parte delle intrusioni lasciano uno spoor ... se hai il tempo e la pazienza di trovarlo. "Drive by": intrusioni di script kiddie o intrusioni con i toolkit di hacking tendono a concentrarsi su punti deboli comuni e possono lasciare uno schema che ti indirizza nella giusta direzione. La cosa più difficile da analizzare può essere un'intrusione diretta manuale (ad es. Qualcuno non ha voluto hackerare "un" sito Web, ma ha invece voluto hackerare "il tuo" sito Web in modo specifico), e queste ovviamente sono le cose più importanti da capire.

Per qualcuno che non sa davvero da dove cominciare (o anche per persone con esperienza che hanno altri doveri) il primo passo è probabilmente assumere qualcuno con una buona esperienza dei passaggi precedenti. Un altro vantaggio di questo approccio è che guarderanno la tua configurazione senza alcuna nozione preconcetta o interesse personale nelle risposte.


1
+1 In effetti aggiungerei che prevenire è meglio che combattere, ciò significa anche prevenire che accada un giorno. Quindi è importante a prima vista avere una strategia per semplificare la risoluzione dei problemi e ridurre gli impatti.
dal

1

"So che potresti cercare nei file di registro del server ma come attaccante la prima cosa che farei sarebbe quella di cancellare i file di registro."

A seconda del tipo di compromesso, l'utente malintenzionato potrebbe non disporre di privilegi sufficienti sul server compromesso per poter cancellare i log. È inoltre consigliabile che i registri del server siano disattivati ​​su un altro server, per evitare manomissioni (esportate automagicamente a determinati intervalli).

Oltre ai log del server compromessi, ci sono ancora i log di rete (Firewall, Router, ecc.) Nonché i log di autenticazione dal servizio directory, se ce n'è uno (Active Directory, RADIUS, ect)

Quindi guardare i registri è ancora una delle cose migliori che si possano fare.

Quando si ha a che fare con una scatola compromessa, la vagliatura dei registri è sempre uno dei miei principali modi di mettere insieme ciò che è accaduto.

-Josh


Ho fatto alcune analisi dei tronchi molto limitate per un corso della scorsa settimana. Come troveresti il ​​buco in un enorme file di registro? Guarderesti le ultime voci? Come identificheresti voci sospette?
sixtyfootersdude,

Come identificheresti voci sospette? idealmente mantenendo le cronologie dei registri per il confronto e / o esaminandole abbastanza frequentemente per sapere che aspetto hanno le voci non sospette, in modo da poter eliminare le normali cose quotidiane e osservare da vicino ciò che resta.
Rob Moir,

1
Concordo con Moir. Il amministratore di sistema deve conoscere il sistema abbastanza bene da sapere quando è in esecuzione un servizio che non dovrebbe essere. Alcune voci di registro sospette sono davvero facili da trovare perché hanno una firma specifica che lasciano (ad esempio la scansione di Nimda), mentre con altre voci di registro, solo più contesto determinerà se era legittimo o meno.
Josh Brower,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.