Aller au contenu

CoolRaoul

Membres
  • Compteur de contenus

    5940
  • Inscription

  • Dernière visite

  • Jours gagnés

    61

Tout ce qui a été posté par CoolRaoul

  1. CoolRaoul

    Synolocker

    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).
  2. CoolRaoul

    Synolocker

    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.
  3. CoolRaoul

    Synolocker

    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:
  4. CoolRaoul

    Synolocker

    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.
  5. CoolRaoul

    Synolocker

    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.
  6. CoolRaoul

    Synolocker

    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
  7. CoolRaoul

    Synolocker

    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...
  8. CoolRaoul

    Synolocker

    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)
  9. Mais la ce ne sont pas des disques vierges inconnus pourtant: puisqu'ils n'ont pas été modifiés.
  10. 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
  11. CoolRaoul

    Synolocker

    Peux-tu dire comment se met en place le second blocage?** **edit** c'est bon: trouvé
  12. 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é?
  13. 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.
  14. 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.
  15. 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.
  16. "Tous les ports", pas "toutes les adresses":
  17. 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
  18. 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
  19. Je te conseille de passer a nginx, ce que j'ai fait, voir mon tuto:
  20. Oh! je serai très intéresse par le détail ce cette partie de l'opération (*) Apres avoir résolu le problème principal faudra nous faire un tuto détaillé sur cette procédure et les résultats obtenus. Par construction, tous les comptes sont membres du groupe "users", ce comportement est normal. Tu as sans doute du configurer les droits des partages à problèmes, en utilisant l'option "pas d’accès" sur ce groupe. C'est une approche que je déconseille. Mieux vaut utiliser uniquement les colonnes "lecture/écriture" ou "lecture seule" selon le cas. Par suite tous les utilisateur non membres d'un des groupes autorisés se verra de fait refuser l’accès. Inutile de passer en plus par l'option "pas d'acces"
  21. CoolRaoul

    Synology

    Le non support du DTS date de l'année dernière, DSM 4.3:
  22. C'est bien aussi ce que je déduis, mais ma question portait sur l'avantage de mettre le SYNO en DHCP plutôt qu'en IP Fixe même quand on utilise pas le serveur DHCP du NAS. Me semblait avoir lu dans le forum des conseils contradictoires sur ce point.
  23. Tu pourras donner des détails sur ce point? C'est cette config que j'utilise (mais faut dire qu'utilisant mon NAS comme serveur DHCP je suis bien obligé aussi)
  24. Pour commencer, peut-être abandonner le bail statique et configurer directement le NAS en IP LAN Fixe
  25. Sans aller jusqu'à engueuler, comment peut-on être géné par l'existence d'une fonction de DSM sous prétexte qu'on ne l'utilise pas? Ça me fait penser à la polémique lors de la sortie de DSM5 sur la présence des fonctionnalités de connexion aux réseaux sociaux, d'aucuns allant même jusqu'à menacer de passer à la concurrence à cause de ça. De plus, on croirait lire ("quand on veut un Nas minimum ...") que les NAS devraient être réservés aux happy fews qui savent ouvrir un port sur son routeur! Et pourquoi pas un examen de passage pour les débutants, ou un permis de conduire un NAS alors? Faut savoir raison garder: je reconnais que cette fonction est franchement limitée que le fonctionnement de son mode UPNP est un peu flou; mais bof, après tout, sa présence n'a aucun impact négatif sur le syno que ce soit en terme de perfs ou de fonctionnalités. Alors... Voila pourquoi je rejoint ceux qui considèrent qu'il manque une réponse au sondage (auquel je n'ai pas répondu pour cette raison): "Non - je ne me suis pas servi de cette fonction, mais ça présence ne me dérange pas"
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.