Aller au contenu

Ssh Spam Depuis Mise


Messages recommandés

Bonjour,

Depuis la mise a jour de DSM en update 3, j'ai du spam SSH bloqué par le programme de blocage auto du NAS (DS214).

Avant cette mise à jour, je désactivé SSH via : Panneau de Configuration > Terminal > Activé SSH "décoché"

Maintenant, même si le SSH est désactivé, il est possible de tenter une authentification même si elle n'aboutie pas quand j'utilise mon compte. (Quand j'active SSH, ça fonctionne évidement)

Avez-vous le même problème ???

Morgan

Lien vers le commentaire
Partager sur d’autres sites

Depuis la mise a jour de DSM en update 3, j'ai du spam SSH bloqué par le programme de blocage auto du NAS (DS214).

"Spam" n'est pas le mot que j'emploierai mais c'est pas important

Avant cette mise à jour, je désactivé SSH via : Panneau de Configuration > Terminal > Activé SSH "décoché"

Maintenant, même si le SSH est désactivé, il est possible de tenter une authentification même si elle n'aboutie pas quand j'utilise mon compte. (Quand j'active SSH, ça fonctionne évidement)

N'aurais-tu pas tout simplement le serveur sftp actif?

XoTpBsP.png

Lien vers le commentaire
Partager sur d’autres sites

Autre chose: si tu as des alertes de tentatives de connexions ssh sur ton NAS c'est que tu fait une redirection du port 22 en entrée de ta box/routeur vers le NAS.

Pourquoi avoir fait cela puisque tu nous dit ne pas vouloir faire de SSH ("désactivé SSH via : Panneau de Configuration > Terminal > Activé SSH "décoché")?

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Merci pour les réponses.

J'ai fais une redirection du port 22 car je souhaite accéder en SSH ponctuellement. J'avais également activé le SFTP.

J'ai désactivé le SFTP, mais la demande d'authentification s'effectue toujours. Je suis certain qu'avant ce n'était pas le cas.

Néanmoins, j'ai fermer le port 22 sur ma box pour ne plus être dérangé.

Une nouvelle fois, merci à toi (vous) :)

++

Lien vers le commentaire
Partager sur d’autres sites

J'ai fais une redirection du port 22 car je souhaite accéder en SSH ponctuellement. J'avais également activé le SFTP.

J'ai désactivé le SFTP, mais la demande d'authentification s'effectue toujours. Je suis certain qu'avant ce n'était pas le cas.

Pas seulement avant, j'ai la dernière version de DSM et quand ssh et sftp sont arrété je n'ai plus de demande d'authentification.

J'ai simplement "connexion refusée".

Il y un lézard dans ton NAS .

Néanmoins, j'ai fermer le port 22 sur ma box pour ne plus être dérangé.

Si SSH et SFTP sont désactivés plus aucun process n'écoute sur le port 22.

Pour vérifier, je me suis connecté en telnet, et voici ce que çà donne (ssh activé):

fserv> netstat -tpln | grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6222/sshd
tcp 0 0 ::%20:22 :::* LISTEN 6222/sshd

En suite, une fois ssh désactivé, la commande ci dessus ne liste plus rien.

Si chez toi il y a quelque chose c'est soit que as oublié certaines information (un sshd de chez optware à la place de celui de syno par exemple) soit que le démon ssh DSM ne s’arrête pas (et ce n'est pas normal)

Serait intéressant de voir ce que donne chez toi:

$ /bin/ps -w | grep NNNN

En substituant à "NNNN" le numéro pid donné par netstat (avant le "/sshd")

Sinon, pour ne plus (ou moins en tout cas) être dérangé je te conseille de faire la redirection ssh sur la box avec un port plus exotique que le 22 qui doit être l'un des plus attaqués après le 80.

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

J'ai exactement le même problème. Depuis la mise à jour je suis attaqué continuellement via SSH même si les services SSH et SFTP sont décochés. .
J'ai toutefois activé le blocage auto au bout de 5 tentatives pour ne pas me faire bruteforcer mais je reçois quand même des mails..
Quand je regarde les logs de connexion, c'est la qu'on voit bien l'importance de bien desactiver le compte admin de base du syno et de mettre un mot de passe et un nom de connexion exotique (pele mele j'ai eu le droit à du root,admin,administrator et même redtube :D )
Bref, je penche aussi plus pour un probléme lié au DSM (j'ai un DS213J) carc'est trés clairement l'update qui à déclenché tout ça puisque je n'ai pas touché à la conf'.
Je m'en vais de ce pas appliquer les conseils de CoolRaoul en shuitant directement le port 22 depuis mon routeur, ce qui devrait régler directement le problème.
N'empeche que le DSM est buggué. J'imagine qu'un update réglera le pbm...

Lien vers le commentaire
Partager sur d’autres sites

N'empeche que le DSM est buggué. J'imagine qu'un update réglera le pbm...

Pas convaincu: si l'un d'entre vous voulait bien répondre a ma demande de passer la commande netstat permettant de vérifier quel est le process à l'écoute sur le port 22 on pourrait peut être faire avancer le dossier -_-

Sur mon NAS (dernière version aussi), avec les deux services (ssh et sftp) arrétés le port 22 est fermé sur le NAS car *aucun* process n'est à l'écoute. Donc aucune attaque est possible en SSH.

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Bon alors reprenons:

En telnet, SSH et SFTP activé:

Odin> netstat -tpln | grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6171/sshd
tcp 0 0 ::%14:22 :::* LISTEN 6171/sshd

En telnet SSH et SFTP désactivé:

Odin> netstat -tpln | grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6171/sshd
tcp 0 0 ::%14:22 :::* LISTEN 6171/sshd

La même chose donc que quand le SSH est activé.
Donc même si le SSH et le SFTP désactivé on à quelque chose qui écoute sur ce port si je comprends bien?

Et quand je lance cette commande:
/bin/ps -w | grep 6171
6171 root 12800 S /usr/syno/sbin/sshd
18438 root 4052 S grep 6171

Bon c'est plus ou moins du chinois pour moi :huh:

EDIT: J'ai été voir dans le moniteur de ressource et j'ai le process ssh et sshd en veille.
Logiquement, il devrait pas y figuré du tout ?

Modifié par bobiwan
Lien vers le commentaire
Partager sur d’autres sites

Donc même si le SSH et le SFTP désactivé on à quelque chose qui écoute sur ce port si je comprends bien?

Ca ne devrait pas être le cas normalement.

6171 root 12800 S /usr/syno/sbin/sshd

Ceci montre que le démon SSH de DSM n'est pas réellement arrêté.

Peut-être qu'une session est resté activée et qu'il attend que tout soit terminé pour terminer le process.

Ou bien que le script d'arret de ssh à échoué à tuer le process pour une raison restant à élucider.

Un reboot réglera le problème dans tout les cas.

Lien vers le commentaire
Partager sur d’autres sites

Un reboot réglera le problème dans tout les cas.

C'est la premiere chose que j'ai fait, aprés avoir réactivé/désactivé le SSH une fois le problème constaté.

Je vais le redémarrer en direct live avec juste telnet d'activé et SSH SFTP désactivé et j'éditerai le message pour essayer d'élucider ce mystére.

EDIT: Bon ben même aprés un reboot, service ssh/ sftp décoché on à quand même le process en écoute :wacko: :

Odin> netstat -tpln | grep :22

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6169/sshd

tcp 0 0 ::%13:22 :::* LISTEN 6169/sshd

Odin> /bin/ps -w | grep 6169

6169 root 12800 S /usr/syno/sbin/sshd

9674 root 4048 S grep 6169

Modifié par bobiwan
Lien vers le commentaire
Partager sur d’autres sites

Bigre!

A distance ça va pas être facile à diagnostiquer ce bidule...

Par curiosité, est ce qu'apres avoir executé la commande "/usr/syno/etc/rc.d/S95sshd.sh stop" le service est inactif?

**EDIT**

Serait aussi intéressant de connaitre le résultat de :

egrep "run(ssh|sftp)"  /etc/synoinfo.conf
Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Aprés avoir lancé la commande "/usr/syno/etc/rc.d/S95sshd.sh stop" plus aucune trace du processus "SSH" dans le moniteur de ressource même en veille. Juste SSHD qui est présent avec un statut "en veille".

Par contre si je lance la commande netstat, j'ai quand même du monde à la porte...

"Odin> /usr/syno/etc/rc.d/S95sshd.sh stop
Stop SSH...

Odin> netstat -tpln | grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6170/sshd
tcp 0 0 ::%14:22 :::* LISTEN 6170/sshd"

Et j'ai toujours accés à l'authentification SSH (j'ai même un beau message d'erreur "Access Denied" quand je mets des idenfiants erronés, par contre si je rentre un root avec le mdp correct putty se ferme automatiquement).

Il s'accroche ce bougre de service.

Et j'ai bien lancé la commande "egrep "run(ssh|sftp)" /etc/synoinfo.conf" juste aprés et j'ai ceci:
runssh="no"
runsftp="no"
Mais ca change rien, toujours possibilité de s'identifier en SSH.

Bref, à part un défaut de l'OS, je vois pas. Mais le fait de ne pas rediriger le port 22 est radical. Et si j'en ai besoin je peux toujours modifier la conf' directement depuis mon DSM ;-)

Modifié par bobiwan
Lien vers le commentaire
Partager sur d’autres sites

Bon, ça me désole de devoir en rester la mais faudrait accéder au NAS en ligne pour comprendre ce qui peut se passer sur celui-ci.

Faudra donc faire avec le workaround mais ça m'intrique au plus haut point.

Reste juste à espérer que ce ne soit pas le signe d'un truc plus chelou (de type rootkit)

Lien vers le commentaire
Partager sur d’autres sites

J'ai lancé les commandes comme demandé, mais j'ai obtenu les mêmes résultats que bobiwan

J'avoue ne pas comprendre: on a tous la même version de DSM, aucune raison qu'avec ssh et sftp désactivé le NAS lance quand même le démon sshd pour certains et pas pour d'autres.

Si l'un de vous avait du temps a perdre le l'encouragerai bien à contacter le support

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.