RESEAU : bloquer options firefox

Bon pour faire simple, un des gosses à trouver le moyen de modifier les paramètres proxy dans firefox. Donc accès ouvert et plus de contrôle parental.
Je sais qu’on peut obliger un navigateur en modifiant son fichier de configuration mais je ne sais plus comment.
Quelqu’un peut-il m’aiguiller ?!
Autre solution ??

Salut tu peux toujours installer le plug-ing Public Fox
addons.mozilla.org/fr/firefox/a … serprofile
Mais il pourra toujours renommer son ~/.mozilla puis relancer à nouveau firefox pour avoir un nouveau profile.

Réponse rapide parce que je suis pressé, j’utilise ça sur mon réseau :

kb.mozillazine.org/Locking_preferences

Autre méthode : bloquer l’accès direct au web avec iptables.

C’est celle-là à laquelle je pensais.

Alors vas-y. Voir s’il y a lieu de laisser des exceptions le cas échéant (serveur sur le réseau local…).
Plus pervers : avec iptables rediriger de force les connexions HTTP sortantes vers le proxy s’il peut fonctionner aussi en mode transparent.

Je crois me souvenir qu’il ne peut pas fonctionner sur deux modes : transparent ou non transparent ; il faut choisir et j’ai choisi le mode non transparent puisqu’en mode transparent je ne peux avoir d’authentification sur le navigateur.

Dans /home/user/.mozilla/firefox, tu as tout un tas de fichiers de conf.
Mettre en lecture seul le fichier en question, pourrait peut-être être suffisant.

Je sais pas si possible: autoriser que root à l’écriture et autorisé l’utilisateur en lecture et exécution.
Au final, l’utilisateur pourra pas ajouter le droit écriture avec ses propres droit, seul root pourra.

Faut quand même testé.
Car même si firefox n’arrive pas à modifier le fichier, peut-être qu’il autorisera la modification temporairement en cours de l’utilisation actuel, jusqu’à sa fermeture.

La méthode iptable semble bien, si fonctionnel.

Même si l’utilisateur n’a pas les droits en écriture sur un fichier situé dans un répertoire dans lequel il peut écrire, il peut quand même le supprimer. Une possibilité serait de modifier l’attribut “i” du fichier en lecture seule avec [mono]chattr[/mono], ainsi même root ne pourrait pas le modifier.

J’ai ajouté cette règle à iptables :

Après essais, plus possible d’ouvrir une page web en désactivant le proxy. En rétablissant le proxy, on me demande les codes et je peux surfer. Tout bon :stuck_out_tongue:
Par contre, j’accède aux boites mails et autres joyeuseries en désactivant le proxy. Normal car je n’ai indiqué que tcp dans ma règle. Je dois donc bloquer d’autres protocoles ; je commence seulement à envisager le net sous forme de protocoles maintenant ; merci pascalhambourg !!
Donc quels sont les protocoles concernant les messageries, google + et autres reseaux sociaux pour le moment je ne vois que ceux-là mais si vous en voyez d’autres.

Cette règle effectue une redirection vers un proxy transparent. Si ton proxy ne fonctionne pas en mode transparent, c’est inutile. Autant faire une simple blocage dans la chaîne FORWARD avec DROP.

HTTP, tu veux dire (port 80/TCP).

La messagerie peut utiliser plusieurs protocoles et ports TCP associés.
POP3 (110), POP3S(995), SMTP (25), SSMTP (465), Submission (587), IMAP4 (143), IMAPS (995)… Note néanmoins que ces protocoles ne peuvent pas forcément passer par un proxy HTTP, il faut que l’application (voire le proxy) le supporte explicitement, comme un navigateur.

Les webmails, Google, réseaux sociaux, c’est du web donc HTTP (80) et HTTPS (443).

Néanmoins un serveur web ou autre peut très bien écouter sur un port non standard comme 81 ou 8080. C’est pourquoi il est plus sûr de tout bloquer sauf ce qui est autorisé plutôt que tout laisser passer sauf ce qui est interdit.

Mon proxy n’est pas en mode transparent puisque authentification ncsa. Mais avec cette règle, l’accès au http est impossible si on ne configure pas le navigateur AVEC le proxy ; moi çà me suffit !
Est-ce que le blocage dans la chaine FORWARD empêchera l’authentification ?

Non, car l’utilisation du proxy ne fait pas intervenir la fonction routeur de la machine et donc la chaîne FORWARD.
Le seul intérêt d’une redirection des connexions HTTP, ce serait par exemple pour afficher une page d’erreur explicite sur le navigateur à la place du site demandé.

Ok, je vois çà.

[code]iptables -t filter -P FORWARD DROP[/code]
[code]sauf ce qui est autorisé[/code]
Du serveur vers la box et donc l'extérieur
[code]iptables -t filter -A OUTPUT -o eth0 -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -o eth0 -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -o eth0 -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -o eth0 -p tcp --dport 443 -j ACCEPT[/code]
Du LAN vers br0
[code]iptables -t filter -A FORWARD -i br0 -o eth1 -p udp --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -i br0 -o eth1 -p tcp --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -i br0 -o eth1 -p tcp --dport 443 -j ACCEPT[/code]

Je me suis inspiré de ce post :
[debian-fr.org/tout-bloquer-s ... 36642.html](http://www.debian-fr.org/tout-bloquer-sauf-squid-avec-iptables-t36642.html)
J'ai adapté à ma configuration dans laquelle eth0 est relié à la box et eth1 au LAN et br0 le pont
Mais est-ce vraiment utile de faire tout cela ?
[code]Le seul intérêt d'une redirection des connexions HTTP, ce serait par exemple pour afficher une page d'erreur explicite sur le navigateur à la place du site demandé.[/code]
Si je peux faire cela pour les autres connexions, çà me suffit.

Du serveur vers la box et donc l’extérieur

iptables -t filter -A OUTPUT -o eth0 -p udp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -o eth0 -p tcp --dport 53 -j ACCEPT iptables -t filter -A OUTPUT -o eth0 -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -o eth0 -p tcp --dport 443 -j ACCEPT
Du LAN vers br0

iptables -t filter -A FORWARD -i br0 -o eth1 -p udp --dport 53 -j ACCEPT iptables -t filter -A FORWARD -i br0 -o eth1 -p tcp --dport 53 -j ACCEPT iptables -t filter -A FORWARD -i br0 -o eth1 -p tcp --dport 443 -j ACCEPT

Je me suis inspiré de ce post :
debian-fr.org/tout-bloquer-s … 36642.html
J’ai adapté à ma configuration dans laquelle eth0 est relié à la box et eth1 au LAN et br0 le pont
Mais est-ce vraiment utile de faire tout cela ?

Si je peux faire cela pour les autres connexions, çà me suffit.

Pour la clarté, évite d’utiliser les balises de [mono]code[/mono] pour les blocs de citation.

  • Il y a un eth2 qui traîne, je suppose qu’il s’agit en fait d’eth0.
  • Tu n’as pas besoin de filtrer en sortie pour forcer les utilisateurs à passer par le proxy. Si tu veux limiter les ports de destination utilisables via le proxy, tu peux le faire dans la configuration de ce dernier.
  • [mono]-o=eth1[/mono] dans les règles FORWARD ne me semble pas correct. Le pont br0 est entre quelles interfaces et quel est son rôle ?
  • Je ne suis pas sûr que le DNS soit nécessaire pour un client quand il passe par un proxy explicite. C’est le proxy qui fait la résolution de nom des sites demandés.
  • As-tu besoin d’autoriser le HTTPS (port 443) direct dans FORWARD sans passer par le proxy ?

Je conserve uniquement la règle de rejet et j’ajoute pour le moment :

Là j’oblige le traffic sur le port 443 qui entre sur br0 à passer par le proxy qui n’est pas transparent.
Du coup je retire la règle de prerouting.
C’est bon ?

Je ne peux pas répondre car tu n’as pas répondu à ma question concernant br0.

Si j’ai bien retenu ma leçon, le pont sert à faire en sorte que deux interfaces soient sur le même reseau. J’ai une carte wifi (wlan) et une carte ethernet (eth1). la deuxième carte ethernet est reliée à la box.
Le pont relie eth1 et wlan0 sur l’interface br0 qui a pour adressage 172.16.10.0/28

Compris. Donc seule br0 devrait apparaître dans les règles iptables comme l’interface connectée au réseau local (ethernet + wifi), pas eth1.
En supposant que FWDDROP est une chaîne utilisateur que tu as définie et qui se termine par un DROP, alors ta règle bloque toute communication directe sur le port 443 (HTTPS) alors que, si je ne m’abuse, la règle de prerouting que tu dis vouloir supprimer concernait le port 80 (HTTP). D’autre part cette règle prise isolément du jeu de règles complet ne veut pas dire grand-chose. Elle suggère juste que tu adoptes la stratégie “on laisse tout passer sauf ce qui est interdit” au lieu de “on bloque tout sauf ce qui est autorisé”, pourtant plus sûre.