Mic13710

Il y a bien une nouvelle version Synology MailPlus 4.1.1-22335 du 20/10/2026 qui est proposée en téléchargement décalé alors que les versions de PHP et de calendar l'ont été en (quasi) immédiat. La note pour l'avertissement de sécurité Synology-SA-26:14 PHP2Shell ne liste pas MailPlus : Synology_SA_26_14 | Synology Inc.Avertissement de sécurité de produit SynologyCe qui m'inquiète plus ce sont les versions PHP des NAS plus anciens (séries 13 à 15) sous DSM 7.x qui n'ont pas de maj. S'agissant de vulnérabilités critiques, j'espère que synology va proposer des mises à jour pour ces NAS, y compris pour les versions PHP obsolètes qui tournent encore sur ces NAS.

Merci pour l'info. Après avoir écrit mon message, je me suis rendu compte que je faisais fausse route. Pourquoi diable je suis allé sur le lien php ? Mystère. Je viens de me reconnecter et les mises à jour des php sont maintenant proposées dans le centre des paquets ainsi que synology calendar. Maj des php effectuées mais impossible de télécharger synology calendar dans le centre des paquets. Trop de téléchargements peut-être ? J'ai téléchargé via le site et c'est passé.

Pas seulement php8.2. Il y a aussi la 8.3 et la 8.4 qui ont une mise à jour en ligne aujourd'hui. Par contre, ces maj n’apparaissent pas encore dans mon centre des paquets et je ne sais pas quel fichier télécharger. Le lien Synology renvoie vers la page Php : https://www.php.net/ChangeLog-8.php#8.2.35 Il y a deux fichiers possibles et quand on ouvre l'un ou l'autre, on tombe sur une page pas très clair pour un néophyte et qui ne comporte aucun téléchargement pour une installation manuelle. Je n'ai pas non plus trouvé la marche à suivre chez Synology. Si quelqu'un peut me dire comment mettre à jour php sur un NAS Synology à partir du site php, ce serait sympa et ça pourrait aider d'autres membres.

@jeremyc , certes, mais le fait de monter des 14To et de créer plusieurs volumes dans le 814 ne va pas dans le bon sens. Augmenter le stockage ne fera que compliquer un peu plus la migration des données vers un nouveau NAS du fait de l'augmentation des données. La gestion de multi volumes n'est pas non plus très facile (gestion et répartition des dossiers partagés entre volumes) Autre point critique, DSM n'est plus mis à jour, idem pour les applications. Selon l'utilisation qui est faite de ce NAS et son degré d'exposition vers l'extérieur il deviendra vulnérable. Je pense que quitte à investir dans des disques de 14To qui coûtent déjà une blinde, on peut y rajouter un NAS et repartir sur un ensemble à jour. Après, on peut se poser la question d'un basculement soudain d'un groupe en 1To vers une groupe en 14To. Passer de 3To à 42To, ce n'est pas anodin. Pourquoi une telle augmentation ? Même si le stockage existant est arrivé en bout de course au fil du temps, il faut avoir un sacré volume de données nouvelles à stocker d'un coup pour multiplier le groupe par 14 !

Si ces attaques proviennent de sources étrangères (Russie principalement mais pas que...), vous pouvez faire un blocage géographique dans le pare feu. Si vous ne vous connectez qu'à partir de la France, vous pouvez n'autoriser que les seules connexions venant de France. Attention toutefois de ne pas tout bloquer. Les USA (bien qu'ils soient devenus un état voyou de mon point de vue) doivent être conservés si vous avez un nom de domaine en propre pour le renouvellement du certificat chez Let's Encrypt. Vous pouvez dans ce cas, n'ouvrir l'accès que lors de la période de renouvellement mais ça va vite devenir fastidieux. Vous n'empêcherez pas les tentatives de connexion qui persisteront jusqu'à épuisement du bot à l'origine des attaques. Il est difficile de ne pas connecter un NAS sur l'extérieur pour des raisons évidentes d'utilisation à distance. Cependant, les outils proposés par DSM permettent une bonne protection contre les tentatives malveillantes. L'analyse de l'origine des attaques vous permettra de mieux cibler ce qu'il faut bloquer. Une excellente manière de protéger son réseau c'est d'installer un routeur digne de ce nom. Les protections intégrés sont alors plus complètes que celles proposées par les box des opérateurs où elles sont quasi inexistantes. Le filtrage se fait alors en amont du réseau et donc du NAS sans pour autant abandonner les moyens de protection de ce dernier qui doivent continuer de protéger le NAS (pare feu, blocage des tentatives de connexions échouées, DOS, etc..). Par exemple, mon routeur (voir ma signature) bloque la grande majorité des IP malveillantes dès leurs tentatives ce qui soulage le NAS. Le nombre de blocages du routeur par minute est absolument impressionnant. Un toutes les deux à trois secondes venant de tous pays : USA, Bulgarie, Canada, France, Russie, Roumanie, Pays-Bas, Pakistan, Philippines, Allemagne, Argentine, Angleterre, Brésil juste pour les deux dernières minutes. Ce sont pour la grande majorité des bots qui balayent le web à la recherche de cibles.

Pour l'alim, c'est peut-être une capacité HS. Voir cette vidéo : https://www.youtube.com/watch?v=sJsAgQtfoVo Autre solution avec une alimentation atx sur un 1815+. Le gars n'est pas très clair mais ça semble fonctionner : https://www.youtube.com/watch?v=NWH0ZOCyW8s&t=182s Il y avait aussi un sujet assez ancien sur le forum avec une alim ATX mais je ne le retrouve pas.

La seule migration envisageable vers un modèle récent serait de partir sur un ensemble NAS disques neuf et de procéder au transfert des données via hyperbackup. Surtout pas de migration des disques qui importerait toutes les limitations de votre groupe actuel et notamment la limite des 16To par volume. Si vous trouvez une unité d'extension RX 4 baies compatible d'occasion à bon prix, pourquoi pas l'envisager mais votre NAS est ancien (12 ans) et ne peut plus recevoir de mises à jour de DSM. Rajouter une extension ne ferait que retarder le remplacement à plus ou moins brève échéance.

Si vous avez suivi le tuto à la lettre, c'est normal. Avec cette tâche planifiée, docker acme est stoppé, supprimé puis recréé. docker pull neilpang/acme.sh:latest docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart unless-stopped neilpang/acme.sh:latest daemonCette tâche est à mon avis totalement inutile, surtout avec container manager où la mise à jour du docker se fait beaucoup plus simplement que par le passé. Si vous n'avez pas Container Manager, vous pouvez toutefois le conserver mais supprimez le lancement quotidien. Vous le lancez manuellement une fois par mois par exemple, c'est largement suffisant. Je rappelle que ce renouvellement quotidien ne sert qu'à la mise à jour du container, pas du script acme.sh qui lui est vérifié tous les jours par le script lui-même et mis à jour automatiquement.

@PiwiLAbruti Un très beau déterrage ! Il a fallu allez le chercher trèèès loin dans le forum pour l'exhumer. Oui, volume maxi 16To par volume mais la spec parle aussi de 256 volumes internes. Pour que ce soit possible il faut que le groupe soit construit en multi volume. Selon votre version de DSM et surtout si le montage du groupe est monté en SHR, il est possible de le faire à posteriori et sous certaines conditions et pour certains modèles de NAS sans détruire le groupe existant. Si c'est un RAID 5, ce n'est pas possible sans tout reconstruire. Conversion d'un volume en groupe de disques | DSM - Synol...Le Centre de connaissances de Synology offre une assistance complète, fournit des réponses aux questions fréquemment posées, des étapes de dépannage, des tutoriels logiciels et toute la documentationVotre problème c'est que tous les rack de votre NAS sont utilisés, ce qui ne permet pas une augmentation du stockage par ajout de disque. Je ne sais pas s'il est possible de le faire en procédant au changement de 2 disques et plus. Et je ne peux pas vous dire si le RS414 autorise le passage de volume unique en multi volume sans reconstruction du groupe.

Je ne pense pas non. Vos problèmes de disques ne sont pas liés à la sécurité mais ça vous permettra de vous affranchir de quickconnect et de remettre à plat vos paramétrages.

Le tuto que vous avez utilisé est celui pour DSM6. Celui que je vous propose est actualisé pour DSM7. Il y a quelques évolutions. De toute manière, quickconnect est déconseillé dans les deux tutos. C'est très pratique et facile pour réaliser une installation rapide et sans prise de tête. Ca l'est beaucoup moins en utilisation courante car on est alors tributaire du fonctionnement plus ou moins capricieux d'un service qu'on ne maîtrise pas. Lenteurs, dysfonctionnements sont malheureusement à mettre souvent au passif de ce système.

Salut @Oooops! , en principe chaque nouvel update intègre les update précédents. Donc dans ton cas, tu installes la version de base et tu peux ensuite passer directement au U9. DSM devrait te le proposer directement. Fais très attention à la version que tu installeras sur tes disques de test, elle doit être la même que celle que tu as déjà sur ton 415. Si c'est la dernière pour ce modèle, alors la question ne se pose pas. Tes problèmes peuvent très bien provenir de la migration des disques. Peut-être qu'une installation complète directement sur le 415 serait en mesure de résoudre tes soucis de réseau (anciens paramétrages, conflits, etc..). Lors d'un changement de NAS, mieux vaut privilégier la réinstallation que la migration des disques.

Vu les infos que vous donnez, il semblerait que vous n'ayez pas étudié et surtout mis en application le tuto sur la sécurisation de nos NAS. C'est un préalable indispensable.

Comment sont montés vos disques : RAID ou SHR ou deux groupes séparés ? Quel est l'état du voyant marche ? Est-ce que le terminal SSH est activé dans DSM ?

Certainement pas. Le NAS passe en mode sécurité mais ne s'éteint pas. Il continue de fonctionner tant que l'UPS ne s'est pas éteint. Ce n'est seulement que si vous avez activé l'extinction de l'UPS par le NAS que l'UPS va s'éteindre et pas voie de conséquence le NAS aussi. Et cette fonctionnalité n'est absolument pas garantie car certains UPS ne traitent pas les ordres de commande d'extinction externes. Drôle de question. Comment voulez vous que votre unité d'extension fonctionne lors d'une coupure si vous ne la connectez pas à l'onduleur ? Si le NAS est connecté à l'usb de l'UPS et que la fonction UPS est activée sur le NAS, la mise en sécurité de l'extension sera assurée par le NAS.

Par défaut, Hyperbackup sauvegarde aussi le fichier système. Sauf si ça a été décoché, vous ne devriez pas avoir besoin du .dss. Tout dépend de ce que vous avez sauvegardé. Si vous avez sauvegardé les paramètres des paquets couverts par hyperbackup, normalement, le paquets et leurs paramètres sont réinstallés automatiquement lors de la restauration. Mais attention, tout n'est pas systématiquement restauré et il va falloir probablement faire quelques ajustements. Les paquets tiers ne sont pas sauvegardés, les scripts utilisateur non plus, et il faudra les réinstaller et les paramétrer. Il faudra aussi renouveler votre ou vos certificats si vous en avez. Je vous conseille de faire des captures d'écrans de vos paramètres, au moins les plus importants, cela facilitera vos réglages. Autre point important : DSM. Le fichier d'installation n'existe plus sur le site officiel de Synology. A moins que vous l'ayez sauvegardé quelque part autre que le NAS, il faudra le récupérer sur un site d'archivage. Vous trouverez un lien dans la section Firmware du forum Synology.

Vous avez raison, en cas de plantage du NAS principal, le reverse proxy est hs. Raison pour laquelle je maintiens les certificats, le serveur DNS ainsi qu'un reverse proxy sur le NAS 2. Dans ce cas, j'ai deux solutions : soit modifier les règles de redirections des ports vers le NAS 2 (j'ai un accès cloud à mon routeur), soit je passe par le VPN du routeur (wireguard) pour me connecter au réseau et accéder là aussi aux paramètres du routeur et/ou aux autres équipements de manière sécurisée. Vous pouvez tout à fait maintenir un accès vers le NAS 2 avec un port dédié, mais rien n'empêche d'utiliser le reverse proxy du NAS 1 pour atteindre le NAS 2. Ainsi, vous n'avez qu'un port (le 443) utilisé dans la vie de tous les jours, tout en maintenant un accès possible par un autre port en cas de panne du reverse proxy. Perso, je préfère l'utilisation d'un port unique (le moins de ports ouverts c'est mieux) et le VPN en cas de panne du NAS principal.

Oui, vous suivez les indications : vous cliquez sur les 3 points en haut à droite du groupe 1. De toute manière, vous n'avez pas d'autre option et si ça ne fonctionne pas vous avez encore votre sauvegarde et le deuxième disque.

Mouais. Ca peut aussi se faire avec le reverse proxy. Et si je comprends bien, dans ce cas vous avez utilisé des ports différents pour joindre chaque NAS. Un peu compliqué non ? Avec le reverse proxy, vous n'utilisez que le port 443 par défaut et selon le ndd, c'est lui qui dispatche vers les applications quelles que soient leurs localisations sur le réseau. Par exemple : si l'application qui correspond à toto.ndd est sur le NAS 2 (ou tout autre équipement, un RPI par exemple) dont l'IP est 192.168.1.25, port http 8080, sur le reverse proxy du NAS 1 vous mettez : origine : https://toto.ndd destination : 192.168.1.25 port 8080. Et dans ce cas, le seul certificat qui est invoqué est celui du NAS 1. Le certificat ne sert à rien sur le NAS 2.

Le risque est assez contenu puisque vous gardez un des disques au chaud. Si la procédure que je vous propose ne fonctionne pas, vous pourrez toujours soit récupérer les données directement sur le disque restant (ou même sur celui qui n'a pas fonctionné dans la procédure), soit vous avez votre sauvegarde qui contient obligatoirement votre db si vous avez sauvegardé le dossier plex. Donc, même si ça ne se déroule pas bien, vous avez encore deux parachutes (voire 3 si le disque d'essai n'a pas été endommagé) pour vous rattraper. Et perso, je miserai plus sur la sauvegarde hyperbackup.

Une petite question : quel intérêt d'avoir un certificat sur chaque NAS ? Je demande ça parce qu'en général on utilise le reverse proxy d'un des NAS pour atteindre les autres NAS et dans ce cas, seul le certificat du NAS avec le reverse proxy est sollicité, à condition bien entendu que la destination du reverse proxy se fasse en http. Un certificat sur un NAS n'a d'utilité que s'il gère un nom de domaine. Si vous joignez le NAS uniquement avec son IP en local, alors le certificat ne sert ... à rien.

Ce n'était pas assez clair ? Là non plus ce n'était pas assez clair ?

Pour être plus précis, ce n'est pas possible via DSM car la méthode d'obtention du certificat est en http qui nécessite l'ouverture du port 443 vers le NAS. Par la méthode DNS, pas besoin d'ouverture de port et chaque NAS peut obtenir son propre certificat, peu importe le réseau sur lequel il se trouve. Selon que votre NAS est compatible docker (container manager) ou pas, il existe deux manières d'opérer qui toutes deux utilisent le script acme.sh et des clés API : sans docker : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide avec docker : https://www.nas-forum.com/forum/topic/68046-tuto-certificat-lets-encrypt-avec-acmesh-api-ovh-en-docker-dsm67-update-070922/ Si vous n'avez pas docker, le plus simple pour la création des clés API c'est de suivre le tuto pour docker. Vous verrez au final que les deux manières fonctionnent sensiblement pareil. Un conseil : dans les deux cas il faut avoir un identifiant administrateur pour effectuer la demande et créer/actualiser le certificat. Le mieux c'est de créer un identifiant administrateur spécifique que vous n'utiliserez que pour cela. Vous lui donnez un mdp long comme le bras, aucun droit sur les applications et les dossiers (sauf le dossier docker si vous utilisez cette méthode) et surtout pas de double authentification qui complique grandement le processus. A noter : vous ne créez qu'un seul jeu de clés API chez OVH que vous utilisez ensuite sur tous vos NAS.

Ah bon ? Je fais ça sans problème sur plusieurs NAS. Avez-vous au moins essayé ?

Oui. Il se peut que DSM détecte que des données existent sur le disque sans toutefois monter le volume. Il faudra me dire quels sont les messages envoyés par DSM. En principe, il est préférable de garder l'emplacement de chaque disque. Toutefois, DSM autorise le mélange des disques. Je n'ai jamais tenté de le faire donc je ne peux pas confirmer. Le risque en débranchant à la sauvage, c'est la corruption des données si les disques sont en activité. Mais comme vos disques ne travaillent pas, il n'y a pas grand risque à le faire. Cependant le risque 0 n'existant pas, là non plus je ne confirme pas. Vous n'avez pas trop le choix de toute façon, c'est ça ou vous n'avancerez pas. Si la sauvegarde est faite via hyperbackup, la restauration sera beaucoup plus simple. Je n'utilise pas plex et je ne sais pas où se trouve la base de donnée que vous voulez récupérer. Si elle est dans le dossier Plex et que vous l'avez sauvegardé, alors il fait partie de votre sauvegarde.