QNAP Plusieurs tentatives de connexions anormale sur mon serveur Nas QNAP TS-264-8G

[Riad78]

Bonjour,

Je créé ce topics suite aux évènements survenus durant cette nuit.

Plusieurs tentatives de connexions sur mon serveur Nas ont échouées cette nuit et cela avec l'IP "::1" (IP local pour l'IPv6, la même que celle utilisé par le support QNAP j'y reviens un peu plus tard..).

Il faut également savoir que j'ai eu une mésentente avec le support Qnap, (lors d'un case "voir ce sujet") sur le fait que lorsqu'il se sont connecté à mon Nas avec le "Centre d'Assistance à Distance" ils :

• ne m'ont pas prévenu de leur connexion le jour J.
• ont activé le compte admin et sont repartis en le laissant activé. (je l'ai redésactivé juste après qu'ils aient fini leurs opérations.)
• Un dernier point mais qui ne vient pas du technicien mais plutôt du fonctionnement de l'application "Centre d'assistance à Distance".
  • L'application parvient parfaitement à créer l'utilisateur "_qnap_support", pourquoi ne le supprime t-il pas à la fin de la session ?

Je ne sais pas si c'est due à ce qu'ils ont fait mais en tous cas je me souviens ne pas avoir apprécié ce manque de communication lors de leurs opérations.

Actuellement, mon Nas n'est plus connecté au réseau.

J'ai mis en pièces jointes, une archive .zip qui contient :

• Le journal d'accès à mon Nas (fichier : AccessLog_20241214_16_40_08.xlsx)
• Les blocages d'IP effectué par QuFirewall "IP local ::1 ..." (fichier : IP Banned by QuFirewall.xlsx)

J'ai plusieurs interrogations qui reste en suspens.. :

• La principal question : par où et/ou quoi l'attaquant à pu se connecter au NAS ? (Sur Qvpn, Wireguard est activé pour mon téléphone. Suite à cela, je l'ai désactivé et restera désactivé jusqu'à ce je comprenne ce qui à bien pu se passer. Malheureusement, je ne sais pas du tout comment fonctionne les logs sur Qvpn car pour Wireguard, je n'ai aucun logs d'évènements dessus.. )
• Est-ce que l'attaquant a finalement réussi à se connecter malgré toutes ces connexions infructueuse ? (Je pense que non d'après mes notifications de connexions mais je ne suis plus vraiment sur de rien..)
• Si oui, qu'a t-il fait ?
• Vous verrez dans le fichier "AccessLog_20241214_16_40_08.xlsx" qu'il y'a des tentatives venant de l'IP "::1" Est-ce un service qui utilise l'IPv6 qui permet de faire liaison VPN avec l'extérieur qui à ouvert l'accès à mon attaquant ? (d'ailleurs l'IPv6 est désactivé sur mon nas, m'enfin...)
• Puis-je désactiver le fonctionnement du HTTP ou alors forcer la redirection vers le HTTPS sans endommagé les services qui pourrait potentiellement fonctionner sur ce port (même si j'ai un doute qu'il y'ait des un/des services qu'ils utilisent...)

Je ne sais pas vraiment où chercher. A vrai dire, je suis un peu perdu. Je pensai avoir un minimum sécurisé mon Nas, mais visiblement non.

En temps normal, je me serai rapproché du support QNAP mais depuis leur manque de communications de la dernière fois et ce qui se passe aujourd'hui (moins d'une semaine après avoir fait appel à leur aide..), j'ai bien peur de ne plus vraiment leurs faire confiance. (Je dis le support QNAP, mais j'en veux plus particulièrement au technicien qui à travaillé sur mon case. Je suis sûr qu'il y'a pleins de technicien chez eux qui ne manque pas de communication, surtout lorsqu'il s'agit de rentrer dans le Nas des gens..)
Le support QNAP se connecte surement en VPN à via l'application (Centre d'Assistance à Distance). Pourtant la session n'est plus activé depuis la fermeture de mon ticket...

Je ne sais même pas par où l'attaquant est passé pour avoir effectué toutes ces tentatives de connexions échouées.. "::1"

Je ne sais pas quel autre information je pourrai vous fournir pour avancer dans mon problème (et c'est sur qu'il y'en as ... ). N'hésitez pas à revenir vers moi et je vous transmettrai les informations qui pourrait vous aider.

Merci encore pour votre aide !

Cordialement,
Riad

 

[Riad78]

Je pense que le problème vient de l'application "Security Center". En effet, j'ai une tache de planification qui s'exécute tous les jours à 05h30 et je ne sais pas pour quel raison, cette tâche n'a pas pu s'exécuter avec le compte créé à cet effet. Alors la tâche à décidé de s'exécuter avec le compte "admin" alors que celui-ci est désactivé.

Je ne sais pas pourquoi le compte créé pour cette tâche n'a pas fonctionné. Lorsque j'ai voulu la re configurer, j'ai observé cette erreur "Session expirée". J'ai re cliquer sur appliquer et la session était de nouveau fonctionnelle.

Est ce que cela vous est déjà arrivé ?

Riad

 

[EVO]

Salut,
Si tu as eu "Guillaume" au support, alors c'est moi. Et c'est surement le cas, car j'ai géré la majorité des tickets HDP FR suite a la maj 2.2.

ne m'ont pas prévenu de leur connexion le jour J.

ll est vrai que je n'ai pas pour habitude de re-envoyer un message a la connexion, le status sur l'assistance a distance passe de "En attente" à "En cours" quand on prend la main. Concernant le R&D , il n'a pas d’accès direct au ticket, et il y a le décalage horaire qui rend la communication " en live " plus compliqué.

ont activé le compte admin et sont repartis en le laissant activé. (je l'ai redésactivé juste après qu'ils aient fini leurs opérations.)

Cela me surprend, nous n'avons théoriquement pas besoin du compte admin actif. je vais vérifier sur un de mes NAS si l’activation du support re-active admin. Peut être un bug de la dernière version de l'assistance a distance.

L'application parvient parfaitement à créer l'utilisateur "_qnap_support", pourquoi ne le supprime t-il pas à la fin de la session ?

Cela par contre c'est un bug, l'application doit supprimé ce compte quand la session d'assitance a distance expire/est clôturée.
Elle doit également désactiver le SSH s'il n'était pas actif au moment de l'activation de la prise, car l'activation de la prise en main active le SSH ( s'il n'est pas déja actif bien sur ).

par où et/ou quoi l'attaquant à pu se connecter au NAS ?

Ici c'est une connexion purement local, cela viens plutot d'une application.

• Est-ce que l'attaquant a finalement réussi à se connecter malgré toutes ces connexions infructueuse ? (Je pense que non d'après mes notifications de connexions mais je ne suis plus vraiment sur de rien..)
• Si oui, qu'a t-il fait ?

Comme dit, pour moi l'origine est une appli sur le NAS.

(d'ailleurs l'IPv6 est désactivé sur mon nas, m'enfin...)

C'est d'ailleurs le comportement par défaut maintenant lors d'une nouvelle configuration de QTS.

uis-je désactiver le fonctionnement du HTTP ou alors forcer la redirection vers le HTTPS sans endommagé les services qui pourrait potentiellement fonctionner sur ce port (même si j'ai un doute qu'il y'ait des un/des services qu'ils utilisent...)

Tu peux activer la redirection HTTP vers HTTPS oui, mais je ne comprend pas l’intérêt de la chose ?
A partir du moment ou tu te connecte depuis l'extérieur, il faut utiliser le HTTPS. En local c'est moins important pour notre usage.

En temps normal, je me serai rapproché du support QNAP mais depuis leur manque de communications de la dernière fois et ce qui se passe aujourd'hui (moins d'une semaine après avoir fait appel à leur aide..), j'ai bien peur de ne plus vraiment leurs faire confiance. (Je dis le support QNAP, mais j'en veux plus particulièrement au technicien qui à travaillé sur mon case. Je suis sûr qu'il y'a pleins de technicien chez eux qui ne manque pas de communication, surtout lorsqu'il s'agit de rentrer dans le Nas des gens..)

Navré pour cette mauvaise expérience

Le support QNAP se connecte surement en VPN à via l'application (Centre d'Assistance à Distance). Pourtant la session n'est plus activé depuis la fermeture de mon ticket...

La connexion ce fait via une connexion chiffrée assimilable à un VPN oui. C'est un tunnel qui est créé entre une machine virtuelle chez QNAP et ton NAS. A partir du moment ou la session a distance a expirée/est cloturée .. la clé de chiffrement ( visible dans le centre d'assistance ) est détruite. Plus aucune connexion ne peut etre établie.

Je pense que le problème vient de l'application "Security Center". En effet, j'ai une tache de planification qui s'exécute tous les jours à 05h30 et je ne sais pas pour quel raison, cette tâche n'a pas pu s'exécuter avec le compte créé à cet effet. Alors la tâche à décidé de s'exécuter avec le compte "admin" alors que celui-ci est désactivé.

Cela me rappelle un bug que j'ai déjà vu ... ton firmware et les applications sont bien à jour ?

What should I do if receiving the warning message

Applicable Products Security Counselor Symptom Cause The warnings are generated since Security Counselor app token was expired ...

www.qnap.com

 

[Riad78]

Salut,
Si tu as eu "Guillaume" au support, alors c'est moi. Et c'est surement le cas, car j'ai géré la majorité des tickets HDP FR suite a la maj 2.2.

IN-CRO-YABLE !
Je t'en ai voulu fort de fou ! j'en ai même regretté d'avoir créé le ticket !
EVO = Guillaume de QNAP !
Tu peux pas savoir à quel point ça me rassure que tu me dise ça même si la situation et quelque peu gênante ! J'avais zéro confiance à Guillaume par contre, et depuis peu que je connais ce forum, j'ai une confiance absolu envers Evo !

ll est vrai que je n'ai pas pour habitude de re-envoyer un message a la connexion, le status sur l'assistance a distance passe de "En attente" à "En cours" quand on prend la main.

En faite, c'est en me connectant sur le NAS que je me suis aperçu que le "En attente" était passé à "En cours" mais je m'attendais à une notif dans le ticket ou bien dans le NAS.

Cela me surprend, nous n'avons théoriquement pas besoin du compte admin actif. je vais vérifier sur un de mes NAS si l’activation du support re-active admin. Peut être un bug de la dernière version de l'assistance a distance.

Le compte "admin" a été activé quelques minutes après l'activation de l'Assistance à Distance. (par contre, cette action me paraît plutôt normal, d'autant plus que le compte "_qnap_support" n'existait pas encore)

Cela par contre c'est un bug, l'application doit supprimé ce compte quand la session d'assitance a distance expire/est clôturée.
Elle doit également désactiver le SSH s'il n'était pas actif au moment de l'activation de la prise, car l'activation de la prise en main active le SSH ( s'il n'est pas déja actif bien sur ).

J'ai supprimé le compte "_qnap_support" et désactiver le SSH après la fermeture du ticket. (Je préfère laisser le SSH désactivé et l'activer que quand j'en ai besoin..).

Tu peux activer la redirection HTTP vers HTTPS oui, mais je ne comprend pas l’intérêt de la chose ?
A partir du moment ou tu te connecte depuis l'extérieur, il faut utiliser le HTTPS. En local c'est moins important pour notre usage.

Je crois que j'ai d'autres services en plus de "Security Center" qui se connecte au NAS en HTTP. Peut-être parce que je l'ai configuré (planification de tâche, choix du niveau de sécurité, etc..) avant d'avoir activé le HTTPS sur mon NAS, je ne sais pas...

Navré pour cette mauvaise expérience

C'est moi ! Je suis désolé de t'avoir accusé à tord. Je pensais vraiment que le technicien avec qui j'avais travailler sur QNAP tenté de se connecter sur mon NAS. Alors quand je me suis un peu calmé et que j'ai vu que les tentatives de connexions corrélaient avec ma tâche de planification de "Security Center", je me suis sentis très petit !! J'ai finalement compris que c'était mon NAS qui tenté des choses qui n'avait d'ailleurs jamais tenté..
Encore une fois, je suis tellement rassuré que ce sois toi et désolé de t'avoir accusé à tord...

La connexion ce fait via une connexion chiffrée assimilable à un VPN oui. C'est un tunnel qui est créé entre une machine virtuelle chez QNAP et ton NAS. A partir du moment ou la session a distance a expirée/est cloturée .. la clé de chiffrement ( visible dans le centre d'assistance ) est détruite. Plus aucune connexion ne peut etre établie.

Ça me rassure !

Cela me rappelle un bug que j'ai déjà vu ... ton firmware et les applications sont bien à jour ?

Le firmware de mon QTS est en 5.2.1.2930. Ce topics m'a fait un peu peur. Je pense que je ferai la MaJ demain.

What should I do if receiving the warning message

Applicable Products Security Counselor Symptom Cause The warnings are generated since Security Counselor app token was expired ...

www.qnap.com

Pour le coup, c'est exactement ce que j'ai fais. Je me suis connecté avec mon compte qui à des droits d'administrateur, j'ai ouvert l'application "Centre de Sécurité" puis "Contrôle de sécurité" et je suis partis dans la planification de tache. Ensuite, j'ai eu cette fenêtre (voir pièce jointe) et j'ai cliquer sur "Appliquer". Le message "Session expiré" à ensuite disparu.

Encore désolé de t'avoir accusé à tord, j'espère que tu ne l'a pas mal pris.
Je t'avoue que la situation est aussi gênante que rassurante !
Je suis finalement bien content que ce soit toi, Guillaume qui ce soit occupé de mon ticket !

Riad

 

[EVO]

même si la situation et quelque peu gênante !

Il n'y a pas de soucis. C'est toujours bon d'avoir des retours

Je me dit que je devrait changer ma réponse a un ticket clôturé afin d'encourager le client a vérifier apres la cloture de la sessiion que le compte admin est désactivé ainsi que SSH s'il n'en a pas besoin.

En faite, c'est en me connectant sur le NAS que je me suis aperçu que le "En attente" était passé à "En cours" mais je m'attendais à une notif dans le ticket ou bien dans le NAS.

Effectivement, il n'y a pas de notif. Il faut dire aussi que le R&D ce connecte souvent de nuit et de plus, on attend pas d'action du client pendant cette prise en main, j'ai peur qu'une notification fasse penser au client qu'on attend de lui qu'il soit présent devant le NAS, ce qui n'est pas le cas.

Pour la petite anecdote, j'ai eu quelques clients qui ont attend d'avoir une après-midi de dispo chez eux pour activer la prise en main a distance pensant que leur présence était nécessaire. Voir qui m'envoie juste après l'activation un message m'indiquant qu'ils ont activé la prise en main et garde leur PC allumé pour la prise en main

Le compte "admin" a été activé quelques minutes après l'activation de l'Assistance à Distance. (par contre, cette action me paraît plutôt normal, d'autant plus que le compte "_qnap_support" n'existait pas encore)

C'est un point que je vais étudier. Dans tout cas les cas, si le compte admin était inactif à la base la clôture de la prise en main devrait re-désactiver le compte. ( comme il doit le faire pour le SSH ).

J'ai supprimé le compte "_qnap_support" et désactiver le SSH après la fermeture du ticket. (Je préfère laisser le SSH désactivé et l'activer que quand j'en ai besoin..).

Si tu n'a pas besoin du SSH il est effectivement préférable de le désactiver. Choix moi il est toujours actif ( sur un port autre que 22 ) , mais je l'utilise "presque" tous les jours.

Je crois que j'ai d'autres services en plus de "Security Center" qui se connecte au NAS en HTTP. Peut-être parce que je l'ai configuré (planification de tâche, choix du niveau de sécurité, etc..) avant d'avoir activé le HTTPS sur mon NAS, je ne sais pas...

Ha oui, d'accord je pense comprendre. En tout cas, sache que ce forcage de redirection HTTP vers HTTPS n'est pas obligatoire du tout. C'est même contraignant en local je trouve.

Encore une fois, je suis tellement rassuré que ce sois toi et désolé de t'avoir accusé à tord...

Pas de probleme comme dit, je suis content d'avoir des retours d'expérience, et cela me permet de voir les choses d'un autre point de vue. Je n'ai pas la main sur l'ensemble de la procédure de prise en main, ... mais si je peux améliorer/suggérer des améliorations au R&D, je le fait

Le firmware de mon QTS est en 5.2.1.2930. Ce topics m'a fait un peu peur. Je pense que je ferai la MaJ demain.

Oui, tu peu maintenant, ce probleme est résolu.

Encore désolé de t'avoir accusé à tord, j'espère que tu ne l'a pas mal pris.
Je t'avoue que la situation est aussi gênante que rassurante !
Je suis finalement bien content que ce soit toi, Guillaume qui ce soit occupé de mon ticket !

 

[Riad78]

Je me dit que je devrait changer ma réponse a un ticket clôturé afin d'encourager le client a vérifier après la clôture de la session que le compte admin est désactivé ainsi que SSH s'il n'en a pas besoin.

Oui, ce serait intéressant de voir si mon cas est isolé ou à l'inverse si il manque quelques codes à modifiés dans les dernières versions de QTS et/ou "Centre d'Assistance à Distance".

Effectivement, il n'y a pas de notif. Il faut dire aussi que le R&D se connecte souvent de nuit et de plus, on attend pas d'action du client pendant cette prise en main, j'ai peur qu'une notification fasse penser au client qu'on attend de lui qu'il soit présent devant le NAS, ce qui n'est pas le cas.

En faite, je m'attendais à une notif dans le "QuLog Center" du style

"$QNAP-Case-Number" : Le support QNAP est actuellement connecté à votre appareil "$QNAP-name".
Pour assurer la résolution de votre demande, merci de ne pas modifier la configuration de votre QNAP "$QNAP-Name" pendant cette session.
Notre équipe technique vous informera dès que l'intervention sera terminée.
Le Support QNAP

puis

"$QNAP-Case-Number : L'intervention de notre support QNAP sur votre appareil "$QNAP-name" est temporairement terminée.
Il est possible que nos équipes techniques se reconnectent prochainement avec des informations complémentaires pour résoudre votre demande.
Pour faciliter cette intervention, merci de maintenir le "Centre d'Assistance à Distance" actif jusqu'à la résolution complète de votre ticket.
Le Support QNAP

Avec peut-être un peu moins de blabla dans la colonne "Contenu" du logs

Pour la petite anecdote, j'ai eu quelques clients qui ont attendu d'avoir une après-midi de dispo chez eux pour activer la prise en main a distance pensant que leur présence était nécessaire. Voir qui m'envoie juste après l'activation un message m'indiquant qu'ils ont activé la prise en main et garde leur PC allumé pour la prise en main

Aïe , il le s'auront pour les prochaines fois ! Je l'espère pour eux

Pas de probleme comme dit, je suis content d'avoir des retours d'expérience, et cela me permet de voir les choses d'un autre point de vue. Je n'ai pas la main sur l'ensemble de la procédure de prise en main, ... mais si je peux améliorer/suggérer des améliorations au R&D, je le fait

Encore merci à toi !

Oui, tu peu maintenant, ce problème est résolu.

MàJ réalisée avec succès
Pour l'instant pas de problème

Riad