CoolRaoul

Je pense que c'est l'explorer Windows qui ouvre les .zip qu'il rencontre dans les dossier qu'il parcours. Une piste ici: http://www.sevenforums.com/tutorials/13619-zip-folders-enable-disable-windows-explorer-view.html (ça peut aussi être l'antivirus windows)

La dépendance au mkvmerge d'Optware ne risque-elle pas peut être problématique sur le long terme? Le projet me semble en voie d'abandon (cf ici), on ne note quasiment plus d'évolution dans le repository depuis 2010 En outre, de plus en plus de modèles de Syno ne sont pas supportés.

Non, cela ne concerne que la sauvegarde de *configuration*, pas les fichiers (pouquoi donc est-ce indiqué en chinois sur ton screenshot? tu aurais percuté sinon) Exemple en V5 (au look pres c'est pareil qu'en V4): Cela ne permet que de conserver un exemplaire de la dernière version d'un fichier *effacé*. Par contre la sauvegarde d'un fichier *modifié* écrasera sa version sauvegardée précédente

Ah ok, je comprend mieux. Mes filtres RSS ont tiltés a a cause des clés "Synlogy" et "Synlocker" présents dans l'article, et comme on m'attendais pour déjeuner je n'ai pas pris le temps d'approfondir. Désolé pour la fausse joie.

Ah ok alors, si il y a déjà des témoignages négatifs évidemment. Je croyais que c'était un nouveau service vu que la news venait juste d'être postée peu avant midi sur pcworld, ce qui m'a induit en erreur. **EDIT** En fait ca ne concerne meme pas le ransomware Syno, me suis fourvoyé! explications ici:

Scoop: Le ransomware CryptoLocker n'est plus une fatalité : un site Web pour connaître sa clé de déchiffrement sans payer

C'est ainsi que fonctionne le backup Syno, que ce soit en local ou de NAS à NAS, d'ou ma remarque. Pour conserver un historique nécessite faut soit utiliser un volume dédié en cible, soit utiliser Time Backup (dans les deux cas avec les problemes de volumétrie sur la cible lorsque tous les fichiers sources sont modifiés comme tu l'as fait remarquer) ***EDIT** Je viens de tomber sur cet article: Le ransomware CryptoLocker n'est plus une fatalité : un site Web pour connaître sa clé de déchiffrement sans payer Je sens qu'il y en a certains qui vont être soulagés!

Tu m’enlèves les mots du clavier: j'étais en train de composer peu ou prou la même réponse. Attention à la synchro ou au backups automatiques: pour peu que ce soit soient programmé assez fréquemment (ou pire en quasi temps réel) les données chiffrées se retrouveraient à l'identique sur le NAS de sauvegarde (même si ce dernier n'est pas touché directement).

Et pourquoi donc "surement pas"? Serait surprenant que Free supprime des les modèles plus récents des fonctionnalités existantes sur les précédents (C'est une V5 dans mon cas mais je viens de vérifier: c'est pareil sur V6.) Me semble que ce sont certaines box numericable qui ne savent pas faire ça.

Pas besoin de modifier le port sur le Syno quand on peut le faire sur la box dans la règle de redirection. Exemple sur une freebox:

Heureusement que la plupart des box savent faire la translation de port par elle mêmes, parce qu'avoir a mettre ce genre d'architecture avec deux subnets et un routeur intermédiaire juste pour ça, ça me gonflerait un peu.

Dans le cas donné en exemple (je cite: "Mon ip avait été utilisée pour hacker") il est bien question d'usurpation d'IP, pas d'utilisation de proxy pour masquer le pays d'origine.

Contrairement à une idée reçue, c'est non seulement loin d'être aussi facile qu'on pourrait penser, mais quasiment inexploitable dans la plupart des configurations. Et c'est Stéphane Bortzmeyer qui l'écrit: http://www.bortzmeyer.org/usurpation-adresse-ip.html

Oui, avec ce genre de règle en haut de la liste du firewall (modifier éventuellement le subnet 192.168.1.0 selon la config de la box): et aucune autre règle active en dessous. et enfin, terminer par: **EDIT** Cela dit si aucun port n'est redirigé dans la box, ça revient au même...

Il n'en est pas à son premier méfait ce chinois-la http://www.abuseipdb.com/report-history/61.144.43.235 (sans doute une IP dynamique, donc pas forcément toujours le même gus à la manœuvre)

Mais la ce ne sont pas des disques vierges inconnus pourtant: puisqu'ils n'ont pas été modifiés.

Je ne comprend pas bien la manip: apres l'étape 6 ne devrait-on pas se retrouver dans l'état initial de l'étape 1? Vu qu'on on remet des disques qui n'ont pas été modifiés, il va booter sur le DSM installé sur ces derniers

Peux-tu dire comment se met en place le second blocage?** **edit** c'est bon: trouvé

Bien sur: tout répertoire ajouté à "open_basedir" permet aux programmes php d'accéder à toute la hiérarchie sous-jacente (détails ici). Mais pourquoi ne pas simplement avoir testé?

Tu parles sans doute de ma phrase "les settings fait sous DSM sont conservés lors des reboot" je suppose? Tu conviendras que ce problème du wifi est quand même très spécifique. De plus ça ne doit pas courir les rues les personnes utilisant une interface wifi (clé ou intégré) sur le NAS comme interface principale (pour y rediriger les ports de la box). Si le support Synology n'est pas au courant, alors ce bug n'est pas près d'être corrigé, vu qu'il doit toucher bien peu de monde en plus.

Ah je comprend mieux, comme tu parlais de *firewall* j'ai bloqué la dessus. En effet, le blocage IP s'applique exclusivement aux connexions aux service DSM utilisant une authentification compte/mot de passe. Ca se comprend puisque ça se déclenche sur un nombre d'échecs de mot de passe. Voila pourquoi une connexion en mode "socket" tcp, ne peut pas faire l'objet de ce genre de mesures défensives. PS: note bien que ton filtre iptables, non seulement ne résistera pas à un reboot , mais qu'une simple modif de la config du firewall va aussi réinitialiser tous les filtres.

Ma réponse initiale ne portait pas sur le coté plus ou moins rapide ou automatique de la manip, je répondais juste à "Semblerai que le pare-feu des syno ne soit pas très efficace contre des attaques sur la couche tcp". Un autre avantage est que les settings fait sous DSM sont conservés lors des reboot.

"Tous les ports", pas "toutes les adresses":

Euh.. ce qu tu appelle "le pare-feu des syno" n'est pourtant en fait qu'une simple interface graphique à iptables. Devrait suffire de définir la règle avec l'option "ports:tous." Ensuite un simple "iptables -L" permet de constater que ça a bien été traduit par target prot opt source destination DROP all -- XXXXXXXXXX anywhere NB: Infos complémentaires sur l'IP source des attaques: http://www.abuseipdb.com/check/78.232.112.34

Moi non plus je ne connaissais pas du tout, j'ai pris le temps de potasser la doc et ça m'a pris un week-end de bidouille pour aboutir à une solution qui fonctionne et les jours suivants pour affiner la solution. De plus, je pense avoir tout fait pour que mon tuto soit suffisamment didactique. Au debut j'avais ajouté "work in progress" au titre du fil, mais ça fait un bout de temps que je l'ai supprimé. Je condisère la solution comme stable désormais