Controle parental, amsn et autres billevesées

Support Debian
#1

bonjour/soir à tous,

j’ai fait quelques recherches sur le forum, mais rien qui se rapproche de mon objectif.
objectif : mettre en passerelle un poste dédié au contrôle parental avec trafic amsn (pas taper) valide.

disposition :
pc enfant ------------ passerelle ------------------------------------------ pare-feu (netgear… pas taper)
192.168.254.2 ----- 192.168.254.254 / 192.168.168.254 ------ 192.168.168.1 ------------------ free / web

je pensais mettre squid 3 + squidguard ; mais, des tentatives infructueuses passées me font hésiter (sauf que maintenant, les louveteaux grandissent, grandissent et qu’il faut vraiment les protéger du vil internet tout plein de pirates forniquant avec des z’entils bisounours).

plus sérieusement, je n’ai jamais réussi à faire correctement fonctionner le trafic msn (ma fille adore, c’est mon fardeau… le trafic, pas la fille) que ce soit en mode transparent ou non.

la question à wouatmille euros :

  • quels applis me conseilleriez-vous (squid, pas squid, squidguard, pas squidguard, dansguardian, autre…) ?
    la question à trop d’euros :
  • que faut-il faire pour permettre ce #$%à@# trafic msn ?
#2

Le traffic jabber passe ? Parce que sinon, suffit de lui faire un compte sur un serveur jabber qui fournit une passerelle MSN, et tu n’as plus à te préoccuper de ce #$%à@# de protocole propriétaire…
Accessoirement, ça filtre aussi les fenêtres qui bougent toutes seules et les gros lapins roses qui clignotent. Mais si moi j’apprécie ce genre de détails, ce n’est peut-être pas le cas de ta fille…

#3

c’est explicitement le trafic msn pour bénéficier de toutes les fioritures des clients/clones msn (écran qui bouge, sonnerie, et autres &$#à# de caractères flashy pour faire des phrases incompréhensibles…).
donc, jabber et autres passent aux oubliettes.

je me rappelle vaguement que, lors de mes 1ers essais, cela donnait cela :

  • squid 3 seul = trafic ok
  • squid 3 + squidguard = trafic nok ; modif pour autoriser trafic 8198 (de mémoire, le port msn) = nok derechef ; modif pare-feu matériel pour routage 192.168.254.0 = pas mieux

et, en énonçant tout cela, ce qui me traverse l’esprit est : iptable
d’un autre côté, cela fonctionnait sans squidguard, alors…

bref, merci kna d’avoir pris le temps de me répondre ; et merci d’avance à tous si vous avez des conseils, solutions, suggestions, paramètres, idées, pensées et autres interrogations pour m’aider.

#4

Pour MSN, tu as besion de plusieurs choses
Port 1863
Pour les transferts de fichiers: au moins 6891 et jusqu’à 6900 (TCP)
Tableau blanc et le partage d’ application: port 1503
Vidéo : connexion TCP et UDP sur le port 6901 et tous les ports UDP entre 5000 et 65535
Audio : Tous les ports UDP entre 5000 et 65535 en UDP

#5

j’essaye et vous tiens informé :wink:

edit : est-ce que cela signifie que le couple squid 3 + squidguard est la solution “idéale” ?

#6

ça y est, je me rappelle les blocages rencontrés… je suis en plein dedans, ceci explique cela (d’ailleurs mon énoncé est faux : amsn ne fonctionnait pas dès installation de squid)… permettez-moi une larmouille… bouhouhou… maintenant, passons à l’explication :
je m’aide de http://irp.nain-t.net/doku.php/220squid:030_plus_sur_squid
le choix est authentifier ou mode transparent.
je n’ai pas envie de “gonfler” les bout-d’choux avec des mots de passe (ils ont déjà celui pour se connecter, c’est déjà pas mal).
A priori, le mode transparent me sied. mais, il se limite à 1 port en forwarding.

A la vérité, le range 192.168.254.0 est obligé de passer par le serveur car ce dernier fait office de passerelle (je vous renvoie au schéma initial) et le poste des “mini-moi” est en liaison directe (câble croisé) sur eth1 du serveur.
Donc, pas besoin de mode transparent, le contournement est physiquement impossible ; il suffit de “forcer” le proxy dans les paramètres du navigateur (port 3128 par défaut).
Ce qui bloque, c’est quand on redirige amsn sur le proxy.
Parallèlement, le proxy n’a pas besoin de “contrôler” le trafic “aime est-ce haine”.

la facilité serait d’ouvrir tout le trafic sortant du range 192.168.254.0 mais cela “court-circuiterait” le contrôle squidguard

Finalement, ma question devient (et je subodore toujours iptable… ma hantise) pour ouvrir uniquement le trafic amsn sortant :
quelle solution appliquer ? … avec les paramètres, svp, si ce n’est pas trop demander…
[size=50]si c’est iptable, promis, je “rtfmerai”… mais un peu plus tard si cela ne vous dérange pas[/size] :blush:

#7

j’ai un peu “rtfmé”, modifié les règles netfilter sur la passerrelle comme suit :

Generated by iptables-save v1.4.2 on Wed Oct 14 17:05:15 2009

*filter
:INPUT ACCEPT [519:34796]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [521:94644]
:intranet - [0:0]
-A FORWARD -s 192.168.254.2/32 -i eth1 -o eth0 -p tcp -m tcp --dport 1863 -j ACCEPT
-A FORWARD -s 192.168.254.2/32 -i eth1 -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -s 192.168.254.2/32 -i eth1 -o eth0 -p tcp -m tcp --dport 6891:6901 -j ACCEPT
-A FORWARD -s 192.168.254.2/32 -i eth1 -o eth0 -p tcp -m tcp --dport 1533 -j ACCEPT
-A FORWARD -s 192.168.254.2/32 -i eth1 -o eth0 -p udp -m udp --dport 5000:65535 -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p tcp -m tcp --dport 1863 -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p tcp -m tcp --dport 6891:6901 -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p tcp -m tcp --dport 1533 -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p udp -m udp --dport 5000:65535 -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p tcp -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p udp -j ACCEPT
-A FORWARD -d 192.168.254.2/32 -i eth0 -o eth1 -p icmp -j ACCEPT
COMMIT

je viens de tester l’accès ssh de mon propre poste vers celui des ch’tits loups (de 192.168.168 vers 192.168.254) = échec
puis une connexion de 192.168.254 en amsn = échec
idem avec une connexion https (sauf quand le proxy est renseigné sur le navigateur)

remarque : pour le test ssh, ma table de routage est modifiée pour joindre le range 192.168.254.0

un test ping de 192.168.168.x vers 192.168.168.254 = ok
vers 192.168.254.254 = ok
vers 192.168.254.2 = échec

un test ping de 192.168.254.254 vers 192.168.254.2 = ok

wtf ? [size=50]je vous l’avais écrit que iptables est ma hantise[/size]

ps : j’ai oublié la config des postes -bien que cela ne doive pas changer grand-chose.
pc enfant et perso = “mon bon toutou” 9.04
passerelle proxy = debian lenny

#8

Je pense pourtant que la solution iptable est plus simple que squid.
Si tu n’arrives pas à générer les règles à la main, utilise un GUI.
http://afterstep.blogspot.com/2008/01/linux-ubuntu-firewall-lokkit-iptables.html

#9

je regarde tout cela :wink:

#10

Entre chien et loup, c’est normal de s’entraider :slightly_smiling:

#11

je graou à +1 :smiley:
les tests sont reportés à ce dimanche (je suis en pleine migration esx 3.5 vers vsphere pour ce week-end)

#12

:smt089 je suis une brêle… on m’a même conseillé du amon, slis et autre sambedu et même là je suis paumé… je mets en standby pour le moment (je vais mettre un filtrage local sur le navigateur du poste mais c’est une solution qui se contourne trop facilement).

[size=50]au moins, pour petite consolation, la migration vsphere s’est bien déroulée.[/size]