Aller au contenu
Site Communauté

Nombreuses tentatives d'accès rejetées par le pare-feu de mon NAS

Mathieu Réau

Par Mathieu Réau
dans Internet et réseaux

Messages recommandés

Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
Posté(e)

Bonjour à tous, chers amis,

L'informatique, et Internet en particulier, semblent ne pas être le long fleuve tranquille dont je rêve pourtant toutes les nuits... Me voici de nouveau devant une grande source d'inquiétude et d'embarras.

Depuis hier soir, à la suite de la mise à jour vers la version 4.5.3.1697 du système d'exploitation de mon NAS TS231P de la marque Qnap, ayant également entraîné la mise à jour de plusieurs des logiciels installés dessus, dont le pare-feu, je me retrouve comme cela m'était arrivé il y a quelques mois, bombardé de notifications m'indiquant que ledit pare-feu repousse un nombre de tentatives de connexion à mon matériel excédant son seuil de sécurité.

J'ignore si les deux évènements sont liés d'une quelconque manière, mais il m'a semble pertinent de le relever.

Une rapide recherche sur Internet ne m'a pas permis d'être informé d'une attaque de grande envergure comme ce fut le cas la dernière fois...

Afin de mieux comprendre, peut-être, de quoi il retourne, j'ai procédé à un enregistrement des paquets interceptés par le pare-feu. Mais je suis bien en peine de comprendre le rapport produit. L'un d'entre vous saurait-il le décrypter et déterminer, notamment, la provenance géographique de ces tentatives d'accès rejetées ? Cela me serait vraiment d'une grande aide et je vous en remercie sincèrement d'avance.

QuFirewall_Basic protection_20210627.pcap

Lien vers le commentaire
Toto61 Major

Toto61

Posté(e)
Posté(e) (modifié)

Salut,

Si je ne dit pas de bêtises, ton NAS est en 192.168.1.2. Or, la majeur partie des tentatives d'accès vers cette IP se fait via le protocole UDP 6881, habituellement utilisé par BitTorrent. Les sources sont variés (Chine, Australie, Russie, Corée...). Donc je commencerai par désactiver le serveur Torrent hébergé sur ton NAS, ou, à défaut, fermer le port UDP 6881 depuis ta box.

image.png.1220d9c8cc74a10fd09ac8f4c489790f.png

Modifié par Toto61
Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e)

Bon, l'extinction de mon logiciel de Torrent n'a rien donné. Mais à la réflexion, je me suis rendu compte que c'est normal, puisque ce dernier fonctionne sur un autre ordinateur et ne fait que stocker ses données sur le NAS... Les protocoles de transit doivent donc être tout autres. Suis-je bête... :c_coldsweat:

Je n'ai donc pas de logiciel de torrent actif sur mon NAS. Hier, après la survenue du problème, j'avais essayé de désactiver les deux applications que j'utilise pour synchroniser certains dossiers de mon appareil à des services d'hébergement en ligne, tels Google Drive et Dropbox, sans résultat.

Depuis la dernière attaque, je n'ai également rétabli aucun des services permettant normalement l'accès à distance à mon NAS, tels le service FTP ou DDNS...

Je ne vois donc rien sur mon appareil qui puisse communiquer via ce port jusqu'à des adresses situées hors de mon réseau local... On dirait bien quelque chose cloche.

Si je ferme le port 6881 de la box, cependant, est-ce que cela ne risque pas d'interférer avec le fonctionnement de mon client de torrent dont je parlais plus haut ?

Lien vers le commentaire
Toto61 Major

Toto61

Posté(e)
Posté(e)

Si tu arrêtes le serveur BitTorrent, tu n'enrayes pas les tentatives d'attaques. Mais si l'UPNP de ta box était activé, cela devrait permettre de fermer en même temps les ports utilisés. Si ce n'est pas le cas, c'est qu'une règle sur ta box doit explicitement rediriger vers l'IP de ton NAS : à fermer pour rejeter les tentatives de connexions.

  • Plusser (+1) 1
Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e)
il y a 33 minutes, Toto61 a dit :

Si ce n'est pas le cas, c'est qu'une règle sur ta box doit explicitement rediriger vers l'IP de ton NAS : à fermer pour rejeter les tentatives de connexions.

En effet, je trouve deux règles sur ma Livebox redirigeant le trafic sur le port 6881 directement vers mon NAS via les protocoles UDP et TCP !

J'ai retrouvé une capture d'écran que j'avais faite lors de la dernière attaque, et ces deux règles n'existaient alors pas. C'est dommage que la date de leur création ne soit pas indiquée, mais il est bien possible que cela se soit produit lors de la mise à jour du NAS l'autre jour...

D'après le libellé, l'application associée à ce trafic est un client libtorrent à la version 0.16.17. Après quelques recherches, cela me permet de désigner, je pense, le coupable : mon NAS dispose effectivement d'une application permettant le téléchargement en p2p via libtorrent !

Deux remarques m'interrogent, cependant :

  • je m'en sers très rarement et aucun torrent n'est actif depuis un moment avec cette application
  • la version de libtorrent indiquée dans le tableau de la Livebox n'a rien à voir avec la version 1.2.11 que l'appli sur mon NAS dit utiliser

L'application de téléchargement en question fait justement partie de celles que j'ai dû mettre à jour après avoir mis à jour le système d'exploitation du NAS. Il s'est peut-être passé un truc de ce côté-là qui aurait, je sais pas, laissé ouverts des ports de l'ancienne version... Je dis n'importe quoi, mais je ne peux m'empêcher de penser que la concomitance entre la mise à jour et cette avalanche de connexion n'est pas anodine.

J'ai flanqué à la poubelle les deux règles de redirection sur la table UPnP de la Livebox... Ça devrait régler le souci ! Je devrais rapidement m'en rendre compte.

Encore une fois merci pour ton aide, @Toto61 !

Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e)

Désactiver l'application dont je parlais semble empêcher la réapparition des règles que j'ai supprimées...

Sauf que les tentatives d'accès interceptées par mon pare-feu ne s'arrêtent pas, elles !

Alors je suis en train de faire un nouvel enregistrement des paquets interceptés, pour voir d'où ça vient...

Lien vers le commentaire
Toto61 Major

Toto61

Posté(e)
Posté(e)

La capture que tu as envoyé contient 219 trames de plus (pour un peu plus de 27H d'enregistrement), sans trace d'accès vers l'IP de ton NAS (ou de ton réseau) depuis la dernière capture.

Elle comporte essentiellement des requêtes de découvertes SSDP (découverte réseau, en provenance d'une adresse Multicast, non routable), et de quelques requêtes DHCP (en provenance d'un Samsung (adresse MAC : cc:21:19:73:cf:c3).

Rien d'alarmant dans cette capture.

Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e) (modifié)

Aucune trace d'accès vers mon NAS ? Mais il s'agit pourtant d'une capture provenant du pare-feu de mon NAS ! Il ne doit pas pouvoir s'amuser à bloquer des connexions qui ne lui sont pas destinées, si ? 

Je continue également de recevoir des alertes du pare-feu qui bloque entre trois cents et quatre cents paquets entrants par heure alors que son seuil d'alerte est fixé à cent cinquante.

Et comment se fait-il que tu aies pu lire vingt-sept heures d'enregistrement alors que je n'ai fait qu'une capture de trente minutes, exactement comme la précédente ? C'est fourni avec un historique ?

Ça me rassure que tu n'y trouves rien d'alarmant, mais je ne comprends vraiment pas ce qu'il se passe ni si je peux y faire quelque chose. :c_embarrassed:

Modifié par Mathieu Réau
Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e)

Bizarre, je n'ai pas été notifié par mail de ta réponse...

Je me demande quand même ce qui met autant mon pare-feu en alerte si rien dans le suivi du trafic ne semble alarmant... Les fameuses requêtes de découvertes SSDP ou DHCP dont tu parlais ?

Le nombre de paquets bloqués chaque heure par le pare-feu reste stable, autour de 400... S'il ne se passe rien de préoccupant, penses-tu que je n'aie plus qu'à rehausser le seuil d'alerte pour éviter d'être embêté par les notifications ?

À propos, avec quoi réussis-tu à ouvrir le rapport de capture de paquets de mon pare-feu, exactement ? Le seul moyen que j'ai trouvé pour l'ouvrir, pour ma part, est de le convertir en fichier texte, mais cela le rend quasiment inintelligible alors que sur ta capture d'écran, tout semble parfaitement clair ! Si la prochaine fois, je suis en mesure de le lire tout seul, je n'aurai peut-être pas à venir vous embêter ! :c_embarrassed:

Lien vers le commentaire
Toto61 Major

Toto61

Posté(e)
Posté(e)

Tu n'es pas le seul a faire cette remarque concernant les notifications.

Pour tout ce qui est capture de trame, j'utilise WireShark (une version portable existe). C'est une base pour les analyses réseaux, mais qui demande une bonne compréhension du modèle OSI. Cela permet de suivre une trame, et les différentes interactions lors d'une communication.

C'est possible que les requètes SSDP génèrent des alertes, mais tu devrais le "voir" au niveau de ton firewall sur ton QNAS. Tu indiques recevoir des notifs par mail, cela ressemble à quoi ?

Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e)
Il y a 3 heures, Toto61 a dit :

Tu n'es pas le seul a faire cette remarque concernant les notifications.

J'ai bien reçu la notification de vos deux derniers messages, ceci dit. Peut-être que j'ai juste été distrait la dernière fois...

Il y a 3 heures, Toto61 a dit :

C'est possible que les requètes SSDP génèrent des alertes, mais tu devrais le "voir" au niveau de ton firewall sur ton QNAS. Tu indiques recevoir des notifs par mail, cela ressemble à quoi ?

Ben, ça ne ressemble à rien, en fait. Ça dit juste que le seuil d'alerte est dépassé.

Severity: Warning
Date/Time: 2021/07/01 11:11:07

App Name: QuFirewall
Category: Firewall Events
Message: [QuFirewall] In time of 2021-07-01 10:49:01 ~ 2021-07-01 11:11:02, the denied amount reach the set threshold: 150.

 

Le seul moyen que j'ai de voir ce qui est retenu par le pare-feu, c'est la capture de paquets comme celles que je t'ai envoyées, mais je n'ai pas le sentiment que la dernière permette d'y voir vraiment plus clair...

 

Je sais que je change de sujet, mais je rencontre en ce moment un problème encore plus préoccupant avec mon NAS. Suivant les recommandations de la dernière mise à jour de son système d'exploitation que je viens de faire, j'ai décidé (je n'aurais pas dû) de migrer du compte administrateur par défaut que j'utilisais jusque-là vers un autre compte.

Cela m'a aussitôt causé une monstrueuse quantité que je n'avais pas anticipée de problèmes d'accès aux fichiers contenus sur le NAS depuis mon ordinateur qui l'utilisait comme lecteur réseau. C'est en tentant de résoudre ces problèmes d'accès en répartissant les autorisations nécessaires à mon nouveau compte que je crains d'avoir fait planter l'appareil... Tout d'un coup, dans le tableau de création des autorisations, je ne voyais apparaître plus aucun compte, plus aucun dossier, dans le gestionnaires des utilisateurs, mon nouveau compte avait disparu et, maintenant, le NAS mouline dans la semoule parce que j'ai eu la bête idée d'essayer d'ouvrir un onglet...

Je ne sais pas quoi faire, ma hantise étant que, si je fais une bêtise de plus, je ne puisse accéder à plus rien de ce qui est stocké sur le NAS, perdant ainsi de grosses quantités de données que j'ai ajoutées récemment sans avoir eu l'intelligence de les sauvegarder ailleurs...

:c_omad:

Autant dire que je n'ose plus rien faire sans l'avis de quelqu'un de plus qualifié que moi...

Lien vers le commentaire
Toto61 Major

Toto61

Posté(e)
Posté(e)
il y a 17 minutes, Mathieu Réau a dit :

mais je n'ai pas le sentiment que la dernière permette d'y voir vraiment plus clair...

Je te confirme, elle ne donne strictement rien de plus que les requêtes SSDP / DHCP

 

il y a 8 minutes, Mathieu Réau a dit :

'ai encore accès à certains dossiers depuis mon ordinateur, j'en profite pour sauvegarder ce que je peux, au cas où...

Cela semble être une sage décision.

Sur le principe de changement de compte, normalement on pratique de la sorte :

  1. on ajoute un utilisateur, en lui attribuant des droits d'admin et/ou dans le groupe admin.
  2. on ajoute cet utilisateur à la racine de chaque dossier
  3. on déconnecte les lecteurs réseaux, puis on reconnecter avec le nouveau nom d'utilisateur.
  4. si tout est OK, dans ce cas, on peut envisager de désactiver le compte admin.

Après, je ne connais pas les QNAS, je suis historiquement Netgear, sur des produits qui commencent à devenir obsolètes. Mais globalement, cela fonctionne sur une base Linux. On devrait avoir quelques personnes habitués pas très loin.

Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e) (modifié)
il y a 55 minutes, Toto61 a dit :

Sur le principe de changement de compte, normalement on pratique de la sorte :

  1. on ajoute un utilisateur, en lui attribuant des droits d'admin et/ou dans le groupe admin.
  2. on ajoute cet utilisateur à la racine de chaque dossier
  3. on déconnecte les lecteurs réseaux, puis on reconnecter avec le nouveau nom d'utilisateur.
  4. si tout est OK, dans ce cas, on peut envisager de désactiver le compte admin.

Effectivement, la procédure est la même, mais je suis passé à l'étape 4 avant de me rendre compte qu'il y avait les étapes 2 et 3... Et en voulant me rattraper, j'ai fait planter le NAS.

J'ai toutefois l'impression que mon problème d'accès aux dossiers via mon nouveau compte utilisateur a fini par se résoudre. Les modifications que j'avais lancées ont dû finir par s'appliquer...

Mais le système d'exploitation du NAS a complètement planté. Je n'arrive même pas à lancer un redémarrage...

Je viens de découvrir que le redémarrage manuel fonctionne, en revanche ! Redémarrage propre, avec extinction des applications. Ça devrait éviter des problèmes...

J'espère que je pourrai me reconnecter une fois que ce sera fait.

Modifié par Mathieu Réau
Lien vers le commentaire
Toto61 Major

Toto61

Posté(e)
Posté(e)

Aïe !

J'espère qu'il n'est pas trop tard, et que tu n'as pas encore réinitialiser ton NAS. Il faut que tu tentes un accès SSH (indépendant des comptes admin), comme indiquer sur cette procédure : https://www.qnap.com/en/how-to/knowledge-base/article/im-unable-to-log-in-to-qts-and-the-password-reset-does-not-work-what-can-i-do

Il faudra au préalable retirer tes disques ("à froid", NAS éteint), et bien noter leurs ordres.

 

Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e)

Merci, @Toto61 pour cette trouvaille !

Heureusement, non, il n'est pas trop tard, je n'ai encore rien touché depuis hier soir. J'ai découvert qu'il existe apparemment un moyen de réinitialiser le compte administrateur par défaut (celui que j'ai bêtement désactivé) sans formater le disque.

Je commencerai donc par ça et, si ça ne fonctionne toujours pas, j'emploierai la méthode que tu me proposes.

  • J'aime 1
Lien vers le commentaire
Mathieu Réau Maistrancier

Mathieu Réau

Posté(e)
  • Auteur
Posté(e)

Ça y est, la réinitialisation du compte administrateur a fonctionné au poil ! Je suis en train de rétablir les connexions comme avant et je ne compte pas y retoucher avant d'avoir de quoi faire une vraie sauvegarde complète de mes fichiers ! :c_embarrassed:

Bon, ceci étant derrière moi, reste mon problème de pare-feu qui s'affole pour une raison totalement inconnue... Comme je le demandais avant de faire n'importe quoi avec mes comptes, est-ce que je laisse courir en rehaussant simplement le niveau d'alerte ? Est-ce que je fais une nouvelle capture pour jeter un œil ?

Lien vers le commentaire
Invité
Ce sujet ne peut plus recevoir de nouvelles réponses.
Aller sur la liste des sujets

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...