PiwiLAbruti

C'est inscrit dans ta capture d'écran (10000Mbps).

D'après la liste de compatibilité de Synology, seuls les modèles 840/850/860 EVO/PRO sont supportés.

C'est bien ça, et tu sais bien lire car la confusion est facile. J'ai rencontré plusieurs fois cette mauvaise interprétation en milieu professionnel 😉 Pour le reste je ne te serai d'aucune aide, je n'ai aucune expérience des SSD sur du Synology.

🤨🤔😀😄

Connecte un terminal SSH au NAS et affiche le contenu du fichier /etc/crontab : user@diskstation:~$ cat /etc/crontab MAILTO="" PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin #minute hour mday month wday who command 0 0 * * * root /usr/syno/bin/synoschedtask --run id=1 ...

Les bases de données GeoIP changent tous les jours. Demande à Synology à quelle fréquence cette base est mise à jour dans DSM, et quel service ils utilisent (probablement MaxMind).

Le problème semble résolu, la connexion à mon compte fonctionne.

Ça m'étonnerait qu'il y ait effectivement une incompatibilité entre deux révisions de la version 2.2 de Hyper Backup (Vault). Mais comme Synology n'a pas publié le paquet pour certains NAS sous DSM 6, ça laisse perplexe.

Oui, notamment à cause du DS112j qui n'est pas compatible DSM 7, et surtout du fait que je ne suis pas pressé car DSM 7 ne m'apporte rien de plus que DSM 6 pour le moment.

J'ai demandé au support Synology pour savoir ce qu'il en est, j'attends la réponse. Au pire j'ai un NAS intermédiaire en cas de besoin (DS213j), mais ça ne sera pas le cas de tout le monde.

La version 2.2.8 de Hyper Backup et Hyper Backup Vault n'a pas été publiée pour l'architecture ARMv5 qui concerne de vieux NAS comme mon DS109 DS112j : Ne sachant pas si les versions 2.2.7 et 2.2.8 sont interopérables, j'ai bloqué la mise à jour automatique des ces paquets dans le Centre de paquets le temps d'avoir confirmation. Attention donc si vous utilisez Hyper Backup Vault sur un vieux NAS ARMv5 pour de la sauvegarde déportée. La note de mise à jour de Hyper Backup Vault :

Revérifie les redirections et règles de pare-feu : Est-ce que les ports udp/500 et udp/4500 sont bien redirigés pour n'importe quelle source vers l'adresse IP du NAS dans les redirections de ports de la Freebox ? Est-ce que les ports udp/500, udp/1701, et udp/4500 sont ouverts pour n'importe quelle source dans le pare-feu du NAS ? Un numéro de port seul ne veut rien dire, il y a toujours un protocole associé (TCP ou UDP). Dans le cas d'un VPN L2TP/IPsec, tous les ports sont en UDP.

Pas du tout, c'est juste une botnet qui applique le schéma de détection qu'on lui a demandé.

@MilesTEG1 Sachant que tu as déjà une règle qui est systématiquement satisfaite dans la zone "Toutes les interfaces", les règles dans les zones des interfaces ne seront jamais vérifiées. Donc peu importe. L'idéal est de déplacer recréer toutes les règles (sauf celle qui bloque tout) dans la zone de l'interface concernée, activer "Refuser l'accès", et supprimer toutes les règles dans la zone "Toutes les interfaces".

Ce thread mériterait d'aboutir sur un tutoriel dédié à la configuration du pare-feu. Le tutoriel Sécuriser les accès à son NAS (rubrique Sécurité > Pare-feu) est déjà assez explicite sur le sujet même s'il est très dense à suivre pour un utilisateur novice. Contrairement au tutoriel, je préconise de créer des règles pour chaque interface utilisée et de n'en mettre aucune dans Toutes les interfaces (ou alors pour du blocage ciblé). C'est même obligatoire pour ceux utilisant un client VPN sur leur NAS (autoriser des réseaux privés entrants sur une interface VPN, dont 10/8, c'est vraiment mal). On pourrait aussi y expliquer comment identifier les plages d'adresses des opérateurs pour restreindre les accès au minimum nécessaire (comme 37.160/12 pour Free mobile, par exemple). C'est toujours plus efficace que d'exposer des services à la France entière.

Qu'est-ce qui bloque exactement ?

En plus du nombre de versions, il faudrait aussi appliquer une limite de taille aux fichiers pour éviter de doubler le stockage de gros fichiers.

Tant que les serveurs DNS ne sont exposés qu'en local (donc pas sur internet), il n'est pas nécessaire de définir une clé de signature de transaction (TSIG). La procédure de @.Shad. est suffisante.

Ah oui, il s'agit de DSM et non SSH 😅 Quels sont les ports ouverts pour l'accès à DSM ? Commence déjà par restreindre les connexions à ton pays de résidence dans le pare-feu. Ton DSM n'a probablement pas besoin d'être visible du monde entier.

Il l'est nécessairement, sinon il n'y aurait aucune tentative.

Le meilleur moyen de limiter est d'ajouter des règles de pare-feu en identifiant les sources qui peuvent accéder au port tcp/22 (SSH).

Il est plus pertinent de n'autoriser que les adresses qui peuvent accéder au NAS.

L'adresse 173.162.192.5 appartient à Comcast, un FAI Américain, et ne devrait pas être en mesure d'accéder à la page d'identification du NAS si ce dernier était bien sécurisé. Il faut revoir les règles de pare-feu et activer le blocage automatique. Poste ici une capture d'écran des règles de pare-feu actuellement configurées. Précise aussi les paramètres du blocage automatique.

Le NAS sur lequel Synology Directory Server est installé doit nécessairement avoir également le rôle de serveur DNS. Si tu veux que la zone DNS correspondante soit également résolvable sur le serveur DNS du routeur, il suffit de créer une zone DNS secondaire (esclave) sur ce dernier en indiquant l'adresse IP du NAS comme source. Attention à bien paramétrer la zone du NAS pour que le transfert de la zone vers le routeur fonctionne. Je recommande d'ailleurs d'utiliser une clé dans les règles de transfert.

As-tu ouvert un ticket auprès du support Synology en parallèle ?