Asustor Filtrage par fichier HOSTS

Hello

Tu auras peut-être noté que, selon ton conseil, j'avais pris patience et contribué à plusieurs sujets dans cette partie du forum. Bien sûr, le temps passant sans aucune avancée sur les deux fils que j'avais ouverts à propos des problèmes de respect de la vie privée par le NAS, je me suis de nouveau désengagé par lassitude. Je crois malheureusement que tu as raison, il est temps que j'aille faire autre chose, ce sera plus gratifiant pour moi.

J'avais noté !
j'espere juste que malgré ton mécontentement, tu nous resteras fidele et present dans le partage de tes connaissances qui sont, je suis certain, très utiles pour les forumeurs!!!

C'est très décevant et quand il sera temps d'en changer, je ne me ferai pas piéger une troisième fois. D'ici là, je vais informer mes réseaux, et dieu sait qu'il sont vastes après 40 ans d'activité dans une industrie de haute technologie ...
Tu es libre de faire comme bon te semble, et heureusement d'ailleurs ! :lol:

Je souhaite bonne continuation à tous ceux qui sont de bonne volonté.
Passez de joyeuses fêtes

Bon réveillon également de ton coté. :)

Byz
 
Bonjour,
Rappel : le NAS écrase régulièrement s'il est en DHCP et systématiquement au redémarrage le précieux fichier /etc/hosts, ce qui ne permet donc pas de l'utiliser pour protéger le NAS et l'utilisateur contre des URLs malveillants. J'avais ouvert ce sujet il y a plus de 5 mois ...
Dami1 a dit:
Pulsar33 a dit:
- D'informer la technique que ce fonctionnement est non seulement exotique mais préjudiciable à la bonne utilisation du NAS (pour les raisons exposées plus haut)
- De proposer à la technique de ne modifier que la ligne concernée dans le fichier hosts dans les cas où celle-ci doit l'être
- De proposer à la technique de rendre le fichier hosts de sécurité résistant au redémarrage (il existe déjà des scripts permettant cela dans le NAS)

Dans l'attente d'une prise en compte dans ADM de cette évolution, je suggère à la marque :
- De fournir le script qu'il faut rajouter (sans doute dans /usr/builtin/etc/init.d) pour rendre le fichier hosts de sécurité persistant au redémarrage
- A défaut, d'indiquer comment ajouter une tâche root à la crontab pour limiter le temps pendant lequel le NAS est vulnérable

J'ai remonté tes suggestions à l'équipe.

Est-ce que la technique a des réponses à fournir ?
Cordialement
Pulsar33
 
webmail a dit:
je me permet d'intervenir : le support doit traiter en priorité les cas étant dans les conditions d'utilisations normale du produit.
Pour les cas un peu différent je ne pense pas qu'ils aient des obligations de résultat, donc il est normal que ça ne soit pas traité prioritairement

Pas traité prioritairement ?
T'as raison ... :rolleyes:
Pulsar33
 
Bonjour,
Pulsar33 a dit:
Pas traité prioritairement ?
T'as raison ... :rolleyes:
Pulsar33

Peut-être dans un premier temps devriez vous regarder si des solutions simples de contournement ne peuvent vous suffire ??? (la question ayant été abordée (bien sur pas dans les mêmes termes) sur le forum Asustor)
par exemple, utiliser un init script qui se lancera juste après les scripts de base de Asustor ? donc avant des applications (y compris asportal)
cela est documenté, il suffit de placer un script dans /usr/local/etc/init.d avec un Sxx (S pour Start) xx très bas pour démarrer en premier (l'ordre de démarrage dépend de cette valeur sur 2 caractères en mode ascendant)
Vous n'aurez qu'a y écraser le fichier host avec le votre (attention les shell doivent tenir compte que les chemins vers les exécutables ne sont pas obligatoirement connus, il faut donc préférer les chemins complets)
Si vous y associez un cron qui vérifiera si un nouveau ficher host existe (toute les heures, demi, etc.) vous pourrez même faire des mise à jour en modifiant simplement le host origine (le votre) et pas le host réel ... (ceci par exemple si vous avez un outil de surveillance qui vient ajouter des entrées sans intervention humaines) .

Ceci devrait même suffire pour d’éventuels malware installés, car cela est tôt dans le boot, en considérant qu'il est difficile (quoique) de toucher à l'A.D.M. de base.

Suivant votre besoin réel, d'autres solutions peuvent être envisagées, désolé, mais je n'ai pas lu tous les messages de ce fil de discussion.

Fred.
 
Bonjour,

Merci pour cette réponse fred.lacrima :)
C'est justement ce que j'attends depuis des mois : que Asustor indique la procédure à mettre en œuvre pour contourner le problème et fournisse le script qui va bien :

Dans l'attente d'une prise en compte dans ADM de cette évolution, je suggère à la marque :
- De fournir le script qu'il faut rajouter (sans doute dans /usr/builtin/etc/init.d) pour rendre le fichier hosts de sécurité persistant au redémarrage
- A défaut, d'indiquer comment ajouter une tâche root à la crontab pour limiter le temps pendant lequel le NAS est vulnérable

Mais visiblement, ils en sont incapables ... ou alors c'est de la mauvaise volonté ...
Cordialement
Pulsar33
 
Bonjour,
Pulsar33 a dit:
Bonjour,
C'est justement ce que j'attends depuis des mois : que Asustor indique la procédure à mettre en œuvre pour contourner le problème et fournisse le script qui va bien :

Dans l'attente d'une prise en compte dans ADM de cette évolution, je suggère à la marque :
- De fournir le script qu'il faut rajouter (sans doute dans /usr/builtin/etc/init.d) pour rendre le fichier hosts de sécurité persistant au redémarrage
- A défaut, d'indiquer comment ajouter une tâche root à la crontab pour limiter le temps pendant lequel le NAS est vulnérable

Mais visiblement, ils en sont incapables ... ou alors c'est de la mauvaise volonté ...
Cordialement
Pulsar33

Peut-être est-ce simplement un problème de planning et de priorité (sachant qu'un script personnel dans la partie "utilisateur" couvre un gros pourcentage des besoins :rolleyes: )
Mais, bien sur, vous avez raison de l'espérer au niveau "premier" du lancement du système, même si à mon avis la surveillance (par inotify par ex.) APRES le boot est un besoin en terme de sécurité.
Le problème, parfois, est que le support passe au développeurs qui pensent uniquement en "répondre à la demande" est pas en terme générique "comment donner la main à un script utilisateur tôt dans le boot" .
Par contre la réponse via cron pourrait être plus simple (pour Asustor) en utilisant une version G.N.U. de crond supportant le déclencheur @reboot et non une version modifiée et incomplète pour changer les chemins de recherche des tables cron (ha! les spécifications qui passe par (dépendent des) les compétences techniques des développeurs et pas par la réponse au besoins utilisateur) "pilotage technique vs pilotage marketing" si on ajoute un ou des départs et un manque de documentation technique pour "reprendre" les modifications, on obtient du silence.

Fred.
N.B. je pense que Asustor (comme d'autres fournisseur de NAS) a des ressources limitées (le marché n'est pas au beau fixe), mais je pense aussi qu'il devrait mieux communiquer et faire confiance à leurs utilisateurs (en leur donnant "la main" pour ajouter des fonctions simples au processus ). Mais ce que je pense a peu d'importance :lol:
 
Sujet de 7 pages démarré le 9 septembre 2018.
J'ai demandé une procédure officielle de contournement dès mi-septembre en mâchant le travail et en expliquant ce qu'il fallait faire.
Ce n'est donc pas un problème de priorité, c'est un problème de (mauvaise) volonté.
D'où ma remarque ces jours-ci, sans aucune illusion ...

Bonne journée
Pulsar33
 
Bonjour,

Je pense qu il est inutile de remettre une couche et tu as compris qu il était temps de tourner la page.

Déçu : je comprends très bien ton sentiment mais le fait de revenir dessus ici n y changera rien. Tu comprendras que je ne souhaite pas que ça reparte comme les fois précédentes... [emoji23] - ca nous donne trop de boulot loooooool.
Esteban





Sent from my iPhone using Tapatalk
 
Bonsoir Esteban,

Je comprends très bien ta position et j'en resterai là, au moins pour l'instant. Je ne désespère pas cependant qu'un jour il comprenne l'impact négatif de son attitude ou pourquoi pas, qu'une autre personne s'occupe du lien entre les clients et la technique, sait-on jamais ...

Cordialement.
Pulsar33
 
maintenant il faudrait se poser la question de savoir si ce que tu demandes fonctionnerait à la concurrence...