Bonjour,
J'entends parlé de linux , il parait qu'il n'est pas utile d'avoir
d'antivirus, pare-feu etc... j'ai un pc uniquement dédier à la navigation
internet, ,où ce procurer cette OS, comment le configurer pour internet et
un réseau local avec la livebox, y a t il une liste de logiciel ?
merci
serge
Le NAT est par essence un filtrage en entrée pour le réseau NATé.
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de Netfilter/iptables ne filtre rien du tout.
Sébastien Monbrun aka TiChou
Dans le message <news:em0nqh$i2i$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Le NAT est par essence un filtrage en entrée pour le réseau NATé.
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de Netfilter/iptables ne filtre rien du tout.
Ce qui permet par ailleurs la possibilité à deux machines derrières un routeur NAT Linux de pouvoir établir malgré tout un canal de communication pour s'échanger des données sans qu'il y ait pour autant des règles de redirection de port définies sur les deux routeurs. Exemple du protocole STUN pour les communications VoIP.
-- Sébastien Monbrun aka TiChou
Dans le message <news:em0nqh$i2i$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.o.l.configuration :
Le NAT est par essence un filtrage en entrée pour le réseau NATé.
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de
Netfilter/iptables ne filtre rien du tout.
Ce qui permet par ailleurs la possibilité à deux machines derrières un
routeur NAT Linux de pouvoir établir malgré tout un canal de communication
pour s'échanger des données sans qu'il y ait pour autant des règles de
redirection de port définies sur les deux routeurs. Exemple du protocole
STUN pour les communications VoIP.
Dans le message <news:em0nqh$i2i$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Le NAT est par essence un filtrage en entrée pour le réseau NATé.
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de Netfilter/iptables ne filtre rien du tout.
Ce qui permet par ailleurs la possibilité à deux machines derrières un routeur NAT Linux de pouvoir établir malgré tout un canal de communication pour s'échanger des données sans qu'il y ait pour autant des règles de redirection de port définies sur les deux routeurs. Exemple du protocole STUN pour les communications VoIP.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Dans le message <news:4583c1e2$0$32543$, *sansflotusspam* tapota sur f.c.o.l.configuration :
Quant aux ACL, c'est juste une aimable fadaise à la sauce M$ en face d'un unix.
Euh, non c'est nettement plus puissant que le modèle unix traditionel.
pas du tout ! le modèle unix "user-group-wordl" permet des combinaisons beaucoup plus puissantes, souples, programmables, que le système de liste ACL.
J'attends impatiemment la réponse que tu donneras à Pascal Hambourg. Et nous déçois pas, on veut quelque chose de concret. ;-)
Au passage, tu sais quand même que n'importe quelle machine tournant sous un Win$ quelconque est une vraie passoire : en bootant avec une bête disquette, on fait sauter tous les mots de passe en deux coups de petite cuiller ...
Non, ça ne se fait pas non plus en deux coups de cuillère à pot et ce n'est pas non plus sans risque.
Bah c'est vrai sous n'importe quel unix aussi.
exact, mais c'est souvent beaucoup plus poilu ; quand on peut éditer les fichiers password et shadow en direct sur le disque, OK, mais il faut accéder au disque en écriture.
mount -o remount,rw ?
sed -i /root/s/:[^:]*:/::/ /etc/passwd ?
faire ça sur des machines Sun (Solaris), SGI (IRIX) ou HP (true64) est plus coton que sur un PC avec une disquette Tom's ou CD-Live.
Suffit de connaître les procédures et elles existent.
On notera que pour la plupart des unix il n'y a même pas besoin de démarrer sur une quelconque disquette ou CD Live.
Conclusion, j'aimerai savoir en quoi un Windows est plus une passoire qu'un unix quand il s'agit de shunter un mot de passe.
-- Sébastien Monbrun aka TiChou
Dans le message <news:4583c1e2$0$32543$426a74cc@news.free.fr>,
*sansflotusspam* tapota sur f.c.o.l.configuration :
Quant aux ACL, c'est juste une aimable fadaise à la sauce M$ en face
d'un unix.
Euh, non c'est nettement plus puissant que le modèle unix traditionel.
pas du tout ! le modèle unix "user-group-wordl" permet des combinaisons
beaucoup plus puissantes, souples, programmables, que le système de liste
ACL.
J'attends impatiemment la réponse que tu donneras à Pascal Hambourg. Et nous
déçois pas, on veut quelque chose de concret. ;-)
Au passage, tu sais quand même que n'importe quelle machine tournant
sous un Win$ quelconque est une vraie passoire : en bootant avec une
bête disquette, on fait sauter tous les mots de passe en deux coups de
petite cuiller ...
Non, ça ne se fait pas non plus en deux coups de cuillère à pot et ce n'est
pas non plus sans risque.
Bah c'est vrai sous n'importe quel unix aussi.
exact, mais c'est souvent beaucoup plus poilu ; quand on peut éditer les
fichiers password et shadow en direct sur le disque, OK, mais il faut
accéder au disque en écriture.
mount -o remount,rw ?
sed -i /root/s/:[^:]*:/::/ /etc/passwd ?
faire ça sur des machines Sun (Solaris), SGI (IRIX) ou HP (true64) est
plus coton que sur un PC avec une disquette Tom's ou CD-Live.
Suffit de connaître les procédures et elles existent.
On notera que pour la plupart des unix il n'y a même pas besoin de démarrer
sur une quelconque disquette ou CD Live.
Conclusion, j'aimerai savoir en quoi un Windows est plus une passoire qu'un
unix quand il s'agit de shunter un mot de passe.
Dans le message <news:4583c1e2$0$32543$, *sansflotusspam* tapota sur f.c.o.l.configuration :
Quant aux ACL, c'est juste une aimable fadaise à la sauce M$ en face d'un unix.
Euh, non c'est nettement plus puissant que le modèle unix traditionel.
pas du tout ! le modèle unix "user-group-wordl" permet des combinaisons beaucoup plus puissantes, souples, programmables, que le système de liste ACL.
J'attends impatiemment la réponse que tu donneras à Pascal Hambourg. Et nous déçois pas, on veut quelque chose de concret. ;-)
Au passage, tu sais quand même que n'importe quelle machine tournant sous un Win$ quelconque est une vraie passoire : en bootant avec une bête disquette, on fait sauter tous les mots de passe en deux coups de petite cuiller ...
Non, ça ne se fait pas non plus en deux coups de cuillère à pot et ce n'est pas non plus sans risque.
Bah c'est vrai sous n'importe quel unix aussi.
exact, mais c'est souvent beaucoup plus poilu ; quand on peut éditer les fichiers password et shadow en direct sur le disque, OK, mais il faut accéder au disque en écriture.
mount -o remount,rw ?
sed -i /root/s/:[^:]*:/::/ /etc/passwd ?
faire ça sur des machines Sun (Solaris), SGI (IRIX) ou HP (true64) est plus coton que sur un PC avec une disquette Tom's ou CD-Live.
Suffit de connaître les procédures et elles existent.
On notera que pour la plupart des unix il n'y a même pas besoin de démarrer sur une quelconque disquette ou CD Live.
Conclusion, j'aimerai savoir en quoi un Windows est plus une passoire qu'un unix quand il s'agit de shunter un mot de passe.
-- Sébastien Monbrun aka TiChou
Christophe HENRY
Le Sat, 16 Dec 2006 15:09:49 +0100, Sébastien Monbrun aka TiChou a écrit:
Dans le message <news:em0nqh$i2i$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Le NAT est par essence un filtrage en entrée pour le réseau NATé.
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de Netfilter/iptables ne filtre rien du tout.
Une seule adresse IP est visible de l'extérieur. Logiquement l'IP du système est non routable. Comment le routeur va-t-il décider de faire suivre les paquets provenant de l'extérieur ? Il faut bien qu'il y ait une règle de traduction de port. De ce fait, un routeur ne faisant que de NAT sans traduction de port ne laisse pas entrer les connexions initiées depuis l'extérieur.
Ce qui permet par ailleurs la possibilité à deux machines derrières un routeur NAT Linux de pouvoir établir malgré tout un canal de communication pour s'échanger des données sans qu'il y ait pour autant des règles de redirection de port définies sur les deux routeurs. Exemple du protocole STUN pour les communications VoIP.
Je crois bien qu'il faut un intermédiaire, non ? Genre un serveur accueillant les connexions entrantes des deux systèmes.
Mais là, on est loin des services écoutant simplement sur leurs ports et inaccessibles de l'extérieur à cause du NAT ; tant qu'une règle de traduction est définie...
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 15:09:49 +0100, Sébastien Monbrun aka TiChou a écrit:
Dans le message <news:em0nqh$i2i$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.o.l.configuration :
Le NAT est par essence un filtrage en entrée pour le réseau NATé.
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de
Netfilter/iptables ne filtre rien du tout.
Une seule adresse IP est visible de l'extérieur. Logiquement l'IP du
système est non routable. Comment le routeur va-t-il décider de faire
suivre les paquets provenant de l'extérieur ? Il faut bien qu'il y ait une
règle de traduction de port.
De ce fait, un routeur ne faisant que de NAT sans traduction de port ne
laisse pas entrer les connexions initiées depuis l'extérieur.
Ce qui permet par ailleurs la possibilité à deux machines derrières un
routeur NAT Linux de pouvoir établir malgré tout un canal de communication
pour s'échanger des données sans qu'il y ait pour autant des règles de
redirection de port définies sur les deux routeurs. Exemple du protocole
STUN pour les communications VoIP.
Je crois bien qu'il faut un intermédiaire, non ? Genre un serveur
accueillant les connexions entrantes des deux systèmes.
Mais là, on est loin des services écoutant simplement sur leurs ports et
inaccessibles de l'extérieur à cause du NAT ; tant qu'une règle de
traduction est définie...
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 15:09:49 +0100, Sébastien Monbrun aka TiChou a écrit:
Dans le message <news:em0nqh$i2i$, *Pascal Hambourg* tapota sur f.c.o.l.configuration :
Le NAT est par essence un filtrage en entrée pour le réseau NATé.
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de Netfilter/iptables ne filtre rien du tout.
Une seule adresse IP est visible de l'extérieur. Logiquement l'IP du système est non routable. Comment le routeur va-t-il décider de faire suivre les paquets provenant de l'extérieur ? Il faut bien qu'il y ait une règle de traduction de port. De ce fait, un routeur ne faisant que de NAT sans traduction de port ne laisse pas entrer les connexions initiées depuis l'extérieur.
Ce qui permet par ailleurs la possibilité à deux machines derrières un routeur NAT Linux de pouvoir établir malgré tout un canal de communication pour s'échanger des données sans qu'il y ait pour autant des règles de redirection de port définies sur les deux routeurs. Exemple du protocole STUN pour les communications VoIP.
Je crois bien qu'il faut un intermédiaire, non ? Genre un serveur accueillant les connexions entrantes des deux systèmes.
Mais là, on est loin des services écoutant simplement sur leurs ports et inaccessibles de l'extérieur à cause du NAT ; tant qu'une règle de traduction est définie...
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Christophe HENRY
Le Sat, 16 Dec 2006 16:15:23 +0100, Pascal Hambourg a écrit:
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de Netfilter/iptables ne filtre rien du tout.
Une seule adresse IP est visible de l'extérieur.
Pas forcément. Avec le SNAT/masquerading "stateful" de Linux 2.4/2.6 (Netfilter/iptables), les adresses "internes" du réseau NATé restent accessibles de l'extérieur.
Aussi loin que je comprends le NAT, on accède à un système de l'extérieur au moyen d'une adresse IP visible de l'extérieur et de son numéro de port. Le routeur traduit ensuite la requête pour la faire suivre au bon système sur le bon port. Il me semble bien qu'à aucun moment la pile IP du système à l'extérieur ne connaît l'adresse IP du système avec lequel il communique. Il ne devrait connaître que l'adresse IP du routeur, visible de l'extérieur. Me tromperais-je ?
Comment le routeur va-t-il décider de faire suivre les paquets provenant de l'extérieur ?
Facile : il consulte sa table de routage, voit que l'adresse destination appartient au réseau interne et transmet le paquet. C'est du routage classique.
Mon réseau local est natté. J'ai une adresse en 10/24. Comment va-tu indiquer à mon routeur que tu veux joindre mon système ? Les routeurs intermédiaires rejetteraient la requête. Par contre j'ai du bit-torrent, là je traduit délicatement le port idoine afin que la source soit accessible de façon optimale.
Il faut bien qu'il y ait une règle de traduction de port.
Non, pas besoin.
Avec de l'IPv6, je comprendrais. Aurais-tu une source à me proposer pour améliorer mes connaissances ?
De ce fait, un routeur ne faisant que de NAT sans traduction de port ne laisse pas entrer les connexions initiées depuis l'extérieur.
Un routeur basé sur Linux, si.
Ça m'ennuie ça. Des liens à me proposer ?
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 16:15:23 +0100, Pascal Hambourg a écrit:
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de
Netfilter/iptables ne filtre rien du tout.
Une seule adresse IP est visible de l'extérieur.
Pas forcément. Avec le SNAT/masquerading "stateful" de Linux 2.4/2.6
(Netfilter/iptables), les adresses "internes" du réseau NATé restent
accessibles de l'extérieur.
Aussi loin que je comprends le NAT, on accède à un système de l'extérieur
au moyen d'une adresse IP visible de l'extérieur et de son numéro de port.
Le routeur traduit ensuite la requête pour la faire suivre au bon système
sur le bon port.
Il me semble bien qu'à aucun moment la pile IP du système à l'extérieur ne
connaît l'adresse IP du système avec lequel il communique. Il ne devrait
connaître que l'adresse IP du routeur, visible de l'extérieur.
Me tromperais-je ?
Comment le routeur va-t-il décider de faire
suivre les paquets provenant de l'extérieur ?
Facile : il consulte sa table de routage, voit que l'adresse destination
appartient au réseau interne et transmet le paquet. C'est du routage
classique.
Mon réseau local est natté. J'ai une adresse en 10/24. Comment va-tu
indiquer à mon routeur que tu veux joindre mon système ? Les routeurs
intermédiaires rejetteraient la requête.
Par contre j'ai du bit-torrent, là je traduit délicatement le port idoine
afin que la source soit accessible de façon optimale.
Il faut bien qu'il y ait une règle de traduction de port.
Non, pas besoin.
Avec de l'IPv6, je comprendrais. Aurais-tu une source à me proposer pour
améliorer mes connaissances ?
De ce fait, un routeur ne faisant que de NAT sans traduction de port ne
laisse pas entrer les connexions initiées depuis l'extérieur.
Un routeur basé sur Linux, si.
Ça m'ennuie ça. Des liens à me proposer ?
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 16:15:23 +0100, Pascal Hambourg a écrit:
Non, le NAT n'est pas du filtrage par essence. D'ailleurs, le NAT de Netfilter/iptables ne filtre rien du tout.
Une seule adresse IP est visible de l'extérieur.
Pas forcément. Avec le SNAT/masquerading "stateful" de Linux 2.4/2.6 (Netfilter/iptables), les adresses "internes" du réseau NATé restent accessibles de l'extérieur.
Aussi loin que je comprends le NAT, on accède à un système de l'extérieur au moyen d'une adresse IP visible de l'extérieur et de son numéro de port. Le routeur traduit ensuite la requête pour la faire suivre au bon système sur le bon port. Il me semble bien qu'à aucun moment la pile IP du système à l'extérieur ne connaît l'adresse IP du système avec lequel il communique. Il ne devrait connaître que l'adresse IP du routeur, visible de l'extérieur. Me tromperais-je ?
Comment le routeur va-t-il décider de faire suivre les paquets provenant de l'extérieur ?
Facile : il consulte sa table de routage, voit que l'adresse destination appartient au réseau interne et transmet le paquet. C'est du routage classique.
Mon réseau local est natté. J'ai une adresse en 10/24. Comment va-tu indiquer à mon routeur que tu veux joindre mon système ? Les routeurs intermédiaires rejetteraient la requête. Par contre j'ai du bit-torrent, là je traduit délicatement le port idoine afin que la source soit accessible de façon optimale.
Il faut bien qu'il y ait une règle de traduction de port.
Non, pas besoin.
Avec de l'IPv6, je comprendrais. Aurais-tu une source à me proposer pour améliorer mes connaissances ?
De ce fait, un routeur ne faisant que de NAT sans traduction de port ne laisse pas entrer les connexions initiées depuis l'extérieur.
Un routeur basé sur Linux, si.
Ça m'ennuie ça. Des liens à me proposer ?
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Christophe HENRY
Le Sat, 16 Dec 2006 17:47:29 +0100, Sébastien Monbrun aka TiChou a écrit:
Je crois bien qu'il faut un intermédiaire, non ? Genre un serveur accueillant les connexions entrantes des deux systèmes.
Je vais parler du cas du protocole VoIP SIP utilisé conjointement avec le protocole STUN. ... Ainsi, avec ces mécanismes, des clients derrières un NAT peuvent établir des communications de client à client (donc sortantes mais aussi entrantes) sans pour autant que les données échangées passent par un autre peer et sans que le NAT les ait filtrées.
Merci pour l'explication :-) Donc les clients bernent le NAT en faisant croire qu'ils sortent bien gentillement et que le serveur c'est l'autre.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 17:47:29 +0100, Sébastien Monbrun aka TiChou a écrit:
Je crois bien qu'il faut un intermédiaire, non ? Genre un serveur
accueillant les connexions entrantes des deux systèmes.
Je vais parler du cas du protocole VoIP SIP utilisé conjointement avec le
protocole STUN.
...
Ainsi, avec ces mécanismes, des clients derrières un NAT peuvent établir des
communications de client à client (donc sortantes mais aussi entrantes) sans
pour autant que les données échangées passent par un autre peer et sans que
le NAT les ait filtrées.
Merci pour l'explication :-) Donc les clients bernent le NAT en faisant
croire qu'ils sortent bien gentillement et que le serveur c'est l'autre.
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 17:47:29 +0100, Sébastien Monbrun aka TiChou a écrit:
Je crois bien qu'il faut un intermédiaire, non ? Genre un serveur accueillant les connexions entrantes des deux systèmes.
Je vais parler du cas du protocole VoIP SIP utilisé conjointement avec le protocole STUN. ... Ainsi, avec ces mécanismes, des clients derrières un NAT peuvent établir des communications de client à client (donc sortantes mais aussi entrantes) sans pour autant que les données échangées passent par un autre peer et sans que le NAT les ait filtrées.
Merci pour l'explication :-) Donc les clients bernent le NAT en faisant croire qu'ils sortent bien gentillement et que le serveur c'est l'autre.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Fabien LE LEZ
On Sat, 16 Dec 2006 12:24:09 +0100, Pascal Hambourg :
La nécessité d'un firewall est relativement indépendante de l'OS,
Si, quand même un peu. Quand un certain OS ne permet pas de désactiver certains service - ou au minimum de désactiver l'accès à ces services depuis l'extérieur via le réseau [...]
Avec un OS Linux et des applications bien configurées, ça ne risque pas grand chose.
J'entends des gens qui clament être capables d'obtenir un Windows fiable sans protection ; j'entends aussi des gens qui clament être capables de faire la même chose sous Linux.
Le fait est que moi je n'en suis pas capable, et a priori l'OP non plus.
et dépend beaucoup plus de la configuration du réseau, et de tes habitudes.
Par exemple, si tu es derrière un routeur qui fait du NAT, tu as déjà un filtrage en entrée ;
Non, pas forcément. Un contributeur avait publié le jeu de règles iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule règle de filtrage en entrée.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à une redirection NAT est jeté.
On Sat, 16 Dec 2006 12:24:09 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org>:
La nécessité d'un firewall est relativement indépendante de l'OS,
Si, quand même un peu. Quand un certain OS ne permet pas de désactiver
certains service - ou au minimum de désactiver l'accès à ces services
depuis l'extérieur via le réseau
[...]
Avec un OS Linux et des applications bien configurées, ça ne risque pas
grand chose.
J'entends des gens qui clament être capables d'obtenir un Windows
fiable sans protection ; j'entends aussi des gens qui clament être
capables de faire la même chose sous Linux.
Le fait est que moi je n'en suis pas capable, et a priori l'OP non
plus.
et dépend beaucoup plus de la configuration du réseau, et de tes
habitudes.
Par exemple, si tu es derrière un routeur qui fait du NAT,
tu as déjà un filtrage en entrée ;
Non, pas forcément. Un contributeur avait publié le jeu de règles
iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule
règle de filtrage en entrée.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à
une redirection NAT est jeté.
On Sat, 16 Dec 2006 12:24:09 +0100, Pascal Hambourg :
La nécessité d'un firewall est relativement indépendante de l'OS,
Si, quand même un peu. Quand un certain OS ne permet pas de désactiver certains service - ou au minimum de désactiver l'accès à ces services depuis l'extérieur via le réseau [...]
Avec un OS Linux et des applications bien configurées, ça ne risque pas grand chose.
J'entends des gens qui clament être capables d'obtenir un Windows fiable sans protection ; j'entends aussi des gens qui clament être capables de faire la même chose sous Linux.
Le fait est que moi je n'en suis pas capable, et a priori l'OP non plus.
et dépend beaucoup plus de la configuration du réseau, et de tes habitudes.
Par exemple, si tu es derrière un routeur qui fait du NAT, tu as déjà un filtrage en entrée ;
Non, pas forcément. Un contributeur avait publié le jeu de règles iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule règle de filtrage en entrée.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à une redirection NAT est jeté.
Fabien LE LEZ
On Sun, 17 Dec 2006 03:57:54 +0100, Fabien LE LEZ :
Non, pas forcément. Un contributeur avait publié le jeu de règles iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule règle de filtrage en entrée.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à une redirection NAT est jeté.
J'ai peut-être été un peu lapidaire.
Je parle ici d'un NAT "1 adresse IP publique <-> plusieurs adresses IP privées, non routables sur Internet".
L'ouverture d'une connexion TCP de l'extérieur vers l'intérieur est refusée, sauf si une règle indique qu'il faut transmettre la demande de connexion à l'une des machines du LAN.
De même, un paquet UDP sera jeté, sauf si une règle indique qu'il faut transmettre ce paquet à l'une des machines du LAN.
La protection apportée par ce type de NAT est liée au fait que le routeur jette tous les paquets, sauf ceux qu'il sait associer à une machine interne (d'après les règles, ou parce que le paquet est lié à une connexion TCP sortante).
Évidemment, le routeur en lui-même doit être protégé en interne. Par exemple, son serveur web interne ne doit écouter que sur l'interface LAN.
On Sun, 17 Dec 2006 03:57:54 +0100, Fabien LE LEZ
<gramster@gramster.com>:
Non, pas forcément. Un contributeur avait publié le jeu de règles
iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule
règle de filtrage en entrée.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à
une redirection NAT est jeté.
J'ai peut-être été un peu lapidaire.
Je parle ici d'un NAT "1 adresse IP publique <-> plusieurs adresses IP
privées, non routables sur Internet".
L'ouverture d'une connexion TCP de l'extérieur vers l'intérieur est
refusée, sauf si une règle indique qu'il faut transmettre la demande
de connexion à l'une des machines du LAN.
De même, un paquet UDP sera jeté, sauf si une règle indique qu'il faut
transmettre ce paquet à l'une des machines du LAN.
La protection apportée par ce type de NAT est liée au fait que le
routeur jette tous les paquets, sauf ceux qu'il sait associer à une
machine interne (d'après les règles, ou parce que le paquet est lié à
une connexion TCP sortante).
Évidemment, le routeur en lui-même doit être protégé en interne. Par
exemple, son serveur web interne ne doit écouter que sur l'interface
LAN.
On Sun, 17 Dec 2006 03:57:54 +0100, Fabien LE LEZ :
Non, pas forcément. Un contributeur avait publié le jeu de règles iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule règle de filtrage en entrée.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à une redirection NAT est jeté.
J'ai peut-être été un peu lapidaire.
Je parle ici d'un NAT "1 adresse IP publique <-> plusieurs adresses IP privées, non routables sur Internet".
L'ouverture d'une connexion TCP de l'extérieur vers l'intérieur est refusée, sauf si une règle indique qu'il faut transmettre la demande de connexion à l'une des machines du LAN.
De même, un paquet UDP sera jeté, sauf si une règle indique qu'il faut transmettre ce paquet à l'une des machines du LAN.
La protection apportée par ce type de NAT est liée au fait que le routeur jette tous les paquets, sauf ceux qu'il sait associer à une machine interne (d'après les règles, ou parce que le paquet est lié à une connexion TCP sortante).
Évidemment, le routeur en lui-même doit être protégé en interne. Par exemple, son serveur web interne ne doit écouter que sur l'interface LAN.
Pascal Hambourg
Non, pas forcément. Un contributeur avait publié le jeu de règles iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule règle de filtrage en entrée.
Je précise que toutes les politiques par défaut étaient ACCEPT.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à une redirection NAT est jeté.
J'ai peut-être été un peu lapidaire.
J'allais le dire. :-) Je n'ai jamais entendu parler de règles "non écrites" dans iptables.
Je parle ici d'un NAT "1 adresse IP publique <-> plusieurs adresses IP privées, non routables sur Internet".
Peu importe, le NAT d'iptables fonctionne de la même façon dans tous les cas.
L'ouverture d'une connexion TCP de l'extérieur vers l'intérieur est refusée, sauf si une règle indique qu'il faut transmettre la demande de connexion à l'une des machines du LAN.
De même, un paquet UDP sera jeté, sauf si une règle indique qu'il faut transmettre ce paquet à l'une des machines du LAN.
C'est faux. Il suffit d'essayer avec trois machines simulant un hôte externe, le routeur NAT et un hôte interne. Encore une fois, le NAT d'iptables ne fait pas de filtrage. Il ne fait que de la translation d'adresse et/ou de port, indépendamment de tout filtrage.
Tu confonds probablement avec le cas où le paquet est adressé à l'adresse publique du routeur NAT. Bien sûr dans ce cas si aucune règle DNAT n'est définie, le paquet est routé vers le routeur lui-même. Je parle du cas où un paquet arrive directement avec pour destination l'adresse interne de la machine cible.
La protection apportée par ce type de NAT est liée au fait que le routeur jette tous les paquets, sauf ceux qu'il sait associer à une machine interne (d'après les règles, ou parce que le paquet est lié à une connexion TCP sortante).
Non. Comme je l'ai déjà dit, la protection est liée au fait que les adresses internes ne sont pas routées sur le réseau externe.
Non, pas forcément. Un contributeur avait publié le jeu de règles
iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule
règle de filtrage en entrée.
Je précise que toutes les politiques par défaut étaient ACCEPT.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à
une redirection NAT est jeté.
J'ai peut-être été un peu lapidaire.
J'allais le dire. :-) Je n'ai jamais entendu parler de règles "non
écrites" dans iptables.
Je parle ici d'un NAT "1 adresse IP publique <-> plusieurs adresses IP
privées, non routables sur Internet".
Peu importe, le NAT d'iptables fonctionne de la même façon dans tous les
cas.
L'ouverture d'une connexion TCP de l'extérieur vers l'intérieur est
refusée, sauf si une règle indique qu'il faut transmettre la demande
de connexion à l'une des machines du LAN.
De même, un paquet UDP sera jeté, sauf si une règle indique qu'il faut
transmettre ce paquet à l'une des machines du LAN.
C'est faux. Il suffit d'essayer avec trois machines simulant un hôte
externe, le routeur NAT et un hôte interne.
Encore une fois, le NAT d'iptables ne fait pas de filtrage. Il ne fait
que de la translation d'adresse et/ou de port, indépendamment de tout
filtrage.
Tu confonds probablement avec le cas où le paquet est adressé à
l'adresse publique du routeur NAT. Bien sûr dans ce cas si aucune règle
DNAT n'est définie, le paquet est routé vers le routeur lui-même. Je
parle du cas où un paquet arrive directement avec pour destination
l'adresse interne de la machine cible.
La protection apportée par ce type de NAT est liée au fait que le
routeur jette tous les paquets, sauf ceux qu'il sait associer à une
machine interne (d'après les règles, ou parce que le paquet est lié à
une connexion TCP sortante).
Non. Comme je l'ai déjà dit, la protection est liée au fait que les
adresses internes ne sont pas routées sur le réseau externe.
Non, pas forcément. Un contributeur avait publié le jeu de règles iptables de sa *box modem-routeur-NAT, et il n'y avait pas une seule règle de filtrage en entrée.
Je précise que toutes les politiques par défaut étaient ACCEPT.
Il y a une "règle 0", non écrite : tout paquet qui ne correspond pas à une redirection NAT est jeté.
J'ai peut-être été un peu lapidaire.
J'allais le dire. :-) Je n'ai jamais entendu parler de règles "non écrites" dans iptables.
Je parle ici d'un NAT "1 adresse IP publique <-> plusieurs adresses IP privées, non routables sur Internet".
Peu importe, le NAT d'iptables fonctionne de la même façon dans tous les cas.
L'ouverture d'une connexion TCP de l'extérieur vers l'intérieur est refusée, sauf si une règle indique qu'il faut transmettre la demande de connexion à l'une des machines du LAN.
De même, un paquet UDP sera jeté, sauf si une règle indique qu'il faut transmettre ce paquet à l'une des machines du LAN.
C'est faux. Il suffit d'essayer avec trois machines simulant un hôte externe, le routeur NAT et un hôte interne. Encore une fois, le NAT d'iptables ne fait pas de filtrage. Il ne fait que de la translation d'adresse et/ou de port, indépendamment de tout filtrage.
Tu confonds probablement avec le cas où le paquet est adressé à l'adresse publique du routeur NAT. Bien sûr dans ce cas si aucune règle DNAT n'est définie, le paquet est routé vers le routeur lui-même. Je parle du cas où un paquet arrive directement avec pour destination l'adresse interne de la machine cible.
La protection apportée par ce type de NAT est liée au fait que le routeur jette tous les paquets, sauf ceux qu'il sait associer à une machine interne (d'après les règles, ou parce que le paquet est lié à une connexion TCP sortante).
Non. Comme je l'ai déjà dit, la protection est liée au fait que les adresses internes ne sont pas routées sur le réseau externe.
Nicolas George
Pascal Hambourg wrote in message <em12if$m67$:
Pas forcément. Avec le SNAT/masquerading "stateful" de Linux 2.4/2.6 (Netfilter/iptables), les adresses "internes" du réseau NATé restent accessibles de l'extérieur.
Tu as raison, mais tu tétracapilotomises. Le NAT tel qu'il a été évoqué dans le message auquel je répondrais correspond à du NAPT d'un réseau en adresses privées sur une seule adresse publique fournie par un FAI.
Il est vrai qu'on paquet qui arrive sur le routeur NAPT avec la bonne adresse IP va traverser, mais pour qu'il y arrive, il faut que le routeur du FAI l'ait envoyé, ce qui suppose :
- soit que le routeur du FAI a été compromis, ce qui n'est pas complètement impossible évidemment, mais quand même assez peu probable ;
- soit que le FAI et toutes les étapes pour y arrive acceptent le routage à la source, ce qui est excessivement rare.
Pascal Hambourg wrote in message <em12if$m67$1@biggoron.nerim.net>:
Pas forcément. Avec le SNAT/masquerading "stateful" de Linux 2.4/2.6
(Netfilter/iptables), les adresses "internes" du réseau NATé restent
accessibles de l'extérieur.
Tu as raison, mais tu tétracapilotomises. Le NAT tel qu'il a été évoqué dans
le message auquel je répondrais correspond à du NAPT d'un réseau en adresses
privées sur une seule adresse publique fournie par un FAI.
Il est vrai qu'on paquet qui arrive sur le routeur NAPT avec la bonne
adresse IP va traverser, mais pour qu'il y arrive, il faut que le routeur du
FAI l'ait envoyé, ce qui suppose :
- soit que le routeur du FAI a été compromis, ce qui n'est pas complètement
impossible évidemment, mais quand même assez peu probable ;
- soit que le FAI et toutes les étapes pour y arrive acceptent le routage à
la source, ce qui est excessivement rare.
Pas forcément. Avec le SNAT/masquerading "stateful" de Linux 2.4/2.6 (Netfilter/iptables), les adresses "internes" du réseau NATé restent accessibles de l'extérieur.
Tu as raison, mais tu tétracapilotomises. Le NAT tel qu'il a été évoqué dans le message auquel je répondrais correspond à du NAPT d'un réseau en adresses privées sur une seule adresse publique fournie par un FAI.
Il est vrai qu'on paquet qui arrive sur le routeur NAPT avec la bonne adresse IP va traverser, mais pour qu'il y arrive, il faut que le routeur du FAI l'ait envoyé, ce qui suppose :
- soit que le routeur du FAI a été compromis, ce qui n'est pas complètement impossible évidemment, mais quand même assez peu probable ;
- soit que le FAI et toutes les étapes pour y arrive acceptent le routage à la source, ce qui est excessivement rare.
