PiwiLAbruti

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 ?

Soit le NAS a un souci d'accès à internet (peu probable), soit les serveurs de Synology ne sont pas disponibles (très courant en ce moment).

Ton serveur DNS ne sachant pas résoudre d'autres domaines que ceux que tu y as défini dans les zones, il demande la résolution des autres domaines aux serveurs DNS externes que tu as configurés (ceux de FDN). Naturellement, ce sont ces serveurs qui sont vus par n'importe quel service externe. Pour info, mullvad.net utilise un nom de domaine généré aléatoirement (<random>.mullvad.net) pour détecter le serveur DNS qui interroge son serveur DNS.

C'est exactement le contraire. Le 10/8 permet de créer 65536 réseaux en /24, là où un 192.168/16 ne t'en laisse que 256, et 4096 dans un 172.16/12. @.Shad. donnait les cas d'utilisation des autres réseaux utilisés par défaut par certains services du NAS. Je ne vois pas ce qu'il y a d'étrange à cela.

Je découvre en même temps que toi : https://fr.wikipedia.org/wiki/NAT_Port_Mapping_Protocol

Il faut commencer par créer un utilisateur et activer SSH sur le switch : xxxxxxxx# configure terminal xxxxxxxx(config)# password manager user-name {nomUtilisateur} xxxxxxxx(config)# crypto key generate ssh xxxxxxxx(config)# ip ssh Pour se connecter via le client SSH de PowerShell, il faut forcer la méthode d'échange de clés (-o) et l'algorithme de chiffrement (-c). Ils ne sont pas supportés par défaut car obsolètes : > ssh user@switch Unable to negotiate with x.x.x.x port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > ssh -o KexAlgorithms=diffie-hellman-group1-sha1 user@switch Unable to negotiate with x.x.x.x port 22: no matching cipher found. Their offer: des,3des-cbc > ssh -o KexAlgorithms=diffie-hellman-group1-sha1 -c 3des-cbc user@switch

@bibinault Je te donne les détails pour PowerShell demain (si j'y pense). De mémoire il faut forcer l'échange de clés avec le paramètre -c avec une des propositions du switch (l'alerte vient du fait que ces méthodes de chiffrement sont obsolètes aujourd'hui).

Concernant le switch (j'ai un 2810-48G sous la main), il faut déjà commencer par réinitialiser sa configuration : https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=c02012397 Une fois réinitialisé, tous les ports du switch sont dans le VLAN 1 par défaut. Il ne reste plus qu'à lui attribuer une adresse IP via DHCP : xxxxxxxx# configure terminal xxxxxxxx(config)# vlan 1 xxxxxxxx(vlan-1)# ip address dhcp-bootp xxxxxxxx(vlan-1)# write memory Toutes les documentations relatives à ton modèle (J9021A) se trouvent ici : https://support.hpe.com/hpesc/public/km/product/5179346/Product#f:@contenttype=[Documents] La référence de la ligne de commande (CLI) contient la documentation de toutes les commandes : https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=c02564233 Pour éviter d'avoir à te connecter via la console, tu peux configurer Telnet ou SSH sur le switch. -------- Une fois que ton switch a accès au réseau local et que tu as du temps à perdre, tu peux mettre à jour le firmware. Vérifie la version du firmware avec la commande show flash : xxxxxxxx# show flash Image Size(Bytes) Date Version ----- ---------- -------- ------- Primary Image : 3189436 02/23/10 N.11.25 Secondary Image : 3176720 10/21/08 N.11.15 Boot Rom Version: N.10.01 Current Boot : Primary Le mien est en N.11.25 (23 février 2010 😱) alors que le dernière version est N.11.78 (11 octobre 2017). Ce switch dispose du dual boot. Il y a deux images (primary et secondary) vers lesquelles un nouveau firmware peut être copié. Il faudra copier le nouveau firmware sur l'image ayant la plus ancienne version. Dans l'exemple ci-dessus, la secondary en N.11.15 devra être écrasée par la version la plus récente. Tu peux télécharger la dernière version de firmware pour ton modèle (J9021A) ici : https://h10145.www1.hpe.com/downloads/SoftwareReleases.aspx?ProductNumber=J9021A Pour l'installation, il te faudra configurer un serveur TFTP (comme tftpd64 sur PC, ou celui d'un NAS Synology) et utiliser la commande suivante : xxxxxxxx# copy tftp flash {adresseIPduServeurTFTP} /{chemin}/{fichier} {imageNumber} xxxxxxxx# copy tftp flash 192.168.42.7 /hp/procurve/J9021A/N_11_78.swi secondary Si le fichier est à la racine du serveur TFTP, il faut omettre le chemin : xxxxxxxx# copy tftp flash 192.168.42.7 N_11_78.swi secondary Une fois la copie terminée, il faut indiquer au switch celle qu'il doit utiliser pour démarrer : xxxxxxxx# boot system flash secondary Puis redémarre le switch : xxxxxxxx# reload

Qu'est-ce que tu ne comprends pas avec ces réseaux ?

Donc ça ne doit pas changer grand chose par rapport à DSM 6 ?

Dans le cas d'un seul disque, il est plus intéressant qu'il ne soit jamais saturé par une simple copie car ça pénaliserait considérablement les autres services du NAS. Le 1GbE est donc (de mon point de vue) bien suffisant pour un NAS 1 ou 2 baies. De plus, le multi-Gig (2.5 ,5, et 10 GbE) est encore trop peu accessible pour que Synology se décide à proposer plus pour le moment. Par contre, c'est une vraie plaie pour les professionnels que ces débits ne soient pas natifs par paire sur les équipements. Par exemple, le choix d'un seul port 10GbE sur le SA3200D ou carrément aucun sur la série xs (non +) est complètement absurde.

@Skylitik : Ça bouge pas mal chez QNAP en ce moment avec la bêta de QTS 5 : https://www.qnap.com/qts/5.0/fr-fr/ À voir les retours sur un forum dédié à cette marque (comme déjà conseillé par @pluton212+).

@rvga : C'est indiqué dans le premier message du sujet dédié :