Dans le message <news:40978888$0$31939$, *Guillaume* tapota sur f.c.o.l.configuration :
la seule solution cets un firewall niveay 7 (content filtering) et ca cets pas donne,
Une autre solution pourrait consister à faire transiter le trafic vers le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et de paramétrer ces derniers pour refuser les extensions de fichiers indésirables telles que celles que l'on retrouve le plus fréquemment dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire déjà assez valable, non ?
Non. Le P2P ce n'est pas du http. Squid permet du filtrage IP, du filtrage http mais certainement pas du filtrage au niveau contenu des paquets.
-- TiChou
Dans le message <news:40978888$0$31939$626a14ce@news.free.fr>,
*Guillaume* tapota sur f.c.o.l.configuration :
la seule solution cets un firewall niveay 7 (content filtering) et ca
cets pas donne,
Une autre solution pourrait consister à faire transiter le trafic vers
le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et
de paramétrer ces derniers pour refuser les extensions de fichiers
indésirables telles que celles que l'on retrouve le plus fréquemment
dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un
vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une
solution intermédiaire déjà assez valable, non ?
Non. Le P2P ce n'est pas du http. Squid permet du filtrage IP, du filtrage
http mais certainement pas du filtrage au niveau contenu des paquets.
Dans le message <news:40978888$0$31939$, *Guillaume* tapota sur f.c.o.l.configuration :
la seule solution cets un firewall niveay 7 (content filtering) et ca cets pas donne,
Une autre solution pourrait consister à faire transiter le trafic vers le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et de paramétrer ces derniers pour refuser les extensions de fichiers indésirables telles que celles que l'on retrouve le plus fréquemment dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire déjà assez valable, non ?
Non. Le P2P ce n'est pas du http. Squid permet du filtrage IP, du filtrage http mais certainement pas du filtrage au niveau contenu des paquets.
-- TiChou
Guillaume
En cette bucolique journée du Tue, 04 May 2004 14:58:02 +0200, alban nous diffusa sa prose en ces termes :
80 n'est pas pour alléz sur le web
Ah bon ? Il va falloir que tu expliques ça à ma passerelle.
80 est le port au quel viens ce connecter un client http mais ce n'est pas géneralement le port internet utilisé par le browser,
netstat
tcp 0 0 192.168.22.250:33454 216.239.51.99:http ESTABLISHED
ici le port qui est utiliser pour aller sur une page web est le port 33454
Non : c'est le port d'origine sur ton _PC_, le port de destination est bien le 80 (et c'est ce qui importe un firewall), à moins que ce ne soit pas du http ... ou que le serveur ne communique pas sur le port standard.
Une autre solution pourrait consister à faire transiter le trafic vers le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et de paramétrer ces derniers pour refuser les extensions de fichiers indésirables telles que celles que l'on retrouve le plus fréquemment dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire déjà assez valable, non ?
pas tout a fais d'accord avec toi mais je me trompe peu etre, la paquet que tu recois ne porte pas le type d'extention je pense,
Tu penses bien, mais tu aurais pu lire en entier çi-dessus :
ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire
Je ne parlais pas de filtrer au niveau des paquets, ce qui est effectivement compliqué, onéreux et très gourmand en ressources comme le disait Sauron, mais d'une solution intermédiaire qui élimine tout de même une bonne partie du trafic indésirable.
on telecharge un mp3 mais en morceaux puis il est réconstitué par le logiciel de p2p.
Mmoui, pour simplifier. Mais un proxy tel que Squid identifie l'extension dès que la requête lui est soumise, et refusera de rapatrier le fichier en question si ses access-lists vont dans ce sens. Donc les _fichiers_ qui font généralement l'objet des transferts P2P peuvent être filtrés par leur extension sur le port 80, et si les autres ports sont fermés, ça commence à être une solution de filtrage satisfaisante sans nécessiter les grands moyens d'un filtrage au niveau applicatif.
-- Guillaume
En cette bucolique journée du Tue, 04 May 2004 14:58:02 +0200, alban
nous diffusa sa prose en ces termes :
80 n'est pas pour alléz sur le web
Ah bon ? Il va falloir que tu expliques ça à ma passerelle.
80 est le port au quel viens ce connecter un client http mais
ce n'est pas géneralement le port internet utilisé par
le browser,
netstat
tcp 0 0 192.168.22.250:33454 216.239.51.99:http ESTABLISHED
ici le port qui est utiliser pour aller sur une page web est le port 33454
Non : c'est le port d'origine sur ton _PC_, le port de destination est
bien le 80 (et c'est ce qui importe un firewall), à moins que ce ne soit
pas du http ... ou que le serveur ne communique pas sur le port standard.
Une autre solution pourrait consister à faire transiter le trafic vers
le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et
de paramétrer ces derniers pour refuser les extensions de fichiers
indésirables telles que celles que l'on retrouve le plus fréquemment
dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un
vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une
solution intermédiaire déjà assez valable, non ?
pas tout a fais d'accord avec toi mais je me trompe peu etre, la paquet que
tu recois ne porte pas le type d'extention je pense,
Tu penses bien, mais tu aurais pu lire en entier çi-dessus :
ce n'est pas non plus un
vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est
une solution intermédiaire
Je ne parlais pas de filtrer au niveau des paquets, ce qui est
effectivement compliqué, onéreux et très gourmand en ressources comme le
disait Sauron, mais d'une solution intermédiaire qui élimine tout de
même une bonne partie du trafic indésirable.
on telecharge un mp3 mais en morceaux
puis il est réconstitué par le logiciel de p2p.
Mmoui, pour simplifier. Mais un proxy tel que Squid identifie l'extension
dès que la requête lui est soumise, et refusera de rapatrier le fichier
en question si ses access-lists vont dans ce sens. Donc les _fichiers_ qui
font généralement l'objet des transferts P2P peuvent être filtrés par
leur extension sur le port 80, et si les autres ports sont fermés, ça
commence à être une solution de filtrage satisfaisante sans nécessiter
les grands moyens d'un filtrage au niveau applicatif.
En cette bucolique journée du Tue, 04 May 2004 14:58:02 +0200, alban nous diffusa sa prose en ces termes :
80 n'est pas pour alléz sur le web
Ah bon ? Il va falloir que tu expliques ça à ma passerelle.
80 est le port au quel viens ce connecter un client http mais ce n'est pas géneralement le port internet utilisé par le browser,
netstat
tcp 0 0 192.168.22.250:33454 216.239.51.99:http ESTABLISHED
ici le port qui est utiliser pour aller sur une page web est le port 33454
Non : c'est le port d'origine sur ton _PC_, le port de destination est bien le 80 (et c'est ce qui importe un firewall), à moins que ce ne soit pas du http ... ou que le serveur ne communique pas sur le port standard.
Une autre solution pourrait consister à faire transiter le trafic vers le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et de paramétrer ces derniers pour refuser les extensions de fichiers indésirables telles que celles que l'on retrouve le plus fréquemment dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire déjà assez valable, non ?
pas tout a fais d'accord avec toi mais je me trompe peu etre, la paquet que tu recois ne porte pas le type d'extention je pense,
Tu penses bien, mais tu aurais pu lire en entier çi-dessus :
ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire
Je ne parlais pas de filtrer au niveau des paquets, ce qui est effectivement compliqué, onéreux et très gourmand en ressources comme le disait Sauron, mais d'une solution intermédiaire qui élimine tout de même une bonne partie du trafic indésirable.
on telecharge un mp3 mais en morceaux puis il est réconstitué par le logiciel de p2p.
Mmoui, pour simplifier. Mais un proxy tel que Squid identifie l'extension dès que la requête lui est soumise, et refusera de rapatrier le fichier en question si ses access-lists vont dans ce sens. Donc les _fichiers_ qui font généralement l'objet des transferts P2P peuvent être filtrés par leur extension sur le port 80, et si les autres ports sont fermés, ça commence à être une solution de filtrage satisfaisante sans nécessiter les grands moyens d'un filtrage au niveau applicatif.
-- Guillaume
Guillaume
En cette bucolique journée du Tue, 4 May 2004 15:22:45 +0200, TiChou nous diffusa sa prose en ces termes :
Non. Le P2P ce n'est pas du http.
Tu m'en diras tant.
-- Guillaume
En cette bucolique journée du Tue, 4 May 2004 15:22:45 +0200, TiChou
nous diffusa sa prose en ces termes :
En cette bucolique journée du Tue, 4 May 2004 15:22:45 +0200, TiChou nous diffusa sa prose en ces termes :
Non. Le P2P ce n'est pas du http.
Tu m'en diras tant.
-- Guillaume
alban
Guillaume wrote:hébergeanttt ? Il va falloir que tnaviguerrques ça à ma passerelle.
80 est le port au quel viens ce connecter un client http mais ce n'est pas géneralement le port internet utilisé par le browser,
netstat
tcp 0 0 192.168.22.250:33454 216.239.51.99:http ESTABLISHED
ici le port qui est utiliser pour aller sur une page web est le port 33454
Non : c'est le port d'origine sur ton PC, le port de destination est bien le 80 (et c'est ce qui importe un firewall), à moins que ce ne soit pas du http ... ou que le serveur ne communique pas sur le port standard.
oui alors un pc hébergeant un site web ne peu pas naviguer sur le net vu que sont port 80 est utiliser ? si tu fais du filtrage en interdisant les paquet a destination de port 80 tu ne peu pas aller sur le net mais le port qui est ouvert sur ta passerelle pour sortir ver le net pour surfer n'est pas le port 80, comme tu la dis la destination et le port 80 mais pourquoi bloquer le port 80 en destination enpecher les gens d'aller sur le net ?
je cite ce qui etait dit "a partir du moment ou certain ports sont ouverts genre le 80 pour pouvoir allez sur le web, il suffit de mettre dans la conbd de emul/mldonkey/edonkey/.... le port qui vas bien."
le port 80 n'a pas a etre ouvert sur ton firewall mais sur le firewall du serveur ! ferme ton port 80 et va voir si tu n'a pas la possibiliter de surfer ! parcontre filtrer le paquet a destination du port 80 et autre chose que de l'ouverture et de la fermeture de port !
Une autre solution pourrait consister à faire transiter le trafic vers le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et de paramétrer ces derniers pour refuser les extensions de fichiers indésirables telles que celles que l'on retrouve le plus fréquemment dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire déjà assez valable, non ?
pas tout a fais d'accord avec toi mais je me trompe peu etre, la paquet que tu recois ne porte pas le type d'extention je pense,
Tu penses bien, mais tu aurais pu lire en entier çi-dessus :
ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire
Je ne parlais pas de filtrer au niveau des paquet
oui a quoi ca sert alors ?
filtrage applicatif comme tu semble l'avoir comprie et completement autre chose ! va fais un tour sur www.arkoon.fr -- oui je sais...
Guillaume wrote:hébergeanttt ? Il va falloir que tnaviguerrques ça à ma
passerelle.
80 est le port au quel viens ce connecter un client http mais
ce n'est pas géneralement le port internet utilisé par
le browser,
netstat
tcp 0 0 192.168.22.250:33454 216.239.51.99:http
ESTABLISHED
ici le port qui est utiliser pour aller sur une page web est le port
33454
Non : c'est le port d'origine sur ton PC, le port de destination est
bien le 80 (et c'est ce qui importe un firewall), à moins que ce ne soit
pas du http ... ou que le serveur ne communique pas sur le port standard.
oui alors un pc hébergeant un site web ne peu pas naviguer sur le net vu que
sont port 80 est utiliser ? si tu fais du filtrage en interdisant les
paquet a destination de port 80 tu ne peu pas aller sur le net mais le port
qui est ouvert sur ta passerelle pour sortir ver le net pour surfer n'est
pas le port 80, comme tu la dis la destination et le port 80 mais pourquoi
bloquer le port 80 en destination enpecher les gens d'aller sur le net ?
je cite ce qui etait dit "a partir du moment ou certain ports
sont ouverts genre le 80 pour pouvoir allez sur le web,
il suffit de mettre dans la conbd de
emul/mldonkey/edonkey/.... le port qui vas bien."
le port 80 n'a pas a etre ouvert sur ton firewall mais sur le firewall du
serveur ! ferme ton port 80 et va voir si tu n'a pas la possibiliter de
surfer ! parcontre filtrer le paquet a destination du port 80 et autre
chose que de l'ouverture et de la fermeture de port !
Une autre solution pourrait consister à faire transiter le trafic vers
le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et
de paramétrer ces derniers pour refuser les extensions de fichiers
indésirables telles que celles que l'on retrouve le plus fréquemment
dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un
vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une
solution intermédiaire déjà assez valable, non ?
pas tout a fais d'accord avec toi mais je me trompe peu etre, la paquet
que tu recois ne porte pas le type d'extention je pense,
Tu penses bien, mais tu aurais pu lire en entier çi-dessus :
ce n'est pas non plus un
vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est
une solution intermédiaire
Je ne parlais pas de filtrer au niveau des paquet
oui a quoi ca sert alors ?
filtrage applicatif comme tu semble l'avoir comprie et completement autre
chose ! va fais un tour sur www.arkoon.fr
--
oui je sais...
Guillaume wrote:hébergeanttt ? Il va falloir que tnaviguerrques ça à ma passerelle.
80 est le port au quel viens ce connecter un client http mais ce n'est pas géneralement le port internet utilisé par le browser,
netstat
tcp 0 0 192.168.22.250:33454 216.239.51.99:http ESTABLISHED
ici le port qui est utiliser pour aller sur une page web est le port 33454
Non : c'est le port d'origine sur ton PC, le port de destination est bien le 80 (et c'est ce qui importe un firewall), à moins que ce ne soit pas du http ... ou que le serveur ne communique pas sur le port standard.
oui alors un pc hébergeant un site web ne peu pas naviguer sur le net vu que sont port 80 est utiliser ? si tu fais du filtrage en interdisant les paquet a destination de port 80 tu ne peu pas aller sur le net mais le port qui est ouvert sur ta passerelle pour sortir ver le net pour surfer n'est pas le port 80, comme tu la dis la destination et le port 80 mais pourquoi bloquer le port 80 en destination enpecher les gens d'aller sur le net ?
je cite ce qui etait dit "a partir du moment ou certain ports sont ouverts genre le 80 pour pouvoir allez sur le web, il suffit de mettre dans la conbd de emul/mldonkey/edonkey/.... le port qui vas bien."
le port 80 n'a pas a etre ouvert sur ton firewall mais sur le firewall du serveur ! ferme ton port 80 et va voir si tu n'a pas la possibiliter de surfer ! parcontre filtrer le paquet a destination du port 80 et autre chose que de l'ouverture et de la fermeture de port !
Une autre solution pourrait consister à faire transiter le trafic vers le Net par un Squid + SquidGuard à l'exclusion de tout autre chemin, et de paramétrer ces derniers pour refuser les extensions de fichiers indésirables telles que celles que l'on retrouve le plus fréquemment dans les échanges P2P. Ce n'est pas coûteux, ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire déjà assez valable, non ?
pas tout a fais d'accord avec toi mais je me trompe peu etre, la paquet que tu recois ne porte pas le type d'extention je pense,
Tu penses bien, mais tu aurais pu lire en entier çi-dessus :
ce n'est pas non plus un vrai firewall applicatif qui filtrerait au niveau 7 OSI, mais c'est une solution intermédiaire
Je ne parlais pas de filtrer au niveau des paquet
oui a quoi ca sert alors ?
filtrage applicatif comme tu semble l'avoir comprie et completement autre chose ! va fais un tour sur www.arkoon.fr -- oui je sais...
alban
Guillaume wrote:
En cette bucolique journée du Tue, 4 May 2004 15:22:45 +0200, TiChou nous diffusa sa prose en ces termes :
Non. Le P2P ce n'est pas du http.
Tu m'en diras tant.
le P2P n'est pas du http oui, mais le port 80 ne support que du HTTP ? je ne pense pas ! un socket sur le port 80 et comme l'ouverture d'un socket sur le port 4661.
-- oui je sais...
Guillaume wrote:
En cette bucolique journée du Tue, 4 May 2004 15:22:45 +0200, TiChou
nous diffusa sa prose en ces termes :
Non. Le P2P ce n'est pas du http.
Tu m'en diras tant.
le P2P n'est pas du http oui, mais le port 80 ne support que du HTTP ? je ne
pense pas ! un socket sur le port 80 et comme l'ouverture d'un socket sur
le port 4661.
En cette bucolique journée du Tue, 4 May 2004 15:22:45 +0200, TiChou nous diffusa sa prose en ces termes :
Non. Le P2P ce n'est pas du http.
Tu m'en diras tant.
le P2P n'est pas du http oui, mais le port 80 ne support que du HTTP ? je ne pense pas ! un socket sur le port 80 et comme l'ouverture d'un socket sur le port 4661.
