web-dev-qa-db-fra.com

journal sshd plein de "N'a pas reçu la chaîne d'identification 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

Mon /var/log/auth.log est plein de ces messages, spammés toutes les 6 secondes. mon serveur est sur vps et l'ip semble être une ip interne. quelle pourrait être la cause de ce problème?

ssh
17
thkang

Certains mécréants (surprise!) Martèlent ssh pour essayer de trouver une combinaison nom d'utilisateur/mot de passe qui les fasse entrer dans le système. Probablement d'un réseau de zombies faisant de même pour qui sait combien d'autres victimes sans méfiance.

Installez quelque chose comme fail2ban ou DenyHosts (certains des deux devraient être disponibles pour toute distribution Linux), ou configurez votre pare-feu local pour limiter les tentatives de connexion SSH. La modification du port SSH fait échouer les tentatives de force brute stupides, mais échoue également les utilisations légitimes.

5
vonbrand

En fait, cela venait de mon fournisseur d'hébergement - ils spamment mon VPS toutes les 6 secondes, pour afficher l'état de mon serveur sur leur console Web. Mon serveur s'affiche comme actif si mon sshd y répond.

Je viens d'installer OpenVPN et d'autoriser SSH uniquement via cela - donc, selon mes fournisseurs, mon serveur dispose de 100% de temps d'arrêt.

34
thkang

Il s'agit très probablement d'un Keepalive (vérification que le serveur répond) à partir d'une communication. dispositif.

10
JTrunk

Ces messages sont lancés par SSH lorsque quelqu'un a essayé d'y accéder mais n'a pas terminé les étapes. Par exemple, si NMS vérifie si le port ssh 22 est actif ou non, il essaiera simplement de se connecter sur le port 22 et si la connexion réussit, il raccroche, dans ce cas, SSH rapporte la même chose.

C'est donc à cause d'une analyse du port SSH.

7
Suyash Jain

Essayez de changer le port ssh de 22 en un autre dans sshd_config:

Sudo nano /etc/ssh/sshd_config

Si cela n'arrête pas les messages, le problème peut également être causé par ceci: Freebpx provoque des erreurs sshd dans/var/log/fichier journal sécurisé ou voir la discussion ici "" N'a pas reçu d'identification string "dans auth.log sur les forums Ubuntu.

1
Meriadoc Brandybuck

Si vous vous demandez qui analyse le port ou essaie de s'authentifier sur votre machine, vérifiez simplement:

# whois 211.110.33.50

# KOREAN(UTF8)

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

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

etc.

0
private_nodez

Il peut également s'agir d'une tentative de réalisation d'un exploit de dépassement de tampon bien connu.

Il est documenté dans le filtre /etc/fail2ban/filter.d/sshd-ddos.conf, que vous pouvez activer pour vous protéger par ces tentatives de piratage:

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 chaîne cible pour cet exploit est (devinez quoi?) "N'a pas reçu de chaîne d'identification de ..."

Vous pouvez distinguer les connexions légitimes provenant de votre réseau de fournisseur à des fins de surveillance, par toute autre source non autorisée, simplement en vérifiant la plage réseau de l'adresse IP distante.

Il est possible d'instruire le filtre fail2ban (via la directive 'ignoreregex') afin d'ignorer la tentative légitime en conséquence.

0
Demis Palma ツ