Nous avons deux disques USB "My Passport" d'un To (modèles WDBACX0010BBL
et WDBACX0010BRD). J'ai une question sur le fonctionnement des buffers
disques.
Avec l'un ou l'autre disque, monté en ntfs-g3, je lance plusieurs fois la
commande suivante :
# time tar -C $repertoire_disque -c ./ > /dev/null
La 1ère fois, elle met environ 1'10" à se terminer
Un coup d'oeil sur le site de WDt me dit que le taux de transfert peut
atteindre 480Mo/s en USB-2, ce qui est le cas de mon système.
Déjà là, on dépasse la vitesse théorique de 50% !
Mais la 2ème fois, la commande prend 12", à la 3ème 5,2", puis 4.7", etc.
La comande du se comporte de la même manière ; 1'8" puis 3.7" en
enchaînant les appels avec un disque; mais 53" puis 13" avec l'autre.
Je n'ai que 2Go de RAM, il est impossible que les données des disques
soient bufferisées là. Quelqu'un pourrait me dire si cette évolution des
temps de transfert est normale et à quoi elle est dûe dans ce cas ?
Le 25 Nov 2011 15:52:50 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces arguments rebattus.
Et tu es toujours le même. C'est même pour cela que tu es régulièrement dans mon killfile parce que tu es l'exact reflet de Stéphane Tougard. Tu affirmes n'importe quoi sous prétexte que tu _sais_ (voire que tu as la science infuse). Surtout, tu es capable de t'accrocher contre vents et marées pour ne surtout pas te dédire. Ça fait trop mal à l'amour propre. C'en est presque amusant si ce n'était pas ridicule.
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine (sur une machine distante dont on supposera qu'elle n'est pas elle-même vérolée) et à partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule). Pour répondre à mes arguments, il ne suffit pas de dire qu'ils sont ridicules ou parfaitemente idiots. Il faut encore dire en quoi ils sont parfaitement cons.
Au passage, cette technique est un grand classique. Mais ceux qui l'utilisent sont certainement tous des imbéciles. Je t'ai d'ailleurs déjà dit que je me contrefichais comme de ma première chemise que tu me traites d'imbécile ou que tu penses que je suis le dernier des crétins. Je n'ai aucune preuve à donner à Nicolas George qu'il s'agisse de mes comptétences ou de ce que tu croies être mes incompétences. En revanche, je trouve assez amusant que tu colles dans la même catégorie tous les utilisateurs des mêmes techniques.
Au fait, tu n'as toujours pas répondu à la question du /tmp et à ton extrait d'un script configure que visiblement tu n'as pas compris parce que tu as dégaîné plus vite que ton ombre.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 15:52:50 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjcv271.g08.jkb@rayleigh.systella.fr>, a
écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne
pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les
mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces
arguments rebattus.
Et tu es toujours le même. C'est même pour cela que tu es
régulièrement dans mon killfile parce que tu es l'exact reflet de
Stéphane Tougard. Tu affirmes n'importe quoi sous prétexte que tu
_sais_ (voire que tu as la science infuse). Surtout, tu es capable
de t'accrocher contre vents et marées pour ne surtout pas te dédire.
Ça fait trop mal à l'amour propre. C'en est presque amusant si ce
n'était pas ridicule.
J'aimerais que tu expliques à l'auditoire ici présent comment une
attaque peut passer inaperçue à partir du moment où tu loggues en
lecture seule tout ce qui se passe sur ta machine (sur une machine
distante dont on supposera qu'elle n'est pas elle-même vérolée) et à
partir du moment où tu vérifie périodiquemenet les sommes de hashage
de tous tes fichiers (à partir d'une machine distante en lecture
seule). Pour répondre à mes arguments, il ne suffit pas de dire
qu'ils sont ridicules ou parfaitemente idiots. Il faut encore dire
en quoi ils sont parfaitement cons.
Au passage, cette technique est un grand classique. Mais ceux qui
l'utilisent sont certainement tous des imbéciles. Je t'ai d'ailleurs
déjà dit que je me contrefichais comme de ma première chemise que tu
me traites d'imbécile ou que tu penses que je suis le dernier des
crétins. Je n'ai aucune preuve à donner à Nicolas George qu'il
s'agisse de mes comptétences ou de ce que tu croies être mes
incompétences. En revanche, je trouve assez amusant que tu colles dans
la même catégorie tous les utilisateurs des mêmes techniques.
Au fait, tu n'as toujours pas répondu à la question du /tmp et à ton
extrait d'un script configure que visiblement tu n'as pas compris
parce que tu as dégaîné plus vite que ton ombre.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 15:52:50 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces arguments rebattus.
Et tu es toujours le même. C'est même pour cela que tu es régulièrement dans mon killfile parce que tu es l'exact reflet de Stéphane Tougard. Tu affirmes n'importe quoi sous prétexte que tu _sais_ (voire que tu as la science infuse). Surtout, tu es capable de t'accrocher contre vents et marées pour ne surtout pas te dédire. Ça fait trop mal à l'amour propre. C'en est presque amusant si ce n'était pas ridicule.
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine (sur une machine distante dont on supposera qu'elle n'est pas elle-même vérolée) et à partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule). Pour répondre à mes arguments, il ne suffit pas de dire qu'ils sont ridicules ou parfaitemente idiots. Il faut encore dire en quoi ils sont parfaitement cons.
Au passage, cette technique est un grand classique. Mais ceux qui l'utilisent sont certainement tous des imbéciles. Je t'ai d'ailleurs déjà dit que je me contrefichais comme de ma première chemise que tu me traites d'imbécile ou que tu penses que je suis le dernier des crétins. Je n'ai aucune preuve à donner à Nicolas George qu'il s'agisse de mes comptétences ou de ce que tu croies être mes incompétences. En revanche, je trouve assez amusant que tu colles dans la même catégorie tous les utilisateurs des mêmes techniques.
Au fait, tu n'as toujours pas répondu à la question du /tmp et à ton extrait d'un script configure que visiblement tu n'as pas compris parce que tu as dégaîné plus vite que ton ombre.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Nicolas George
JKB , dans le message , a écrit :
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine
Il suffit que l'attaque ne laisse pas immédiatement de traces différentes d'une connexion légitime, le temps de prendre le contrôle du dispositif qui envoie les logs.
partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule)
Tu veux dire : tu utilises la machine B pour lire par réseau les fichiers de la machine A ? Dans ce cas, la réponse est assez triviale, il suffit de prendre le contrôle du serveur de fichiers sur la machine A.
Pour le reste, je ne répondrai pas, j'ai déjà dit pourquoi.
JKB , dans le message <slrnjcvhjb.4ro.jkb@rayleigh.systella.fr>, a
écrit :
J'aimerais que tu expliques à l'auditoire ici présent comment une
attaque peut passer inaperçue à partir du moment où tu loggues en
lecture seule tout ce qui se passe sur ta machine
Il suffit que l'attaque ne laisse pas immédiatement de traces différentes
d'une connexion légitime, le temps de prendre le contrôle du dispositif qui
envoie les logs.
partir du moment où tu vérifie périodiquemenet les sommes de hashage
de tous tes fichiers (à partir d'une machine distante en lecture
seule)
Tu veux dire : tu utilises la machine B pour lire par réseau les fichiers de
la machine A ? Dans ce cas, la réponse est assez triviale, il suffit de
prendre le contrôle du serveur de fichiers sur la machine A.
Pour le reste, je ne répondrai pas, j'ai déjà dit pourquoi.
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine
Il suffit que l'attaque ne laisse pas immédiatement de traces différentes d'une connexion légitime, le temps de prendre le contrôle du dispositif qui envoie les logs.
partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule)
Tu veux dire : tu utilises la machine B pour lire par réseau les fichiers de la machine A ? Dans ce cas, la réponse est assez triviale, il suffit de prendre le contrôle du serveur de fichiers sur la machine A.
Pour le reste, je ne répondrai pas, j'ai déjà dit pourquoi.
JKB
Le 25 Nov 2011 17:31:04 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine
Il suffit que l'attaque ne laisse pas immédiatement de traces différentes d'une connexion légitime, le temps de prendre le contrôle du dispositif qui envoie les logs.
C'est très bien. Est-ce que tu m'as lu ?
partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule)
Tu veux dire : tu utilises la machine B pour lire par réseau les fichiers de la machine A ? Dans ce cas, la réponse est assez triviale, il suffit de prendre le contrôle du serveur de fichiers sur la machine A.
J'ai la réponse.
Tu m'as peut-être lu, mais tu n'as rien compris une fois de plus. Je répète une dernière fois pour toi. La machine A envoie ses logs en SQL sur un serveur présent sur la machine B qui n'a que des autorisations d'écriture. Avant de prendre la main sur le logger de A, l'attaquant laisse des traces qui sont visibles dans les logs de B qui ne sont pas effaçables comme il le ferait normalement. Les sommes de hashages sont lues aussi au travers d'une base SQL de B (pas la même) qui n'est accessible qu'en lecture seule depuis A. Il n'y a pas de lecture par le réseau, pas même un NFS. Tout passe par du SQL (sans mot de passe, mais avec des autorisations strictes). Pour que l'attaque passe inaperçue, il faut que l'attaquant prenne d'abord la main sur la machine hébergeant les logs (qui n'est pas accessible depuis l'extérieur) et qui analyse en temps réel.
Pour le reste, je ne répondrai pas, j'ai déjà dit pourquoi.
Non, tu tiens à avoir raison, ni plus ni moins et surtout, tu tiens à être le dernier à parler, ça te donne l'impression d'avoir raison.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 17:31:04 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :
JKB , dans le message <slrnjcvhjb.4ro.jkb@rayleigh.systella.fr>, a
écrit :
J'aimerais que tu expliques à l'auditoire ici présent comment une
attaque peut passer inaperçue à partir du moment où tu loggues en
lecture seule tout ce qui se passe sur ta machine
Il suffit que l'attaque ne laisse pas immédiatement de traces différentes
d'une connexion légitime, le temps de prendre le contrôle du dispositif qui
envoie les logs.
C'est très bien. Est-ce que tu m'as lu ?
partir du moment où tu vérifie périodiquemenet les sommes de hashage
de tous tes fichiers (à partir d'une machine distante en lecture
seule)
Tu veux dire : tu utilises la machine B pour lire par réseau les fichiers de
la machine A ? Dans ce cas, la réponse est assez triviale, il suffit de
prendre le contrôle du serveur de fichiers sur la machine A.
J'ai la réponse.
Tu m'as peut-être lu, mais tu n'as rien compris une fois de plus. Je
répète une dernière fois pour toi. La machine A envoie ses logs en SQL
sur un serveur présent sur la machine B qui n'a que des autorisations
d'écriture. Avant de prendre la main sur le logger de A, l'attaquant
laisse des traces qui sont visibles dans les logs de B qui ne sont
pas effaçables comme il le ferait normalement. Les sommes de
hashages sont lues aussi au travers d'une base SQL de B (pas la
même) qui n'est accessible qu'en lecture seule depuis A. Il n'y a
pas de lecture par le réseau, pas même un NFS. Tout passe par du SQL
(sans mot de passe, mais avec des autorisations strictes). Pour que
l'attaque passe inaperçue, il faut que l'attaquant prenne d'abord la
main sur la machine hébergeant les logs (qui n'est pas accessible
depuis l'extérieur) et qui analyse en temps réel.
Pour le reste, je ne répondrai pas, j'ai déjà dit pourquoi.
Non, tu tiens à avoir raison, ni plus ni moins et surtout, tu tiens
à être le dernier à parler, ça te donne l'impression d'avoir raison.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 25 Nov 2011 17:31:04 GMT, Nicolas George <nicolas$ écrivait :
JKB , dans le message , a écrit :
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine
Il suffit que l'attaque ne laisse pas immédiatement de traces différentes d'une connexion légitime, le temps de prendre le contrôle du dispositif qui envoie les logs.
C'est très bien. Est-ce que tu m'as lu ?
partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule)
Tu veux dire : tu utilises la machine B pour lire par réseau les fichiers de la machine A ? Dans ce cas, la réponse est assez triviale, il suffit de prendre le contrôle du serveur de fichiers sur la machine A.
J'ai la réponse.
Tu m'as peut-être lu, mais tu n'as rien compris une fois de plus. Je répète une dernière fois pour toi. La machine A envoie ses logs en SQL sur un serveur présent sur la machine B qui n'a que des autorisations d'écriture. Avant de prendre la main sur le logger de A, l'attaquant laisse des traces qui sont visibles dans les logs de B qui ne sont pas effaçables comme il le ferait normalement. Les sommes de hashages sont lues aussi au travers d'une base SQL de B (pas la même) qui n'est accessible qu'en lecture seule depuis A. Il n'y a pas de lecture par le réseau, pas même un NFS. Tout passe par du SQL (sans mot de passe, mais avec des autorisations strictes). Pour que l'attaque passe inaperçue, il faut que l'attaquant prenne d'abord la main sur la machine hébergeant les logs (qui n'est pas accessible depuis l'extérieur) et qui analyse en temps réel.
Pour le reste, je ne répondrai pas, j'ai déjà dit pourquoi.
Non, tu tiens à avoir raison, ni plus ni moins et surtout, tu tiens à être le dernier à parler, ça te donne l'impression d'avoir raison.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Herve Autret
Hugues :
ma prochaine install aura sans doute le /tmp monté en tmpfs avec un plus gros swap.
Hum, quel est le rapport avec la swap ?
C'est dit là : [linux sources]/Documentation/filesystems/tmpfs.txt
[trad. (à la louche) :] Le contenu d'un tmpfs est contenu dans les tampons internes du noyau, et swappé au besoin.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du répertoire mais s'il y a des mouvements je finirai bien par les voir, non ?
Si ça peut te faire plaisir. Mais je rejoins Nicolas : ça ne sert strictement à rien.
Ce qui ne tue pas ... :-)
à + -- Hervé
Hugues :
ma prochaine install aura sans doute le /tmp monté en tmpfs avec un
plus gros swap.
Hum, quel est le rapport avec la swap ?
C'est dit là : [linux sources]/Documentation/filesystems/tmpfs.txt
[trad. (à la louche) :] Le contenu d'un tmpfs est contenu dans les
tampons internes du noyau, et swappé au besoin.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du
répertoire mais s'il y a des mouvements je finirai bien par les voir,
non ?
Si ça peut te faire plaisir.
Mais je rejoins Nicolas : ça ne sert strictement à rien.
ma prochaine install aura sans doute le /tmp monté en tmpfs avec un plus gros swap.
Hum, quel est le rapport avec la swap ?
C'est dit là : [linux sources]/Documentation/filesystems/tmpfs.txt
[trad. (à la louche) :] Le contenu d'un tmpfs est contenu dans les tampons internes du noyau, et swappé au besoin.
Durée inférieure mais non nulle. Je n'aurai pas le contenu réel du répertoire mais s'il y a des mouvements je finirai bien par les voir, non ?
Si ça peut te faire plaisir. Mais je rejoins Nicolas : ça ne sert strictement à rien.
Ce qui ne tue pas ... :-)
à + -- Hervé
Stephane CARPENTIER
Herve Autret wrote:
Hugues :
Mais je rejoins Nicolas : ça ne sert strictement à rien.
Ce qui ne tue pas ... :-)
Le problème, c'est que le jour où tu ça te pète à la figure, tu dois :
1- comprendre que le problème vient de ce que tu fais depuis un certain temps, 2- chercher à savoir comment tu vas t'y prendre désormais, 3- retrouver tous les endroits où tu avais fait ça parce que tu trouvais ça cool pour appliquer ta nouvelle méthode.
Ça peut ne jamais te claquer à la figure, mais si ça arrive, tu perds beaucoup de temps. Alors que d'appliquer directement la bonne méthode t'évide le temps perdu aux étapes 1 et 3 (sans compter les désagréments).
Herve Autret wrote:
Hugues :
Mais je rejoins Nicolas : ça ne sert strictement à rien.
Ce qui ne tue pas ... :-)
Le problème, c'est que le jour où tu ça te pète à la figure, tu dois :
1- comprendre que le problème vient de ce que tu fais depuis un certain
temps,
2- chercher à savoir comment tu vas t'y prendre désormais,
3- retrouver tous les endroits où tu avais fait ça parce que tu trouvais ça
cool pour appliquer ta nouvelle méthode.
Ça peut ne jamais te claquer à la figure, mais si ça arrive, tu perds
beaucoup de temps. Alors que d'appliquer directement la bonne méthode
t'évide le temps perdu aux étapes 1 et 3 (sans compter les désagréments).
Mais je rejoins Nicolas : ça ne sert strictement à rien.
Ce qui ne tue pas ... :-)
Le problème, c'est que le jour où tu ça te pète à la figure, tu dois :
1- comprendre que le problème vient de ce que tu fais depuis un certain temps, 2- chercher à savoir comment tu vas t'y prendre désormais, 3- retrouver tous les endroits où tu avais fait ça parce que tu trouvais ça cool pour appliquer ta nouvelle méthode.
Ça peut ne jamais te claquer à la figure, mais si ça arrive, tu perds beaucoup de temps. Alors que d'appliquer directement la bonne méthode t'évide le temps perdu aux étapes 1 et 3 (sans compter les désagréments).
Herve Autret
Stephane CARPENTIER :
Ce qui ne tue pas ... :-)
Le problème, c'est que le jour où tu ça te pète à la figure, tu dois : 1- comprendre que le problème vient de ce que tu fais depuis un certain temps, 2- chercher à savoir comment tu vas t'y prendre désormais, 3- retrouver tous les endroits où tu avais fait ça parce que tu trouvais ça cool pour appliquer ta nouvelle méthode.
Encore faut-il n'avoir qu'une casserole sur le feu... :-^
Ça peut ne jamais te claquer à la figure, mais si ça arrive, tu perds beaucoup de temps. Alors que d'appliquer directement la bonne méthode t'évide le temps perdu aux étapes 1 et 3 (sans compter les désagréments).
Je suis d'accord avec tout ce que tu viens de dire. En pratique, je pense même qu'il faut plus de QI pour faire comme tu dis, que pour vivre en pariant que tel ou tel comportement imprudent va m'être bénéficiaire sans contrepartie à long terme.
Concernant /dev/shm : D'un côté, le fait que personne ne soutiene mes assertions devrait m'inciter à la prudence, au moins déclarative. D'un autre côté, je devrais creuser la question ; me contenter d'avoir trouvé juste « shm_open ("/shm-test" ... » dans les source de la libc, c'est un peu léger pour conclure (et le fd, on lui fait quoi ensuite ?).
Pour l'instant je fais le truc pas propre : désormais j'échantillonne / dev/shm. Je garde le truc plus ardu à faire (lire le source) sous le coude.
à + -- Hervé
Stephane CARPENTIER :
Ce qui ne tue pas ... :-)
Le problème, c'est que le jour où tu ça te pète à la figure, tu dois :
1- comprendre que le problème vient de ce que tu fais depuis un certain
temps,
2- chercher à savoir comment tu vas t'y prendre désormais,
3- retrouver tous les endroits où tu avais fait ça parce que tu trouvais
ça cool pour appliquer ta nouvelle méthode.
Encore faut-il n'avoir qu'une casserole sur le feu... :-^
Ça peut ne jamais te claquer à la figure, mais si ça arrive, tu perds
beaucoup de temps. Alors que d'appliquer directement la bonne méthode
t'évide le temps perdu aux étapes 1 et 3 (sans compter les
désagréments).
Je suis d'accord avec tout ce que tu viens de dire. En pratique, je pense
même qu'il faut plus de QI pour faire comme tu dis, que pour vivre en
pariant que tel ou tel comportement imprudent va m'être bénéficiaire sans
contrepartie à long terme.
Concernant /dev/shm : D'un côté, le fait que personne ne soutiene mes
assertions devrait m'inciter à la prudence, au moins déclarative.
D'un autre côté, je devrais creuser la question ; me contenter d'avoir
trouvé juste « shm_open ("/shm-test" ... » dans les source de la libc,
c'est un peu léger pour conclure (et le fd, on lui fait quoi ensuite ?).
Pour l'instant je fais le truc pas propre : désormais j'échantillonne /
dev/shm. Je garde le truc plus ardu à faire (lire le source) sous le
coude.
Le problème, c'est que le jour où tu ça te pète à la figure, tu dois : 1- comprendre que le problème vient de ce que tu fais depuis un certain temps, 2- chercher à savoir comment tu vas t'y prendre désormais, 3- retrouver tous les endroits où tu avais fait ça parce que tu trouvais ça cool pour appliquer ta nouvelle méthode.
Encore faut-il n'avoir qu'une casserole sur le feu... :-^
Ça peut ne jamais te claquer à la figure, mais si ça arrive, tu perds beaucoup de temps. Alors que d'appliquer directement la bonne méthode t'évide le temps perdu aux étapes 1 et 3 (sans compter les désagréments).
Je suis d'accord avec tout ce que tu viens de dire. En pratique, je pense même qu'il faut plus de QI pour faire comme tu dis, que pour vivre en pariant que tel ou tel comportement imprudent va m'être bénéficiaire sans contrepartie à long terme.
Concernant /dev/shm : D'un côté, le fait que personne ne soutiene mes assertions devrait m'inciter à la prudence, au moins déclarative. D'un autre côté, je devrais creuser la question ; me contenter d'avoir trouvé juste « shm_open ("/shm-test" ... » dans les source de la libc, c'est un peu léger pour conclure (et le fd, on lui fait quoi ensuite ?).
Pour l'instant je fais le truc pas propre : désormais j'échantillonne / dev/shm. Je garde le truc plus ardu à faire (lire le source) sous le coude.
cela ressemble a un deamon qui s’efface du disque http://www.siteduzero.com/tutoriel-3-234522-faire-un-demon-sous-linux.html
Ce site porte bien son nom....
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
JKB
Le Wed, 30 Nov 2011 15:49:26 +0100, remy écrivait :
Le 25/11/2011 17:46, JKB a écrit :
Le 25 Nov 2011 15:52:50 GMT, Nicolas George<nicolas$ écrivait :
JKB , dans le message, a écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces arguments rebattus.
Et tu es toujours le même. C'est même pour cela que tu es régulièrement dans mon killfile parce que tu es l'exact reflet de Stéphane Tougard. Tu affirmes n'importe quoi sous prétexte que tu _sais_ (voire que tu as la science infuse). Surtout, tu es capable de t'accrocher contre vents et marées pour ne surtout pas te dédire. Ça fait trop mal à l'amour propre. C'en est presque amusant si ce n'était pas ridicule.
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine (sur une machine distante dont on supposera qu'elle n'est pas elle-même vérolée) et à partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule). Pour répondre à mes arguments, il ne suffit pas de dire qu'ils sont ridicules ou parfaitemente idiots. Il faut encore dire en quoi ils sont parfaitement cons.
moi moi je sais mr mr
cela ressemble a un deamon qui s’efface du disque http://www.siteduzero.com/tutoriel-3-234522-faire-un-demon-sous-linux.html
Et tu crois franchement que ça passe inaperçu ? Je t'aide, des trucs comme chkrootkit sont vraiment efficaces pour récupérer ce genre de choses, parce que ton daemon, il va bien devoir communiquer par une socket (locale ou réseau) et que chkrootkit ne va pas aimer du tout.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 30 Nov 2011 15:49:26 +0100,
remy <remy@fctpas.fr> écrivait :
Le 25/11/2011 17:46, JKB a écrit :
Le 25 Nov 2011 15:52:50 GMT,
Nicolas George<nicolas$george@salle-s.org> écrivait :
JKB , dans le message<slrnjcv271.g08.jkb@rayleigh.systella.fr>, a
écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne
pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les
mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces
arguments rebattus.
Et tu es toujours le même. C'est même pour cela que tu es
régulièrement dans mon killfile parce que tu es l'exact reflet de
Stéphane Tougard. Tu affirmes n'importe quoi sous prétexte que tu
_sais_ (voire que tu as la science infuse). Surtout, tu es capable
de t'accrocher contre vents et marées pour ne surtout pas te dédire.
Ça fait trop mal à l'amour propre. C'en est presque amusant si ce
n'était pas ridicule.
J'aimerais que tu expliques à l'auditoire ici présent comment une
attaque peut passer inaperçue à partir du moment où tu loggues en
lecture seule tout ce qui se passe sur ta machine (sur une machine
distante dont on supposera qu'elle n'est pas elle-même vérolée) et à
partir du moment où tu vérifie périodiquemenet les sommes de hashage
de tous tes fichiers (à partir d'une machine distante en lecture
seule). Pour répondre à mes arguments, il ne suffit pas de dire
qu'ils sont ridicules ou parfaitemente idiots. Il faut encore dire
en quoi ils sont parfaitement cons.
moi moi je sais mr mr
cela ressemble a un deamon qui s’efface du disque
http://www.siteduzero.com/tutoriel-3-234522-faire-un-demon-sous-linux.html
Et tu crois franchement que ça passe inaperçu ? Je t'aide, des trucs
comme chkrootkit sont vraiment efficaces pour récupérer ce genre de
choses, parce que ton daemon, il va bien devoir communiquer par une
socket (locale ou réseau) et que chkrootkit ne va pas aimer du tout.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Wed, 30 Nov 2011 15:49:26 +0100, remy écrivait :
Le 25/11/2011 17:46, JKB a écrit :
Le 25 Nov 2011 15:52:50 GMT, Nicolas George<nicolas$ écrivait :
JKB , dans le message, a écrit :
Remarque j'ai mis 'je _sais_' à la place de 'je suis quasiment sûr',
Eh bien tu as eu tort. J'ai envie de dire que seul un guignol est sûr de ne pas avoir été piraté. D'ailleurs, il me semble t'avoir déjà vu tenir les mêmes propos.
uniquement pour toi, parce que tu allais relever ça sans lire le reste.
J'ai lu le reste, je t'ai déjà dit que je ne souhaitais pas répondre à ces arguments rebattus.
Et tu es toujours le même. C'est même pour cela que tu es régulièrement dans mon killfile parce que tu es l'exact reflet de Stéphane Tougard. Tu affirmes n'importe quoi sous prétexte que tu _sais_ (voire que tu as la science infuse). Surtout, tu es capable de t'accrocher contre vents et marées pour ne surtout pas te dédire. Ça fait trop mal à l'amour propre. C'en est presque amusant si ce n'était pas ridicule.
J'aimerais que tu expliques à l'auditoire ici présent comment une attaque peut passer inaperçue à partir du moment où tu loggues en lecture seule tout ce qui se passe sur ta machine (sur une machine distante dont on supposera qu'elle n'est pas elle-même vérolée) et à partir du moment où tu vérifie périodiquemenet les sommes de hashage de tous tes fichiers (à partir d'une machine distante en lecture seule). Pour répondre à mes arguments, il ne suffit pas de dire qu'ils sont ridicules ou parfaitemente idiots. Il faut encore dire en quoi ils sont parfaitement cons.
moi moi je sais mr mr
cela ressemble a un deamon qui s’efface du disque http://www.siteduzero.com/tutoriel-3-234522-faire-un-demon-sous-linux.html
Et tu crois franchement que ça passe inaperçu ? Je t'aide, des trucs comme chkrootkit sont vraiment efficaces pour récupérer ce genre de choses, parce que ton daemon, il va bien devoir communiquer par une socket (locale ou réseau) et que chkrootkit ne va pas aimer du tout.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
