Hexagone

Si tu viens de mettre à jour c'est normal. Laisse faire ça devrait se tasser... Bon sinon, c'est quoi ce délire de devoir toucher au fichier PHP pour changer la langue ? Où ont-ils la tête chez Syno ?... et là on ne parle plus de version béta... @chickenbox Je ne sais pas si la casse de "VideoStation" a changé dans le chemin, entre la béta et la version finale mais à mon avis il serait judicieux de corriger ton premier post (si faisable) indiquant la manip à faire pour changer la langue de recherche car je pense qu'il y en a plus d'un qui va se faire avoir... ^^ Donc, je reprécise ici quand même le chemin correct : /volume1/@appstore/VideoStation/plugins/syno_themoviedb/search.php[/CODE] Personnellement, j'ai aussi changé le fichier [b]INFO[/b] qui se trouve à côté, dans lequel j'ai modifié la ligne [b]"language": ["fre"][/b] Par contre j'ai aucune idée de l'impact que ça peut avoir et si ça en a vraiment... A ce sujet, il a un tutoriel en fait et une discussion

Je ne me suis pas encore lancé dans l'opération, j'attends de trouver un peu de temps pour m'y mettre tranquillement. Entre temps, par contre, j'ai réfléchi et je me dis qu'il n'y a pas forcément besoin de passer par un port intermédiaire... Sinon, as-tu une explication sur tes problèmes de lenteur et l'impossibilité d'uploader ? Pour cette dernière, à première vue c'est parce qu'il manque une règle quelque part...

@CricX : Effectivement, je ne me doutais pas pouvoir faire cela de cette manière. Merci. Donc, j'imagine comment procéder : Je configure ma box pour quelle redirige le port 443 vers un port 5551 par exemple. Sur le NAS, je configure un reverse proxy pour qu'il écoute le port 5551. Si le proxy reçoit une requête ne comportant pas le chemin attendu (et inconnu du grand publique) alors la requête est envoyée vers le néant. Et je configure également ce proxy pour qu'une requête comportant le chemin attendu pointe sur l'URL classique sur le DSM avec le port 5001. Voilà comment je vois les choses. Je ne dis pas de bêtise ? Je vais me pencher sur le sujet. Merci

@marcien : Disons que dans l'absolut c'est faisable mais ce n'est sans doute pas souhaitable ou pas simple dans le cas présent. Par contre, je pensais qu'il serait plus simple de supprimer la redirection et customiser le chemin racine. Donc, ne pas renvoyer https://ip_box_ou_domain_name:5001/ vers https://ip_box_ou_domain_name:5001/webman/index.cgi et de fait remplacer webman par un nom improbable. Ca me paraît plus simple mais peut-être pas très viable, si jamais il y a des URL codées en dur dans les cgi... J'essaierai de modifier les fichiers Apache mais à la limite si quelqu'un a déjà tenté et qu'il sait que ce n'est pas viable, qu'il ne se prive pas de le dire .

Merci marcien pour ces infos. Effectivement, je n'avais pas franchement idée de rajouter des règles dans le pare-feu, surtout les plages IP que tu indiques. Par contre, le fait de ne permettre l'affichage de la page de login (en HTTPS) que lorsque l'url contient un paramètre particulier (inconnu du grand public), ça ne semble pas une idée intéressante selon vous ?

Merci pour vos réponses. Par contre, je ne suis pas naïf, je cherche à savoir ce qui se pratique et ce qui pourrait me permettre d'avoir l'esprit un peu plus tranquille. Ma politique de mot de passe est assez poussée mais on n'est jamais à l'abri d'une faille qui ne se base pas sur les tentatives de connexion de manière classique. Donc, l'idée est simplement de masquer tout ce qui pourrait donner des indications sur la nature du serveur qui se trouve au bout d'une IP, à quiconque n'est pas censé faire de visite à celle-ci. Voilà, donc si certains ont de bonnes idées, je suis tout ouïe.

Bonjour, J'aimerais savoir si certains d'entre vous auraient par hasard quelques astuces pour tromper la plupart des tentatives de connexion au DSM et autres accès aux services du NAS. Je ne suis pas novice en matière d'administration de serveur web mais je suis quand même assez loin d'être un expert, d'autant plus que ce n'est pas mon domaine de prédilection. Donc, j'aimerais, pour me rassurer avant tout, éviter de constater les nombreuses tentatives de connexions quotidiennes. Avant de mettre en route mon NAS fraichement acquis, je n'avais pas idée du nombre de tentatives belliqueuses que l'on pouvait recevoir en une journée seulement. C'est en voyant que j'obtenais pas moins de 10 tentatives/jour en moyenne que j'ai rapidement décidé de faire quelques changements dans ma configuration. Donc, ayant quelques notions en matière de sécurité informatique, j'ai pris le parti de ne pas utiliser les ports standard pour le HTTP et pour le reste. Cette solution semble relativement efficace puisque les tentatives se sont réduites à 1 seule sur plusieurs jours. Mais bon, vu les ports que j'utilise, inutile de préciser que cela a dû nécessiter un scan de ports préalable... Bref ! Je n'avais plus franchement mis le nez dans ce genre de problématique depuis des années et je me rends compte que ça s'est bien accentué mais bon, rien de très étonnant finalement. C'est pourquoi, sachant que pour retarder l'effraction, une fois les recommandations standards appliquées, il faut s'attacher à brouiller les pistes, j'ai donc entamé quelques recherches dans ce domaine. Tout d'abord, je viens de modifier la page 404 de façon à ne plus faire apparaître Synology dedans. Ben oui ! Pourquoi ne pas fournir l'ensemble des caractéristiques du NAS aussi tant qu'on y est. Ma page 404 est à présent une page parfaitement laconique, qui n'indique que le principal "Erreur 404". Bon, en réalité c'est moyennement efficace puisque j'ai mis un accès via HTTPS uniquement et que le certificat par défaut mentionne Synology... Je n'ai pas encore pris de certificat SSL car je n'ai pas de nom de domaine qui m'appartienne (pour le moment), je me contente du reverse DNS de Free puisque c'est mon fournisseur. Il n'a pas été simple de configurer tous les services web en HTTPS, tout en faisant en sorte que le NAS reste accessible de l'extérieur. Et mon problème à présent, c'est que je vais devoir faire un peu machine arrière, notamment pour remettre le port HTTPS standard (443) sur ma configuration de Freebox. Avec un port non standard, il n'est pas toujours possible, depuis l'extérieur, d'accéder à un serveur web, FTP ou autre, selon le réseau à partir duquel on tente de se connecter. C'est notamment le cas dans l'entreprise où je travaille puisque je ne peux pas accéder à mon NAS personnel étant donné que la politique de sécurité du réseau empêche les requêtes sortantes sur des ports non conventionnels. Du coup, c'est un peu dommage. Donc, voilà ma problématique pour le moment est de repasser sur des ports standards mais en faisant en sorte que la page de login ne soit plus accessible de façon automatique. J'ai notamment pensé à faire en sorte que pour l'obtenir, il faudrait fournir un paramètre tout à fait spécifique dans l'url, pour que celle-ci veuille bien s'afficher. Cela nécessiterait de modifier le fonctionnement par défaut de l'accès au DSM et autres services et donc, je me demandais si c'était faisable et de quelle manière précisément ? Quelqu'un saurait-il me dire ce qu'il en pense, voire de m'indiquer d'autres techniques plus appropriées ? Merci d'avance pour vos suggestions.

Bonjour, Etant donné que cette discussion n'est pas récente et qu'elle n'est a priori plus trop exploitable en l'état, voici ma solution sur une version DSM 4.0 avec un DS212j : Editer le fichier /usr/syno/apache/conf/httpd.conf-sys Modifier la ligne existante qui concerne l'erreur 404 en pointant sur le fichier d'erreur, par exemple missing.html #ErrorDocument 404 /error.cgi?status=404 ErrorDocument 404 /missing.html Faire en sorte d'avoir le fichier missing.html dans le répertoire /usr/syno/synoman en lui donnant les droits suffisants. Redémarrer Apache. Personnellement, j'ai utilisé cette commande : /usr/syno/etc/rc.d/S97apache-sys.sh restart[/code] Voilà.