log sshd cheio de "Não recebeu a sequência de identificação de"

16

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

Meu /var/log/auth.log está cheio dessas mensagens, com spam a cada 6 segundos. meu servidor está no vps e o ip parece ser um ip interno. qual poderia ser a causa desse problema?

ssh

— thkang
fonte

Você tem trabalhos cron em execução no root ?

— Shimon Rachlenko

4

Alguns mal-entendidos (surpresa!) Estão martelando no ssh para tentar encontrar uma combinação de nome de usuário / senha que os leve ao sistema. Provavelmente de algum botnet fazendo o mesmo com quem sabe quantas outras vítimas inocentes.

Instale algo como fail2ban ou DenyHosts (alguns de ambos devem estar disponíveis para qualquer distribuição Linux) ou configure seu firewall local para limitar as tentativas de conexão SSH. Alterar a porta SSH faz com que as tentativas de força bruta mudem, mas também faz com que os usos legítimos falhem.

— vonbrand
fonte

Não se esqueça: sshguard

— 0xC0000022L

3

Eles não estão tentando senhas se não chegaram longe o suficiente para negociar o conjunto de criptografia.

— Jo Rhett

15

Esta resposta está completamente errada e um pouco enganadora. Como mencionado abaixo, se você receber esta mensagem, a conexão não chegou ao estágio de fornecer um nome de usuário, portanto, não pode ser possível adivinhar um. Pode ser: a) verificar legitimamente se sua máquina está ativa - o que é bom ou b) procurar portas ssh que elas atacariam. No entanto, no caso b) você normalmente vê apenas uma única mensagem de qualquer outro endereço. Você pode terminar com a máquina reiniciada por alguma pessoa ou sistema tentando consertar as coisas se a manutenção da atividade for feita para monitoramento.

— Michael

32

Na verdade, isso era do meu provedor de hospedagem - eles enviam spam para meu VPS a cada 6 segundos, para mostrar o status do meu servidor no console da web. Meu servidor é exibido como ativo se meu sshd responder a eles.

Acabei de instalar o OpenVPN e permiti o SSH somente por isso - de acordo com meus provedores, meu servidor possui 100% de tempo de inatividade.

— thkang
fonte

9

Os verificadores de pulsação insensíveis ao protocolo são irritantes.

— Falcon Momot

Sim - por exemplo, se o servidor sshd estiver em execução em uma instância do AWS EC2 e você o configurou atrás de um Elastic Load Balancer com uma verificação de integridade na porta SSH, você verá essa mensagem nos logs sempre que a verificação de integridade for executada .

— Hugh W

9

Provavelmente, é um keepalive (verificando se o servidor está respondendo) de uma comunicação. dispositivo.

— JTrunk
fonte

Você pode explicar que tipos de dispositivos de comunicação podem fazer isso e por quê?

— Elliott B

6

Essas mensagens são lançadas pelo SSH quando alguém tenta acessá-lo, mas não conclui as etapas. Por exemplo, se o NMS estiver verificando se a porta ssh 22 está ativa ou não, ela simplesmente tentará conectar-se à porta 22 e, se a conexão for bem-sucedida, ela será interrompida; nesses casos, o SSH reporta o mesmo.

Por isso, é devido a uma verificação de porta SSH.

— Suyash Jain
fonte

1

Tente alterar a porta ssh de 22 para outra em sshd_config:

sudo nano /etc/ssh/sshd_config

Se não parar as mensagens, o problema também pode ser causado por isso: O Freebpx causa erros sshd no arquivo / var / log / secure log ou veja a discussão aqui "Não recebi a string de identificação" no auth.log nos fóruns do Ubuntu.

— Meriadoc Brandybuck
fonte

1

obrigado, as mensagens com spam desapareceram (pelo menos por enquanto) e não tenho o freepbx instalado.

— thkang

0

Se você já se perguntou quem está digitalizando a porta ou tentando se autenticar em sua máquina, verifique:

# whois 211.110.33.50

# KOREAN(UTF8)

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

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

etc.

— private_nodez
fonte

0

Também pode ser uma tentativa de realizar uma exploração bem conhecida de estouro de buffer.

Está documentado no filtro /etc/fail2ban/filter.d/sshd-ddos.conf, que você pode ativar para se proteger com estas tentativas de invasão:

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".

A sequência de destino para esta exploração é (adivinhem?) "Não recebeu a sequência de identificação de ..."

Você pode distinguir conexões legítimas da rede do provedor para fins de monitoramento, por qualquer outra fonte não autorizada, simplesmente verificando o alcance da rede do endereço IP remoto.

É possível instruir o filtro fail2ban (por meio da diretiva 'ignoreregex') para ignorar a tentativa legítima de acordo.

— Demis Palma ツ
fonte