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 Sat, 16 Dec 2006 19:37:15 +0100, Pascal Hambourg a écrit:
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.
Et s'il la connaît, ou la devine ?
Une adresse de type 10.1.2.3 n'est pas accessible de l'extérieur, dans des conditions usuelles. Même en connaissant les IP internes, ce n'est pas exploitable tel quel.
Il ne devrait connaître que l'adresse IP du routeur, visible de l'extérieur. Me tromperais-je ?
Si l'hôte extérieur utilise la redirection de port mise en place, il n'a pas besoin de connaître l'adresse réelle du serveur.
'faut dire qu'il n'a pas vraiment le choix. L'adresse IP externe est seule connue.
Mais j'insiste bien sur le fait que la redirection de port seule ne suffit pas à empêcher l'accès direct au serveur par son adresse propre.
Si on prend des cas tordus, oui. À l'origine de ce fil il y avait la question d'un pare-feu sous Linux. Dans ce cadre, un routeur faisant du NAT empêche les accès initiés depuis l'extérieur. Évidemment, cela sous-entend qu'il filtre les paquets anormaux...
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 ?
Je vais tout simplement lui envoyer un paquet avec comme destination l'adresse de ta machine, en supposant que je la connais. Si ce paquet parvient à ton routeur Linux, il le routera vers ta machine.
Tout est dans le "si". Mon adresse étant en 10/24, elle n'est pas accessible de l'extérieur car non routée. Et encore, cela devrait ne pas passer le filtrage. Un dispositif faisant du NAT devrait normalement filtrer les paquets selon le sens de traversée du routeur et interdire les flux ayant une adresse source en 10/24 provenant d'une interface différente.
Les routeurs intermédiaires rejetteraient la requête.
Il y a des chances. :-) Mais encore faut-il qu'il y ait des routeurs intermédiaires. Quid si je suis placé juste à l'extérieur de ton routeur qui fait le NAT ?
Dans le cas d'un NAT strict, je pense que cela franchit le routeur. Dans la pratique, c'est filtré. Enfin j'espère que c'est systématiquement le cas. Pas de bon NAT sans filtrage.
Ce qui protège, ce n'est pas le NAT mais l'utilisation d'adresses non routées sur internet. Hélas ça ne protège pas dans tous les cas, par exemple quand "l'attaquant" est situé juste devant le routeur NAT.
Évidemment. Dans ce fil le NAT devrait désigner le machin qui permet de partager la connexion d'un réseau local. En tout cas, mes routeurs - de base - vérifient la direction du flux. Il y a un filtrage basique accompagnant le NAT.
Avec de l'IPv6, je comprendrais.
Forcément, avec IPv6, il n'y a pas de NAT, du moins sous Linux. :-)
D'ailleurs, c'est aussi un ennui. Le NATv4 (au sens large) a le mérite de protéger correctement un réseau local de particulier.
Aurais-tu une source à me proposer pour améliorer mes connaissances ?
Pas vraiment. Il faut juste comprendre que sous Linux le NAT est une fonctionnalité qui s'ajoute au routage normal mais ne se substitue pas à lui. Par conséquent tout paquet qui ne correspond à aucune règle NAT est routé le plus normalement du monde vers sa destination.
Pas que sous Linux. Le NAT brut de décoffrage doit ressembler à ce que tu en dis. Mais dans la pratique et dans les équipements vendus il y a du filtrage. J'espère encore...
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 ?
Des liens à quel sujet ? La parade est simple : il suffit de faire du filtrage en plus du NAT. Par exemple : on autorise les connexions sortantes et seulement les connexions entrantes correspondant à une redirection de port.
Oui :-)
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 19:37:15 +0100, Pascal Hambourg a écrit:
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.
Et s'il la connaît, ou la devine ?
Une adresse de type 10.1.2.3 n'est pas accessible de l'extérieur, dans des
conditions usuelles. Même en connaissant les IP internes, ce n'est pas
exploitable tel quel.
Il ne devrait
connaître que l'adresse IP du routeur, visible de l'extérieur.
Me tromperais-je ?
Si l'hôte extérieur utilise la redirection de port mise en place, il n'a
pas besoin de connaître l'adresse réelle du serveur.
'faut dire qu'il n'a pas vraiment le choix. L'adresse IP externe est seule
connue.
Mais j'insiste bien
sur le fait que la redirection de port seule ne suffit pas à empêcher
l'accès direct au serveur par son adresse propre.
Si on prend des cas tordus, oui. À l'origine de ce fil il y avait la
question d'un pare-feu sous Linux. Dans ce cadre, un routeur faisant du
NAT empêche les accès initiés depuis l'extérieur. Évidemment, cela
sous-entend qu'il filtre les paquets anormaux...
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 ?
Je vais tout simplement lui envoyer un paquet avec comme destination
l'adresse de ta machine, en supposant que je la connais. Si ce paquet
parvient à ton routeur Linux, il le routera vers ta machine.
Tout est dans le "si". Mon adresse étant en 10/24, elle n'est pas
accessible de l'extérieur car non routée. Et encore, cela devrait ne pas
passer le filtrage. Un dispositif faisant du NAT devrait normalement
filtrer les paquets selon le sens de traversée du routeur et interdire
les flux ayant une adresse source en 10/24 provenant d'une interface
différente.
Les routeurs intermédiaires rejetteraient la requête.
Il y a des chances. :-) Mais encore faut-il qu'il y ait des routeurs
intermédiaires. Quid si je suis placé juste à l'extérieur de ton routeur
qui fait le NAT ?
Dans le cas d'un NAT strict, je pense que cela franchit le routeur. Dans
la pratique, c'est filtré. Enfin j'espère que c'est systématiquement le
cas. Pas de bon NAT sans filtrage.
Ce qui protège, ce n'est pas le NAT mais l'utilisation d'adresses non
routées sur internet. Hélas ça ne protège pas dans tous les cas, par
exemple quand "l'attaquant" est situé juste devant le routeur NAT.
Évidemment. Dans ce fil le NAT devrait désigner le machin
qui permet de partager la connexion d'un réseau local. En tout cas, mes
routeurs - de base - vérifient la direction du flux. Il y a un filtrage
basique accompagnant le NAT.
Avec de l'IPv6, je comprendrais.
Forcément, avec IPv6, il n'y a pas de NAT, du moins sous Linux. :-)
D'ailleurs, c'est aussi un ennui. Le NATv4 (au sens large) a le mérite de
protéger correctement un réseau local de particulier.
Aurais-tu une source à me proposer pour améliorer mes connaissances ?
Pas vraiment. Il faut juste comprendre que sous Linux le NAT est une
fonctionnalité qui s'ajoute au routage normal mais ne se substitue pas à
lui. Par conséquent tout paquet qui ne correspond à aucune règle NAT est
routé le plus normalement du monde vers sa destination.
Pas que sous Linux. Le NAT brut de décoffrage doit ressembler à ce que tu
en dis. Mais dans la pratique et dans les équipements vendus il y a du
filtrage. J'espère encore...
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 ?
Des liens à quel sujet ?
La parade est simple : il suffit de faire du filtrage en plus du NAT.
Par exemple : on autorise les connexions sortantes et seulement les
connexions entrantes correspondant à une redirection de port.
Oui :-)
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Le Sat, 16 Dec 2006 19:37:15 +0100, Pascal Hambourg a écrit:
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.
Et s'il la connaît, ou la devine ?
Une adresse de type 10.1.2.3 n'est pas accessible de l'extérieur, dans des conditions usuelles. Même en connaissant les IP internes, ce n'est pas exploitable tel quel.
Il ne devrait connaître que l'adresse IP du routeur, visible de l'extérieur. Me tromperais-je ?
Si l'hôte extérieur utilise la redirection de port mise en place, il n'a pas besoin de connaître l'adresse réelle du serveur.
'faut dire qu'il n'a pas vraiment le choix. L'adresse IP externe est seule connue.
Mais j'insiste bien sur le fait que la redirection de port seule ne suffit pas à empêcher l'accès direct au serveur par son adresse propre.
Si on prend des cas tordus, oui. À l'origine de ce fil il y avait la question d'un pare-feu sous Linux. Dans ce cadre, un routeur faisant du NAT empêche les accès initiés depuis l'extérieur. Évidemment, cela sous-entend qu'il filtre les paquets anormaux...
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 ?
Je vais tout simplement lui envoyer un paquet avec comme destination l'adresse de ta machine, en supposant que je la connais. Si ce paquet parvient à ton routeur Linux, il le routera vers ta machine.
Tout est dans le "si". Mon adresse étant en 10/24, elle n'est pas accessible de l'extérieur car non routée. Et encore, cela devrait ne pas passer le filtrage. Un dispositif faisant du NAT devrait normalement filtrer les paquets selon le sens de traversée du routeur et interdire les flux ayant une adresse source en 10/24 provenant d'une interface différente.
Les routeurs intermédiaires rejetteraient la requête.
Il y a des chances. :-) Mais encore faut-il qu'il y ait des routeurs intermédiaires. Quid si je suis placé juste à l'extérieur de ton routeur qui fait le NAT ?
Dans le cas d'un NAT strict, je pense que cela franchit le routeur. Dans la pratique, c'est filtré. Enfin j'espère que c'est systématiquement le cas. Pas de bon NAT sans filtrage.
Ce qui protège, ce n'est pas le NAT mais l'utilisation d'adresses non routées sur internet. Hélas ça ne protège pas dans tous les cas, par exemple quand "l'attaquant" est situé juste devant le routeur NAT.
Évidemment. Dans ce fil le NAT devrait désigner le machin qui permet de partager la connexion d'un réseau local. En tout cas, mes routeurs - de base - vérifient la direction du flux. Il y a un filtrage basique accompagnant le NAT.
Avec de l'IPv6, je comprendrais.
Forcément, avec IPv6, il n'y a pas de NAT, du moins sous Linux. :-)
D'ailleurs, c'est aussi un ennui. Le NATv4 (au sens large) a le mérite de protéger correctement un réseau local de particulier.
Aurais-tu une source à me proposer pour améliorer mes connaissances ?
Pas vraiment. Il faut juste comprendre que sous Linux le NAT est une fonctionnalité qui s'ajoute au routage normal mais ne se substitue pas à lui. Par conséquent tout paquet qui ne correspond à aucune règle NAT est routé le plus normalement du monde vers sa destination.
Pas que sous Linux. Le NAT brut de décoffrage doit ressembler à ce que tu en dis. Mais dans la pratique et dans les équipements vendus il y a du filtrage. J'espère encore...
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 ?
Des liens à quel sujet ? La parade est simple : il suffit de faire du filtrage en plus du NAT. Par exemple : on autorise les connexions sortantes et seulement les connexions entrantes correspondant à une redirection de port.
Oui :-)
-- Christophe HENRY http://www.sbgodin.fr - Site perso
GuiGui
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 :
Ce qui suppose soit que le FAI laisse passer du RFC1918 ce qui est peu probable (cela suppose une compromission de *tous* les routeurs entre l'attaquant et l'attaqué), soit que l'attaquant est sur le même subnet ce qui laisse 253 possibilités. Sinon il reste la possibilité que le paquet soit source-routé, mais là encore c'est en général filtré chez le FAI. Mais bon, la plupart des distrib linux permettent maintenant de mettre en place simplement à l'intall des règles iptable minimum (tout sort et rien n'entre).
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 :
Ce qui suppose soit que le FAI laisse passer du RFC1918 ce qui est peu
probable (cela suppose une compromission de *tous* les routeurs entre
l'attaquant et l'attaqué), soit que l'attaquant est sur le même subnet
ce qui laisse 253 possibilités. Sinon il reste la possibilité que le
paquet soit source-routé, mais là encore c'est en général filtré chez le
FAI. Mais bon, la plupart des distrib linux permettent maintenant de
mettre en place simplement à l'intall des règles iptable minimum (tout
sort et rien n'entre).
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 :
Ce qui suppose soit que le FAI laisse passer du RFC1918 ce qui est peu probable (cela suppose une compromission de *tous* les routeurs entre l'attaquant et l'attaqué), soit que l'attaquant est sur le même subnet ce qui laisse 253 possibilités. Sinon il reste la possibilité que le paquet soit source-routé, mais là encore c'est en général filtré chez le FAI. Mais bon, la plupart des distrib linux permettent maintenant de mettre en place simplement à l'intall des règles iptable minimum (tout sort et rien n'entre).
sansflotusspam
Pascal Hambourg wrote:
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.
Un petit exemple pour la route de ce que permet le système de droits d'Unix que ne permettent pas les ACL de Windows NT ? Merci.
il n'est pas besoin "d'exemple", c'est une question de structure : en unix, les "droits" sont un principe substantiel du file-system, en NT c'est une sur-couche au file-system. en unix, le système "user-group-other" avec rwx plus les marqueurs suid et guid intègre en interne la gestion des accès, en NT, on ajoute par-dessus des listes de cas particuliers.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle combinaison de droits unix, mais ce n'est pas une propriété générique du système.
ça va comme ça ?
Pascal Hambourg wrote:
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.
Un petit exemple pour la route de ce que permet le système de droits
d'Unix que ne permettent pas les ACL de Windows NT ? Merci.
il n'est pas besoin "d'exemple", c'est une question de structure :
en unix, les "droits" sont un principe substantiel du file-system,
en NT c'est une sur-couche au file-system.
en unix, le système "user-group-other" avec rwx plus les marqueurs suid et
guid intègre en interne la gestion des accès,
en NT, on ajoute par-dessus des listes de cas particuliers.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle
combinaison de droits unix, mais ce n'est pas une propriété générique du
système.
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.
Un petit exemple pour la route de ce que permet le système de droits d'Unix que ne permettent pas les ACL de Windows NT ? Merci.
il n'est pas besoin "d'exemple", c'est une question de structure : en unix, les "droits" sont un principe substantiel du file-system, en NT c'est une sur-couche au file-system. en unix, le système "user-group-other" avec rwx plus les marqueurs suid et guid intègre en interne la gestion des accès, en NT, on ajoute par-dessus des listes de cas particuliers.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle combinaison de droits unix, mais ce n'est pas une propriété générique du système.
ça va comme ça ?
sansflotusspam
Sébastien Monbrun aka TiChou wrote:
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 ?
ah, quand on peut faire ça, ya pas de problème ! encore faut-il accéder aux partitions et au(x) systèmes de fichiers, et que le truc accepte de se laisser monter en écriture. essaye de faire ça en aveugle sur des slices BSD, pour voir ! ou sur des disques en raid, ou sur des disques scsi protégés au niveau kernel ... c'est autre chose que du bête IDE en ext2. je ne dis pas que ce n'est pas possible, je dis que c'est vachement plus coton qu'un système NT ; j'ai fait les deux, j'ai bien vu la différence.
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.
oui, mais ce n'est pas de la tarte à faire ! et encore une fois, il faut pouvoir accéder aux disques, aux partitions, aux slices
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.
because aucun système Window$ ne sait créer et encore moins gérer des systèmes de disques avec protection d'accès au niveau kernel, comme unix
Sébastien Monbrun aka TiChou wrote:
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 ?
ah, quand on peut faire ça, ya pas de problème !
encore faut-il accéder aux partitions et au(x) systèmes de fichiers,
et que le truc accepte de se laisser monter en écriture.
essaye de faire ça en aveugle sur des slices BSD, pour voir !
ou sur des disques en raid, ou sur des disques scsi protégés au niveau
kernel ... c'est autre chose que du bête IDE en ext2.
je ne dis pas que ce n'est pas possible, je dis que c'est vachement plus
coton qu'un système NT ; j'ai fait les deux, j'ai bien vu la différence.
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.
oui, mais ce n'est pas de la tarte à faire !
et encore une fois, il faut pouvoir accéder aux disques, aux partitions, aux
slices
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.
because aucun système Window$ ne sait créer et encore moins gérer des
systèmes de disques avec protection d'accès au niveau kernel, comme unix
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 ?
ah, quand on peut faire ça, ya pas de problème ! encore faut-il accéder aux partitions et au(x) systèmes de fichiers, et que le truc accepte de se laisser monter en écriture. essaye de faire ça en aveugle sur des slices BSD, pour voir ! ou sur des disques en raid, ou sur des disques scsi protégés au niveau kernel ... c'est autre chose que du bête IDE en ext2. je ne dis pas que ce n'est pas possible, je dis que c'est vachement plus coton qu'un système NT ; j'ai fait les deux, j'ai bien vu la différence.
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.
oui, mais ce n'est pas de la tarte à faire ! et encore une fois, il faut pouvoir accéder aux disques, aux partitions, aux slices
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.
because aucun système Window$ ne sait créer et encore moins gérer des systèmes de disques avec protection d'accès au niveau kernel, comme unix
Nicolas George
sansflotusspam wrote in message <458654e4$0$26434$:
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.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle combinaison de droits unix, mais ce n'est pas une propriété générique du système.
Tu te rends compte que tu te contredis ? J'ai laissé le bout de citation correspondant, pour que tu puisses bien te rendre compte de la contradiction entre « des combinaisons beaucoup plus puissantes, souples, programmables » et « on peut imiter n'importe quelle combinaison ».
sansflotusspam wrote in message
<458654e4$0$26434$426a74cc@news.free.fr>:
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.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle
combinaison de droits unix, mais ce n'est pas une propriété générique du
système.
Tu te rends compte que tu te contredis ? J'ai laissé le bout de citation
correspondant, pour que tu puisses bien te rendre compte de la contradiction
entre « des combinaisons beaucoup plus puissantes, souples, programmables »
et « on peut imiter n'importe quelle combinaison ».
sansflotusspam wrote in message <458654e4$0$26434$:
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.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle combinaison de droits unix, mais ce n'est pas une propriété générique du système.
Tu te rends compte que tu te contredis ? J'ai laissé le bout de citation correspondant, pour que tu puisses bien te rendre compte de la contradiction entre « des combinaisons beaucoup plus puissantes, souples, programmables » et « on peut imiter n'importe quelle combinaison ».
Nicolas George
GuiGui wrote in message <45864d9c$0$1515$:
Ce qui suppose soit que le FAI laisse passer du RFC1918 ce qui est peu probable
Pas seulement qu'ils les laisse passer, qu'il les route spécifiquement vers la connexion en question.
soit que l'attaquant est sur le même subnet
Il n'y a pas de telle notion en PPP.
Sinon il reste la possibilité que le paquet soit source-routé
Que j'ai évoquée.
GuiGui wrote in message <45864d9c$0$1515$426a74cc@news.free.fr>:
Ce qui suppose soit que le FAI laisse passer du RFC1918 ce qui est peu
probable
Pas seulement qu'ils les laisse passer, qu'il les route spécifiquement vers
la connexion en question.
soit que l'attaquant est sur le même subnet
Il n'y a pas de telle notion en PPP.
Sinon il reste la possibilité que le
paquet soit source-routé
Ce qui suppose soit que le FAI laisse passer du RFC1918 ce qui est peu probable
Pas seulement qu'ils les laisse passer, qu'il les route spécifiquement vers la connexion en question.
soit que l'attaquant est sur le même subnet
Il n'y a pas de telle notion en PPP.
Sinon il reste la possibilité que le paquet soit source-routé
Que j'ai évoquée.
Nina Popravka
On Mon, 18 Dec 2006 09:44:13 +0100, sansflotusspam wrote:
en NT c'est une sur-couche au file-system.
Vaut mieux lire ça qu'être aveugle. NT est l'héritier de VMS, et il connaît aussi la notion de droits depuis le berceau, faut arrêter de croire que ça a été développé à partir de Windows 1.0 ;-> A part ça, il y a des choses très intéressantes sur la comparaison NT/Unix dans la doc de cygwin, ce sont des gens qui connaissent très bien le sujet :-) <http://cygwin.com/cygwin-ug-net/ntsec.html> -- Nina
On Mon, 18 Dec 2006 09:44:13 +0100, sansflotusspam
<sansalain.flotspam@free.fr> wrote:
en NT c'est une sur-couche au file-system.
Vaut mieux lire ça qu'être aveugle.
NT est l'héritier de VMS, et il connaît aussi la notion de droits
depuis le berceau, faut arrêter de croire que ça a été développé à
partir de Windows 1.0 ;->
A part ça, il y a des choses très intéressantes sur la comparaison
NT/Unix dans la doc de cygwin, ce sont des gens qui connaissent très
bien le sujet :-)
<http://cygwin.com/cygwin-ug-net/ntsec.html>
--
Nina
On Mon, 18 Dec 2006 09:44:13 +0100, sansflotusspam wrote:
en NT c'est une sur-couche au file-system.
Vaut mieux lire ça qu'être aveugle. NT est l'héritier de VMS, et il connaît aussi la notion de droits depuis le berceau, faut arrêter de croire que ça a été développé à partir de Windows 1.0 ;-> A part ça, il y a des choses très intéressantes sur la comparaison NT/Unix dans la doc de cygwin, ce sont des gens qui connaissent très bien le sujet :-) <http://cygwin.com/cygwin-ug-net/ntsec.html> -- Nina
Nicolas George
Nina Popravka wrote in message :
NT est l'héritier de VMS
À part le fait que tous les systèmes d'exploitation s'appuient sur les progrès faits par leurs prédécesseurs, le seul élément d'héritage attesté est l'identité du chef programmeur.
Nina Popravka wrote in message
<g7pco2d9jvp8edn2uq74ar6qqnife3sal3@4ax.com>:
NT est l'héritier de VMS
À part le fait que tous les systèmes d'exploitation s'appuient sur les
progrès faits par leurs prédécesseurs, le seul élément d'héritage attesté
est l'identité du chef programmeur.
À part le fait que tous les systèmes d'exploitation s'appuient sur les progrès faits par leurs prédécesseurs, le seul élément d'héritage attesté est l'identité du chef programmeur.
Nina Popravka
On 18 Dec 2006 12:47:11 GMT, Nicolas George <nicolas$ wrote:
À part le fait que tous les systèmes d'exploitation s'appuient sur les progrès faits par leurs prédécesseurs, Si je n'avais pas fréquenté très longtemps MacOS9 (je parle de l'OS,
hein, pas des petits mickeys qui l'habillent), je serais d'accord avec toi. ;->
le seul élément d'héritage attesté est l'identité du chef programmeur. Tu crois que David Cutler avait envie de se mettre en totale détente ?
:-) -- Nina
On 18 Dec 2006 12:47:11 GMT, Nicolas George
<nicolas$george@salle-s.org> wrote:
À part le fait que tous les systèmes d'exploitation s'appuient sur les
progrès faits par leurs prédécesseurs,
Si je n'avais pas fréquenté très longtemps MacOS9 (je parle de l'OS,
hein, pas des petits mickeys qui l'habillent), je serais d'accord avec
toi. ;->
le seul élément d'héritage attesté
est l'identité du chef programmeur.
Tu crois que David Cutler avait envie de se mettre en totale détente ?
On 18 Dec 2006 12:47:11 GMT, Nicolas George <nicolas$ wrote:
À part le fait que tous les systèmes d'exploitation s'appuient sur les progrès faits par leurs prédécesseurs, Si je n'avais pas fréquenté très longtemps MacOS9 (je parle de l'OS,
hein, pas des petits mickeys qui l'habillent), je serais d'accord avec toi. ;->
le seul élément d'héritage attesté est l'identité du chef programmeur. Tu crois que David Cutler avait envie de se mettre en totale détente ?
:-) -- Nina
Pascal Hambourg
Un petit exemple pour la route de ce que permet le système de droits d'Unix que ne permettent pas les ACL de Windows NT ? Merci.
il n'est pas besoin "d'exemple", c'est une question de structure : en unix, les "droits" sont un principe substantiel du file-system, en NT c'est une sur-couche au file-system.
Et qu'est-ce que ça change d'un point de vue opérationnel ?
en unix, le système "user-group-other" avec rwx plus les marqueurs suid et guid intègre en interne la gestion des accès,
Je n'y avais pas pensé mais puisque tu en parles, existe-t-il sous NT un équivalent de SUID/SGID ?
en NT, on ajoute par-dessus des listes de cas particuliers.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle combinaison de droits unix, mais ce n'est pas une propriété générique du système.
ça va comme ça ?
Franchement, je reste sur ma faim.
Un petit exemple pour la route de ce que permet le système de droits
d'Unix que ne permettent pas les ACL de Windows NT ? Merci.
il n'est pas besoin "d'exemple", c'est une question de structure :
en unix, les "droits" sont un principe substantiel du file-system,
en NT c'est une sur-couche au file-system.
Et qu'est-ce que ça change d'un point de vue opérationnel ?
en unix, le système "user-group-other" avec rwx plus les marqueurs suid et
guid intègre en interne la gestion des accès,
Je n'y avais pas pensé mais puisque tu en parles, existe-t-il sous NT un
équivalent de SUID/SGID ?
en NT, on ajoute par-dessus des listes de cas particuliers.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle
combinaison de droits unix, mais ce n'est pas une propriété générique du
système.
Un petit exemple pour la route de ce que permet le système de droits d'Unix que ne permettent pas les ACL de Windows NT ? Merci.
il n'est pas besoin "d'exemple", c'est une question de structure : en unix, les "droits" sont un principe substantiel du file-system, en NT c'est une sur-couche au file-system.
Et qu'est-ce que ça change d'un point de vue opérationnel ?
en unix, le système "user-group-other" avec rwx plus les marqueurs suid et guid intègre en interne la gestion des accès,
Je n'y avais pas pensé mais puisque tu en parles, existe-t-il sous NT un équivalent de SUID/SGID ?
en NT, on ajoute par-dessus des listes de cas particuliers.
bien sûr, on peut imiter par une règle particulière en ACL n'importe quelle combinaison de droits unix, mais ce n'est pas une propriété générique du système.
