PiwiLAbruti

C'est effectivement le minimum à faire (limiter au pays de résidence). Selon les usages externes on peut réduire drastiquement les accès (ce que je fais). Mais c'est du cas par cas, et les réseaux ne sont pas toujours évidents à identifier (bgpview.io et les logs de connexion de DSM/SRM aident grandement à affiner les réseaux). Ça m'a par exemple permis de définir les réseaux suivants (en gras) pour Free mobile : 37.160/12 (non affiné, un partie est utilisée pour Free mobile en Italie 🇮🇹) 37.164/14 37.168/14 37.172/15 2a0d:e480::/29 (non affiné) 2a0d:e487::/35 Ou pour Orange mobile : 92.128/10 (non affiné) 92.184.96/19 2a01:cb04::/30 (non affiné) Pour voir les authentifications réussies, vous pouvez parcourir les logs de connexion de DSM avec SQLite (en root). La commande suivante va afficher les 10 dernières authentifications réussies : # sudo sqlite3 -header -column /var/log/synolog/.SYNOCONNDB "SELECT strftime('%Y-%m-%d %H:%M:%S',datetime(time,'unixepoch')) AS datetime,msg AS message FROM logs WHERE msg LIKE '% logged in successfully % ' ORDER BY time DESC LIMIT 10;" Tout comme @MilesTEG1, ça fait longtemps que je n'ai pas vu de tentative d'intrusion.

Synology pourrait même intégrer ça dans le Conseiller de sécurité. 😂

Il y aurait un moyen, publier un site qui indique au client si son adresse IP (présente les en-têtes de requête) a été détectée comme source d'attaque de botnet. Un tel site existe peut-être déjà. Pour automatiser tout ça, il faudrait centraliser les adresse IP bloquées par les NAS afin de constituer une base de comparaison. J'ai déjà tous les éléments techniques pour le faire, mais l'intérêt reste limité.

Tant que vous n'aurez pas restreint suffisamment l'exposition de DSM (ou SRM) sur internet via le pare-feu, les tentatives d'instrusions continueront d'atteindre votre NAS. @Dex : Les logs que tu mas envoyés contiennent environ 500 adresses IP correspondant à une 40aine de pays. Est-ce qu'une exposition aussi large de ton DSM est nécessaire ?

-------- Après quelques investigations (merci @Dex pour les logs), les tentatives d'intrusion sont menées par un bon vieux botnet constitué de diverses machines. L'écrasante majorité d'entre elles sont des NAS Synology fonctionnant sous DSM 6. Il y a aussi des NAS QNAP, des routeurs Draytek, des pares-feu SonicWall, des serveurs Microsoft IIS7 ... Certaines d'entre elles sont même encore cryptolockés par DeadBolt. Les tentatives viennent de tous les pays possibles, France/Belgique/Suisse incluses. Les NAS Synology depuis lesquels sont lancées les tentatives d'intrusion ont presque tous les ports tcp/5000 et/ou tcp/5001 ouverts aux quatre vents. Le point commun entre toutes ces machines est l'absence de restriction d'accès par IP (= absence de pare-feu correctement configuré). Vous aurez beau ajouter n'importe quelle sécurité en aval de celle-ci (mot de passe fort, 2FA, blocage auto IP, ...), elle sera inopérante car il suffit qu'un service vulnérable soit atteignable pour qu'il soit détecté et que les failles puissent être exploitées. Tout ça pour souligner l'extrême importance de bien configurer son pare-feu (au minimum un filtrage GeoIP limité au pays de résidence), surtout dans le contexte actuel où les tentatives d'instrusion sont de plus en plus fréquentes.

Je fais les tests avec un ping continu vers un NAS en DSM 6. C'est un mauvais test car le ping continu fonctionne même si un blocage a été activé. Il faut stopper le ping continu quelques secondes et le relancer pour constater le blocage. Conclusion : Une règle de blocage dans la section [Global] bloque bien le trafic. Finalement, fausse alerte (cf. ci-dessus). Ça restera malgré tout une bonne pratique.

Ça c'est pas bon @Dex, ça voudrait dire qu'un paquet de NAS ont été infectés 😕 Apparemment ça concernerait les NAS sous DSM 6. Tu peux m'envoyer la liste de tes IP bloquées en MP, je vais identifier les appareils concernés et faire un retour à Synology (sans les IP évidemment). Ca fait longtemps que DSM 6 n'a pas reçu de mise à jour de sécurité. Le plus probable est qu'une faille ait été exploitée massivement.

Le CPL peut être une alternative. Synology n'a plus à maintenir les pilotes pour différents appareils USB (chronophage). L'analyse de périphérique* a également dû peser dans cette décision (trop peu de clients utilisent leur NAS en Wi-Fi). * Dans Panneau de configuration > Icône Centre d'infos > Onglet Analyse du périphérique > Case à cocher Activer l'envoi de l'analyse du périphérique.

Suite à un test, je m'auto-réponds : Une règle "Refuser tout" dans la section [Globale] bloque bien le trafic et les règles d'interface ne sont pas évaluées dans ce cas précis ne bloque pas le trafic et les règles d'interface sont bien évaluées. À partir de là je ne sais pas ce qui laissait passer le trafic chez @Geoff1330. edit : Ça m'apprendra à faire la moitié des tests 😅 Protocole de test : Ajouter une règle globale qui autorise tout accès depuis votre adresse IP locale unqiuement. Ajouter en-dessous une règle qui bloque tout. Dans la section [LAN], cocher "Si aucune règle n'est remplie : Autoriser l'accès". Valider les paramètres de pare-feu. Accéder au NAS depuis une autre machine (adresse IP différente), ça fonctionne malgré la règle de blocage de la section [Global]. Conclusion : Il est urgent de mettre à jour le tutoriel sur la sécurité pour préciser qu'il faut cocher "Si aucune règle n'est remplie : Refuser l'accès" dans chaque section d'interface ("Autoriser l'accès" par défaut). Tu peux t'en charger @Einsteinium ou seul @Fenrir peut éditer le tutoriel ?

Donc ça serait quoi la conclusion ? Qu'une règle "Refuser tout" dans la section [Global] ne servirait à rien ? Je n'ai pas testé, mais si c'est bien le cas, il va devenir urgent de mettre à jour le tutoriel sur la sécurité 😕 Ce n'est pas décrit de manière explicite dans l'aide de Synology : Au passage, ta règle manuelle "Refuser tout" dans la section [LAN 1] est inutile si tu as cocher "Refuser l'accès" par défaut (en bas de la fenêtre).

À mon avis, il ne s'agit pas d'un blocage volontaire de ces ports mais plutôt d'une limitation de l'architecture réseau (partage de ports ou plus probable, CG-NAT).

Ok, donc ce n'est pas un client VPN (on va y arriver...).

Il y a donc un client OpenVPN configuré sur ton NAS ?

Peu importe, pour le moment il faut stopper les tentatives d'intrusion. Ton accès sera autorisé puisque tu te connectes depuis la Belgique (je suppose), donc tu peux bloquer par défaut dans la section LAN. D'après ce constat, le pare-feu est clairement mal configuré : 220.133.114.62 : 🇹🇼 Taïwan 185.49.168.31 : 🇪🇸 Espagne 81.201.58.86 : 🇨🇿 République Tchèque 124.148.176.86 : 🇦🇺 Australie 83.52.56.69 : 🇪🇸 Espagne Est-ce que cette bouse de QuickConnect est activé ?

Évidemment... Normalement ça n'a pas d'incidence si une règle de blocage totale est présente dans la section globale, mais dans le doute...

Si, en bas de la fenêtre : Si aucune règle n'est remplie :

Le tutoriel sur la sécurité date et aurait besoin d'une mise à jour, mais le principal y est. Utiliser des règles dans la partie globale a une incidence sur la sécurité des connexions VPN (d'autres clients du même service VPN peuvent avoir accès au NAS), c'est pour ça que je déconseille son utilisation. Quelle est l'action par défaut pour l'interface LAN ? (à sélectionner dans la liste en haut à droite) Est-ce qu'un client VPN est configuré sur le NAS ? Est-ce que le NAS a une adresse IPv6 publique attribuée ? (autre que fe80::/10) Quel le type des adresses IP signalées ? (IPv4, IPv6) @Geoff1330 Tu autorises tout un pays (la Belgique) à accéder à ton NAS (ce que je ne recommanderais pas non plus). Les adresses signalées sont peut-être également originaires de Belgique. Tu aurais un échantillon des adresses IP bloquées que je fasse quelques vérifications ?

Vos pare-feux sont mal configurés, je ne peux que vous recommander de lire ce tutoriel : Je déconseille fortement de créer des règles dans la section [Toutes les interfaces] (liste déroulante en haut à droite), mais plutôt de les créer pour chaque interface utilisée. Il est inutile de créer des règles de blocage, il est plus efficace d'identifier les sources auxquelles vous voulez autoriser les accès et de créer les règles associées.

Ça m'apprendra à ne pas regarder où est posté un sujet. Par défaut, SRM utilise les ports tcp/8000 et tcp/8001. Tu l'as probablement modifié : https://kb.synology.com/fr-fr/SRM/help/SRM/ControlPanel/system_srm?version=1_3#t1 Sinon, un autre service du routeur utiliserait ce port ? (un paquet ?)

🤓

Il n'y a rien de plus que les options de l'éditeur. Au pire tu peux utiliser un bloc de code et faire un tableau en ASCII 🤖

Concernant le support sur navigateur, ça va bouger côté Chromium à partir de la version 107 (Chrome, Edge, Vivaldi, Opera, ...) : https://caniuse.com/hevc Je ne sais pas si Microsoft Edge (utilisant également Chromium) nécessitera toujours l'extension HEVC payante du Windows Store : https://www.microsoft.com/store/productId/9NMZLZ57R3T7

C'est indiqué dans les notes de version de DSM 7.0-41890 : https://www.synology.com/fr-fr/releaseNote/DSM?model=DS414

Windows XP ne supporte que la version 1.0 de SMB, vérifie la version minimale configurée : https://kb.synology.com/fr-fr/DSM/help/DSM/AdminCenter/file_winmacnfs_win?version=7#b_31