Il mio server Linux è stato violato. Come faccio a sapere come e quando è stato fatto?


11

Ho un server di casa che esegue una distribuzione Ubuntu desktop. L'ho trovato nel mio crontab

* * * * * /home/username/ /.access.log/y2kupdate >/dev/null 2>&1

e guardando in quella directory (lo spazio dopo username / è un nome di directory) ho trovato molti script che ovviamente stanno facendo qualcosa che non dovrebbero.

Prima di cancellare quel computer e reinstallare elementi, vorrei scoprire cosa ha causato la violazione della sicurezza e quando è stata eseguita. Quindi non apro più lo stesso buco.

In quali file di registro dovrei cercare? Gli unici server di cui sono a conoscenza che sono in esecuzione sul computer sono sshd e lighttpd.

Cosa devo fare per rilevare se succedono cose del genere?


@Person che ha votato per passare a SU: come pensi che la forensics di virus / hacking si riferisca a Super User più di Server Fault ??
Chris S,

3
Sono felice di sapere che il piano è quello di cancellare il computer e reinstallare le cose. Questa è assolutamente la cosa giusta da fare, non importa quello che trovi, perché c'è sempre una buona possibilità che ci sia qualcosa di peggio che non hai trovato.
Mattdm,

Sì, dovresti davvero votare per passare a IT Security ( security.stackexchange.com ), non SU o Serverfault!
Rory Alsop,

Risposte:


4

Innanzitutto, assicurati che il computer sia disconnesso da qualsiasi rete.
In secondo luogo, assicurarsi di rimuovere tutti i dati importanti dalle unità prima di riavviare il sistema operativo compromesso.

Inizia con il controllo dei timestamp sui file in questione. Spesso sono accurati.
Fai un riferimento incrociato a quelli con il registro httpd e il registro auth se non sono stati cancellati. Se l'altro è stato cancellato, puoi scommettere che era il mezzo di accesso. Se sono ancora intatti, potresti essere in grado di ottenere maggiori informazioni su come sono entrati dal registro.

Se sono tutti cancellati, sei piuttosto fregato. Probabilmente ci vorrebbe più tempo per capire cosa è successo di quanto valga la pena.

Hai detto che quei due servizi erano in esecuzione, c'era un buon firewall in atto per impedire l'accesso a tutto il resto? Hai autorizzato SSH sulla porta 22; il tuo login è ragionevolmente facile da indovinare; hai autorizzato gli accessi con password; hai avuto qualche tipo di limite di velocità reale per gli accessi con password? Hai installato qualche software aggiuntivo con lighttpd; perl; php; cgi; un CMS o simile? Stavi eseguendo la versione aggiornata di tutto il software; ti iscrivi alle notifiche di sicurezza per tutto il software che esegui e valuti attentamente tutte le notifiche per vedere se si applicano al software che esegui / esponi al pubblico?


L'installazione era una Ubuntu Desktop Edition 10.x standard, nulla in particolare è stato fatto per motivi di sicurezza. Ho pensato che ci fosse un firewall abbastanza buono di default. Non è corretto? Ho consentito l'accesso con password sulla porta 22, ma la password era una stringa casuale di 8 caratteri. Dovrebbe essere abbastanza buono?
Jonatan Kallus,

Credo che il firewall predefinito sia "Wide Open - No Firewall". A meno che non sia stato configurato con cura, non sta facendo nulla.
Chris S,

La domanda è: quali servizi stavi eseguendo più di quale firewall. A meno che il firewall non sia impostato per configurare particolari IP per l'accesso, il firewall migliore è innanzitutto non eseguire servizi non necessari. E qual è stata la tua configurazione di rete? Aperto a Internet? All'interno di una rete privata? Non avevi un firewall nel punto in cui la tua rete interna andava in Internet o il tuo server era in una DMZ?
Bart Silverstrim,

Il server è stato collegato direttamente a Internet. L'ho usato anche come router. Se il firewall predefinito è completamente aperto, penso di avere abbastanza spiegazioni su come ciò potrebbe accadere ..
Jonatan Kallus,

4

Questo è un tipo di argomento in sé; puoi cercare Google forensics su Linux per maggiori informazioni. Fondamentalmente dovresti prima creare un'immagine delle tue unità per l'analisi offline, quindi pulire il computer e installarlo da una lavagna pulita.

E ricorda tutte le spese accessorie. Chiunque utilizzasse il computer avrebbe potuto compromettere le proprie password. Cambia password, mantienilo offline, ecc. Fino a quando non lo ottieni in una "stanza pulita" (VM isolata).

Altrimenti è un sacco di controllo dei registri (che possono essere falsi) e controllo delle applicazioni (script php? Database? Aggiornato per le ultime correzioni? Altri utenti che forniscono password?)

Non c'è letteralmente un modo semplice per rispondere alla tua domanda poiché avresti bisogno di fare un lavoro forense sul server e verificare la presenza di buchi. È possibile utilizzare alcuni strumenti automatici, ma tenere presente che se l'attaccante aveva i privilegi di root non ci si può più fidare dei binari di sistema e non ci si può fidare dei log.

Per quanto riguarda gli attacchi futuri, a seconda di quanto si desidera renderlo sicuro, è possibile iniziare reindirizzando i registri su un sistema che viene appena utilizzato per salvare i registri di sistema. Nessun altro accesso, per ridurre l'impronta dell'attacco.

Avresti anche eseguito software di checksum sul tuo sistema come Tripwire per verificare l'integrità dei tuoi file.

E ovviamente tieniti aggiornato con gli aggiornamenti ed esegui il software di scansione che controlla i rootkit.

Ancora una volta, la sicurezza non è una novità. Può essere una specialità in sé. La sicurezza a più livelli può diventare tanto rigorosa quanto il controllo di host / IP che non appartengono alla tua rete, crittografia di tutti gli accessi al sistema, invio di registri giornalieri delle modifiche rilevate sul tuo sistema e configurazione di un honeypot sulla tua rete per cercare attività strane (perché il mio server sta provando a connettersi alla porta 25 sul computer honeypot?)

Innanzitutto, se si desidera verificare l'attività, ottenere l'immagine del disco e reinstallare il software del server. Da zero. I file binari del server non possono più essere considerati attendibili.

EDIT - alcune altre cose che mi capitano da quando stai eseguendo SSH - installa denyhosts. Può essere configurato in modo che gli attacchi automatizzati contro il tuo sistema su SSHD vengano bloccati dopo un numero X di tentativi. Può anche essere configurato per l'aggiornamento da altri server denyhost in un "cloud" per condividere IP bloccati per ridurre al minimo gli attacchi automatici. Puoi anche spostare la porta su cui è in ascolto; molte persone sottolineano che è solo la sicurezza attraverso l'oscurità, ma dato il numero di scansioni di robot, ciò riduce significativamente i tentativi casuali di irruzione.


Grazie! Hai davvero risposto a metà della domanda ciascuno, vorrei poter contrassegnare entrambi come risposta accettata.
Jonatan Kallus,
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.