CoolRaoul

Ca doit poser problème pour le renouvellement auto de(s) certifcat(s) let's encrypt non?

Mais qui a suggéré de se connecter en http? On a simplement dit que laisser le port non chiffré ouvert était sans danger du moment qu'on ne l'utilise pas, rien de plus. (et donc, bien sur, que de ce fait c'est inutile de l'ouvrir à l'extérieur on est d'accord la dessus) Cela dit, je répète, aucun danger à le laisser ouvert: vu qu'on ne l'utilise pas il n'y aura rien à capturer puisque aucun traffic.

Sur le port en clair ça sera les pseudo et pass que le "hacker" utilise lors de ses essais pour tenter de se connecter, quelle importance? Je suis d'accord que fermer le port non SSL est légitime, mais simplement parce que ça ne sert à rien de le laisser ouvert, pas pour raison de sécurité.

Il ne pourra rien faire de plus via le port 5000 que via le port 5001. Juste que le traffic entre le "hacker" et le NAS ne sera pas chiffré, pas de protection supplémentaire pour autant. Mais bien entendu, pas la peine de l'ouvrir à l'extérieur non plus, le port SSL suffit.

Pour forcer l'acces en HTTPS à l'interface d'administration (5000/5001) il y ceci aussi: Toute tentative de connexion sur le port 5000 est automatiquement reroutée sur le port SSL. Sinon il ne faut pas oublier que laisser l'acces HTTP ouvert n'est potentiellement risqué que pour les éventueles utilisateurs externes qui l'utilisent pour se connecter. Ca ne rend pas le NAS plus vulnérable, qu'il écoute activement sur ce port n'est pas un risque "en soi".

Le futur spammeur qui teste la réactivité des modos en mode furtif je dirai.

WTF?

Oui d'autres l'ont signalé aussi: https://www.reddit.com/r/synology/comments/p2booi/dsm7_automatic_configuration_backup_failing/

Pareil:

Pareil, et j'en ai parlé (avec la solution) un peu plus haut (en oubliant de spécifier que c'était sur un 213J aussi mais c'est dans ma signature)

Pour tester c'est trop tard par contre: https://dev.freebox.fr/bugs/task/35342 Ouverte par Marios Makassikis (mmakassikis) - 03/08/2021 UPDATE 04/08 14h35 Les inscriptions sont closes. A quelques minutes pres 😕

Ah oui c'est exact, j'avais mal interprété la phrase "le paquet est mis à disposition par Synology" dans l'article

Pour info ça ne fonctionnait pas pour moi. J'ai désinstallé le paquet officiel, remplacé par celui téléchargé ici: https://github.com/tailscale/tailscale-synology/releases et là plus de pb.

Apparemment ca vient juste de sortir: J'ai trouvé l'info ici: https://www.cachem.fr/synology-tailscale-wireguard-vpn/

Un coup de synoindex en ligne de commande devrait pouvoir régler ça: https://www.nas-forum.com/forum/topic/58011-r%C3%A9solu-re-indexation-automatique/?do=findComment&comment=1319338283

Apparemment c'est le même lsof "light" qu'on trouve dans BusyBox

Avec un peu plus de 5600 messages au compteur, je dois dire que ca fait un peu mal au *** . Au passage, j'ai perdu le "slogan" de mon profil ("brigade synophile") **edit** Bon, j'ai mis ça en signature du coup

Bonjour, je viens d'installer les "monitor tools" et je ne retrouve pas dans le lsof inclus dans ce paquet les options auxquelles je suis habitué. On dirait d'ailleurs qu'il n'en supporte aucune (même pas --help).

Bien que que non, j'ai fait ça en root, forcément (ça n'aurait pas pu installer quoi que ce soit dans /bin sinon).

C'est possible ça? Extrait de Release Notes for DSM 7.0-41890 "After the installation of DSM 7.0, you will not be able to downgrade to a previous DSM version."

Je peux confirmer que c'est le cas. Mon NAS était en RC et me suis volontairement abstenu de faire la mise à jour manuelle forcée via la seconde méthode pour vérifier cela. C'est devenu disponible ce matin dans la section mises à jour du panneau de configuration.

C'est bien ça

Je pense avoir réparé, vu que le rapport avec syslog me semblait bien probable, j'ai investigué de ce coté. Il me restait un (très) vieux reste de "hack" perso que j'avais documenté ici: https://www.nas-forum.com/forum/topic/42140-comment-parer-durablement-lattaque-chine-teste-r/?do=findComment&comment=1319237860 Apres avoir supprimé mon fichier "/usr/local/etc/syslog-ng/patterndb.d/local.conf", au reboot il semble que ce soit rétabli. (je vais refaire un reboot supplémentaire pour en avoir le coeur net)

Hélas c'est revenu Avec un peu de reverse engineering , je constate que le process apache ouvre un socket unix en écriture: openat(AT_FDCWD, "/run/apache24-error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE|O_CLOEXEC, 0666 mais aucun process n'est en lecture à l'autre bout, et ca bloque. Le premier message d'erreur, au reboot à été celui-ci: Accompagné de Bien etendy "repair" ne marche pas plus qu'un désinstall/install. J'ai ouvert un ticket au support Syno, mais je ne la sens pas trop cette affaire..

Dans le cas de @Nouch je déduis qu'il était déjà configuré de cette façon et qu'il souhaite continuer à iso fonctionnalité. En plus j'imagine qu'il n'a pas rendu le port 445 de son NAS visible sur internet. Le risque se limite donc aux attaques par rebond interne, quand même plus restreint