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

17

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?

ssh

— thkang
fuente

¿Tiene trabajos cron ejecutándose bajo root ?

— Shimon Rachlenko

4

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.

— vonbrand
fuente

No olvides: sshguard

— 0xC0000022L

3

No están probando contraseñas si no llegaron lo suficientemente lejos como para negociar el conjunto de cifrado.

— Jo Rhett

15

Esta respuesta es completamente incorrecta y un poco engañosa. Como se menciona a continuación, si recibe este mensaje, la conexión no llegó a la etapa de dar un nombre de usuario, por lo que no puede intentar adivinar uno. Puede ser a) verificar legítimamente que su máquina está viva, lo cual está bien ob) escanear en busca de puertos ssh que atacaría. Sin embargo, en el caso b) normalmente solo vería un solo mensaje de cualquier otra dirección. Podría terminar con su máquina reiniciada por alguna persona o sistema que intente arreglar las cosas si el keepalive se realiza para monitoreo.

— Michael

32

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.

— thkang
fuente

99

Los verificadores de latidos insensibles al protocolo son molestos.

— Falcon Momot

Sí, por ejemplo, si su servidor sshd se ejecuta en una instancia de AWS EC2 y lo configuró detrás de un Elastic Load Balancer con una comprobación de estado en el puerto SSH, verá este mensaje en los registros cada vez que se ejecute la comprobación de estado .

— Hugh W

10

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

— JTrunk
fuente

¿Puede explicar qué tipos de dispositivos de comunicación pueden hacer esto y por qué?

— Elliott B

7

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.

— Suyash Jain
fuente

1

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.

— Meriadoc Brandybuck
fuente

1

gracias, los mensajes de spam desaparecieron (al menos por ahora) y no tengo instalado freepbx.

— thkang

0

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.

— privado_nodez
fuente

0

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.

— Demis Palma ツ
fuente