Le Tue, 15 Mar 2005 12:28:34 +0000, Kevin Denis a écrit :tu ne pourras plus le faire tourner sur le port 80,
A ce propos; que penser d'une redirection de port?
apache ecoute sur le 8080 (donc en user de base). Une regle iptables (dans
le cas linux) qui redirige le 80 sur le 8080. Et hop, plus de root a
peu de frais.
C'est une bonne solution amha. Cela impose juste de maintenir un
système de NAT en plus et de complexifier un peu l'architecture globale.
Le Tue, 15 Mar 2005 12:28:34 +0000, Kevin Denis a écrit :
tu ne pourras plus le faire tourner sur le port 80,
A ce propos; que penser d'une redirection de port?
apache ecoute sur le 8080 (donc en user de base). Une regle iptables (dans
le cas linux) qui redirige le 80 sur le 8080. Et hop, plus de root a
peu de frais.
C'est une bonne solution amha. Cela impose juste de maintenir un
système de NAT en plus et de complexifier un peu l'architecture globale.
Le Tue, 15 Mar 2005 12:28:34 +0000, Kevin Denis a écrit :tu ne pourras plus le faire tourner sur le port 80,
A ce propos; que penser d'une redirection de port?
apache ecoute sur le 8080 (donc en user de base). Une regle iptables (dans
le cas linux) qui redirige le 80 sur le 8080. Et hop, plus de root a
peu de frais.
C'est une bonne solution amha. Cela impose juste de maintenir un
système de NAT en plus et de complexifier un peu l'architecture globale.
Kevin Denis writes:
Sur les systemes UNIX, il y a 2 facons de lacher ses privileges (en
schematisant un peu, hein): la temporaire et la definitive.
La temporaire permet a un programme qui n'a besoin d'un privilege que
pour certaines occasions bien precises de le lacher le reste du
temps. Si un attaquant prend la main, ca reste possible de recuperer
les privileges en question (le programme y arrive, apres tout), bien
que ca ne soit pas trivial du tout.
Dans le second cas, le privilege est definitivement droppe, donc c'est
impossible a recuperer (enfin, pas avec un set*uid*() ou un "truc
affilie", il reste toujours la possibilite de chercher une autre
faille a exploiter pour augmenter ses privileges, bien sur).
La question qui reste est donc "est-ce que Apache droppe
definitivement les droits root quand il passe en www-data", et ma
reponse est "que je soie pendu si j'en ai la moindre idee !!!"...
Mais la reponse doit bien se trouver, au pire dans le code source
d'Apache....
Kevin Denis <kevin@nowhere.invalid> writes:
Sur les systemes UNIX, il y a 2 facons de lacher ses privileges (en
schematisant un peu, hein): la temporaire et la definitive.
La temporaire permet a un programme qui n'a besoin d'un privilege que
pour certaines occasions bien precises de le lacher le reste du
temps. Si un attaquant prend la main, ca reste possible de recuperer
les privileges en question (le programme y arrive, apres tout), bien
que ca ne soit pas trivial du tout.
Dans le second cas, le privilege est definitivement droppe, donc c'est
impossible a recuperer (enfin, pas avec un set*uid*() ou un "truc
affilie", il reste toujours la possibilite de chercher une autre
faille a exploiter pour augmenter ses privileges, bien sur).
La question qui reste est donc "est-ce que Apache droppe
definitivement les droits root quand il passe en www-data", et ma
reponse est "que je soie pendu si j'en ai la moindre idee !!!"...
Mais la reponse doit bien se trouver, au pire dans le code source
d'Apache....
Kevin Denis writes:
Sur les systemes UNIX, il y a 2 facons de lacher ses privileges (en
schematisant un peu, hein): la temporaire et la definitive.
La temporaire permet a un programme qui n'a besoin d'un privilege que
pour certaines occasions bien precises de le lacher le reste du
temps. Si un attaquant prend la main, ca reste possible de recuperer
les privileges en question (le programme y arrive, apres tout), bien
que ca ne soit pas trivial du tout.
Dans le second cas, le privilege est definitivement droppe, donc c'est
impossible a recuperer (enfin, pas avec un set*uid*() ou un "truc
affilie", il reste toujours la possibilite de chercher une autre
faille a exploiter pour augmenter ses privileges, bien sur).
La question qui reste est donc "est-ce que Apache droppe
definitivement les droits root quand il passe en www-data", et ma
reponse est "que je soie pendu si j'en ai la moindre idee !!!"...
Mais la reponse doit bien se trouver, au pire dans le code source
d'Apache....
p.s.: je suis surpris que -en dépit d'un effort de portage vers Linux-
systrace n'ai pas rencontré plus de succès sur cette plateforme...
peut-être par a-t-il manqué de "publicité" ? une idée ?
p.s.: je suis surpris que -en dépit d'un effort de portage vers Linux-
systrace n'ai pas rencontré plus de succès sur cette plateforme...
peut-être par a-t-il manqué de "publicité" ? une idée ?
p.s.: je suis surpris que -en dépit d'un effort de portage vers Linux-
systrace n'ai pas rencontré plus de succès sur cette plateforme...
peut-être par a-t-il manqué de "publicité" ? une idée ?
Apache n'a besoin des droits de root que pour prendre le bind
sur le port 80 (et n'en a pas besoin par la suite, pour accepter les
sessions).
Apache n'a besoin des droits de root que pour prendre le bind
sur le port 80 (et n'en a pas besoin par la suite, pour accepter les
sessions).
Apache n'a besoin des droits de root que pour prendre le bind
sur le port 80 (et n'en a pas besoin par la suite, pour accepter les
sessions).
Dans fr.comp.securite, vous ecriviez:
comment savoir si il y a des trous de sécurité dans ma version
d'apache
svp ? (1.3.29)
Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
Dans fr.comp.securite, vous ecriviez:
comment savoir si il y a des trous de sécurité dans ma version
d'apache
svp ? (1.3.29)
Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
Dans fr.comp.securite, vous ecriviez:
comment savoir si il y a des trous de sécurité dans ma version
d'apache
svp ? (1.3.29)
Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
ah, bonne idée
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
(j'ai deja fait l'operation de ne garder que les modules qui m'etaient
utiles, et j'ai retiré perl et php)
mais de toutes facons je suis deja attaqué alors ...
Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
ah, bonne idée
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
(j'ai deja fait l'operation de ne garder que les modules qui m'etaient
utiles, et j'ai retiré perl et php)
mais de toutes facons je suis deja attaqué alors ...
Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
ah, bonne idée
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
(j'ai deja fait l'operation de ne garder que les modules qui m'etaient
utiles, et j'ai retiré perl et php)
mais de toutes facons je suis deja attaqué alors ...
In article
,
Thomas wrote:Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
je rajouterais que les grosses failles à la mode sont des problèmes
d'implémentation dans des pages web actives (php, jsp, asp, ...), il ne
faut pas se focaliser sur le serveur. Ce qu'on met dedans est très
important aussi et peut mener à de grave problèmes.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
ah, bonne idée
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
tu ne risques rien, ta config par défaut est déjà correcte normalement.
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
avec les listes
de correctifs de sécurité du vendeur de ton système.
Tu verras notamment
que les références CAN-xxxx-yyyy et CVE-zzzz-wwww devrait s'y trouver,
t'indiquant par là même que les vulnérabilités sont corrigées pour ta
version d'apache sur ton OS.
mais de toutes facons je suis deja attaqué alors ...
attaqué c'est sûrement un bien grand mot. D'autant plus que ta
plateforme de travail à de quoi déconcerter le script kiddy.
Comme indiqué ailleurs, tu peux te pencher sur chroot, si tu évacues les
modules php et perl ce devrait être assez facile à mettre en oeuvre.
In article
<fantome.forums.tDeContes-BC6EAC.15132823032005@news16-e.proxad.net>,
Thomas <fantome.forums.tDeContes@free.fr> wrote:
Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
je rajouterais que les grosses failles à la mode sont des problèmes
d'implémentation dans des pages web actives (php, jsp, asp, ...), il ne
faut pas se focaliser sur le serveur. Ce qu'on met dedans est très
important aussi et peut mener à de grave problèmes.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
ah, bonne idée
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
tu ne risques rien, ta config par défaut est déjà correcte normalement.
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
avec les listes
de correctifs de sécurité du vendeur de ton système.
Tu verras notamment
que les références CAN-xxxx-yyyy et CVE-zzzz-wwww devrait s'y trouver,
t'indiquant par là même que les vulnérabilités sont corrigées pour ta
version d'apache sur ton OS.
mais de toutes facons je suis deja attaqué alors ...
attaqué c'est sûrement un bien grand mot. D'autant plus que ta
plateforme de travail à de quoi déconcerter le script kiddy.
Comme indiqué ailleurs, tu peux te pencher sur chroot, si tu évacues les
modules php et perl ce devrait être assez facile à mettre en oeuvre.
In article
,
Thomas wrote:Il ne suffit pas de s'interesser aux bugs connus d'apache, mais aussi
aux bugs connus des modules d'apache utilisés dans votre installation.
Et des éventuelles blibliothèques utilisées par apache et/ou par ses
modules.
je rajouterais que les grosses failles à la mode sont des problèmes
d'implémentation dans des pages web actives (php, jsp, asp, ...), il ne
faut pas se focaliser sur le serveur. Ce qu'on met dedans est très
important aussi et peut mener à de grave problèmes.
Si vous utilisez mod_perl ou mod_php par exemple, ça fait beaucoup de
choses.
ah, bonne idée
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
tu ne risques rien, ta config par défaut est déjà correcte normalement.
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
avec les listes
de correctifs de sécurité du vendeur de ton système.
Tu verras notamment
que les références CAN-xxxx-yyyy et CVE-zzzz-wwww devrait s'y trouver,
t'indiquant par là même que les vulnérabilités sont corrigées pour ta
version d'apache sur ton OS.
mais de toutes facons je suis deja attaqué alors ...
attaqué c'est sûrement un bien grand mot. D'autant plus que ta
plateforme de travail à de quoi déconcerter le script kiddy.
Comme indiqué ailleurs, tu peux te pencher sur chroot, si tu évacues les
modules php et perl ce devrait être assez facile à mettre en oeuvre.
j'ai que des pages statiques
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
tu ne risques rien, ta config par défaut est déjà correcte normalement.
(au fait, si on commente un module, il est completement sorti d'apache ?
ca devient totalement impossible d'exploiter ses failles ?)
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
j'ai sous les yeux :-)avec les listes
de correctifs de sécurité du vendeur de ton système.
c'est où ? (puisque tu connais mon systeme, c'est mac os x 10.2.8 :-)
ah ? parce que moi j'ai tjr apache 1.3.29 !
au fait, sous mac os x 10.3, quelle est la derniere version d'apache ?
mais moi ce que j'ai vu, c'est que regulierement,
je pars et quand je reviens, mon ordi a planté (l'ecran reste noir, mais
en bougeant la souris elle deviens plus lumineuse),
et en meme temps, il y a des choses bizarres dans mes fichiers log !
alors si y a des choses dans les logs, c'est bien que c'est une attaque,
pas un plantage classique, non ?
en plus, le pirate peut choisir de ne pas faire de changements et faire
que de la lecture, auquel cas on ne voit meme pas qu'il y a eu une
attaque, non ?
j'ai que des pages statiques
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
tu ne risques rien, ta config par défaut est déjà correcte normalement.
(au fait, si on commente un module, il est completement sorti d'apache ?
ca devient totalement impossible d'exploiter ses failles ?)
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
j'ai sous les yeux :-)
avec les listes
de correctifs de sécurité du vendeur de ton système.
c'est où ? (puisque tu connais mon systeme, c'est mac os x 10.2.8 :-)
ah ? parce que moi j'ai tjr apache 1.3.29 !
au fait, sous mac os x 10.3, quelle est la derniere version d'apache ?
mais moi ce que j'ai vu, c'est que regulierement,
je pars et quand je reviens, mon ordi a planté (l'ecran reste noir, mais
en bougeant la souris elle deviens plus lumineuse),
et en meme temps, il y a des choses bizarres dans mes fichiers log !
alors si y a des choses dans les logs, c'est bien que c'est une attaque,
pas un plantage classique, non ?
en plus, le pirate peut choisir de ne pas faire de changements et faire
que de la lecture, auquel cas on ne voit meme pas qu'il y a eu une
attaque, non ?
j'ai que des pages statiques
je risque pas trop gros en indiquant ma liste de modules pour que vous
puissiez me diriger ?
tu ne risques rien, ta config par défaut est déjà correcte normalement.
(au fait, si on commente un module, il est completement sorti d'apache ?
ca devient totalement impossible d'exploiter ses failles ?)
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
j'ai sous les yeux :-)avec les listes
de correctifs de sécurité du vendeur de ton système.
c'est où ? (puisque tu connais mon systeme, c'est mac os x 10.2.8 :-)
ah ? parce que moi j'ai tjr apache 1.3.29 !
au fait, sous mac os x 10.3, quelle est la derniere version d'apache ?
mais moi ce que j'ai vu, c'est que regulierement,
je pars et quand je reviens, mon ordi a planté (l'ecran reste noir, mais
en bougeant la souris elle deviens plus lumineuse),
et en meme temps, il y a des choses bizarres dans mes fichiers log !
alors si y a des choses dans les logs, c'est bien que c'est une attaque,
pas un plantage classique, non ?
en plus, le pirate peut choisir de ne pas faire de changements et faire
que de la lecture, auquel cas on ne voit meme pas qu'il y a eu une
attaque, non ?
apache (dans la configuration courante) conserve un
processus père en root qui forke des processus fils ayant
(definitivement) une (e)uid non privilégiée, et assurant le traitement
de la requète.
Il n'est pas pour autant totalement exclus qu'un bug permette de tirer
parti des droits roots du processus père via le fils, car l'appel
système fork donne aux fils en héritage (pour ainsi dire) un certain
nombre de ressources "ouvertes" par le père (descripteurs de fichiers,
shm etc.).
apache (dans la configuration courante) conserve un
processus père en root qui forke des processus fils ayant
(definitivement) une (e)uid non privilégiée, et assurant le traitement
de la requète.
Il n'est pas pour autant totalement exclus qu'un bug permette de tirer
parti des droits roots du processus père via le fils, car l'appel
système fork donne aux fils en héritage (pour ainsi dire) un certain
nombre de ressources "ouvertes" par le père (descripteurs de fichiers,
shm etc.).
apache (dans la configuration courante) conserve un
processus père en root qui forke des processus fils ayant
(definitivement) une (e)uid non privilégiée, et assurant le traitement
de la requète.
Il n'est pas pour autant totalement exclus qu'un bug permette de tirer
parti des droits roots du processus père via le fils, car l'appel
système fork donne aux fils en héritage (pour ainsi dire) un certain
nombre de ressources "ouvertes" par le père (descripteurs de fichiers,
shm etc.).
In article
,
Thomas wrote:j'ai que des pages statiques
bon, ben t'es plutot tranquille de ce côté(au fait, si on commente un module, il est completement sorti d'apache ?
ca devient totalement impossible d'exploiter ses failles ?)
complètement, il n'est pas chargé en mémoire, il peut même ne pas
exister sur le disque.
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
j'ai sous les yeux :-)avec les listes
de correctifs de sécurité du vendeur de ton système.
c'est où ? (puisque tu connais mon systeme, c'est mac os x 10.2.8 :-)
point de départ : http://docs.info.apple.com/article.html?artnuma798
tu pourras t'inscrire à la ML de sécurité d'apple, qui envoie un mail
relativement détaillé (trop peu diront certains ici) a chaque mise à
jour de sécu.
10.2.8, hmmm tu dois être en retard de quelques patch de sécu je pense :/
C'est pas top.
ah ? parce que moi j'ai tjr apache 1.3.29 !
au fait, sous mac os x 10.3, quelle est la derniere version d'apache ?
$ httpd -V
Server version: Apache/1.3.33 (Darwin)
Server built: Nov 29 2004 17:59:31
mais moi ce que j'ai vu, c'est que regulierement,
je pars et quand je reviens, mon ordi a planté (l'ecran reste noir, mais
en bougeant la souris elle deviens plus lumineuse),
et en meme temps, il y a des choses bizarres dans mes fichiers log !
c'est peut être un problème de mise en veille,
un problème matériel, ...
et des choses bizarres dans les logs, c'est flou. As tu des exemples ?
Se passe t'il la meme chose si tu coupes apache ?
alors si y a des choses dans les logs, c'est bien que c'est une attaque,
pas un plantage classique, non ?
non, pas forcément.
en plus, le pirate peut choisir de ne pas faire de changements et faire
que de la lecture, auquel cas on ne voit meme pas qu'il y a eu une
attaque, non ?
pas forcément non plus :)
Balance des extraits de log ici, qu'on puisse te dire ce qu'il en
retourne.
In article
<fantome.forums.tDeContes-749613.18134423032005@news16-e.proxad.net>,
Thomas <fantome.forums.tDeContes@free.fr> wrote:
j'ai que des pages statiques
bon, ben t'es plutot tranquille de ce côté
(au fait, si on commente un module, il est completement sorti d'apache ?
ca devient totalement impossible d'exploiter ses failles ?)
complètement, il n'est pas chargé en mémoire, il peut même ne pas
exister sur le disque.
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
j'ai sous les yeux :-)
avec les listes
de correctifs de sécurité du vendeur de ton système.
c'est où ? (puisque tu connais mon systeme, c'est mac os x 10.2.8 :-)
point de départ : http://docs.info.apple.com/article.html?artnuma798
tu pourras t'inscrire à la ML de sécurité d'apple, qui envoie un mail
relativement détaillé (trop peu diront certains ici) a chaque mise à
jour de sécu.
10.2.8, hmmm tu dois être en retard de quelques patch de sécu je pense :/
C'est pas top.
ah ? parce que moi j'ai tjr apache 1.3.29 !
au fait, sous mac os x 10.3, quelle est la derniere version d'apache ?
$ httpd -V
Server version: Apache/1.3.33 (Darwin)
Server built: Nov 29 2004 17:59:31
mais moi ce que j'ai vu, c'est que regulierement,
je pars et quand je reviens, mon ordi a planté (l'ecran reste noir, mais
en bougeant la souris elle deviens plus lumineuse),
et en meme temps, il y a des choses bizarres dans mes fichiers log !
c'est peut être un problème de mise en veille,
un problème matériel, ...
et des choses bizarres dans les logs, c'est flou. As tu des exemples ?
Se passe t'il la meme chose si tu coupes apache ?
alors si y a des choses dans les logs, c'est bien que c'est une attaque,
pas un plantage classique, non ?
non, pas forcément.
en plus, le pirate peut choisir de ne pas faire de changements et faire
que de la lecture, auquel cas on ne voit meme pas qu'il y a eu une
attaque, non ?
pas forcément non plus :)
Balance des extraits de log ici, qu'on puisse te dire ce qu'il en
retourne.
In article
,
Thomas wrote:j'ai que des pages statiques
bon, ben t'es plutot tranquille de ce côté(au fait, si on commente un module, il est completement sorti d'apache ?
ca devient totalement impossible d'exploiter ses failles ?)
complètement, il n'est pas chargé en mémoire, il peut même ne pas
exister sur le disque.
Je t'encourage à mettre en regard les listes de vulnérabilités (et de
correctifs) du site Apache dont on t'a fourni l'URL ici,
j'ai sous les yeux :-)avec les listes
de correctifs de sécurité du vendeur de ton système.
c'est où ? (puisque tu connais mon systeme, c'est mac os x 10.2.8 :-)
point de départ : http://docs.info.apple.com/article.html?artnuma798
tu pourras t'inscrire à la ML de sécurité d'apple, qui envoie un mail
relativement détaillé (trop peu diront certains ici) a chaque mise à
jour de sécu.
10.2.8, hmmm tu dois être en retard de quelques patch de sécu je pense :/
C'est pas top.
ah ? parce que moi j'ai tjr apache 1.3.29 !
au fait, sous mac os x 10.3, quelle est la derniere version d'apache ?
$ httpd -V
Server version: Apache/1.3.33 (Darwin)
Server built: Nov 29 2004 17:59:31
mais moi ce que j'ai vu, c'est que regulierement,
je pars et quand je reviens, mon ordi a planté (l'ecran reste noir, mais
en bougeant la souris elle deviens plus lumineuse),
et en meme temps, il y a des choses bizarres dans mes fichiers log !
c'est peut être un problème de mise en veille,
un problème matériel, ...
et des choses bizarres dans les logs, c'est flou. As tu des exemples ?
Se passe t'il la meme chose si tu coupes apache ?
alors si y a des choses dans les logs, c'est bien que c'est une attaque,
pas un plantage classique, non ?
non, pas forcément.
en plus, le pirate peut choisir de ne pas faire de changements et faire
que de la lecture, auquel cas on ne voit meme pas qu'il y a eu une
attaque, non ?
pas forcément non plus :)
Balance des extraits de log ici, qu'on puisse te dire ce qu'il en
retourne.
