PiwiLAbruti

Fais une demande d'amélioration à Synology. Au-delà du DHCP, il faut fait également un serveur TFTP absent de SRM.

Surtout quand on voit les notes de mise à jour de cette Update 2, avec les 28 bugs DSM et 6 vulnérabilités résolues, ça peut pousser à vouloir installer rapidement cette mise à jour. Mais il faut bien garder à l'esprit que ces bugs et vulnérabilités sont là depuis longtemps, donc l'urgence est très relative. Concernant les vulnérabilités, avec un NAS déjà bien sécurisé et peu exposé, ça limite énormément les possibilités de compromission. Donc il n'y a pas de raison d'être un asthmatique des mises à jour. Au risque de radoter, évitez au maximum les mises à jour manuelles chez Synology. Il y a eu trop de loupés dernièrement pour avoir confiance.

La mise à jour est proposée automatiquement, elle a été installée avec succès sur mon kamikaze de DS109. Magie Synology oblige, je vais patienter au moins jusqu'à la fin du mois avant de mettre à jour les autres.

Il y a un mot pour ça : amateurisme.

@oracle7 : Ouvre un ticket auprès du support Synology et poste leur réponse ici qu'on rigole un peu. L'explication, seule Synology te la donnera. Mais il est fort à parier que DSM voit la même version que celle déjà installée et refuse donc de l'installer une deuxième fois. Pour que la mise à jour fonctionne, il aurait fallu que Synology incrémente le numéro de build (6.2.4.25556 Update 2) et/ou le numéro d'update (6.2.4.25556 Update 2). Bref, s'il fallait encore démontrer qu'il ne faut pas se précipiter sur les mises à jour de Synology, en voici une preuve de plus.

Je ne vois pas ce qu'il y a de compliqué à configurer. Et même sans y penser, il suffit de laisser un accès VPN actif pour faire la modification à distance si nécessaire.

Il est contre-productif de faire de l'exclusion géographique (ça n'a même aucun sens). Il est beaucoup plus efficace de n'ouvrir que pour le pays de résidence et d'autres pays dans lesquels on se rend régulièrement. En sécurité on ne commence à faire de l'exclusion (liste noire) que lorsqu'il n'est pas possible de passer par une inclusion (liste blanche). ⬆️ Grillé par @MilesTEG1 Mon serveur reçoit bien les mails de n'importe quel expéditeur (heureusement, c'est un peu le but), il faut pour cela n'ouvrir que le port SMTP tcp/25 (communications entre les MTA) au monde entier. Toutes les tentatives de connexions authentifiées (même avec des identifiants valides) sur ce port se solderont par un échec (considéré comme SMTP relay). On peut voir toutes ces tentatives dans MailPlus Server > Audit en cours > Journal de sécurité. Les ports IMAP tcp/993 et SMTP tcp/587 ne servent que pour les clients mail (MUA), d'où leur restriction au strict minimum.

Bien sûr que c'est de l'entrant, et c'est bien parce que c'est une usine à gaz que ce service n'est que très peu ciblé par les détections (ISAKMP sur udp/500). Je n'utilise que du L2TP/IPSec car c'est natif sur la grande majorité des systèmes et donc peu contraignant à configurer et à utiliser. La limitation géographique diminue drastiquement les tentatives de connexion. Je vais même bien plus loin que ça en n'autorisant que certaines plages IP des opérateurs que j'utilise. Par exemple, les services mail client (IMAP sur tcp/993 et SMTP sur tcp/587) ne sont accessibles que depuis le réseau 37.160/12 (Free Mobile). Je n'ai jamais vu une seule détection provenant de ce réseau. Je n'essaye pas de te convaincre que c'est la meilleure façon de sécuriser des accès. Ce que je décris là arrive bien après l'utilisation de mots de passe forts à durée de vie limitée et du blocage automatique des échecs de connexion. Et la notion de sécurité devient complètement subjective à partir d'un certain seuil qu'on a tous les deux atteint 😉

Oui car le trafic est uniquement bloqué dans le sens entrant. Pour ce qui est d'ouvrir des accès lorsqu'on se trouve à l'étranger, le VPN est une bonne solution. Ça permet de faire les réglages nécessaires de n'importe où si besoin. C'est d'ailleurs le seul service totalement ouvert chez moi avec SMTP (tcp/25).

Il y a une tout de même une différence entre du trafic indésirable bloqué en amont (avec un pare-feu par exemple) et ce même trafic bloqué en aval après avoir atteint les services concernés. De plus, si le service devient vulnérable (faille de sécurité, vulnérabilité, ...), il sera beaucoup moins sensible à la compromission qu'un service totalement exposé. Bref, c'est un peu la base en sécurité.

Quand je vois les logs de @bliz, il y a quand même un minimum à assurer avec une limitation géographique. 187.188.201.104 > Mexique Limitez au moins les accès au(x) pays strictement nécessaire(s), ça élimine déjà plus de 99% des tentatives.

En théorie, c'est que rien n'a été modifié par rapport à la version précédente 🤓 (dans le cadre d'une RC ça peut avoir du sens, mais là...). Dans la pratique, la magie Synology a encore frappé 🪄🎩🐰 Je n'avais pas installé l'update 2 et elle n'est pas encore proposée, peut-être en prévision d'un deuxième retrait 😇

Si tu ne sais pas ce que DSM 7 va t'apporter et que DSM 6 convient à ton utilisation actuelle, c'est qu'il n'y a pas besoin de changer quoi que ce soit. DSM 6 étant encore maintenu, tu pourras migrer au plus tard lorsque Synology annoncera la fin de son support. Après je ne vois rien de bloquant dans ton utilisation, à part la gestion des photos si tu utilises la géolocalisation (absente de Synology Photo).

L'encodage du message est nécessaire avec la méthode GET mais pas avec POST. C'est d'ailleurs indiqué dans l'espace client Free Mobile :

Merci pour les explications @jacaj, ton avatar prend maintenant tout son sens 😉 La différence se voit surtout sur la baisse d'intensité lié à l'augmentation de la valeur de la résistance. Une résistance de 100Ω donne un courant de 33mA (plutôt conséquent pour ce type de matériel), là où une autre de 470Ω donne 7mA (déjà plus raisonnable en terme de durabilité).

Je suppose que tu as créé un nouveau fournisseur dans Panneau de configuration > Notification > Ajouter un fournisseur de service SMS ? URL SMS : https://smsapi.free-mobile.fr/sendmsg?user=&pass=&pn=&msg=Hello+world Méthode HTTP : GET Aucune en-tête HTTP Catégorie des paramètres : user : Nom d'utilisateur pass : Mot de passe pn : Numéro de téléphone msg : Contenu du message Ensuite, il suffit de sélectionner dans la liste le fournisseur nouvellement créé, et de renseigner l'identifiant composé uniquement de chiffres dans Nom d'utilisateur, la clé API dans Mot de passe, et ton numéro [+] [33] [06...] ou [07...] dans Numéro de téléphone principal.

Je vous incite à vous inscrire à ce webinar pour manifester votre mécontentement concernant les régressions de Synology Photos : https://event.synology.com/fr-fr/SPOT_webinar Ça mettra un peu d'ambiance 🥳

D'après toi, comment fait l'écrasante majorité des clients Synology qui n'utilisent que les mises à jour automatiques et qui ne savent même pas que cette version de DSM existe ?

As-tu contacté le support Synology ?

@oracle7 à raison, le réseau 192.168.2/24 n'est pas visible par là Livebox car il est NATé par le RT. La Livebox ne voit donc que l'adresse WAN du RT.

Je crains que oui, à voir avec un autre client Orange qui aurait le même souci. À une époque maintenant révolue, Orange s'était même réservé l'exclusivité du port udp/1701 pour le partage Wi-Fi, donc impossible de monter un VPN L2TP/IPSec standard. D'un point de vue qualité de connexion, Orange est certainement n°1 en France. D'un point de vue box ils sont bons derniers (je les placerais peut-être même derrière SFR, c'est dire... 😅).

Si on considère certaines situations comme un changement de FAI, il est plus judicieux de le laisser sur le NAS. Par contre il peut être utile d'en créer un deuxième chez OVH, dédié à la box pour l'accès à l'interface de gestion à distance (par exemple). C'est aussi une raison tout à fait valable et justifiée 😂 D'après ce qui est indiqué par Orange, oui (c'est d'ailleurs inadmissible de la part d'un FAI, surtout quand on fait la taille d'Orange).

Non, le fait qu'un bail statique soit défini sur l'un ou l'autre ou les deux serveurs DHCP ne constitue pas une priorité.

Sans VLAN, ton réseau dispose de deux serveurs DHCP qui ne distribuent pas les adresses sur un même réseau. L'attribution dépend de la vitesse à laquelle les serveurs DHCP répondent (et éventuellement du client DHCP qui peut conserver les informations du dernier serveur qui lui a répondu, je détaillerai si besoin). Dans ton cas, la Livebox semble plus rapide que le routeur Synology puisque le décodeur Orange récupère visiblement le bon adressage. Mais ce ne sera pas forcément toujours le cas. Si le décodeur Orange TV reçoit la réponse du routeur Synology avant celle de la Livebox, il aura une adresse en 192.168.10/24 et ne communiquera plus avec la Livebox. Plus inquiétant, les machines derrière ton routeur sont susceptibles d'être adressées par la Livebox en 192.168.0/24 et ne bénéficieront plus de la sécurité du routeur Synology. Avec des VLAN, on a l'assurance qu'un seul serveur DHCP répond aux clients.

Pour compléter un peu le sujet, voici la réponse officielle de Chromium : https://bugs.chromium.org/p/chromium/issues/detail?id=684382#c1