Bonjour,
Je ne suis pas (encore) un spécialiste reseaux et je souhaite faire un
firewall ave iptables (Linux ) . Je n'ai qu'une seule machine chez moi
donc pas de forwarding .
Mais avant , je voudrai donc savoir quels sont les ports que j'ai a
autoriser .
Il me semble avoir lu quelquepart que pour le http , le client adresse ses
requetes sur le port 80 et annonce au serveur sur quel port lui repondre (
ptet le 81 , j'en sais trop rien ) Est ce vrai ? dois-je laisser le traffic
sortant sans regles de filtrage ?
j'ai une utilisation personnelle de cette machine et elle fait aussi serveur
avec :
Pour utilisation personnelle :
-lecture des news (Usenet)
-irc
-pop /smtp de mes mail
-serveur d'impression CUPS ( port 631 )
-navigation web et ftp
Pour le coté utilisation serveur
-http
-ftp
Sauriez-vous donc les ports que je dois laisser "sans filtrage" pour ces
services ? merci de votre aide .
Les ports sont les port par defaut .. je ne les connais pas tous.. c'est
pour cela que je demande votre aide .
Cela est bien pratique en effet. Pratique aussi pour la personne malveillante qui cherche une cible au hasard. Le ping d'une plage d'adresse IP n'est pas rare. Si on y répond pas cela n'est qu'un début, nécessaire à mon avis qui nous permet de passer un peu plus inapercu que celui qui y répond. Cependant il est tout à fait possible d'accepter les echo-reply et pas les echo-request. De cette façon tu peux "pinguer", mais tu ne répondras pas aux pings des autres !
Pierre LALET wrote:
il serait bon que tu rajoutes a la liste: UDP 53 sortant pour faire la resolution de noms (vers les serveurs DNS de ton provider)
UDP *et* TCP port 53.
bloque de meme les pings sur ta machine (ICMP all entrant deny)
Pourquoi ? ping c'est pas mal. Faudrait voir à pas tomber dans la paranoïa extrème. Qu'on ne laisse pas passer tous les messages ICMP, ok, mais de là à empêcher les pings... quand on veut tester la connexion avec un autre site, c'est bien pratique.
Pierre
Cela est bien pratique en effet. Pratique aussi pour la personne
malveillante qui cherche une cible au hasard. Le ping d'une plage
d'adresse IP n'est pas rare. Si on y répond pas cela n'est qu'un début,
nécessaire à mon avis qui nous permet de passer un peu plus inapercu que
celui qui y répond.
Cependant il est tout à fait possible d'accepter les echo-reply et pas
les echo-request. De cette façon tu peux "pinguer", mais tu ne
répondras pas aux pings des autres !
Pierre LALET wrote:
il serait bon que tu rajoutes a la liste:
UDP 53 sortant pour faire la resolution de noms (vers les serveurs DNS de
ton provider)
UDP *et* TCP port 53.
bloque de meme les pings sur ta machine (ICMP all entrant deny)
Pourquoi ? ping c'est pas mal. Faudrait voir à pas tomber dans la
paranoïa extrème. Qu'on ne laisse pas passer tous les messages ICMP, ok,
mais de là à empêcher les pings... quand on veut tester la connexion
avec un autre site, c'est bien pratique.
Cela est bien pratique en effet. Pratique aussi pour la personne malveillante qui cherche une cible au hasard. Le ping d'une plage d'adresse IP n'est pas rare. Si on y répond pas cela n'est qu'un début, nécessaire à mon avis qui nous permet de passer un peu plus inapercu que celui qui y répond. Cependant il est tout à fait possible d'accepter les echo-reply et pas les echo-request. De cette façon tu peux "pinguer", mais tu ne répondras pas aux pings des autres !
Pierre LALET wrote:
il serait bon que tu rajoutes a la liste: UDP 53 sortant pour faire la resolution de noms (vers les serveurs DNS de ton provider)
UDP *et* TCP port 53.
bloque de meme les pings sur ta machine (ICMP all entrant deny)
Pourquoi ? ping c'est pas mal. Faudrait voir à pas tomber dans la paranoïa extrème. Qu'on ne laisse pas passer tous les messages ICMP, ok, mais de là à empêcher les pings... quand on veut tester la connexion avec un autre site, c'est bien pratique.
Pierre
Rakotomandimby Mihamina
T0t0 wrote:
Oui pour le début. Lorsque tu essaies de te connecter à un serveur web, ton navigateur initialise une connexion vers le port 80 du serveur. De plus, ta machine doit aussi pouvoir recevoir les réponses du serveur. Pour cela, elle se met en écoute sur un port dit "élevé" (>1024). C'est le port source. Donc c'est pas 81, mais un port censé être aléatoire entre 1024 et 65535. Les ports entre 1 et 1023 sont réservés pour certaines applications client/serveur, comme 80 pour http par exemple. ca m'aide pas ça ...
et comment ils s'en sortent ceux qui veulent mettre un firewall ? quelle genre de solution ils ont face a cette situation de "port aleatoire" ? -- RKTMB http://mrakotom.free.fr
T0t0 wrote:
Oui pour le début. Lorsque tu essaies de te connecter à un serveur
web, ton navigateur initialise une connexion vers le port 80 du
serveur. De plus, ta machine doit aussi pouvoir recevoir les réponses
du serveur. Pour cela, elle se met en écoute sur un port dit "élevé"
(>1024). C'est le port source. Donc c'est pas 81, mais un port censé
être aléatoire entre 1024 et 65535. Les ports entre 1 et 1023 sont
réservés pour certaines applications client/serveur, comme 80 pour http
par exemple.
ca m'aide pas ça ...
et comment ils s'en sortent ceux qui veulent mettre un firewall ?
quelle genre de solution ils ont face a cette situation de "port aleatoire"
?
--
RKTMB http://mrakotom.free.fr
Oui pour le début. Lorsque tu essaies de te connecter à un serveur web, ton navigateur initialise une connexion vers le port 80 du serveur. De plus, ta machine doit aussi pouvoir recevoir les réponses du serveur. Pour cela, elle se met en écoute sur un port dit "élevé" (>1024). C'est le port source. Donc c'est pas 81, mais un port censé être aléatoire entre 1024 et 65535. Les ports entre 1 et 1023 sont réservés pour certaines applications client/serveur, comme 80 pour http par exemple. ca m'aide pas ça ...
et comment ils s'en sortent ceux qui veulent mettre un firewall ? quelle genre de solution ils ont face a cette situation de "port aleatoire" ? -- RKTMB http://mrakotom.free.fr
Nicob
On Wed, 27 Aug 2003 08:37:03 +0000, Julien Salgado wrote:
Iirc, udp est suffisant, tcp ne servant que pour les transferts de zone.
Sauf si la reponse est trop de taille trop importante pour 1 paquet UDP, auquel cas la réponse UDP à le drapeau TC postionné (Tuncated Bit) et le client peut refaire sa requête si les information transmise dans la réponse UDP ne son pas suffisante (cf RFC 2181).
Je suis ravi de voir autant de monde répondre présent pour tordre le coup à cette vieille légende urbaine :)
Parceque n'autoriser que le UDP/53 et devoir débugger ce type de problème, c'est la croix et la bannière. Mais bon, je suis sûr qu'on va encore devoir passer un moment à expliquer que non, TCP/53 ne sert pas qu'aux transferts de zone.
Btw, est-ce que quelqu'un à un exemple de résolution passant en TCP (soit un site web ayant de multiples IP, soit un domaine ayant de nombreux MX) ? J'en avais trouvé un, mais je n'arrive plus à mettre la main dessus ...
(Non non, je ne suis pas HS. Je cherche justement un exemple pour démontrer la stupidité de certaines configurations de firewalls)
Nicob
On Wed, 27 Aug 2003 08:37:03 +0000, Julien Salgado wrote:
Iirc, udp est suffisant, tcp ne servant que pour les transferts de zone.
Sauf si la reponse est trop de taille trop importante pour 1 paquet UDP,
auquel cas la réponse UDP à le drapeau TC postionné (Tuncated Bit) et le
client peut refaire sa requête si les information transmise dans la
réponse UDP ne son pas suffisante (cf RFC 2181).
Je suis ravi de voir autant de monde répondre présent pour tordre le coup à
cette vieille légende urbaine :)
Parceque n'autoriser que le UDP/53 et devoir débugger ce type de problème,
c'est la croix et la bannière. Mais bon, je suis sûr qu'on va encore
devoir passer un moment à expliquer que non, TCP/53 ne sert pas qu'aux
transferts de zone.
Btw, est-ce que quelqu'un à un exemple de résolution passant en TCP (soit
un site web ayant de multiples IP, soit un domaine ayant de nombreux MX) ?
J'en avais trouvé un, mais je n'arrive plus à mettre la main dessus ...
(Non non, je ne suis pas HS. Je cherche justement un exemple pour
démontrer la stupidité de certaines configurations de firewalls)
On Wed, 27 Aug 2003 08:37:03 +0000, Julien Salgado wrote:
Iirc, udp est suffisant, tcp ne servant que pour les transferts de zone.
Sauf si la reponse est trop de taille trop importante pour 1 paquet UDP, auquel cas la réponse UDP à le drapeau TC postionné (Tuncated Bit) et le client peut refaire sa requête si les information transmise dans la réponse UDP ne son pas suffisante (cf RFC 2181).
Je suis ravi de voir autant de monde répondre présent pour tordre le coup à cette vieille légende urbaine :)
Parceque n'autoriser que le UDP/53 et devoir débugger ce type de problème, c'est la croix et la bannière. Mais bon, je suis sûr qu'on va encore devoir passer un moment à expliquer que non, TCP/53 ne sert pas qu'aux transferts de zone.
Btw, est-ce que quelqu'un à un exemple de résolution passant en TCP (soit un site web ayant de multiples IP, soit un domaine ayant de nombreux MX) ? J'en avais trouvé un, mais je n'arrive plus à mettre la main dessus ...
(Non non, je ne suis pas HS. Je cherche justement un exemple pour démontrer la stupidité de certaines configurations de firewalls)
Nicob
Pierre LALET
Cela est bien pratique en effet. Pratique aussi pour la personne malveillante qui cherche une cible au hasard. Le ping d'une plage d'adresse IP n'est pas rare. Si on y répond pas cela n'est qu'un début, nécessaire à mon avis qui nous permet de passer un peu plus inapercu que celui qui y répond.
Ma vision des choses est que ce genre de pratiques est inutile. Je tiens mes machines à jour régulièrement, et cela suffit à éloigner les 'script kidies' boutonneux.
Je pense que si l'on a un bon système, cela apporte plus d'ennuis que d'avantages.
Quant au ping d'une plage IP, cela arrive en effet (j'en vois passer un paquet sur les miennes), mais je réponds sur toutes les adresses des plages, ce qui ralentit pas mal les scanneurs.
Pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Cela est bien pratique en effet. Pratique aussi pour la personne
malveillante qui cherche une cible au hasard. Le ping d'une plage
d'adresse IP n'est pas rare. Si on y répond pas cela n'est qu'un début,
nécessaire à mon avis qui nous permet de passer un peu plus inapercu que
celui qui y répond.
Ma vision des choses est que ce genre de pratiques est inutile. Je tiens
mes machines à jour régulièrement, et cela suffit à éloigner les 'script
kidies' boutonneux.
Je pense que si l'on a un bon système, cela apporte plus d'ennuis que
d'avantages.
Quant au ping d'une plage IP, cela arrive en effet (j'en vois passer un
paquet sur les miennes), mais je réponds sur toutes les adresses des
plages, ce qui ralentit pas mal les scanneurs.
Pierre
--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Cela est bien pratique en effet. Pratique aussi pour la personne malveillante qui cherche une cible au hasard. Le ping d'une plage d'adresse IP n'est pas rare. Si on y répond pas cela n'est qu'un début, nécessaire à mon avis qui nous permet de passer un peu plus inapercu que celui qui y répond.
Ma vision des choses est que ce genre de pratiques est inutile. Je tiens mes machines à jour régulièrement, et cela suffit à éloigner les 'script kidies' boutonneux.
Je pense que si l'on a un bon système, cela apporte plus d'ennuis que d'avantages.
Quant au ping d'une plage IP, cela arrive en effet (j'en vois passer un paquet sur les miennes), mais je réponds sur toutes les adresses des plages, ce qui ralentit pas mal les scanneurs.
Pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Pierre LALET
Oui pour le début. Lorsque tu essaies de te connecter à un serveur web, ton navigateur initialise une connexion vers le port 80 du serveur. De plus, ta machine doit aussi pouvoir recevoir les réponses du serveur. Pour cela, elle se met en écoute sur un port dit "élevé"
Non. La machine n'écoute pas sur un port élevé, il n'y a qu'un seul canal de communication.
Et comment tu reçois ta réponse ? Le port source il est là pour juste pour faire joli ?
Non ; mais le client ne se met pas en écoute. Il initie la connexion à partir d'un port élevé, et dans *ce* socket, reçoit la réponse. Il fait donc appel à la primitive 'connect', mais ni à 'listen', ni à 'accept'.
Ce que tu décris par contre correspond à peu près à ce qui se passe pour le ftp actif : le client initie la connexion depuis un port élevé vers le port 21 du serveur ('connect'), puis le serveur lui demande d'ouvrir un port élevé ('listen'), et d'accepter la connexion que le serveur initie vers le client à partir de son port 20 vers le port élevé en question ('accept').
Donc :
[...] De plus, ta machine doit aussi pouvoir recevoir les réponses du serveur. Pour cela, elle se met en écoute sur un port dit "élevé" Non.
N'oublies pas le module ftp pour iptables (ip_conntrack_ftp et ip_nat_ftp si je me rappelle bien)
Euh... il me semble que dans son cas ("Je n'ai qu'une seule machine chez moi donc pas de forwarding") ce ne sera pas nécessaire.
Si si, pas le NAT effectivement, mais il vaut mieux avoir conntrack pour profiter de l'état RELATED.
Oui, bien sur.
Pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Oui pour le début. Lorsque tu essaies de te connecter à un serveur
web, ton navigateur initialise une connexion vers le port 80 du
serveur. De plus, ta machine doit aussi pouvoir recevoir les réponses
du serveur. Pour cela, elle se met en écoute sur un port dit "élevé"
Non. La machine n'écoute pas sur un port élevé, il n'y a qu'un seul
canal de communication.
Et comment tu reçois ta réponse ?
Le port source il est là pour juste pour faire joli ?
Non ; mais le client ne se met pas en écoute. Il initie la connexion à
partir d'un port élevé, et dans *ce* socket, reçoit la réponse. Il fait
donc appel à la primitive 'connect', mais ni à 'listen', ni à 'accept'.
Ce que tu décris par contre correspond à peu près à ce qui se passe pour
le ftp actif : le client initie la connexion depuis un port élevé vers
le port 21 du serveur ('connect'), puis le serveur lui demande d'ouvrir
un port élevé ('listen'), et d'accepter la connexion que le serveur
initie vers le client à partir de son port 20 vers le port élevé en
question ('accept').
Donc :
[...] De plus, ta machine doit aussi pouvoir recevoir les réponses
du serveur. Pour cela, elle se met en écoute sur un port dit "élevé"
Non.
N'oublies pas le module ftp pour iptables (ip_conntrack_ftp et
ip_nat_ftp si je me rappelle bien)
Euh... il me semble que dans son cas ("Je n'ai qu'une seule machine chez
moi donc pas de forwarding") ce ne sera pas nécessaire.
Si si, pas le NAT effectivement, mais il vaut mieux avoir conntrack
pour profiter de l'état RELATED.
Oui, bien sur.
Pierre
--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Oui pour le début. Lorsque tu essaies de te connecter à un serveur web, ton navigateur initialise une connexion vers le port 80 du serveur. De plus, ta machine doit aussi pouvoir recevoir les réponses du serveur. Pour cela, elle se met en écoute sur un port dit "élevé"
Non. La machine n'écoute pas sur un port élevé, il n'y a qu'un seul canal de communication.
Et comment tu reçois ta réponse ? Le port source il est là pour juste pour faire joli ?
Non ; mais le client ne se met pas en écoute. Il initie la connexion à partir d'un port élevé, et dans *ce* socket, reçoit la réponse. Il fait donc appel à la primitive 'connect', mais ni à 'listen', ni à 'accept'.
Ce que tu décris par contre correspond à peu près à ce qui se passe pour le ftp actif : le client initie la connexion depuis un port élevé vers le port 21 du serveur ('connect'), puis le serveur lui demande d'ouvrir un port élevé ('listen'), et d'accepter la connexion que le serveur initie vers le client à partir de son port 20 vers le port élevé en question ('accept').
Donc :
[...] De plus, ta machine doit aussi pouvoir recevoir les réponses du serveur. Pour cela, elle se met en écoute sur un port dit "élevé" Non.
N'oublies pas le module ftp pour iptables (ip_conntrack_ftp et ip_nat_ftp si je me rappelle bien)
Euh... il me semble que dans son cas ("Je n'ai qu'une seule machine chez moi donc pas de forwarding") ce ne sera pas nécessaire.
Si si, pas le NAT effectivement, mais il vaut mieux avoir conntrack pour profiter de l'état RELATED.
Oui, bien sur.
Pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Pierre LALET
ca m'aide pas ça ... et comment ils s'en sortent ceux qui veulent mettre un firewall ? quelle genre de solution ils ont face a cette situation de "port aleatoire" ?
Il faut un firewall 'statefull', c'est-à-dire qui soit capable de se souvenir que tu as initié une connection depuis ton port N vers le port 80 de www.vpn.u-bordeaux.fr (</pub> ;-) ), et que donc il peut accepter les paquets de réponse. Pour FTP, il faut faire la même chose, mais en bonus, il y a un port sur lequel il faut écouter, et c'est plus complexe, car le port à ouvrir est passé au niveau applicatif. Il faut donc soit un proxy transparent, soit un module du firewall capable de lire et d'interpréter la commande (PORT il me semble).
Pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
ca m'aide pas ça ...
et comment ils s'en sortent ceux qui veulent mettre un firewall ?
quelle genre de solution ils ont face a cette situation de "port aleatoire"
?
Il faut un firewall 'statefull', c'est-à-dire qui soit capable de se
souvenir que tu as initié une connection depuis ton port N vers le port
80 de www.vpn.u-bordeaux.fr (</pub> ;-) ), et que donc il peut accepter
les paquets de réponse. Pour FTP, il faut faire la même chose, mais en
bonus, il y a un port sur lequel il faut écouter, et c'est plus
complexe, car le port à ouvrir est passé au niveau applicatif. Il faut
donc soit un proxy transparent, soit un module du firewall capable de
lire et d'interpréter la commande (PORT il me semble).
Pierre
--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
ca m'aide pas ça ... et comment ils s'en sortent ceux qui veulent mettre un firewall ? quelle genre de solution ils ont face a cette situation de "port aleatoire" ?
Il faut un firewall 'statefull', c'est-à-dire qui soit capable de se souvenir que tu as initié une connection depuis ton port N vers le port 80 de www.vpn.u-bordeaux.fr (</pub> ;-) ), et que donc il peut accepter les paquets de réponse. Pour FTP, il faut faire la même chose, mais en bonus, il y a un port sur lequel il faut écouter, et c'est plus complexe, car le port à ouvrir est passé au niveau applicatif. Il faut donc soit un proxy transparent, soit un module du firewall capable de lire et d'interpréter la commande (PORT il me semble).
Pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
T0t0
"Rakotomandimby Mihamina" wrote in message news:3f4b67ab$0$27058$
ca m'aide pas ça ...
Désolé :-(
et comment ils s'en sortent ceux qui veulent mettre un firewall ?
Sans vouloir être sarcastique, la plupart du temps ils installent un firewall. Le configurent comme ils le peuvent, et si ca marche, on laisse en l'état, si ca marche pas, on desinstalle, ou on ouvre tout plein de choses plus ou moins utiles.
Le problème majeur à mon avis est que la configuration correcte d'un firewall n'est pas une chose aisée. Elle nécessite la connaissance des protocoles utilisés, de l'architecture, des flux, etc. Les firewalls personnels proposent des solutions, qui ne sont pas adaptées, à mon avis.
On en arrive à des situations ou les gens pensent être protégés par la simple utilisation d'un firewall... sachant que c'est surtout la configuration de celui-ci qui est importante.
quelle genre de solution ils ont face a cette situation de "port aleatoire" ?
Il me semble que j'avais mis un élément de réponse dans mon premier mail (tout fermer, voir ce qui pose problème, puis ouvrir au coup par coup) Pour compléter, même si les ports source sont choisis aléatoirement, un firewall stateful pourra laisser passer les flux de retour sur le port choisi dynamiquement sans intervention dans la configuration. Ainsi, si tu veux surfer, par exemple, tu laisses sortir le port 80 en destination, et ton firewall sera capable de reconnaître le flux de retour et de le laisser passer.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Rakotomandimby Mihamina" <mrakotom@free.fr> wrote in message
news:3f4b67ab$0$27058$626a54ce@news.free.fr
ca m'aide pas ça ...
Désolé :-(
et comment ils s'en sortent ceux qui veulent mettre un firewall ?
Sans vouloir être sarcastique, la plupart du temps ils installent un
firewall. Le configurent comme ils le peuvent, et si ca marche, on
laisse en l'état, si ca marche pas, on desinstalle, ou on ouvre tout
plein de choses plus ou moins utiles.
Le problème majeur à mon avis est que la configuration correcte d'un
firewall n'est pas une chose aisée. Elle nécessite la connaissance
des protocoles utilisés, de l'architecture, des flux, etc.
Les firewalls personnels proposent des solutions, qui ne sont pas
adaptées, à mon avis.
On en arrive à des situations ou les gens pensent être protégés
par la simple utilisation d'un firewall... sachant que c'est surtout
la configuration de celui-ci qui est importante.
quelle genre de solution ils ont face a cette situation de "port aleatoire"
?
Il me semble que j'avais mis un élément de réponse dans mon premier
mail (tout fermer, voir ce qui pose problème, puis ouvrir au coup par
coup)
Pour compléter, même si les ports source sont choisis aléatoirement,
un firewall stateful pourra laisser passer les flux de retour sur le
port choisi dynamiquement sans intervention dans la configuration.
Ainsi, si tu veux surfer, par exemple, tu laisses sortir le port 80
en destination, et ton firewall sera capable de reconnaître le flux de
retour et de le laisser passer.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Rakotomandimby Mihamina" wrote in message news:3f4b67ab$0$27058$
ca m'aide pas ça ...
Désolé :-(
et comment ils s'en sortent ceux qui veulent mettre un firewall ?
Sans vouloir être sarcastique, la plupart du temps ils installent un firewall. Le configurent comme ils le peuvent, et si ca marche, on laisse en l'état, si ca marche pas, on desinstalle, ou on ouvre tout plein de choses plus ou moins utiles.
Le problème majeur à mon avis est que la configuration correcte d'un firewall n'est pas une chose aisée. Elle nécessite la connaissance des protocoles utilisés, de l'architecture, des flux, etc. Les firewalls personnels proposent des solutions, qui ne sont pas adaptées, à mon avis.
On en arrive à des situations ou les gens pensent être protégés par la simple utilisation d'un firewall... sachant que c'est surtout la configuration de celui-ci qui est importante.
quelle genre de solution ils ont face a cette situation de "port aleatoire" ?
Il me semble que j'avais mis un élément de réponse dans mon premier mail (tout fermer, voir ce qui pose problème, puis ouvrir au coup par coup) Pour compléter, même si les ports source sont choisis aléatoirement, un firewall stateful pourra laisser passer les flux de retour sur le port choisi dynamiquement sans intervention dans la configuration. Ainsi, si tu veux surfer, par exemple, tu laisses sortir le port 80 en destination, et ton firewall sera capable de reconnaître le flux de retour et de le laisser passer.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
T0t0
"Pierre LALET" wrote in message news:biht7i$3l0$
Non ; mais le client ne se met pas en écoute. Il initie la connexion à partir d'un port élevé, et dans *ce* socket, reçoit la réponse. Il fait donc appel à la primitive 'connect', mais ni à 'listen', ni à 'accept'.
Je ne parle pas de l'aspect applicatif, mais de l'aspect réseau. Lorsque tu inities une connexion vers un serveur, ta machine se met en écoute sur le port source choisi. C'est comme cela que tu peux recevoir la réponse du serveur à tes requêtes (et que la réponse peut être retransmise à la socket en écoute)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Pierre LALET" <lalet@enseirb.fr> wrote in message
news:biht7i$3l0$1@news.u-bordeaux.fr
Non ; mais le client ne se met pas en écoute. Il initie la connexion à
partir d'un port élevé, et dans *ce* socket, reçoit la réponse. Il fait
donc appel à la primitive 'connect', mais ni à 'listen', ni à 'accept'.
Je ne parle pas de l'aspect applicatif, mais de l'aspect réseau.
Lorsque tu inities une connexion vers un serveur, ta machine se met
en écoute sur le port source choisi. C'est comme cela que tu peux
recevoir la réponse du serveur à tes requêtes (et que la réponse peut
être retransmise à la socket en écoute)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Non ; mais le client ne se met pas en écoute. Il initie la connexion à partir d'un port élevé, et dans *ce* socket, reçoit la réponse. Il fait donc appel à la primitive 'connect', mais ni à 'listen', ni à 'accept'.
Je ne parle pas de l'aspect applicatif, mais de l'aspect réseau. Lorsque tu inities une connexion vers un serveur, ta machine se met en écoute sur le port source choisi. C'est comme cela que tu peux recevoir la réponse du serveur à tes requêtes (et que la réponse peut être retransmise à la socket en écoute)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
