PiwiLAbruti

Dois-je comprendre que si le NAS tombe en panne, il n'y a actuellement aucune sauvegarde pour restaurer les données perdues ? Si les données du NAS sont importantes, il va falloir songer à y remédier. Cette page répondra à cette question : https://www.synology.com/en-us/products/status?tab=software DSM 5 est obsolète. DSM 6 le sera dans 1 an, le 1er octobre 2024.

Je me permets de rajouter quelques questions auxquelles je n'ai pas trouvé la réponse dans les précédents messages : Quel est le modèle de ton NAS ? Quelle est la vitesse de connexion négociée avec la box ? (voir l'onglet Network Interface de la précédente capture d'écran)

Attends les interventions d'autres membres du forum avant de te lancer, ça te laissera le choix entre plusieurs possibilités (réinitialisation en mode 2 ?). -------- De mon point de vue, il y a trop de versions d'écart entre la 4.3 et la 7.1 pour envisager une migration. Cela s'explique notamment par une différence au niveau de la taille de la partition système. Il faut aussi faire l'inventaire des paquets utilisés actuellement, car certains n'existent plus (ou ont été remplacés) dans les version ultérieures. Pour installer la version la plus récente de DSM, je te conseillerais les étapes suivantes : Sauvegarder les données du NAS sur un support externe (ça doit déjà être le cas), Réinitialiser le NAS, Installer directement la version 7.1.1 (puis l'update 6), Restaurer les données. -------- Si tu souhaites installer les versions telles qu'indiquées par Synology, tu peux récupérer les versions manquantes sur archive.org. J'ai aussi un DS213j depuis mars 2013 (encore merci Derren pour le cadeau 😉), je l'avais réinitialisé lors du passage à DSM 7 pour les raisons évoquées plus haut.

L'update 1 a été intégrée à la version 7.2.1-69057 de base aujourd'hui même :

Aucune idée. Tu peux regarder dans les autres fichiers de configuration présents aux mêmes emplacements que ceux cités précédemment.

Ouais en fin là, sans plus analyser l'origine, ça n'a aucun sens. L'un des cas d'utilisation du réseau 0/8 est DHCP où le client utilise une adresse de ce réseau comme source (par ce qu'il en faut bien une) pour broadcaster sa demande d'adressage. Si tu utilises DHCP pour adresser une partie des machines de ton réseau local, les 6075 drops proviennent des demandes DHCP des différents appareils de ton réseau local. Je ne vais pas m'étendre sur le reste des blocages dont les origines sont tout aussi légitimes que celle expliquée ci-dessus. Si les origines ne le sont pas, le réseau 0/8 n'étant pas routable, le réseau local serait alors complètement compromis. L'analyse est un des gros blocs de la SSI sur la sécurisation des réseaux. C'est grâce à ça qu'on dimensionne des moyens de sécurité pertinents à mettre en face. Sans ça, on se retrouve à mettre de la sécurité à outrance là où ce n'est pas utile et à titrer des conclusions farfelues.

N'ayant jamais configuré de client VPN (type NordVPN, …) sur le NAS, la section VPN du pare-feu est restée telle quelle ("Autoriser l'accès" par défaut). Si on passe en "Refuser accès", les clients VPN de VPN Server n'ont plus accès aux ressources locales. Quand on autorise l'accès aux ports locaux dans cette section, ça l'autorise pour tout le réseau local. Par exemple, le port tcp/80 permet aux clients VPN d'accéder aussi bien à WebStation qu'aux autres serveurs web du réseau local. C'est là qu'on voit les limites du pare-feu du NAS (absence de destination dans les règles). J'ai vaguement fouillé la doc de Synology pour trouver des explications à ce comportement étrange (et apparemment global quelque soit le type de VPN client/serveur, sans distinction d'interface), et je n'ai rien trouvé. Dans tous les cas, restreindre cette section dans le cadre de l'utilisation de VPN Server uniquement n'apporte pas rien de plus à la sécurité étant donné que les adresses IP utilisables sont définies dans VPN Server et que leur obtention est soumise à authentification. Ce n'est pas du tout applicable à la sécurité d'un NAS. La source que tu cites précise d'ailleurs que c'est à appliquer sur l'interface publique de routeur : C'est pour éviter le spoofing sur une interface publique de type CG-NAT.

Consommer des ressource ne veut pas dire les saturer. Dans le cas présent c'est de la consommation inutile vu les autres politiques de sécurité appliquées.

Il me semble que la section VPN du pare-feu concerne les connexions VPN clientes crées sur le NAS (NordVPN, ...). Elle n'aurait donc rien à voir avec VPN Server.

Les listes d'adresses IP suspectes sont excessivement longues et impliquent que ton NAS va systématiquement vérifier chaque adresse IP source avec toutes celles renseignées, ce qui demande des ressources. En plus, la fréquence à laquelle peuvent bouger ces listes font qu'elles sont inexploitables. Le blocage IP automatique du NAS est suffisant pour bloquer les tentatives d'authentification échouées à condition de bien le paramétrer.

@alan.dub Oui, c'est ce que je préconise car ces ports (465, 587, 993, et 995) ne sont utilisés qu'entre le client et le serveur (MUA). Le port tcp/25 est utilisé par les serveurs SMTP pour communiquer entre eux (MTA). Tu as la source de cette information ? Le port tcp/587 utilise TLS par défaut, c'est moins sécurisé que SSL ? C'est exactement ce qu'il ne faut pas faire car c'est totalement contre-productif.

D'après les fichiers de configuration nginx (/var/packages/WebStation/target/misc/syslog.conf) et Apache (/var/packages/WebStation/target/misc/apache24_service_template.mustache), les logs se trouvent dans /var/packages/WebStation/var/log.

Comme le dit le message, ton NAS a subit une coupure électrique et a redémarré automatiquement lorsque le courant est revenu.

N'utilisant plus QuickConnect depuis un paquet d'années, je ne saurai pas dire si c'est plus fiable aujourd'hui.

En espérant que la disponibilité du service QuickConnect se soit améliorée.

C'est un problème signalé de manière récurrente par les utilisateurs de Synology Drive. Synology ne donne toujours pas la possibilité de modifier le port utilisé par Synology Drive, aussi bien serveur que client. Je ne peux que te conseiller de faire une demande d'amélioration à Synology. Plus il y en aura, plus la probabilité que Synology le fasse augmente. Tu peux aussi ouvrir un ticket d'incident pour les secouer un peu plus.

Le NAS n'a pas besoin d'être changé, surtout qu'il est toujours supporté par Synology (la dernière version de DSM peut y être installée). À moins que tu souhaites prendre des disques de capacité supérieure aux actuels, tu peux ne changer que le disque défaillant car la référence WD60EFPX est toujours commercialisée. Si j'ai bien compris, tu as deux volumes séparés de 6To chacun ? Attention à bien séparer le nouveau disque dans un groupe de stockage différent de celui déjà en place.

@maxou56 H.265 est supporté par Safari depuis la version 13 (19/09/2019), mais je n'ai pas de Mac sous la main pour tester (je n'ai pas encore passé mon MacBook Air de 2012 vers Sonoma avec OpenCore).

Merci pour l'info @Titi95 Ça fonctionne aussi dans ✅ Vivaldi et Opera, mais pas (encore) dans ❌ Edge et Firefox. J'avais fait la demande à Synology le 27/11/2022, lorsque Chrome 107 annonçait le support de H.265. Voici la réponse du support Synology à l'époque :

On pouvait le voir facilement dans les logs de sécurité de MailPlus Server, mais Synology a modifié la gestion et l'affichage des logs lors de la dernière mise à jour publiée le 24 août dernier : Merci Synology d'avoir tronqué les logs à 30 jours… 🤦‍♂️ Les blocages sont visibles dans le paquet Centre de journaux > Journaux > Actuel > Sélectionner Connexion au lieu de Général dans la liste déroulante.

Seul le port tcp/25 de MailPlus Server nécessite d'être ouvert à tout internet. Les autres ports nécessaires aux clients, à savoir : tcp/993 (IMAP), tcp/587 (SMTPS), et éventuellement tcp/995 (POP) si utilisé, doivent être restreints au pays depuis lesquels les mails sont consultés. Comme le port tcp/25 est toujours exposé, il est nécessaire de bien paramétrer le Blocage automatique pour bloquer les tentatives de connexion abusives. RetEx : J'avais constaté le même comportement il y a quelques semaines. Les tentatives de connexion étaient émises par un petit botnet (862 adresses IP) mais suffisamment gros pour que les blocages ne soient effectifs que tardivement. J'avais donc activé temporairement le blocage au bout d'une seule tentative échoué, ce qui en quelques jours a suffit à bloquer l'ensemble des adresses IP du botnet. N'observant donc plus aucune tentative dans les logs de MailPlus Server, j'avais rétabli les paramètres de blocage initiaux. En tenant compte des explications précédentes, le blocage de pays est totalement inutile.

La méthode que tu donnes est celle qui existe depuis longtemps pour revenir à une version antérieure de DSM, je ne saurais dire si elle est toujours d'actualité avec DSM 7+. PHP 7.3 est obsolète depuis fin 2021 et ne reçoit donc plus de mises à jour de sécurité depuis cette date : https://www.php.net/supported-versions.php J'envisagerais sérieusement de rendre le site au moins compatible avec PHP 8.1 (8.0 expire à la fin de cette année).

Essaye avec le port 80, mais je n'y crois pas trop.

Lis ce qui est écrit dans la rubrique Delivery > Paramètres de relais sur la deuxième capture d'écran.