“POSSÍVEL PARTE DE INTERVALO!” Em / var / log / secure - o que isso significa?


96

Eu tenho uma caixa do CentOS 5.x sendo executada em uma plataforma VPS. Meu host VPS interpretou mal uma consulta de suporte que eu tinha sobre conectividade e liberou efetivamente algumas regras do iptables. Isso resultou na escuta do ssh na porta padrão e no reconhecimento dos testes de conectividade da porta. Irritante.

A boa notícia é que eu preciso de chaves autorizadas SSH. Pelo que sei, não acho que houve uma violação bem-sucedida. Ainda estou muito preocupado com o que estou vendo em / var / log / secure:


Apr 10 06:39:27 echo sshd[22297]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:27 echo sshd[22298]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:31 echo sshd[22324]: Invalid user edu1 from 222.237.78.139
Apr 10 06:39:31 echo sshd[22324]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:31 echo sshd[22330]: input_userauth_request: invalid user edu1
Apr 10 13:39:31 echo sshd[22330]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:35 echo sshd[22336]: Invalid user test1 from 222.237.78.139
Apr 10 06:39:35 echo sshd[22336]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:35 echo sshd[22338]: input_userauth_request: invalid user test1
Apr 10 13:39:35 echo sshd[22338]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:39 echo sshd[22377]: Invalid user test from 222.237.78.139
Apr 10 06:39:39 echo sshd[22377]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:39 echo sshd[22378]: input_userauth_request: invalid user test
Apr 10 13:39:39 echo sshd[22378]: Received disconnect from 222.237.78.139: 11: Bye Bye

O que exatamente significa "POSSÍVEL QUEBRA TENTATIVA"? Que foi bem sucedido? Ou que não gostou do IP do qual o pedido estava vindo?

Respostas:


78

Infelizmente isso agora é uma ocorrência muito comum. É um ataque automatizado ao SSH que usa nomes de usuário 'comuns' para tentar invadir seu sistema. A mensagem significa exatamente o que diz, não significa que você foi hackeado, apenas que alguém tentou.


Graças à Lain. Isso me faz sentir melhor. Estou muito feliz por precisar de chaves autorizadas para ssh. =)
Mike B

28
"verificação de mapeamento reverso para getaddrinfo" é mais sobre o IP / nome do host de origem criado. O mesmo tráfego criado está tentando nomes de usuário incorretos, mas nomes de usuário incorretos não geram a mensagem "POSSÍVEL QUEBRA TENTATIVA".
poisonbit

11
@ MikeyB: Você pode querer adicionar o fail2ban ao seu sistema. Isso pode ser configurado para bloquear os endereços IP desses atacantes automaticamente.
user9517

9
Observe que 'falha no mapeamento reverso' pode simplesmente significar que o ISP do usuário não configurou o DNS reverso corretamente, o que é bastante comum. Veja a resposta de @Gaia.
Wilfred Hughes

1
Isso é impreciso, apenas significa que o DNS reverso não corresponde ao nome do host que o cliente enviou para se identificar. É provável que seja sinalizado, pois pode ter sido uma falha na tentativa de pessoas que usam .rhostsou .shostsautenticação (nunca vi isso usado). Scans acontece, mas não é isso que esta mensagem é sobre (embora qualquer conexão pode acioná-lo) (Para scans, os / as mensagens de usuários desconhecidos de autenticação falhadas são melhores para procurar)
Gert van den Berg

52

A parte "POSSÍVEL QUEBRA TENTATIVA", especificamente, está relacionada à parte "verificação reversa do mapeamento getaddrinfo com falha". Isso significa que a pessoa que estava se conectando não tinha o DNS direto e reverso configurado corretamente. Isso é bastante comum, especialmente para conexões ISP, que é de onde provavelmente veio o "ataque".

Independentemente da mensagem "POSSÍVEL QUEBRA-INTENSÃO", a pessoa está realmente tentando invadir usando nomes de usuário e senhas comuns. Não use senhas simples para SSH; de fato, a melhor ideia é desativar completamente as senhas e usar apenas chaves SSH.


1
Se for gerado por uma conexão (válida) por meio de um ISP, você poderá adicionar uma entrada ao seu arquivo / etc / hosts para se livrar desse erro de mapeamento reverso. Obviamente, você faria isso apenas se soubesse que o erro é benigno e desejasse limpar seus logs.
Artfulrobot

32

"O que exatamente" POSSÍVEL INTERVENÇÃO DE INTERRUPÇÃO "significa"?

Isso significa que o proprietário do netblock não atualizou o registro PTR para um IP estático dentro do seu intervalo e disse que o registro PTR está desatualizado, OU um ISP não configura registros reversos adequados para seus clientes IP dinâmicos. Isso é muito comum, mesmo para grandes ISPs.

Você acaba recebendo a mensagem no seu log porque alguém proveniente de um IP com registros PTR inadequados (devido a um dos motivos acima) está tentando usar nomes de usuário comuns para tentar o SSH no servidor (possivelmente ataque de força bruta ou talvez um erro honesto )

Para desativar esses alertas, você tem duas opções:

1) Se você possui um IP estático , adicione seu mapeamento reverso ao seu arquivo / etc / hosts (veja mais informações aqui ):

10.10.10.10 server.remotehost.com

2) Se você possui um IP dinâmico e realmente deseja que esses alertas sejam desativados, comente o "GSSAPIAuthentication yes" no seu arquivo / etc / ssh / sshd_config.


2
comentar GSSAPIAuthenticationnão ajuda no meu caso (
SET

UseDNS noé provavelmente o melhor cenário para se livrar dele (e de logins lentas quando o servidor tem problemas de DNS ...)
Gert van den Berg

15

Você pode facilitar a leitura e a verificação de seus logs desativando as pesquisas reversas em sshd_config (UseDNS no). Isso impedirá que o sshd registre as linhas de "ruído" que contêm "POSSÍVEL QUEBRA-INTENSÃO", deixando você se concentrar nas linhas um pouco mais interessantes que contêm "Usuário inválido do USUÁRIO do IPADDRESS".


4
Qual é a desvantagem de desativar as pesquisas inversas sshd em um servidor conectado à Internet pública? Existe alguma vantagem em deixar essa opção ativada?
Eddie

2
@ Eddie Eu não acho que as pesquisas de DNS realizadas pelo sshd tenham algum propósito útil. Há duas boas razões para desativar as pesquisas de DNS. As pesquisas de DNS podem diminuir o login se as pesquisas expirarem. E as mensagens "POSSÍVEL QUEBRA TENTAR" no log são enganosas. Tudo o que realmente significa é que o cliente configurou o DNS incorretamente.
kasperd

1
Eu discordo do @OlafM - "UseDNS no" diz ao sshd para não executar a verificação de mapeamento reverso e, portanto, não adicionará nenhuma linha que contenha "POSSIBLE BREAK-IN ATTEMPT" nos logs do sistema. Como efeito colateral, também pode acelerar as tentativas de conexão dos hosts que não possuem o DNS reverso configurado corretamente.
TimT 4/17/17

1
Sim @OlafM eu fiz, cerca de 4-5 anos atrás, no Linux. Reduziu consideravelmente meus logs e parou de logcheckme incomodar com relatórios de email inúteis.
TimT

1
O principal uso de UseDNSé para (má idéia de usar) .rhostse .shostsautenticação ( HostbasedAuthentication). (E a Fromopção de correspondência na configuração do SSHD e nas chaves autorizadas) ( HostbasedUsesNameFromPacketOnlyembora exista uma configuração separada que possa ser necessária para alternar as pesquisas inversas para autenticação baseada em hosts, é uma ideia pior do que usar a autenticação de host com base em hosts ...)
Gert van den Berg

5

Não é necessário um login bem-sucedido, mas o que diz "possível" e "tentativa".

Alguns garotos maus ou crianças pequenas de scripts estão enviando tráfego criado com um IP de origem falso.

Você pode adicionar limitações de IP de origem às suas chaves SSH e tentar algo como fail2ban.


2
Obrigado. Eu tenho o iptables configurado para permitir apenas a conectividade ssh de fontes selecionadas. Eu também tenho o fail2ban instalado e em execução.
Mike B
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.