PiwiLAbruti

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.

Ce sont les identifiants de la caméra qu'il faut entrer, pas ceux du NAS.

Je confirme, le reverse DNS personnalisé fonctionne de nouveau 🍾🥳 Il faut renseigner un FQDN comme domain.tld ou sub.domain.tld.

Un support externe en USB (disque dur, SSD, clé, …). Comme pour beaucoup d'autres choses, la marque n'a pas grande importance. Non, il est inutile de le relancer. Il faut se rendre dans le Gestionnaire de stockage et vérifier si la réparation doit être lancée ou si elle est déjà en cours.

Il n'y a pas de seuil minimal à respecter, il faut simplement qu'il reste un peu de place pour que le NAS puisse écrire ce dont il a besoin. Comme DSM (le système du NAS) est stocké sur une partition indépendante en RAID1 sur tous les disques, le remplissage à 100% de la partition de données n'impactera pas le système en lui-même. Seuls les paquets présenteront des dysfonctionnements, en plus plus des pertes de données liées au manque de place. Pour ne plus avoir d'alerte, tu peux modifier le seuil d'alerte de 20% dans le Gestionnaire de stockage, Stockage > Groupe de stockage {n} > Volume {n} > Menu ... sur le volume en bas de page > Paramètres > Notification de faible capacité.