PiwiLAbruti

Quelle est/sera l'utilité des RT2600ac et RT6600ac ? (mise en place d'un tunnel VPN, mais encore ?)

Si tu sais pourquoi tu utilises un VPN, tu sais où il est le plus judicieux de le configurer.

Ces serveurs DNS doivent être ceux qui hébergent la zone de ton domaine, c'est pour ça que ça ne fonctionne pas. Le reste est très confus et mélange plusieurs notions qui n'ont pas grand chose à voir entre elles. Je n'ai rien compris à ce que tu essayes de faire.

Il n'y a pas beaucoup de monde qui va être concerné par cette mise à jour, mais j'en connais qui vont la forcer manuellement sans savoir pourquoi 😄 Source : https://www.synology.com/fr-fr/releaseNote/DSM#7_1

fc00::/7 est l'équivalent IPv6 de 10/8, 172.16/12 et 192.168/16, donc dédié aux réseaux privés non-routables sur internet. C'est un préfixe que tu ne rencontreras probablement jamais étant donné qu'il est utilisé dans des configurations professionnelles/spécifiques. Tu peux donc retirer la règle qui l'utilise. Pour information fe80::/10 est l'équivalent de 169.254/16 (adresses automatiques non routable).

Les trois réseaux utilisés dans les règles de pare-feu sont des réseaux privés pouvant correspondre aux usages indiqués par @Jeff777. https://fr.wikipedia.org/wiki/Réseau_privé En France, l'écrasante majorité des réseaux locaux configurés par défaut sur les box des opérateurs sont 192.168.0.0/24 ou 192.168.1.0/24, ils appartiennent donc à 192.168.0.0/16 (qu'on pourrait même réduire à 192.168.0.0/23). Tu pourrais finalement désactiver les deux autres règles comportant les réseaux 10.0.0.0/8 et 172.16.0.0/12. Si tu veux approfondir le sujet des adresse IPv4 : https://fr.wikipedia.org/wiki/Adresse_IP Ce tutoriel commence à dater et ne tient pas compte d'IPv6 alors qu'il est utilisé chez tous les opérateurs et est bien moins prise de tête qu'IPv4. Tu pourrais ajouter une règle autorisant le réseau fe80::/10 (réseau privé IPv6).

Même avec un compte ayant les droits administrateur ? Au pire tu dois pouvoir en modifier les droits d'accès dans Panneau de configuration > Dossier partagé. https://kb.synology.com/fr-fr/DSM/tutorial/Why_are_there_sysvol_netlogn_folders ---- Edit Avec les droits administrateur ça fonctionne : https://community.synology.com/enu/forum/1/post/144184

De quel SMTP parles-tu ? Le port SMTP tcp/587 doit être restreints aux clients. Le port SMTP tcp/25 doit être ouvert aux MTA.

Du moment que tu as conscience que ton NAS est trop exposé sur internet et des risques encourus, c'est le principal.

La version indiquée est inférieure à celle du .pat que tu veux installer ?

Synology ne propose pas de solution pour ce cas d'usage, et c'est bien dommage. Mais ce n'est pas forcément un problème si le pare-feu est correctement configuré (secondé par un profil d'accès si nécessité de restreindre encore plus certains services). Quelle est la surface d'exposition du proxy inversé sur internet ?

Au risque de me répéter :

Que dit Synology Assistant sur l'état du NAS ?

@Brunchto, est-ce que seul le port tcp/25 est ouvert sans limitation ? Les ports client (tcp/587 et tcp/993) doivent être restreints dans le pare-feu.

Seul Synology a la réponse, tu peux leur demander ici : https://www.synology.com/fr-fr/form/inquiry/feature

C'est vraiment n'importe quoi leurs box chez Orange. Je comprends pourquoi un collègue les a laissées dans leur carton 😄

Il faut utiliser localhost comme hôte local dans la configuration du reverse proxy, et définir une liste blanche dans le blocage automatique des IP.

Pour ceux qui ont à disposition un switch capable de faire du miroir de port, il est possible de capturer la requête DHCP du boitier TV et la réponse DHCP de la Livebox. On pourrait facilement y voir les options spécifiques qu'il faudrait ajouter à un serveur DHCP tiers pour que ça fonctionne.

Pour être exact, les attaques existent toujours. C'est juste que le pare-feu les bloque avant qu'elles puissent atteindre le moindre service du NAS.

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.