Le vendredi 18 novembre 2005, Yves Rutschle a écrit...
Ne fallait-il pas aussi deux ports ouverts vers 7000? Rien que ça devrait mettre à l'abri n'importe quelle installation vaguement sérieuse...
Et pouvoir exploiter les 3 failles de sécurité, dont xml-rpc fait partie (mais les deux autres peuvent être liées à xml-rpc, je n'en sais rien)
-- jm
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson
Glennie Vignarajah a écrit:
Le Friday 18 November 2005 07:38, François Boisson(François Boisson ) disait:
Par recherche de processus cachés, j'entends rechercher les processus existant mais n'apparaissant pas via ps. Comme ils existent, je me suis aperçu qu'on pouvait quand même aller dans le repertoire sous /proc correspondant même si ce repertoire n'apparait pas.
C'est possible ça? Je croyais que pour cacher un process sous linux, il fallait un ps patché... Et chkrootkit fonctionne de cette manière : il fait des ps et compare les entrées dans /proc...
J'ai eu une machine compromise, checkrootkit n'a rien vu, c'est pour ça que j'ai essayé de comprendre. Le ps n'était absolument pas patché, le repertoire n'apparaissait pas via un ls sous /proc mais un cd PID fonctionnait....
François Boisson (ps: va sur mon site, tu verras le script bash qui fait cela, puis tu peux regarder le source (en Caml :) ) du programme correspondant (plus rapide...)
A+
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Glennie Vignarajah a écrit:
Le Friday 18 November 2005 07:38, François Boisson(François Boisson
<user.anti-spam@maison.homelinux.net>) disait:
Par recherche de processus cachés, j'entends rechercher les
processus existant mais n'apparaissant pas via ps. Comme ils
existent, je me suis aperçu qu'on pouvait quand même aller dans le
repertoire sous /proc correspondant même si ce repertoire
n'apparait pas.
C'est possible ça?
Je croyais que pour cacher un process sous linux, il fallait un ps
patché...
Et chkrootkit fonctionne de cette manière : il fait des ps et compare
les entrées dans /proc...
J'ai eu une machine compromise, checkrootkit n'a rien vu, c'est pour ça
que j'ai essayé de comprendre. Le ps n'était absolument pas patché, le
repertoire n'apparaissait pas via un ls sous /proc mais un cd PID
fonctionnait....
François Boisson
(ps: va sur mon site, tu verras le script bash qui fait cela, puis tu
peux regarder le source (en Caml :) ) du programme correspondant (plus
rapide...)
A+
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le Friday 18 November 2005 07:38, François Boisson(François Boisson ) disait:
Par recherche de processus cachés, j'entends rechercher les processus existant mais n'apparaissant pas via ps. Comme ils existent, je me suis aperçu qu'on pouvait quand même aller dans le repertoire sous /proc correspondant même si ce repertoire n'apparait pas.
C'est possible ça? Je croyais que pour cacher un process sous linux, il fallait un ps patché... Et chkrootkit fonctionne de cette manière : il fait des ps et compare les entrées dans /proc...
J'ai eu une machine compromise, checkrootkit n'a rien vu, c'est pour ça que j'ai essayé de comprendre. Le ps n'était absolument pas patché, le repertoire n'apparaissait pas via un ls sous /proc mais un cd PID fonctionnait....
François Boisson (ps: va sur mon site, tu verras le script bash qui fait cela, puis tu peux regarder le source (en Caml :) ) du programme correspondant (plus rapide...)
A+
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le 18.11.2005 09:25:40, Jean-Michel OLTRA a écrit :
bonjour,
Le vendredi 18 novembre 2005, Yves Rutschle a écrit...
> Ne fallait-il pas aussi deux ports ouverts vers 7000? Rien > que ça devrait mettre à l'abri n'importe quelle installation > vaguement sérieuse...
Et pouvoir exploiter les 3 failles de sécurité, dont xml-rpc fait partie (mais les deux autres peuvent être liées à xml-rpc, je n'en sais rien)
Mais des failles de sécurité, il y en a tous les jours, et des exploits pour ces failles se trouvent assez facilement. N'est qu'à voir le nombre de correctifs de sécurité qu'on peut voir diffuser. Tout ceci est public il me semble dans le mode Debian. Il est sans doute plus efficace et plus sûr de corriger les failles de sécurité au niveau des logiciels eux-même, à la source, plutôt qu e de mettre en oeuvre une architecture lourde pour prévenir d'un worm qui peu exploiter la faille en question. Les intérêts financiers ne sont sans doute pas les mêmes et les responsables informatiques ne jurent aujourd'hui que par les anti-spams, les anti-virus et les firewall. Si leur vie ne dépendant que de ces trois facteurs, il y aurait sans doute des promotions.
Le 18.11.2005 09:25:40, Jean-Michel OLTRA a écrit :
bonjour,
Le vendredi 18 novembre 2005, Yves Rutschle a écrit...
> Ne fallait-il pas aussi deux ports ouverts vers 7000? Rien
> que ça devrait mettre à l'abri n'importe quelle installation
> vaguement sérieuse...
Et pouvoir exploiter les 3 failles de sécurité, dont xml-rpc fait
partie (mais les deux autres peuvent être liées à xml-rpc, je n'en
sais
rien)
Mais des failles de sécurité, il y en a tous les jours, et des exploits
pour ces failles se trouvent assez facilement. N'est qu'à voir le
nombre de correctifs de sécurité qu'on peut voir diffuser.
Tout ceci est public il me semble dans le mode Debian.
Il est sans doute plus efficace et plus sûr de corriger les failles de
sécurité au niveau des logiciels eux-même, à la source, plutôt qu e de
mettre en oeuvre une architecture lourde pour prévenir d'un worm qui
peu exploiter la faille en question. Les intérêts financiers ne sont
sans doute pas les mêmes et les responsables informatiques ne jurent
aujourd'hui que par les anti-spams, les anti-virus et les firewall. Si
leur vie ne dépendant que de ces trois facteurs, il y aurait sans doute
des promotions.
Le 18.11.2005 09:25:40, Jean-Michel OLTRA a écrit :
bonjour,
Le vendredi 18 novembre 2005, Yves Rutschle a écrit...
> Ne fallait-il pas aussi deux ports ouverts vers 7000? Rien > que ça devrait mettre à l'abri n'importe quelle installation > vaguement sérieuse...
Et pouvoir exploiter les 3 failles de sécurité, dont xml-rpc fait partie (mais les deux autres peuvent être liées à xml-rpc, je n'en sais rien)
Mais des failles de sécurité, il y en a tous les jours, et des exploits pour ces failles se trouvent assez facilement. N'est qu'à voir le nombre de correctifs de sécurité qu'on peut voir diffuser. Tout ceci est public il me semble dans le mode Debian. Il est sans doute plus efficace et plus sûr de corriger les failles de sécurité au niveau des logiciels eux-même, à la source, plutôt qu e de mettre en oeuvre une architecture lourde pour prévenir d'un worm qui peu exploiter la faille en question. Les intérêts financiers ne sont sans doute pas les mêmes et les responsables informatiques ne jurent aujourd'hui que par les anti-spams, les anti-virus et les firewall. Si leur vie ne dépendant que de ces trois facteurs, il y aurait sans doute des promotions.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
François Boisson
Yves Rutschle a écrit:
On Fri, Nov 18, 2005 at 07:38:18AM +0100, François Boisson wrote:
En ce qui concerne le controle d'intégrité, l'amusant a été de constater que les changements de bits de 1 à 0 arrivent de temps à autre et qu'un binaire avec un bit modifié continue de marcher la plupart du temps.
J'ai eu un disque qui perdait un bit, malheureusement dans un inode: libreadline se transformait en libreadlIne, ce qui mine de rien empêche le boot. Allons bon.
Par rapport à l'intégrité des fichiers, pourquoi n'as-tu pas utilisé AIDE? Il semble faire tout ce que ton script fait.
Je voulais un truc
1) petit et autonome (qui puisse être mis sur un couple de disquettes bootables) donc en statique compilé par diet gcc
2) que je comprenne
3) dont le binaire et les données puissent être mis sur un CDrom appelable directemenbt ou par cron. Pour cette raison, j'ai intégré le le md5sums (patchable sinon), etc. Bref, à part modifier le CDrom, on ne peut rien faire contre ce pgm.
François Boisson
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Yves Rutschle a écrit:
On Fri, Nov 18, 2005 at 07:38:18AM +0100, François Boisson wrote:
En ce qui concerne le controle d'intégrité, l'amusant a été de
constater que les changements de bits de 1 à 0 arrivent de temps à
autre et qu'un binaire avec un bit modifié continue de marcher la
plupart du temps.
J'ai eu un disque qui perdait un bit, malheureusement dans
un inode: libreadline se transformait en libreadlIne, ce qui
mine de rien empêche le boot. Allons bon.
Par rapport à l'intégrité des fichiers, pourquoi n'as-tu pas
utilisé AIDE? Il semble faire tout ce que ton script fait.
Je voulais un truc
1) petit et autonome (qui puisse être mis sur un couple de disquettes
bootables) donc en statique compilé par diet gcc
2) que je comprenne
3) dont le binaire et les données puissent être mis sur un CDrom
appelable directemenbt ou par cron. Pour cette raison, j'ai intégré le
le md5sums (patchable sinon), etc. Bref, à part modifier le CDrom, on ne
peut rien faire contre ce pgm.
François Boisson
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Fri, Nov 18, 2005 at 07:38:18AM +0100, François Boisson wrote:
En ce qui concerne le controle d'intégrité, l'amusant a été de constater que les changements de bits de 1 à 0 arrivent de temps à autre et qu'un binaire avec un bit modifié continue de marcher la plupart du temps.
J'ai eu un disque qui perdait un bit, malheureusement dans un inode: libreadline se transformait en libreadlIne, ce qui mine de rien empêche le boot. Allons bon.
Par rapport à l'intégrité des fichiers, pourquoi n'as-tu pas utilisé AIDE? Il semble faire tout ce que ton script fait.
Je voulais un truc
1) petit et autonome (qui puisse être mis sur un couple de disquettes bootables) donc en statique compilé par diet gcc
2) que je comprenne
3) dont le binaire et les données puissent être mis sur un CDrom appelable directemenbt ou par cron. Pour cette raison, j'ai intégré le le md5sums (patchable sinon), etc. Bref, à part modifier le CDrom, on ne peut rien faire contre ce pgm.
François Boisson
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
