Après une petite vérification de sécurité sur sygate, je constate que les
ports 80 (web), 110 (pop3), 113 (ident), 139 (NetBIOS), 443 (HTTPS) , 445
(Server Message Block), 1080 (Socks Proxy) et 8080 (Web Proxy) sont fermés
en accès sur ma Mandrake, mais ils ne sont pas invisibles (stealth du net.
J'utilise shorewall comme pare-feu.
Question:
Est-il souhaitable de rendre ces ports invisibles à partir du Net? Si oui,
vous auriez une URL à me conseiller? Je dis tout de suite que malgré ma
lecture de la documentation de shorewal, je ne comprends rien à tous ces
ACCEPT, DROP et autres.
Le 18 Juin 2004 09:17 Corsica a écrit en cette journée dans fr.comp.os.linux.configuration:
Salut ! Bonjour
Petit question : Tu utilise un modem Usb ou Ethernet pour te connecter ? Un modem Ethernet car je préfère au USB.
Corsica
Le 18 Juin 2004 09:17 Corsica a écrit en cette journée dans fr.comp.os.linux.configuration:
Salut !
Bonjour
Petit question : Tu utilise un modem Usb ou Ethernet pour te connecter ?
Un modem Ethernet car je préfère au USB.
Salut !
J'ai eu le même soucis. Avant, j'avais un modem usb et tous les ports étaient OK. Depuis le début de la semaine je suis passé sur un modem routeur Ethernet (c'est le top avec Linux !) et j'avais 2 ports ouverts, le 80 & le 21. Va voir dans la config de ton modem (Routeur ?) si par hasard tu n'as pas un petit serveur web activé ? C'est en fait lui qui te permet de faire la configuration du modem. Si je ne m'abuse, pour le paramètrer tu ouvre ton navigateur et tu tape l'adresse IP du modem ? Si c'est le cas, tu as donc un petit serveur web.... sur le port 80 ! Pour ma part, je suis passé en DMZ avec tout le traffic qui est directement dirigé vers mon PC (Mandrake 10.0 avec Guarddog). Du coup, tous les ports sont à nouveau Ok !
A+ et Bien le Bonjour de Corse
Le 18 Juin 2004 09:17 Corsica a écrit en cette journée dans
fr.comp.os.linux.configuration:
Salut !
Bonjour
Petit question : Tu utilise un modem Usb ou Ethernet pour te connecter ?
Un modem Ethernet car je préfère au USB.
Salut !
J'ai eu le même soucis. Avant, j'avais un modem usb et tous les ports
étaient OK. Depuis le début de la semaine je suis passé sur un modem
routeur Ethernet (c'est le top avec Linux !) et j'avais 2 ports ouverts,
le 80 & le 21.
Va voir dans la config de ton modem (Routeur ?) si par hasard tu n'as
pas un petit serveur web activé ? C'est en fait lui qui te permet de
faire la configuration du modem.
Si je ne m'abuse, pour le paramètrer tu ouvre ton navigateur et tu tape
l'adresse IP du modem ? Si c'est le cas, tu as donc un petit serveur
web.... sur le port 80 !
Pour ma part, je suis passé en DMZ avec tout le traffic qui est
directement dirigé vers mon PC (Mandrake 10.0 avec Guarddog). Du coup,
tous les ports sont à nouveau Ok !
Le 18 Juin 2004 09:17 Corsica a écrit en cette journée dans fr.comp.os.linux.configuration:
Salut !
Bonjour
Petit question : Tu utilise un modem Usb ou Ethernet pour te connecter ?
Un modem Ethernet car je préfère au USB.
Salut !
J'ai eu le même soucis. Avant, j'avais un modem usb et tous les ports étaient OK. Depuis le début de la semaine je suis passé sur un modem routeur Ethernet (c'est le top avec Linux !) et j'avais 2 ports ouverts, le 80 & le 21. Va voir dans la config de ton modem (Routeur ?) si par hasard tu n'as pas un petit serveur web activé ? C'est en fait lui qui te permet de faire la configuration du modem. Si je ne m'abuse, pour le paramètrer tu ouvre ton navigateur et tu tape l'adresse IP du modem ? Si c'est le cas, tu as donc un petit serveur web.... sur le port 80 ! Pour ma part, je suis passé en DMZ avec tout le traffic qui est directement dirigé vers mon PC (Mandrake 10.0 avec Guarddog). Du coup, tous les ports sont à nouveau Ok !
A+ et Bien le Bonjour de Corse
g.patel
On Fri, 18 Jun 2004 13:34:11 +0200, "Annie D." wrote:
Et un port invisible ne répond pas, il est donc par définition fermé.
A ne pas confondre avec un port fermé, qui, lui, répond poliment qu'il est fermé.
Tout à fait. Un port fermé peut soit répondre qu'il l'est, soit ne pas répondre. Si un port répond, il peut soit accepter la connexion, il est alors dit 'ouvert', soit répondre qu'il est fermé, il est alors dit 'fermé'. S'il ne répond pas, il peut etre considéré comme fermé si l'on sait par ailleurs qu'il y a une machine à l'adresse interrogée. Si l'on ne le sait pas, on peut aussi le supposer inexistant, ainsi que la machine. Merci de cette précision qui s'imposait.
Gérard Patel
On Fri, 18 Jun 2004 13:34:11 +0200, "Annie D." <annie.demur@free.fr>
wrote:
Et un port invisible ne répond pas, il est donc par définition fermé.
A ne pas confondre avec un port fermé, qui, lui, répond poliment qu'il
est fermé.
Tout à fait.
Un port fermé peut soit répondre qu'il l'est, soit ne pas répondre.
Si un port répond, il peut soit accepter la connexion, il est alors
dit 'ouvert', soit répondre qu'il est fermé, il est alors dit 'fermé'.
S'il ne répond pas, il peut etre considéré comme fermé si l'on
sait par ailleurs qu'il y a une machine à l'adresse interrogée.
Si l'on ne le sait pas, on peut aussi le supposer inexistant, ainsi
que la machine.
Merci de cette précision qui s'imposait.
On Fri, 18 Jun 2004 13:34:11 +0200, "Annie D." wrote:
Et un port invisible ne répond pas, il est donc par définition fermé.
A ne pas confondre avec un port fermé, qui, lui, répond poliment qu'il est fermé.
Tout à fait. Un port fermé peut soit répondre qu'il l'est, soit ne pas répondre. Si un port répond, il peut soit accepter la connexion, il est alors dit 'ouvert', soit répondre qu'il est fermé, il est alors dit 'fermé'. S'il ne répond pas, il peut etre considéré comme fermé si l'on sait par ailleurs qu'il y a une machine à l'adresse interrogée. Si l'on ne le sait pas, on peut aussi le supposer inexistant, ainsi que la machine. Merci de cette précision qui s'imposait.
Gérard Patel
Ronald
Le Thu, 17 Jun 2004 23:46:21 +0000, Nicolas George a écrit :
Bref, à part des cas très particulier (DoS par saturation de la bande passante montante en ADSL, ou bien bande passante montante facturée comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple, c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
Le Thu, 17 Jun 2004 23:46:21 +0000, Nicolas George a écrit :
Bref, à part des cas très particulier (DoS par saturation de la bande
passante montante en ADSL, ou bien bande passante montante facturée comme
naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall
est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible
étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT
--reject-with icmp-port-unreachable par exemple, c'est peut être pour ça
que le conseil que tout soit en DROP par défaut est généralement donné.
Le Thu, 17 Jun 2004 23:46:21 +0000, Nicolas George a écrit :
Bref, à part des cas très particulier (DoS par saturation de la bande passante montante en ADSL, ou bien bande passante montante facturée comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple, c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
g.patel
On Fri, 18 Jun 2004 12:50:13 GMT, Paul Pygeon wrote:
la documentation de shorewall m'a laissé sur ma faim. Les DROP, ACCEPT, REJECT restent pour moi un véritable mystère
Bon. Le protocole Tcp définit des 'ports' qui sont en fait de simples numéros dans un endroit donné d'un paquet Tcp Lorsque le système d'exploitation reçoit une demande de connexion Tcp, il regarde ce numéro et répond en fonction de la configuration du parefeu :
- Drop : le paquet est ignoré; l'appellant a une non-réponse qu'il détecte éventuellement au bout d'un certain temps. - Reject : le système renvoie une réponse informant poliment l'appellant que la 'porte' est fermée. - Accept : le système laisse passer le paquet en destination des applications; il faut qu'une application lance un processus appellé 'écoute' sur ce numéro de port pour que la connexion réussisse. Dans ce dernier cas, un programme placé sur la machine locale peut dialoguer avec un programme située sur une machine distante.
Gérard Patel
On Fri, 18 Jun 2004 12:50:13 GMT, Paul Pygeon
<ppigeonNOSPAM@globetrotter.net> wrote:
la documentation de shorewall m'a laissé sur ma faim. Les DROP, ACCEPT,
REJECT restent pour moi un véritable mystère
Bon.
Le protocole Tcp définit des 'ports' qui sont en fait de simples
numéros dans un endroit donné d'un paquet Tcp
Lorsque le système d'exploitation reçoit une demande de connexion
Tcp, il regarde ce numéro et répond en fonction de la configuration
du parefeu :
- Drop : le paquet est ignoré; l'appellant a une non-réponse
qu'il détecte éventuellement au bout d'un certain temps.
- Reject : le système renvoie une réponse informant poliment
l'appellant que la 'porte' est fermée.
- Accept : le système laisse passer le paquet en destination des
applications; il faut qu'une application lance un processus appellé
'écoute' sur ce numéro de port pour que la connexion réussisse.
Dans ce dernier cas, un programme placé sur la machine locale
peut dialoguer avec un programme située sur une machine
distante.
On Fri, 18 Jun 2004 12:50:13 GMT, Paul Pygeon wrote:
la documentation de shorewall m'a laissé sur ma faim. Les DROP, ACCEPT, REJECT restent pour moi un véritable mystère
Bon. Le protocole Tcp définit des 'ports' qui sont en fait de simples numéros dans un endroit donné d'un paquet Tcp Lorsque le système d'exploitation reçoit une demande de connexion Tcp, il regarde ce numéro et répond en fonction de la configuration du parefeu :
- Drop : le paquet est ignoré; l'appellant a une non-réponse qu'il détecte éventuellement au bout d'un certain temps. - Reject : le système renvoie une réponse informant poliment l'appellant que la 'porte' est fermée. - Accept : le système laisse passer le paquet en destination des applications; il faut qu'une application lance un processus appellé 'écoute' sur ce numéro de port pour que la connexion réussisse. Dans ce dernier cas, un programme placé sur la machine locale peut dialoguer avec un programme située sur une machine distante.
Gérard Patel
Nicolas George
Ronald wrote in message :
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple, c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
Il doit suffire d'une règle à la fin qui matche tout ce qui n'est pas matché plus haut. Je n'ai pas examiné la question en détail.
Ronald wrote in message <pan.2004.06.18.16.00.50.930326@reply.to>:
Et tu le mets comment en politique par défaut, REJECT est une cible
étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT
--reject-with icmp-port-unreachable par exemple, c'est peut être pour ça
que le conseil que tout soit en DROP par défaut est généralement donné.
Il doit suffire d'une règle à la fin qui matche tout ce qui n'est pas
matché plus haut. Je n'ai pas examiné la question en détail.
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple, c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
Il doit suffire d'une règle à la fin qui matche tout ce qui n'est pas matché plus haut. Je n'ai pas examiné la question en détail.
TiChou
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Bref, à part des cas très particulier (DoS par saturation de la bande passante montante en ADSL, ou bien bande passante montante facturée comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple,
La politique par défaut ne sert pas à filtrer mais à décider de ce qui sera fait des paquets qui n'auraient pas été filtrés, c'est-à-dire les ignorer ou les laisser passer. En principe, dans un bon firewall, un paquet devrait au moins passer dans une des règles du firewall et avoir eu une décision prise sur celui-ci.
c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
Non, c'est tout simplement parce que c'est plus facile d'ignorer un paquet que de prendre la bonne décision et l'action à effectuer sur chaque paquet qui traverse la pile réseau. C'est ce que je qualifie des fois le « firewall du pauvre ». Les paquets qui doivent être ignorés sont généralement les paquets invalides, les protocoles non pris en charge, les réseaux non routables et diverses petites choses.
-- TiChou
Dans le message <news:pan.2004.06.18.16.00.50.930326@reply.to>,
*Ronald* tapota sur f.c.o.l.configuration :
Bref, à part des cas très particulier (DoS par saturation de la bande
passante montante en ADSL, ou bien bande passante montante facturée
comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall
est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible
étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT
--reject-with icmp-port-unreachable par exemple,
La politique par défaut ne sert pas à filtrer mais à décider de ce qui sera
fait des paquets qui n'auraient pas été filtrés, c'est-à-dire les ignorer ou
les laisser passer. En principe, dans un bon firewall, un paquet devrait au
moins passer dans une des règles du firewall et avoir eu une décision prise
sur celui-ci.
c'est peut être pour ça que le conseil que tout soit en DROP par défaut
est généralement donné.
Non, c'est tout simplement parce que c'est plus facile d'ignorer un paquet
que de prendre la bonne décision et l'action à effectuer sur chaque paquet
qui traverse la pile réseau. C'est ce que je qualifie des fois le « firewall
du pauvre ».
Les paquets qui doivent être ignorés sont généralement les paquets
invalides, les protocoles non pris en charge, les réseaux non routables et
diverses petites choses.
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Bref, à part des cas très particulier (DoS par saturation de la bande passante montante en ADSL, ou bien bande passante montante facturée comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple,
La politique par défaut ne sert pas à filtrer mais à décider de ce qui sera fait des paquets qui n'auraient pas été filtrés, c'est-à-dire les ignorer ou les laisser passer. En principe, dans un bon firewall, un paquet devrait au moins passer dans une des règles du firewall et avoir eu une décision prise sur celui-ci.
c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
Non, c'est tout simplement parce que c'est plus facile d'ignorer un paquet que de prendre la bonne décision et l'action à effectuer sur chaque paquet qui traverse la pile réseau. C'est ce que je qualifie des fois le « firewall du pauvre ». Les paquets qui doivent être ignorés sont généralement les paquets invalides, les protocoles non pris en charge, les réseaux non routables et diverses petites choses.
-- TiChou
Ronald
Le Fri, 18 Jun 2004 22:18:47 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Bref, à part des cas très particulier (DoS par saturation de la bande passante montante en ADSL, ou bien bande passante montante facturée comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple,
La politique par défaut ne sert pas à filtrer mais à décider de ce qui sera fait des paquets qui n'auraient pas été filtrés, c'est-à-dire les ignorer ou les laisser passer. En principe, dans un bon firewall, un paquet devrait au moins passer dans une des règles du firewall et avoir eu une décision prise sur celui-ci.
Et? Lorsque la politique par défaut est en DROP, un paquet qui ne matche aucune règles est ignoré, il y a donc bien filtrage, non?
c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
Non, c'est tout simplement parce que c'est plus facile d'ignorer un paquet que de prendre la bonne décision et l'action à effectuer sur chaque paquet qui traverse la pile réseau. C'est ce que je qualifie des fois le « firewall du pauvre ». Les paquets qui doivent être ignorés sont généralement les paquets invalides, les protocoles non pris en charge, les réseaux non routables et diverses petites choses.
La bonne décision? moi je vois deux solutions je laisse passer ou non, j'ai tout simplement pas envie de répondre, d'ailleurs pourquoi faire, la connexion échoue d'une façon ou d'une autre.
Le Fri, 18 Jun 2004 22:18:47 +0200, TiChou a écrit :
Dans le message <news:pan.2004.06.18.16.00.50.930326@reply.to>, *Ronald*
tapota sur f.c.o.l.configuration :
Bref, à part des cas très particulier (DoS par saturation de la bande
passante montante en ADSL, ou bien bande passante montante facturée
comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall
est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible
étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT
--reject-with icmp-port-unreachable par exemple,
La politique par défaut ne sert pas à filtrer mais à décider de ce qui
sera fait des paquets qui n'auraient pas été filtrés, c'est-à-dire les
ignorer ou les laisser passer. En principe, dans un bon firewall, un
paquet devrait au moins passer dans une des règles du firewall et avoir
eu une décision prise sur celui-ci.
Et?
Lorsque la politique par défaut est en DROP, un paquet qui ne matche
aucune règles est ignoré, il y a donc bien filtrage, non?
c'est peut être pour ça que le conseil que tout soit en DROP par
défaut est généralement donné.
Non, c'est tout simplement parce que c'est plus facile d'ignorer un paquet
que de prendre la bonne décision et l'action à effectuer sur chaque
paquet qui traverse la pile réseau. C'est ce que je qualifie des fois le
« firewall du pauvre ».
Les paquets qui doivent être ignorés sont généralement les paquets
invalides, les protocoles non pris en charge, les réseaux non routables
et diverses petites choses.
La bonne décision? moi je vois deux solutions je laisse passer ou non,
j'ai tout simplement pas envie de répondre, d'ailleurs pourquoi faire, la
connexion échoue d'une façon ou d'une autre.
Le Fri, 18 Jun 2004 22:18:47 +0200, TiChou a écrit :
Dans le message <news:, *Ronald* tapota sur f.c.o.l.configuration :
Bref, à part des cas très particulier (DoS par saturation de la bande passante montante en ADSL, ou bien bande passante montante facturée comme naguère chez cybercable), DROP est à éviter.
Pour information, la bonne manière de bloquer un port dans un firewall est REJECT --reject-with icmp-port-unreachable.
Et tu le mets comment en politique par défaut, REJECT est une cible étendue et ce n'est pas possible d'avoir un iptables -P INPUT REJECT --reject-with icmp-port-unreachable par exemple,
La politique par défaut ne sert pas à filtrer mais à décider de ce qui sera fait des paquets qui n'auraient pas été filtrés, c'est-à-dire les ignorer ou les laisser passer. En principe, dans un bon firewall, un paquet devrait au moins passer dans une des règles du firewall et avoir eu une décision prise sur celui-ci.
Et? Lorsque la politique par défaut est en DROP, un paquet qui ne matche aucune règles est ignoré, il y a donc bien filtrage, non?
c'est peut être pour ça que le conseil que tout soit en DROP par défaut est généralement donné.
Non, c'est tout simplement parce que c'est plus facile d'ignorer un paquet que de prendre la bonne décision et l'action à effectuer sur chaque paquet qui traverse la pile réseau. C'est ce que je qualifie des fois le « firewall du pauvre ». Les paquets qui doivent être ignorés sont généralement les paquets invalides, les protocoles non pris en charge, les réseaux non routables et diverses petites choses.
La bonne décision? moi je vois deux solutions je laisse passer ou non, j'ai tout simplement pas envie de répondre, d'ailleurs pourquoi faire, la connexion échoue d'une façon ou d'une autre.
Nicolas George
Ronald wrote in message :
La bonne décision? moi je vois deux solutions je laisse passer ou non, j'ai tout simplement pas envie de répondre, d'ailleurs pourquoi faire, la connexion échoue d'une façon ou d'une autre.
Il est plus efficace pour tout le monde, y compris pour toi, si un diagnostique correct est signalé.
Ronald wrote in message <pan.2004.06.18.20.52.30.511693@reply.to>:
La bonne décision? moi je vois deux solutions je laisse passer ou non,
j'ai tout simplement pas envie de répondre, d'ailleurs pourquoi faire, la
connexion échoue d'une façon ou d'une autre.
Il est plus efficace pour tout le monde, y compris pour toi, si un
diagnostique correct est signalé.
La bonne décision? moi je vois deux solutions je laisse passer ou non, j'ai tout simplement pas envie de répondre, d'ailleurs pourquoi faire, la connexion échoue d'une façon ou d'une autre.
Il est plus efficace pour tout le monde, y compris pour toi, si un diagnostique correct est signalé.
