Come posso dimostrare che gli attacchi SSH non provengono dalla mia applicazione?

6

La mia applicazione web ruby on rails è ospitata su Linode. Linode ha aperto un ticket e ha accusato il mio server Linode di attaccare altri server. I registri hanno rivelato che si tratta di un attacco di forza bruta SSH originato dal mio server. Ho studiato il mio codice sorgente, controllato se sul mio server c'è uno script malevolo ma non ne ho trovato nessuno.

  1. Come posso dimostrare che l'attacco non proviene dalla mia fine?
  2. Se tuttavia l'attacco proviene dalla mia fine, come posso rilevare quale processo è responsabile dell'attacco?

La mia applicazione web è in esecuzione su Ubuntu 12.04.

    
posta Pratik Ganvir 29.05.2013 - 07:32
fonte

3 risposte

6

Linode utilizza Xen , il che significa che non hai solo un'app; hai un intero sistema operativo, completo di kernel e librerie di base. L'attacco proviene dal tuo sistema, quindi è completamente nella tua giurisdizione. L'hacker ha inserito il tuo sistema in qualche modo, ma una volta lì, se è almeno per metà competente, ha usato un rootkit per trasformare la sua irruzione in un'installazione permanente. Il rovescio della medaglia è che un sistema rootkit non verrà visualizzato dall'interno del sistema: il kernel sarebbe stato infetto e non mostrerà il processo di attacco dagli aggressori.

(Sto usando qui l'ipotesi che una volta che l'aggressore è entrato, potrebbe aumentare i suoi diritti a livello di root - questa è l'ipotesi prudente, perché i sistemi operativi sono raramente solidi contro gli attaccanti locali.)

Ciò implica che il tuo sistema dovrebbe essere cancellato e reinstallato da zero; è stato compromesso e non ci si può più fidare. A quel punto avresti due obiettivi:

  1. Scopri come è arrivato l'autore dell'attacco, in modo che non lo faccia più nel sistema appena reinstallato.
  2. Convinci le persone di Linode che sei una vittima, non un complice.

Per il primo punto, questa è una questione di analisi di tutti i log e di altre tracce che possono essere trovate nel tuo sistema. Quindi, prima di raschiare, prendine una copia completa (preferibilmente una copia byte per byte del suo disco rigido virtuale) per ulteriori analisi. Ma ricorda che se l'attaccante è ragionevolmente buono, ha coperto le sue tracce (questo è ciò che i rootkit sono per). Inoltre, alcuni controlli del codice dell'applicazione sarebbero in ordine: l'utente malintenzionato ha inserito in qualche modo tramite uno dei servizi accessibili esternamente del server, che include l'applicazione. Un'altra possibilità è che l'utente malintenzionato abbia indovinato la password dell'account SSH (dopo tutto, sai che questo che fa esegue attacchi a forza bruta sugli accessi SSH): sul tuo nuovo sistema , usa una password nuova, più grande, più casuale (non scriverla sul tuo sistema attuale! È compromessa, quindi probabilmente acquisisce le modifiche della password al volo).

Per il secondo punto, questa è una questione di fiducia e relazioni umane. Non puoi dimostrare che non sei l'attaccante; ma i Linode sanno che i sistemi dirottati sono purtroppo una realtà comune. Basta esercitare la due diligence, come reinstallare il sistema da zero: affrontare questo noioso compito farà molto per stabilire la tua buona fede in questa materia.

    
risposta data 29.05.2013 - 13:11
fonte
2

Devi studiare il traffico proveniente dal tuo server. Rileverà se il tuo server si sta collegando ai servizi SSH su altre reti.

Se non trovi alcuna prova del traffico generato dal tuo server, offri questa prova a linode e falla rifiutarla o accettarla.

Se trovi le prove necessarie per passare attraverso il traffico di rete, i registri, i processi in esecuzione e i file locali per determinare le cause del comportamento del server in questo modo.

Quando ciò è fatto, devi nuke il server e reinstallare da un'origine attendibile mentre implementa la correzione prima che sia esposta allo stesso vettore di attacco che lo ha compromesso in primo luogo.

    
risposta data 29.05.2013 - 09:07
fonte
1

Puoi dimostrarlo, se riesci a trovare un sistema compromesso in qualsiasi modo, forma o forma sul tuo server. Hai una parte della dimostrazione. Avere una singola riga di un file di registro non è una prova. Quindi, questo è davvero difficile da "provare". La sicurezza IT ha molto a che fare con il WOT (Web of Trust). Devi permetterti di "fidarti" di te in qualche modo. Il modo più semplice per farlo è consegnare il codice sorgente. Ma questo non è possibile nella maggior parte dei casi.

Tuttavia, se hanno prove concrete del fatto che il tuo server ha provato più accessi su server con SSH, potresti avere qualcosa da fare. Vorrei effettuare il riavvio di un'immagine (hard disk, RAM) e assumere un pentester.

Informazioni su come rilevare l'attacco da soli. Metti uno sniffer sulla porta ethernet del tuo server. Il modo migliore per farlo è usare una porta SPAN. Non annusare il sistema stesso.

Quindi goodluck:)

    
risposta data 29.05.2013 - 08:26
fonte

Leggi altre domande sui tag