Je recherche quels sont les protocols qui sont au même niveau que la
couche IP, comment ces protocol adresses sur le reseau (WWW, ou autres)
?
En suite je connais deux façons de coder une adresse IP
Classique : xxx.xxx.xxx.xxx
Hexadécimal: FFF00FF0 (par exemple )
Comment une fois après avoir relever ces adresses sur une paserelle
via, toujours par exemple tcpdump, la recherché dans le code source
(quelqu'un me dit que cette opération est imposible )?
<parano_on>
Comment faire en sorte que ma paserelle out-line renvoie un paquet à
chaque requete reseau, afin de voir quel difference de comportement
entre in et out ?
(sur la machine que j'audite !)
<parano_off>
Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
dis-moi si je me trompe, mais tu chercherais pas à savoir si ton "OS" envoie
des paquets vers une adresse précise ou bien en reçoit? (par exemple dans le
cas d'un ver, ou d'un malware qui tente de se compléter).
Mon O.S. envoie bien des paquets, l'infortisien étant fourbe a ses moment perdu j'aimerais pouvoir trouvé par une solution informatique, ces petits morceaux de codes qui permettent, de communiquer avec ce grand reseau (WWW )
http://www.asyd.net/docs/kernel/tcpip-stack.html une tentative de description de la pile tcp/ip sous linux. ça pourrait etre un bon point de départ pour toi pour savoir comment linux (et tout autre linux like) gère les paquets.
"La vérité est ailleurs? Ben Mon cerveau aussi dans ce cas :p"
Au moins, je te fais rire ...
euh... non en fait là c'était ma signature ;-)
"ptilou" <ptilou@gmail.com> a écrit en ces termes
Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
dis-moi si je me trompe, mais tu chercherais pas à savoir si ton
"OS" envoie
des paquets vers une adresse précise ou bien en reçoit? (par
exemple dans le
cas d'un ver, ou d'un malware qui tente de se compléter).
Mon O.S. envoie bien des paquets, l'infortisien étant fourbe a ses
moment perdu j'aimerais pouvoir trouvé par une solution informatique,
ces petits morceaux de codes qui permettent, de communiquer avec ce
grand reseau (WWW )
http://www.asyd.net/docs/kernel/tcpip-stack.html
une tentative de description de la pile tcp/ip sous linux. ça pourrait etre
un bon point de départ pour toi pour savoir comment linux (et tout autre
linux like) gère les paquets.
"La vérité est ailleurs? Ben Mon cerveau aussi dans ce cas :p"
Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
dis-moi si je me trompe, mais tu chercherais pas à savoir si ton "OS" envoie
des paquets vers une adresse précise ou bien en reçoit? (par exemple dans le
cas d'un ver, ou d'un malware qui tente de se compléter).
Mon O.S. envoie bien des paquets, l'infortisien étant fourbe a ses moment perdu j'aimerais pouvoir trouvé par une solution informatique, ces petits morceaux de codes qui permettent, de communiquer avec ce grand reseau (WWW )
http://www.asyd.net/docs/kernel/tcpip-stack.html une tentative de description de la pile tcp/ip sous linux. ça pourrait etre un bon point de départ pour toi pour savoir comment linux (et tout autre linux like) gère les paquets.
"La vérité est ailleurs? Ben Mon cerveau aussi dans ce cas :p"
Au moins, je te fais rire ...
euh... non en fait là c'était ma signature ;-)
hotus
un autre lien pas trop mal: http://www-phase.c-strasbourg.fr/inform/linux/cours/linux-reseau.html#toc3
un autre lien pas trop mal:
http://www-phase.c-strasbourg.fr/inform/linux/cours/linux-reseau.html#toc3
un autre lien pas trop mal: http://www-phase.c-strasbourg.fr/inform/linux/cours/linux-reseau.html#toc3
ptilou
Bonjour,
Xavier wrote:
ptilou wrote:
Tu veux auditer un OS? quel OS ( à priori c'est un truc dérivé du noyau
linux)? (quoique la dernière phrase me fait penser à un soft plutot) l'
"O.S" en question est installé sur ta machine ou sur celle de la "clientèle"?
Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
Ah oui, mais dans ce cas, se pose la question de l'efficacité de la boule de cristal. Si tu veux de l'aide explique clairement les tenants
et aboutissements de l'affaire, dans quel contexte, pourquoi, comment,
etc.
je connais deux façons de coder une adresse IP
Classique : xxx.xxx.xxx.xxx Hexadécimal: FFF00FF0 (par exemple ) Comment une fois après avoir relever ces adresses sur une paserelle via, toujours par exemple tcpdump, la recherché dans le code source ?
En devinant, on n'arrive pas à grand chose.
Et puis je supose qui doit y en avoir d'autre dans le code, mais sans les avoir vu, d'ou ma question sur le poste de départ ...
Philippe
Bonjour,
Xavier wrote:
ptilou <ptilou@gmail.com> wrote:
Tu veux auditer un OS? quel OS ( à priori c'est un truc dérivé
du noyau
linux)? (quoique la dernière phrase me fait penser à un soft
plutot) l'
"O.S" en question est installé sur ta machine ou sur celle de la
"clientèle"?
Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
Ah oui, mais dans ce cas, se pose la question de l'efficacité de la
boule de cristal. Si tu veux de l'aide explique clairement les
tenants
et aboutissements de l'affaire, dans quel contexte, pourquoi,
comment,
etc.
je connais deux façons de coder une adresse IP
Classique : xxx.xxx.xxx.xxx
Hexadécimal: FFF00FF0 (par exemple )
Comment une fois après avoir relever ces adresses sur une paserelle
via, toujours par exemple tcpdump, la recherché dans le code source ?
En devinant, on n'arrive pas à grand chose.
Et puis je supose qui doit y en avoir d'autre dans le code, mais sans
les avoir vu, d'ou ma question sur le poste de départ ...
Tu veux auditer un OS? quel OS ( à priori c'est un truc dérivé du noyau
linux)? (quoique la dernière phrase me fait penser à un soft plutot) l'
"O.S" en question est installé sur ta machine ou sur celle de la "clientèle"?
Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
Ah oui, mais dans ce cas, se pose la question de l'efficacité de la boule de cristal. Si tu veux de l'aide explique clairement les tenants
et aboutissements de l'affaire, dans quel contexte, pourquoi, comment,
etc.
je connais deux façons de coder une adresse IP
Classique : xxx.xxx.xxx.xxx Hexadécimal: FFF00FF0 (par exemple ) Comment une fois après avoir relever ces adresses sur une paserelle via, toujours par exemple tcpdump, la recherché dans le code source ?
En devinant, on n'arrive pas à grand chose.
Et puis je supose qui doit y en avoir d'autre dans le code, mais sans les avoir vu, d'ou ma question sur le poste de départ ...
Philippe
Alain Thivillon
ptilou wrote:
Comment une fois après avoir relever ces adresses sur une paserelle via, toujours par exemple tcpdump, la recherché dans le code source ?
Je vais faire une démonstration par l'absurde : que ferais-je si j'avais à faire ce travail pour un client sur un logiciel dont je n'aurais pas les sources ?
Sous Unix je connais deux moyens directs et standard d'envoyer des paquets à une adresse IP donnée : soit en faisant write(2) dans un socket connecté auparavant par socket(2), soit en utilisant sendto(2) sur un socket non connecté.
Je chercherais donc en dessassemblant tous les appels à ces deux fonctions de la libc (connect et sentdo) en regardant d'ou elles prennent leurs paramètres. Il est possible que j'en oublie, c'est probable même.
Evidemment comme désassembler c'est pénible, on peut évidemment utiliser strace(1) pour voir déjà un peu ce qui se passe.
Voila la manière directe, la manière standard.
Ca ne suffit absolument pas : Evidemment si j'ai des intentions malicieuses (envoyer de précieuses données à l'extérieur) je vais vous compliquer la vie:
- je commencerais par ne pas utiliser la libc mais en appelant le noyau directement. C'est moins portable mais sous Linux ce n'est pas très difficile et ça reste une méthode stable, à la différence de Windows.
- je ferais des requêtes DNS un peu spéciales vers mon domaine ou un domaine compromis, en utilisant les requêtes pour envoyer les données et les réponses pour recevoir les ordres à exécuter. Même si vous utilisez les DNS de votre opérateur vous ne verrez que des requêtes DNS standard vers des adresses IP connues : il faut donc regarder ce qu'il y a à l'intérieur, pas seulement les adresses IP.
- Si je suis sur le meme réseau j'enverrais du multicast, pas vu pas pris, pas détecté en général ("c'est quoi ces adresses 224.x ?" "c'est du multicast !" "ah ok ..., ca sert à quoi ?" "mhhhh je sais pas j'en vois partout même chez moi entre ma livebox et mon XP, c'est compliqué, allez on a mieux à faire !")
Tout ça part du principe évidemment que le programme en question ne soit pas root, parce qu'alors sinon ca se complique:
- j'utiliserais d'autres interfaces moins standard du kernel , par exemple en utilisant libipq ou tout autre moyen pour écrire dans la couche IP en tripatouillant les paquets, il doit bien y avoir une cinq ou six méthodes distinctes, par exemple netlink(7) etc ..; - J'insererais un module à moi qui se branche sur netfilter ou sur la couche IP voir sur les interfaces, et je lui passerais des paquets chiffrés en AES via un ioctl avec une clé qui change à chaque insertion du module. Quand le programme s'arrete il enlève le module. - je n'ai personnellement pas beaucoup d'imagination, mais plein de gens seront très créatifs.
Evidemment, si j'ai le source, c'est tout de suite plus facile: je peux stracer, et chercher dans le code source les appels aux fonctions dont je viens de parler. Si j'ai un doute, je peux toujours recompiler le source qu'on m'a donné pour obtenir un binaire dont je sais à priori prédire le comportement.
Tout ça pour dire que ce travail compliqué est bien évidemment beaucoup plus facile avec les sources, et que vos arguments sont des arguments à la con (en plus d'être ilisibles).
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
ptilou <ptilou@gmail.com> wrote:
Comment une fois après avoir relever ces adresses sur une paserelle
via, toujours par exemple tcpdump, la recherché dans le code source ?
Je vais faire une démonstration par l'absurde : que ferais-je si j'avais
à faire ce travail pour un client sur un logiciel dont je n'aurais pas
les sources ?
Sous Unix je connais deux moyens directs et standard d'envoyer des
paquets à une adresse IP donnée : soit en faisant write(2) dans un
socket connecté auparavant par socket(2), soit en utilisant sendto(2)
sur un socket non connecté.
Je chercherais donc en dessassemblant tous les appels à ces deux
fonctions de la libc (connect et sentdo) en regardant d'ou elles prennent
leurs paramètres. Il est possible que j'en oublie, c'est probable même.
Evidemment comme désassembler c'est pénible, on peut évidemment utiliser
strace(1) pour voir déjà un peu ce qui se passe.
Voila la manière directe, la manière standard.
Ca ne suffit absolument pas : Evidemment si j'ai des intentions
malicieuses (envoyer de précieuses données à l'extérieur) je vais vous
compliquer la vie:
- je commencerais par ne pas utiliser la libc mais en appelant le
noyau directement. C'est moins portable mais sous Linux ce n'est pas
très difficile et ça reste une méthode stable, à la différence de
Windows.
- je ferais des requêtes DNS un peu spéciales vers mon domaine ou un
domaine compromis, en utilisant les requêtes pour envoyer les données
et les réponses pour recevoir les ordres à exécuter. Même si vous
utilisez les DNS de votre opérateur vous ne verrez que des requêtes DNS
standard vers des adresses IP connues : il faut donc regarder ce qu'il y
a à l'intérieur, pas seulement les adresses IP.
- Si je suis sur le meme réseau j'enverrais du multicast, pas
vu pas pris, pas détecté en général ("c'est quoi ces adresses 224.x ?"
"c'est du multicast !" "ah ok ..., ca sert à quoi ?" "mhhhh je sais
pas j'en vois partout même chez moi entre ma livebox et mon XP, c'est
compliqué, allez on a mieux à faire !")
Tout ça part du principe évidemment que le programme en question ne soit
pas root, parce qu'alors sinon ca se complique:
- j'utiliserais d'autres interfaces moins standard du kernel , par
exemple en utilisant libipq ou tout autre moyen pour écrire dans la
couche IP en tripatouillant les paquets, il doit bien y avoir une
cinq ou six méthodes distinctes, par exemple netlink(7) etc ..;
- J'insererais un module à moi qui se branche sur netfilter ou
sur la couche IP voir sur les interfaces, et je lui passerais des
paquets chiffrés en AES via un ioctl avec une clé qui change à chaque
insertion du module. Quand le programme s'arrete il enlève le module.
- je n'ai personnellement pas beaucoup d'imagination, mais plein de gens
seront très créatifs.
Evidemment, si j'ai le source, c'est tout de suite plus facile: je peux
stracer, et chercher dans le code source les appels aux fonctions dont
je viens de parler. Si j'ai un doute, je peux toujours recompiler le
source qu'on m'a donné pour obtenir un binaire dont je sais à priori
prédire le comportement.
Tout ça pour dire que ce travail compliqué est bien évidemment beaucoup
plus facile avec les sources, et que vos arguments sont des arguments à
la con (en plus d'être ilisibles).
--
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Comment une fois après avoir relever ces adresses sur une paserelle via, toujours par exemple tcpdump, la recherché dans le code source ?
Je vais faire une démonstration par l'absurde : que ferais-je si j'avais à faire ce travail pour un client sur un logiciel dont je n'aurais pas les sources ?
Sous Unix je connais deux moyens directs et standard d'envoyer des paquets à une adresse IP donnée : soit en faisant write(2) dans un socket connecté auparavant par socket(2), soit en utilisant sendto(2) sur un socket non connecté.
Je chercherais donc en dessassemblant tous les appels à ces deux fonctions de la libc (connect et sentdo) en regardant d'ou elles prennent leurs paramètres. Il est possible que j'en oublie, c'est probable même.
Evidemment comme désassembler c'est pénible, on peut évidemment utiliser strace(1) pour voir déjà un peu ce qui se passe.
Voila la manière directe, la manière standard.
Ca ne suffit absolument pas : Evidemment si j'ai des intentions malicieuses (envoyer de précieuses données à l'extérieur) je vais vous compliquer la vie:
- je commencerais par ne pas utiliser la libc mais en appelant le noyau directement. C'est moins portable mais sous Linux ce n'est pas très difficile et ça reste une méthode stable, à la différence de Windows.
- je ferais des requêtes DNS un peu spéciales vers mon domaine ou un domaine compromis, en utilisant les requêtes pour envoyer les données et les réponses pour recevoir les ordres à exécuter. Même si vous utilisez les DNS de votre opérateur vous ne verrez que des requêtes DNS standard vers des adresses IP connues : il faut donc regarder ce qu'il y a à l'intérieur, pas seulement les adresses IP.
- Si je suis sur le meme réseau j'enverrais du multicast, pas vu pas pris, pas détecté en général ("c'est quoi ces adresses 224.x ?" "c'est du multicast !" "ah ok ..., ca sert à quoi ?" "mhhhh je sais pas j'en vois partout même chez moi entre ma livebox et mon XP, c'est compliqué, allez on a mieux à faire !")
Tout ça part du principe évidemment que le programme en question ne soit pas root, parce qu'alors sinon ca se complique:
- j'utiliserais d'autres interfaces moins standard du kernel , par exemple en utilisant libipq ou tout autre moyen pour écrire dans la couche IP en tripatouillant les paquets, il doit bien y avoir une cinq ou six méthodes distinctes, par exemple netlink(7) etc ..; - J'insererais un module à moi qui se branche sur netfilter ou sur la couche IP voir sur les interfaces, et je lui passerais des paquets chiffrés en AES via un ioctl avec une clé qui change à chaque insertion du module. Quand le programme s'arrete il enlève le module. - je n'ai personnellement pas beaucoup d'imagination, mais plein de gens seront très créatifs.
Evidemment, si j'ai le source, c'est tout de suite plus facile: je peux stracer, et chercher dans le code source les appels aux fonctions dont je viens de parler. Si j'ai un doute, je peux toujours recompiler le source qu'on m'a donné pour obtenir un binaire dont je sais à priori prédire le comportement.
Tout ça pour dire que ce travail compliqué est bien évidemment beaucoup plus facile avec les sources, et que vos arguments sont des arguments à la con (en plus d'être ilisibles).
-- A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Sebastien Vincent
"O.S" en question est installé sur ta machine ou sur celle de la "clientèle"? Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
Ah oui, mais dans ce cas, se pose la question de l'efficacité de la
boule de cristal. Si tu veux de l'aide explique clairement les tenants et aboutissements de l'affaire, dans quel contexte, pourquoi, je connais deux façons de coder une adresse IP
Classique : xxx.xxx.xxx.xxx Hexadécimal: FFF00FF0 (par exemple ) Comment une fois après avoir relever ces adresses sur une paserelle via, toujours par exemple tcpdump, la recherché dans le code source ?
Bon voici trois questions qui mériteraient des réponses claires pour que les divers intervenants puisse t'aider.
Quel est le système d'exploitation que tu audite (précisément) ?
Qu'est ce qui te fait techniquement penser que la machine recelle un code milicieux ?
As tu déja audité quelque chose car l'audit demande un petit bout d'expérience d'abord ?
Amicalement,
Seb :)
"O.S" en question est installé sur ta machine ou sur celle de la
"clientèle"?
Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
Ah oui, mais dans ce cas, se pose la question de l'efficacité de la
boule de cristal. Si tu veux de l'aide explique clairement les
tenants
et aboutissements de l'affaire, dans quel contexte, pourquoi,
je connais deux façons de coder une adresse IP
Classique : xxx.xxx.xxx.xxx
Hexadécimal: FFF00FF0 (par exemple )
Comment une fois après avoir relever ces adresses sur une paserelle
via, toujours par exemple tcpdump, la recherché dans le code source ?
Bon voici trois questions qui mériteraient des réponses claires pour
que les divers intervenants puisse t'aider.
Quel est le système d'exploitation que tu audite (précisément) ?
Qu'est ce qui te fait techniquement penser que la machine recelle un
code milicieux ?
As tu déja audité quelque chose car l'audit demande un petit bout
d'expérience d'abord ?
"O.S" en question est installé sur ta machine ou sur celle de la "clientèle"? Peut importe, je veux l'auditer ! ( Et c'est bien de l'unix like )
Ah oui, mais dans ce cas, se pose la question de l'efficacité de la
boule de cristal. Si tu veux de l'aide explique clairement les tenants et aboutissements de l'affaire, dans quel contexte, pourquoi, je connais deux façons de coder une adresse IP
Classique : xxx.xxx.xxx.xxx Hexadécimal: FFF00FF0 (par exemple ) Comment une fois après avoir relever ces adresses sur une paserelle via, toujours par exemple tcpdump, la recherché dans le code source ?
Bon voici trois questions qui mériteraient des réponses claires pour que les divers intervenants puisse t'aider.
Quel est le système d'exploitation que tu audite (précisément) ?
Qu'est ce qui te fait techniquement penser que la machine recelle un code milicieux ?
As tu déja audité quelque chose car l'audit demande un petit bout d'expérience d'abord ?
Amicalement,
Seb :)
ptilou
Bonjour,
Xavier wrote:
[...]
Je te dis simplement que tant qu'on ne saura pas de quoi il s'agit, et
ce que tu veux en faire, on ne pourra pas deviner comment t'aider.
Et bien, je ne suis pas la pour faire de la délation ... Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une autre machine, avec un LL j'ai vu que cette machine sans carte reseau configurer à la fin du démarrage de L'os, avait envoyer plusieur paquet sur la machine OBSD ... Pour moi la question n'est pas d'incriminer ce LL, mais comment auditer tous LL ! Je pose une question qui me parrais des plus sérieuse ... C'est pour çà que je tente d'égrainer un raisonement, qui peut paraitre absconce, mais je ne peus me satisfaire, de quelques messages qui proclament une sécurité dans le LL, et je recherche une solution des plus sérieuse, qui le démontre ...
Ptilou
Bonjour,
Xavier wrote:
[...]
Je te dis simplement que tant qu'on ne saura pas de quoi il s'agit,
et
ce que tu veux en faire, on ne pourra pas deviner comment t'aider.
Et bien, je ne suis pas la pour faire de la délation ...
Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une
autre machine, avec un LL j'ai vu que cette machine sans carte reseau
configurer à la fin du démarrage de L'os, avait envoyer plusieur
paquet sur la machine OBSD ...
Pour moi la question n'est pas d'incriminer ce LL, mais comment auditer
tous LL !
Je pose une question qui me parrais des plus sérieuse ...
C'est pour çà que je tente d'égrainer un raisonement, qui peut
paraitre absconce, mais je ne peus me satisfaire, de quelques messages
qui proclament une sécurité dans le LL, et je recherche une solution
des plus sérieuse, qui le démontre ...
Je te dis simplement que tant qu'on ne saura pas de quoi il s'agit, et
ce que tu veux en faire, on ne pourra pas deviner comment t'aider.
Et bien, je ne suis pas la pour faire de la délation ... Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une autre machine, avec un LL j'ai vu que cette machine sans carte reseau configurer à la fin du démarrage de L'os, avait envoyer plusieur paquet sur la machine OBSD ... Pour moi la question n'est pas d'incriminer ce LL, mais comment auditer tous LL ! Je pose une question qui me parrais des plus sérieuse ... C'est pour çà que je tente d'égrainer un raisonement, qui peut paraitre absconce, mais je ne peus me satisfaire, de quelques messages qui proclament une sécurité dans le LL, et je recherche une solution des plus sérieuse, qui le démontre ...
Ptilou
Cedric Blancher
Le Thu, 24 Mar 2005 10:16:41 +0000, ptilou a écrit :
Je te dis simplement que tant qu'on ne saura pas de quoi il s'agit, Et bien, je ne suis pas la pour faire de la délation ...
Justement. Le principe du logiciel libre est d'ouvrir le code à la critique publique. Ce n'est pas de la délation, mais une interrogation légitime sur le fonctionnement d'un logiciel. Si les auteurs ne voulaient pas avoir ce genre d'interrogations sur leur code, il ferait du logiciel propriétaire. Donc il n'y a à mon sens aucun problème à dire ici quel OS/logiciel est incriminé.
Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une autre machine, avec un LL j'ai vu que cette machine sans carte reseau configurer à la fin du démarrage de L'os, avait envoyer plusieur paquet sur la machine OBSD ...
Et évidemment, tu as vérifié toute la configuration de la machine en question pour vérifier que rien n'était susceptible d'envoyer un paquet au cours de ce démarrage ?
Je pose une question qui me parrais des plus sérieuse ... C'est pour çà que je tente d'égrainer un raisonement, qui peut paraitre absconce, mais je ne peus me satisfaire, de quelques messages qui proclament une sécurité dans le LL, et je recherche une solution des plus sérieuse, qui le démontre ...
Personnellement, je dirai qu'apprendre à lire du C serait un bon début.
-- manquerait plus que les groupes soient pollués. c'est beaucoup plus grave que des plages bretonnes à deux francs qui étaient déjà polluées par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus -+- tilt in http://neuneu.mine.nu : Les oiseaux sont des cons.
Le Thu, 24 Mar 2005 10:16:41 +0000, ptilou a écrit :
Je te dis simplement que tant qu'on ne saura pas de quoi il s'agit,
Et bien, je ne suis pas la pour faire de la délation ...
Justement. Le principe du logiciel libre est d'ouvrir le code à la
critique publique. Ce n'est pas de la délation, mais une interrogation
légitime sur le fonctionnement d'un logiciel. Si les auteurs ne
voulaient pas avoir ce genre d'interrogations sur leur code, il ferait du
logiciel propriétaire. Donc il n'y a à mon sens aucun problème à dire
ici quel OS/logiciel est incriminé.
Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une
autre machine, avec un LL j'ai vu que cette machine sans carte reseau
configurer à la fin du démarrage de L'os, avait envoyer plusieur
paquet sur la machine OBSD ...
Et évidemment, tu as vérifié toute la configuration de la machine en
question pour vérifier que rien n'était susceptible d'envoyer un paquet
au cours de ce démarrage ?
Je pose une question qui me parrais des plus sérieuse ... C'est pour
çà que je tente d'égrainer un raisonement, qui peut paraitre
absconce, mais je ne peus me satisfaire, de quelques messages qui
proclament une sécurité dans le LL, et je recherche une solution des
plus sérieuse, qui le démontre ...
Personnellement, je dirai qu'apprendre à lire du C serait un bon début.
--
manquerait plus que les groupes soient pollués. c'est beaucoup plus
grave que des plages bretonnes à deux francs qui étaient déjà polluées
par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus
-+- tilt in http://neuneu.mine.nu : Les oiseaux sont des cons.
Le Thu, 24 Mar 2005 10:16:41 +0000, ptilou a écrit :
Je te dis simplement que tant qu'on ne saura pas de quoi il s'agit, Et bien, je ne suis pas la pour faire de la délation ...
Justement. Le principe du logiciel libre est d'ouvrir le code à la critique publique. Ce n'est pas de la délation, mais une interrogation légitime sur le fonctionnement d'un logiciel. Si les auteurs ne voulaient pas avoir ce genre d'interrogations sur leur code, il ferait du logiciel propriétaire. Donc il n'y a à mon sens aucun problème à dire ici quel OS/logiciel est incriminé.
Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une autre machine, avec un LL j'ai vu que cette machine sans carte reseau configurer à la fin du démarrage de L'os, avait envoyer plusieur paquet sur la machine OBSD ...
Et évidemment, tu as vérifié toute la configuration de la machine en question pour vérifier que rien n'était susceptible d'envoyer un paquet au cours de ce démarrage ?
Je pose une question qui me parrais des plus sérieuse ... C'est pour çà que je tente d'égrainer un raisonement, qui peut paraitre absconce, mais je ne peus me satisfaire, de quelques messages qui proclament une sécurité dans le LL, et je recherche une solution des plus sérieuse, qui le démontre ...
Personnellement, je dirai qu'apprendre à lire du C serait un bon début.
-- manquerait plus que les groupes soient pollués. c'est beaucoup plus grave que des plages bretonnes à deux francs qui étaient déjà polluées par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus -+- tilt in http://neuneu.mine.nu : Les oiseaux sont des cons.
Thierry Boudet
On 2005-03-24, ptilou wrote:
Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une autre machine, avec un LL j'ai vu que cette machine sans carte reseau configurer à la fin du démarrage de L'os, avait envoyer plusieur paquet sur la machine OBSD ...
Bien que je ne sois pas sûr d'avoir bien compris cette phrase, tu pourrais etayer tes affirmations avec un exemple documenté.
Pour moi la question n'est pas d'incriminer ce LL, mais comment auditer tous LL !
Use the source, Luke... Plus sérieusement, il serait bon que tu sois plus précis dans ta demande. Par exemple, on ne peut pas faire les même choses sur un noyau, un démon ou un outil cli. Mais pour te donner un point de départ:
$ cd /usr/src/linux $ cscope -R
Pour une application, tu peux utiliser d'autres techniques pour voir ce qui se passe. Parfois recompiler avec le profiling, et examiner la sortie de gprof peut t'apprendre des choses. Parfois un bon "valgrindage" met le doigt là ou ça chatouille.
qui proclament une sécurité dans le LL, et je recherche une solution des plus sérieuse, qui le démontre ...
Evidemment, si ton noyau est écrit en Caml, cscope ne sert à rien, demande à Tom & Joe Cool.
-- _/°< coin
On 2005-03-24, ptilou <ptilou@gmail.com> wrote:
Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une
autre machine, avec un LL j'ai vu que cette machine sans carte reseau
configurer à la fin du démarrage de L'os, avait envoyer plusieur
paquet sur la machine OBSD ...
Bien que je ne sois pas sûr d'avoir bien compris cette phrase,
tu pourrais etayer tes affirmations avec un exemple documenté.
Pour moi la question n'est pas d'incriminer ce LL, mais comment auditer
tous LL !
Use the source, Luke... Plus sérieusement, il serait bon que
tu sois plus précis dans ta demande. Par exemple, on ne peut
pas faire les même choses sur un noyau, un démon ou un outil
cli. Mais pour te donner un point de départ:
$ cd /usr/src/linux
$ cscope -R
Pour une application, tu peux utiliser d'autres techniques pour
voir ce qui se passe. Parfois recompiler avec le profiling,
et examiner la sortie de gprof peut t'apprendre des choses.
Parfois un bon "valgrindage" met le doigt là ou ça chatouille.
qui proclament une sécurité dans le LL, et je recherche une solution
des plus sérieuse, qui le démontre ...
Evidemment, si ton noyau est écrit en Caml, cscope ne sert à
rien, demande à Tom & Joe Cool.
Un jour j'ai mis une machine sous OBSD avec en consol tcpdump, sur une autre machine, avec un LL j'ai vu que cette machine sans carte reseau configurer à la fin du démarrage de L'os, avait envoyer plusieur paquet sur la machine OBSD ...
Bien que je ne sois pas sûr d'avoir bien compris cette phrase, tu pourrais etayer tes affirmations avec un exemple documenté.
Pour moi la question n'est pas d'incriminer ce LL, mais comment auditer tous LL !
Use the source, Luke... Plus sérieusement, il serait bon que tu sois plus précis dans ta demande. Par exemple, on ne peut pas faire les même choses sur un noyau, un démon ou un outil cli. Mais pour te donner un point de départ:
$ cd /usr/src/linux $ cscope -R
Pour une application, tu peux utiliser d'autres techniques pour voir ce qui se passe. Parfois recompiler avec le profiling, et examiner la sortie de gprof peut t'apprendre des choses. Parfois un bon "valgrindage" met le doigt là ou ça chatouille.
qui proclament une sécurité dans le LL, et je recherche une solution des plus sérieuse, qui le démontre ...
Evidemment, si ton noyau est écrit en Caml, cscope ne sert à rien, demande à Tom & Joe Cool.
-- _/°< coin
ptilou
Bonjour,
Thierry Boudet wrote:
[...]
Use the source, Luke... Plus sérieusement, il serait bon que tu sois plus précis dans ta demande. Par exemple, on ne peut pas faire les même choses sur un noyau, un démon ou un outil cli. Mais pour te donner un point de départ:
$ cd /usr/src/linux $ cscope -R
Pour une application, tu peux utiliser d'autres techniques pour voir ce qui se passe. Parfois recompiler avec le profiling, et examiner la sortie de gprof peut t'apprendre des choses. Parfois un bon "valgrindage" met le doigt là ou ça chatouille.
Bon, alors y a cscope et puis quoi d'autre ? Quesque c'est :valgrindage ?
Ptilou
Bonjour,
Thierry Boudet wrote:
[...]
Use the source, Luke... Plus sérieusement, il serait bon que
tu sois plus précis dans ta demande. Par exemple, on ne peut
pas faire les même choses sur un noyau, un démon ou un outil
cli. Mais pour te donner un point de départ:
$ cd /usr/src/linux
$ cscope -R
Pour une application, tu peux utiliser d'autres techniques pour
voir ce qui se passe. Parfois recompiler avec le profiling,
et examiner la sortie de gprof peut t'apprendre des choses.
Parfois un bon "valgrindage" met le doigt là ou ça chatouille.
Bon, alors y a cscope et puis quoi d'autre ?
Quesque c'est :valgrindage ?
Use the source, Luke... Plus sérieusement, il serait bon que tu sois plus précis dans ta demande. Par exemple, on ne peut pas faire les même choses sur un noyau, un démon ou un outil cli. Mais pour te donner un point de départ:
$ cd /usr/src/linux $ cscope -R
Pour une application, tu peux utiliser d'autres techniques pour voir ce qui se passe. Parfois recompiler avec le profiling, et examiner la sortie de gprof peut t'apprendre des choses. Parfois un bon "valgrindage" met le doigt là ou ça chatouille.
Bon, alors y a cscope et puis quoi d'autre ? Quesque c'est :valgrindage ?
Ptilou
ptilou
Bonjour,
Erwan David wrote: [...]
valgrind est un outil permettant de repérer des comportements pathologiques dans la gestion mémoire de programmes (débordements de
buffers, fuites mémoires, etc.)
Je ne sais pas ci il est necessaire d'aller aussi loin dans l'audite ? Moi je partais du principe qu'il y avait un code qui signaler l'utilisation d'un ou du logiciel, et ma question était quand à relevé l'adresse (IP, mais il doit y avoir d'autre fourberies dans le code ) comment la retrouver dans le code ? Sachant que je ne procede cas une analyse de la couche IP, faut'il annalyser un autre protocol au même niveau que cette couche ?
Merci
Ptilou
Bonjour,
Erwan David wrote:
[...]
valgrind est un outil permettant de repérer des comportements
pathologiques dans la gestion mémoire de programmes (débordements
de
buffers, fuites mémoires, etc.)
Je ne sais pas ci il est necessaire d'aller aussi loin dans l'audite ?
Moi je partais du principe qu'il y avait un code qui signaler
l'utilisation d'un ou du logiciel, et ma question était quand à
relevé l'adresse (IP, mais il doit y avoir d'autre fourberies dans le
code ) comment la retrouver dans le code ?
Sachant que je ne procede cas une analyse de la couche IP, faut'il
annalyser un autre protocol au même niveau que cette couche ?
valgrind est un outil permettant de repérer des comportements pathologiques dans la gestion mémoire de programmes (débordements de
buffers, fuites mémoires, etc.)
Je ne sais pas ci il est necessaire d'aller aussi loin dans l'audite ? Moi je partais du principe qu'il y avait un code qui signaler l'utilisation d'un ou du logiciel, et ma question était quand à relevé l'adresse (IP, mais il doit y avoir d'autre fourberies dans le code ) comment la retrouver dans le code ? Sachant que je ne procede cas une analyse de la couche IP, faut'il annalyser un autre protocol au même niveau que cette couche ?
