registro sshd lleno de "No se recibió cadena de identificación de"

Mar  2 02:34:02 freetalker3 sshd[28436]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:08 freetalker3 sshd[28439]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:13 freetalker3 sshd[28442]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:19 freetalker3 sshd[28445]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:24 freetalker3 sshd[28448]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:30 freetalker3 sshd[28451]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:35 freetalker3 sshd[28454]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:41 freetalker3 sshd[28457]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:46 freetalker3 sshd[28460]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:52 freetalker3 sshd[28463]: Did not receive identification string from 211.110.33.50
Mar  2 02:34:57 freetalker3 sshd[28466]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:03 freetalker3 sshd[28469]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:08 freetalker3 sshd[28472]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:14 freetalker3 sshd[28475]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:20 freetalker3 sshd[28478]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:25 freetalker3 sshd[28481]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:31 freetalker3 sshd[28484]: Did not receive identification string from 211.110.33.50
Mar  2 02:35:36 freetalker3 sshd[28488]: Did not receive identification string from 211.110.33.50

Mi /var/log/auth.log está lleno de estos mensajes, spam cada 6 segundos. mi servidor está en vps y parece que la ip es interna. ¿Cuál podría ser la causa de este problema?

Algunos malhechores (¡sorpresa!) Están martillando en ssh para tratar de encontrar una combinación de nombre de usuario / contraseña que los ingrese al sistema. Probablemente de alguna botnet haciendo lo mismo a quién sabe cuántas otras víctimas desprevenidas.

Instale algo como fail2ban o DenyHosts (algunos de ambos deberían estar disponibles para cualquier distribución de Linux), o configure su firewall local para limitar los intentos de conexión SSH. Cambiar el puerto SSH hace que la tonta fuerza bruta intente fallar, pero también hace que los usos legítimos fallen.

En realidad, esto fue de mi proveedor de alojamiento: envían spam a mi VPS cada 6 segundos, para mostrar el estado de mi servidor en su consola web. Mi servidor se muestra como activo si mi sshd los responde.

Acabo de instalar OpenVPN y permití SSH solo a través de eso, por lo que, según mis proveedores, mi servidor cuenta con un 100% de tiempo de inactividad.

Es muy probable que sea un keepalive (verificando que el servidor está respondiendo) desde una comunicación. dispositivo.

SSH genera dichos mensajes cuando alguien intenta acceder a ellos pero no termina los pasos. Por ejemplo, si NMS está verificando si el puerto ssh 22 está activo o no, simplemente intentará conectarse en el puerto 22 y si la conexión es exitosa, colgará, en tales casos SSH informa lo mismo.

Por lo tanto, se debe a un escaneo de puertos SSH.

Intente cambiar el puerto ssh de 22 a otro en sshd_config:

sudo nano /etc/ssh/sshd_config

Si no detiene los mensajes, el problema también puede ser causado por esto: Freebpx causa errores sshd en el archivo de registro / var / log / secure o vea la discusión aquí "No se recibió la cadena de identificación" en auth.log en los foros de Ubuntu.

Si alguna vez se pregunta quién está escaneando puertos o está intentando autenticarse en su máquina, simplemente verifique:

# whois 211.110.33.50

# KOREAN(UTF8)

조회하신 IPv4주소는 한국인터넷진흥원으로부터 아래의 관리대행자에게 할당되었으며, 할당 정보는 다음과 같습니다.

[ 네트워크 할당 정보 ]
IPv4주소           : 211.110.0.0 - 211.110.239.255 (/17+/18+/19+/20)

etc.

También podría ser un intento de llevar a cabo una conocida explotación de desbordamiento de búfer.

Está documentado en el filtro /etc/fail2ban/filter.d/sshd-ddos.conf, que puede habilitar para protegerse mediante estos intentos de pirateo:

Fail2Ban ssh filter for at attempted exploit
The regex here also relates to a exploit:
http://www.securityfocus.com/bid/17958/exploit
The example code here shows the pushing of the exploit straight after
reading the server version. This is where the client version string normally
pushed. As such the server will read this unparsible information as
"Did not receive identification string".

La cadena de destino para este exploit es (¿adivina qué?) "No recibió la cadena de identificación de ..."

Puede distinguir las conexiones legítimas que provienen de la red de su proveedor para fines de monitoreo, por cualquier otra fuente no autorizada, simplemente verificando el rango de red de la dirección IP remota.

Es posible instruir al filtro fail2ban (a través de la directiva 'ignoreregex') para ignorar el intento legítimo en consecuencia.