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

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

— thkang
source

Avez-vous des tâches cron exécutées sous root ?

— Shimon Rachlenko

4

Un mécréant (surprise!) Martèle ssh pour essayer de trouver une combinaison nom d'utilisateur / mot de passe qui les fasse entrer dans le système. Probablement d'un botnet 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.

— vonbrand
source

N'oubliez pas: sshguard

— 0xC0000022L

3

Ils n'essaient pas les mots de passe s'ils ne sont pas allés assez loin pour négocier l'ensemble de cryptage.

— Jo Rhett

15

Cette réponse est complètement fausse et un peu trompeuse. Comme mentionné ci-dessous, si vous obtenez ce message, la connexion n'a pas atteint le stade de l'attribution d'un nom d'utilisateur et ne peut donc pas essayer d'en deviner un. Cela peut être a) vérifier légitimement que votre machine est vivante - ce qui est bien ou b) rechercher les ports ssh qu'elle attaquerait. Cependant, dans le cas b), vous ne verriez normalement qu'un seul message provenant d'une autre adresse donnée. Vous pourriez vous retrouver avec votre ordinateur redémarré par une personne ou un système essayant de réparer les choses si le Keepalive est fait pour la surveillance.

— Michael

33

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 est affiché 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 bénéficie d'un temps d'arrêt de 100%.

— thkang
source

9

Les contrôleurs de rythme cardiaque insensibles au protocole sont ennuyeux.

— Falcon Momot

Oui - par exemple, si votre serveur sshd s'exécute sur une instance AWS EC2 et que vous l'avez configuré derrière un Elastic Load Balancer avec un contrôle d'intégrité sur le port SSH, vous verrez ce message dans les journaux à chaque exécution du contrôle d'intégrité .

— Hugh W

10

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

— JTrunk
source

Pouvez-vous expliquer quels types de périphériques de communication pourraient faire cela et pourquoi?

— Elliott B

7

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.

— Suyash Jain
source

1

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

sudo nano /etc/ssh/sshd_config

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

— Meriadoc Brandybuck
source

1

merci, les messages spammés ont disparu (du moins pour l'instant) et je n'ai pas installé freepbx.

— thkang

0

Si jamais vous vous demandez qui scanne 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.

— private_nodez
source

0

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.

— Demis Palma ツ
source