Asustor Filtrage par fichier HOSTS

Pulsar33

Chevalier Jedi
1 Mars 2016
152
0
0
Bonjour,

Après une petite séance de surf via Chromium (même pas Chrome) sur des sites banals, je constate plus de 50% d'accès inutiles voire nuisibles à des sites de tracking et autres espions. Il existe une méthode très simple que j'utilise sur tous mes systèmes, y compris mon téléphone, qui consiste à filtrer cela grâce au fichier HOSTS, en particulier celui mis à jour régulièrement sur ce site indispensable.

Puis-je modifier le fichier HOSTS du NAS en me connectant comme root avec SSH sans que ça ne pose de problème ?

Cordialement
Pulsar33

PS pour info : voici le genre de nuisibles constatés
Code:
dmp.adform.net
s1.adform.net
track.adform.net
ih.adscale.de
match.basebanner.com
api.bttrack.com
beacon.krxd.net
pixel.mathtag.com
sync.mathtag.com
ads.pubmatic.com
showads.pubmatic.com
p.rfihub.com
optimized-by.rubiconproject.com
d.turn.com
ad.yieldlab.net
cdn.taboola.com
px.moatads.com
images.taboola.com
trc.taboola.com
ad.360yield.com
dpm.demdex.net
api.viglink.com
x.bidswitch.net
magnetic.t.domdex.com
pm.w55c.net
idsync.rlcdn.com
match.adsrvr.org
api.adrtx.net
apx.moatads.com
match.rundsp.com
ads.adaptv.advertising.com
seb.scorecardresearch.com
cdn.bttrack.com
ps.eyeota.net
js.moatads.com
pixel.tapad.com
pixel.advertising.com
logc279.xiti.com
ib.adnxs.com
nym1.ib.adnxs.com
nym1-ib.adnxs.com
c1.adform.net
b.scorecardresearch.com
cas.criteo.com
static.criteo.net
image2.pubmatic.com
dsp.adfarm1.adition.com
bh.contextweb.com
sync-tm.everesttech.net
cm.g.doubleclick.net
px.adhigh.net
cdn.viglink.com
img.metaffiliation.com
bcp.crwdcntrl.net
eu-u.openx.net
us-u.openx.net
green.erne.co
ads.stickyadstv.com
pixel.sitescout.com
bttrack.com
stags.bluekai.com
tags.bluekai.com
a.tribalfusion.com
loadm.exelator.com
 
Bonjour Dami1,

Oui, je parle de surfer sur internet via Chromium sur le portail du 6204T (affichage HDMI sur ma télé)

Bonne journée
Pulsar33
 
Vous, tu ... etc. je ne sais plus qui je tutoie et qui je vouvoie :lol:
Si je reformule : tu souhaiterais savoir comment procéder avec un terminal en ssh?
 
Sur tous les forums collaboratifs du monde, on se dit tu.
C'est plus facile pour rédiger les phrases et c'est sans doute inspiré des forums anglophones.
Mais c'est comme tu veux.

Non, une fois de plus j'ai du mal à te faire comprendre mes questions. C'est étrange. Je sais très bien utiliser SSH.
Je ne vois pas ce qui n'est pas clair dans la question que j'avais posée :
Pulsar33 a dit:
Puis-je modifier le fichier HOSTS du NAS en me connectant comme root avec SSH sans que ça ne pose de problème ?

Je te demande si le fait de changer le fichier HOSTS (pour les raisons déjà expliquées) est possible sans causer de problème

Bonne soirée
Pulsar33
 
Tu peux le faire . néanmoins nous déclinons toute responsabilité en cas de plantage de ton NAS
 
Bonjour Dami1,

Voilà une belle réponse parapluie :-?
Tu me dis que je peux le faire (en tant que root, je m'en doutais bien)
Tu ne me dis pas s'il y a des risques connus, c'était l'objet de ma question (tu n'en as visiblement aucune idée)
Tu me dis que s'il y a des problèmes, c'est pour mes pieds ...
Ben avec ça, je ne suis pas plus avancé.

Bon, donc j'ai fait la manip et je rends compte ici à la communauté dont certains membres pourraient, comme moi, être contre les pistages et autres espions que le Nas laisse œuvrer sans vergogne.

Après avoir récupéré le dernier fichier à jour sur cette page, désarchivé le fichier HOSTS, ajouté entre les commentaires et les listes d'exclusion la définition locale qui était présente dans le fichier original du Nas, et mis tout ça en place dans /etc, je constate l'efficacité redoutable du filtrage (qui ne me surprend pas, j'ai l'habitude sur mes autres systèmes) !

Malheureusement, il n'a pas fallu attendre longtemps (environ 1h) avant de voir ces efforts anéantis par le Nas lui-même qui a écrasé mon fichier avec le sien, minimaliste et sans intérêt. Et pourtant, j'étais loin d'avoir vérifié tous les cas de figures (redémarrage,, déconnexion, ...), je n'avais fait que surfer sur quelques forums dont celui-ci. J'ai quelques pistes sur les raisons de cet écrasement, la première étant que le Nas vient écrire l'adresse IP locale et le nom de l'hôte qu'on a choisi pour lui dans ce fichier. Non seulement il y a d'autres endroits sous Linux pour stocker ça mais de plus, il ne prend pas la peine de mettre à jour cette définition dans le fichier existant, il écrase le fichier sans aucune formalité.

Je vais bien sûr tenter de l'empêcher de se comporter ainsi mais je suggère déjà à Asustor de rectifier ce comportement, le fichier hosts étant un fichier hautement stratégique pour les ingénieurs système et qui ne mérite pas d'être traité de cette manière désinvolte.

Je vous tiendrai au courant si je trouve une parade.
Bonne journée
Pulsar33

PS : voici le contenu minimaliste du fichier hosts d'Asustor
Code:
127.0.0.1       localhost
::1     localhost
192.168.0.xxx    [NOM_CHOISI_POUR_LE_NAS]
 
Je sens comme une petite tension... là. On respire et on tourne 7 fois son doigt avant de cliquer sur Envoyer :lol:

J'ai souvenir d'un cas similaire pour un autre constructeur... et je crois qu'il n'y avait pas eu de résolution (de mémoire).
Ce qui pourrait être une piste, c'est de créer une tâche (CRONTAB) qui modifie le fichier (ou copie/remplace) toutes les heures par exemple.

L'autre solution, ce serait d'avoir un service DNS Server sur le NAS ;)
 
FX Cachem a dit:
Je sens comme une petite tension... là. On respire et on tourne 7 fois son doigt avant de cliquer sur Envoyer :lol:

Bah, non, c'est simplement que sur les différents sujets évoqués ces derniers temps, Dami1 répond rarement à la question, même quand on l'explique de différentes manières. Ça ne m'empêche pas de vivre, c'est juste dommage pour moi comme pour la communauté. Après, je suppose qu'il a beaucoup de boulot et je sais qu'il est commercial et ne ménage pas sa peine mais bon, il faut bien que les choses progressent pour faire le meilleur produit possible.

Merci pour tes suggestions FX Cachem, néanmoins, si le fichier hosts est écrasé régulièrement ou sur évènements (leur liste restant à définir), il est clair que ce ne peut être que le résultat d'une action volontaire d'ADM car ce n'est pas un fonctionnement standard de Linux, bien au contraire. Je crois pouvoir dire que s'il n'y a pas eu résolution dans le cas que tu cites, c'est que le constructeur n'a pas souhaité modifier le fonctionnement de ses tâches.

Par ailleurs, toute tâche (CRONTAB) de fréquence raisonnable laissera des fenêtres temporelles dans lesquelles les accès ne seront pas filtrés et dont l'utilisateur ne sera pas averti.

Étant donné qu'il est souvent conseillé de protéger le fichier hosts de tout accès indésirable afin d'éviter des modifications sauvages par des malwares, je pense d'abord essayer d'en interdire l'écriture, au risque de faire planter la tâche ADM responsable de cet écrasement. C'est là qu'une réponse argumentée d'Asustor serait appréciable en attendant je l'espère une prise en compte de cette demande d'évolution qui n'est somme toute pas bien compliquée.

Pour ce qui est du DNS server, je regarde ça mais il y a quand même 14000 lignes dans le fichier hosts actuel et il évolue régulièrement ...

Bonne soirée
Pulsar33
 
C'est sûr qu'il serait intéressant de savoir pourquoi... mais à mon avis, c'est leur sauce et on va te répondre que c'est confidentiel. Il doit y avoir une bonne raison (DDNS ?).

Pulsar33 a dit:
Pour ce qui est du DNS server, je regarde ça mais il y a quand même 14000 lignes dans le fichier hosts actuel et il évolue régulièrement ...
C'est effectivement pas mal. Je suis sûr qu'il est possible de trouver une solution :D Peut-être verrouillé le fichier en lecture mais au reboot, l'OS va reprendre la main. Il faudra créer un petit script shell ;)
 
Je ne dis pas que c'est impossible. La prudence est parfois de mise ;)
ASUSTOR décline toute responsabilité en cas de "bidouille", modification logicielle/matérielle. Chromium fait partie intégrante d'ASUSTOR Portal.

Exemples (liste non exhaustive):
- un utilisateur modifie ADM / des applications ASUSTOR
- un utilisateur change l'i3 ou l'i5 d'un AS7004T par un autre CPU => la garantie ne fonctionnera plus
- un utilisateur installe une application non validée par nos équipes (absente d'App Central) qui engendre des dysfonctionnements
- un utilisateur achète des périphériques, ne figurant pas dans notre liste de compatibilité, qui engendrent des dysfonctionnements ou ne sont pas détectés ou ne fonctionnent pas correctement
 
Bon, comme conseillé par FX Cachem, je respire un grand coup, je tourne mon doigt 7 fois avant d'envoyer ...

Dami1, pour la deuxième fois :
- je savais que c'était possible (d'ailleurs je viens de dire que je l'ai fait)
- je comprends que "par défaut" tu ouvres le parapluie en rejetant toute responsabilité (même si c'est désagréable)
- une nouvelle fois, tu réponds "à coté" de la seule question qui importe :
  • Y a-t-il des risques connus à modifier le fichier hosts ?

Tu aurais déjà pu me dire qu'il allait être écrasé rapidement, mais ça je l'ai découvert tout seul.
Tu pourrais me dire quelle est la tâche qui écrase le fichier hosts car ça je n'en sais rien.
Tu pourrais me dire ce qui va se passer si on interdit la modification de ce fichier (si tu as suivi les messages précédents).

Tout ça, ce n'est pas pour te casser les pieds mais pour essayer de contourner une situation désagréable qui limite le fonctionnement du Nas.
Il s'agit donc d'optimiser ton produit.

Accessoirement, tu pourrais suggérer à la technique de se demander s'il est vraiment utile de poursuivre ce fonctionnement totalement exotique.

Voilà qui ferait avancer le schmilblick ...
Bonne soirée
Pulsar33

**** Moderation realisée ****
 
Bonjour,

Voici quelques nouvelles infos sur ce sujet :
- Premièrement, le processus qui écrase le fichier hosts tourne sous root et se fiche royalement des permissions. Il écrase le fichier ! :evil:
- Deuxièmement, j'ai une petite idée du coupable potentiel (à confirmer) :
Code:
$ grep renew messages
2018-08-29T08:44:34.909496+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 42250 seconds.
2018-08-29T20:28:44.609116+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 37565 seconds.
2018-08-30T06:54:49.966345+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 35163 seconds.
2018-08-30T16:40:52.183282+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 37003 seconds.
2018-08-31T02:57:35.625230+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 37557 seconds.
2018-08-31T13:23:32.073209+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 42342 seconds.
2018-09-01T01:09:15.109761+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 41582 seconds.
2018-09-01T12:42:17.759490+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 38994 seconds.
2018-09-01T23:32:11.575610+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 35545 seconds.
2018-09-02T09:24:36.439651+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 41004 seconds.
2018-09-02T20:48:00.790358+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 40158 seconds.
2018-09-03T07:57:18.227392+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 43009 seconds.
2018-09-03T19:54:07.171387+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 39213 seconds.
2018-09-04T06:47:40.830219+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 36931 seconds.
2018-09-04T17:03:11.055141+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 43182 seconds.
2018-09-05T05:02:53.498012+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 34243 seconds.
2018-09-05T14:33:37.012102+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 34417 seconds.
2018-09-06T00:07:14.599419+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 42995 seconds.
2018-09-06T12:03:49.765008+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 39823 seconds.
2018-09-06T23:07:32.749643+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 32592 seconds.
2018-09-07T08:10:44.986834+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 40460 seconds.
2018-09-07T19:25:04.897414+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 36635 seconds.
2018-09-08T05:35:39.557028+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 37176 seconds.
2018-09-08T15:55:16.000965+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 42184 seconds.
2018-09-09T03:38:20.891910+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 38009 seconds.
2018-09-09T14:11:49.344226+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 35590 seconds.
2018-09-10T00:04:59.817325+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 42686 seconds.
2018-09-10T11:56:26.002521+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 36952 seconds.
2018-09-10T22:12:18.959406+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 38049 seconds.
2018-09-11T08:46:27.457319+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 35026 seconds.
2018-09-11T18:30:13.057784+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 34203 seconds.
2018-09-12T04:00:16.391145+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 38065 seconds.
2018-09-12T14:34:41.148398+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 39099 seconds.
2018-09-13T01:26:20.366955+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 35399 seconds.
2018-09-13T11:16:19.778172+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 38391 seconds.
2018-09-13T21:56:10.517065+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 42260 seconds.
2018-09-14T09:40:30.516489+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 37652 seconds.

Bon, dhclient est documenté, je regarde ça ...
Pour info, mon Nas est configuré en DHCP comme le reste de mon réseau, le serveur DHCP étant mon modem routeur ADSL qui connait les adresses MAC réservées.
Je vais essayer de mettre le Nas en manuel pour voir si ça évite le problème

Bonne journée
Pulsar33
 
Je viens de passer l'IP en manuel sur le LAN1 en cohérence bien sûr avec ma réservation sur le routeur.
J'ai ensuite redémarré et là, surprise :
Le Nas a purgé TOUS les fichiers hosts du dossier /etc, en particulier ceux que j'y avais mis (hosts_org et hosts_new)
Il a peut-être même purgé tous les fichiers quels qu'ils soient dans ce dossier d'ailleurs, je n'en sais rien à ce stade.

Le moins qu'on puisse dire, c'est qu'on ne fait pas dans la dentelle chez Asustor :evil:

A suivre
Pulsar33

FX Cachem a dit:
[...] au reboot, l'OS va reprendre la main. Il faudra créer un petit script shell ;)
Ça se précise :-D

**** Moderation realisée ****
 
A cette heure, toujours pas mais si j'en juge par la dernière trace dans le fichier message :
Code:
2018-09-14T09:40:30.516489+02:00 NomDuNAS dhclient: bound to 192.168.0.xxx -- renewal in 37652 seconds
il faut au moins que j'attende 20h30 pour être sûr ...

@+ Puls
 
L'échéance était à 20:08:02 et rien n'a changé pour l'instant (mais sans redémarrer depuis tout à l'heure bien sûr)
Code:
root@xxx:/etc # date +%d/%m/%y-%kh%M;ll hos*
14/09/18-20h36
-rw-r--r--    1 root     root           8 Jan 10  2012 hostname
-rw-r--r--    1 root     root      464.8K Sep 14 12:07 hosts
C'est plutôt bon signe
Je poursuis la surveillance
Pulsar33
 
Bonjour,

Il semble que le passage en IP manuelle a calmé le problème d'écrasement récurrent :
Code:
root@xxx:/etc # date +%d/%m/%y-%kh%M;ll hos*
15/09/18- 8h41
-rw-r--r--    1 root     root           8 Jan 10  2012 hostname
-rw-r--r--    1 root     root      464.8K Sep 14 12:07 hosts

Reste l'écrasement au (re)démarrage et peut-être des cas que je n'ai pas encore vu.
@FX Cachem, as-tu un conseil à me donner pour insérer la copie du fichier au bon moment stp (quel script dois-je modifier) ?
J'imagine que c'est après le Boot Storage et avant le Boot App mais je ne connais pas la séquence. Peut-être as-tu déjà regardé ça ?

Bonne journée
Pulsar33
 
Pulsar33 a dit:
Bon, comme conseillé par FX Cachem, je respire un grand coup, je tourne mon doigt 7 fois avant d'envoyer ...
Hello,
Bon... essayer de touner 8 fois le doigt avant pour voir ... :rolleyes:
Je me suis permis de diminuer la police de caracteres et evite le gras ? jai mal aux yeux et je pense que ca ne fera pas plus avancer les choses... :lol:

@Dami1, pourrais tu prendre un peu de temps pour répondre à notre ami qui aimerait utiliser son Nas pleinement ?
A la vue des différentes actions que tu mènes au quotidien ici, ca sera pas grand chose pour toi, et Pulsar33 sera quant à lui, pleinement satisfait et rassuré d'avoir un bon produit.

Merci par avance, à vous 2 de bien vouloir jouer le jeu... sans CRIER (hein Pulsar33... :lol: )

@++
 
Je ne sais pas si ce Tuto pourrait te mettre sur la bonne voie https://debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian ou celui là https://blog.nicolargo.com/2009/03/creation-dun-script-de-demarrage-sous-linux.html