Désolé de crossposter, mais je ne parviens pas à choisir le groupe le plus
approprié, merci de placer le suivi dans le bon groupe.
Je compte réinstaller le serveur web du boulot début Juillet afin de patcher
toutes les applications et l'OS en un coup et en profiter pour remettre au
propre mes procédures.
PME de 5 personnes; 2 site web sous apache-2.0.53_1 + squid-2.5.9_3 (2
failles) derrière un pare-feu géré par notre FAI, 4 bases
postgresql-server-7.4.7_2, isc-dhcp3-server-3.0.1.r14_6, pas de serveur
mail, sauvegarde sur DVD-RW tout les 2 jours. L'OS a été mis à jour le 21
avril par un buildworld, mais de nouvelles failles sont apparues depuis.
Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de
tous les exécutables du système (nom de fichier / hash MD5) et la graver
sur CD afin de vérifier toute les nuits (au pire à intervalle régulier en
fonction du temps nécessaire) qu'il n'y a aucune altération
(rootkit/corruption d'origine suspecte).
Bien que ce soit facile à mettre en place (et détectable) via un crontab, je
me demande si c'est une mesure d' _alerte_ suffisante et si il n'y a pas
quelque chose de plus simple/sur.
L'idée de base est d'être prévenu par mail le plus rapidement possible de
toute modification, quitte à mettre le serveur hors ligne avant qu'il n'ait
pu faire trop de dégâts.
Pour l'instant, cette machine tourne en mode "parano" (kern.securelevel=5),
system accouting activé, j'essaie d'inspecter les logs tout les 2 à 4
jours, mais je ne me sens pas assez à l'aise.
Si quelqu'un peut me donner des informations pour blinder le système...
J'en suis au point de vouloir booter la machine sur un cd live avec
uniquement les données sur le disque dur; quitte à sacrifier qq Mb de
RAM... Bonne idée, perte de temps ou pur délire?
Vos idées, avis, expériences et commentaires sont les bienvenus..
On Fri, 24 Jun 2005 12:26:13 +0000, VANHULLEBUS Yvan wrote:
Par contre, on ne sait faire ca que si le premier executable est construit d'une facon bien particuliere, actuellement, ce qui rend le truc inexploitable "dans la vraie vie du monde du dehors".
La "vraie vie du monde du dehors" a morflé récemment : http://www.cits.rub.de/MD5Collisions/
Nicob
On Fri, 24 Jun 2005 12:26:13 +0000, VANHULLEBUS Yvan wrote:
Par contre, on ne sait faire ca que si le premier executable est
construit d'une facon bien particuliere, actuellement, ce qui rend le
truc inexploitable "dans la vraie vie du monde du dehors".
La "vraie vie du monde du dehors" a morflé récemment :
http://www.cits.rub.de/MD5Collisions/
On Fri, 24 Jun 2005 12:26:13 +0000, VANHULLEBUS Yvan wrote:
Par contre, on ne sait faire ca que si le premier executable est construit d'une facon bien particuliere, actuellement, ce qui rend le truc inexploitable "dans la vraie vie du monde du dehors".
La "vraie vie du monde du dehors" a morflé récemment : http://www.cits.rub.de/MD5Collisions/
Nicob
Rakotomandimby (R12y) Mihamina
MaXX :
Je suis fier (mais limite enragé) d'être le seul de la boite à me préoccuper de la sécurité et je veux remettre le tout à plat pour repartir sur de meilleures bases.
Est-ce que quelqu'un connait comment contacter les DRH des "boites à zéro sécurité" comme ça, pour qu'"on" puisse gagner son pain?
Bah oui, si je leur explique ce que je peux apporter en sécurité à leur réseau, j'ai une chance... et comme tout nombre positif est supérieur à zéro et que leur sécurité est à zéro, je peux forcément trouver un truc à leur proposer...
-- Miroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
MaXX <bs139412@skynet.be> :
Je suis fier (mais limite enragé)
d'être le seul de la boite à me préoccuper de la sécurité et je veux
remettre le tout à plat pour repartir sur de meilleures bases.
Est-ce que quelqu'un connait comment contacter les DRH des "boites à
zéro sécurité" comme ça, pour qu'"on" puisse gagner son pain?
Bah oui, si je leur explique ce que je peux apporter en sécurité à leur
réseau, j'ai une chance... et comme tout nombre positif est supérieur à
zéro et que leur sécurité est à zéro, je peux forcément trouver un
truc à leur proposer...
--
Miroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Je suis fier (mais limite enragé) d'être le seul de la boite à me préoccuper de la sécurité et je veux remettre le tout à plat pour repartir sur de meilleures bases.
Est-ce que quelqu'un connait comment contacter les DRH des "boites à zéro sécurité" comme ça, pour qu'"on" puisse gagner son pain?
Bah oui, si je leur explique ce que je peux apporter en sécurité à leur réseau, j'ai une chance... et comme tout nombre positif est supérieur à zéro et que leur sécurité est à zéro, je peux forcément trouver un truc à leur proposer...
-- Miroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
VANHULLEBUS Yvan
Nicob writes:
On Fri, 24 Jun 2005 12:26:13 +0000, VANHULLEBUS Yvan wrote:
Par contre, on ne sait faire ca que si le premier executable est construit d'une facon bien particuliere, actuellement, ce qui rend le truc inexploitable "dans la vraie vie du monde du dehors".
La "vraie vie du monde du dehors" a morflé récemment : http://www.cits.rub.de/MD5Collisions/
Oui et non: il faut encore que l'attaquant genere les 2 fichiers de facon bien specifique.
Pour de la verification d'executables dont la version initiale a ete posee par l'admin "normal", on ne peut donc (a ma connaissance) pas (encore ?) utiliser les faiblesses (connues) de MD5 pour poser un autre binaire qui va "faire la meme chose plus d'autres trucs sympas pour l'attaquant et qui a le meme hash MD5".
Mais effectivement, la "vraie vie du monde du dehors" a eu une grosse migraine, sur ce coup la......
A +
VANHU.
Nicob <nicob@I.hate.spammers.com> writes:
On Fri, 24 Jun 2005 12:26:13 +0000, VANHULLEBUS Yvan wrote:
Par contre, on ne sait faire ca que si le premier executable est
construit d'une facon bien particuliere, actuellement, ce qui rend le
truc inexploitable "dans la vraie vie du monde du dehors".
La "vraie vie du monde du dehors" a morflé récemment :
http://www.cits.rub.de/MD5Collisions/
Oui et non: il faut encore que l'attaquant genere les 2 fichiers de
facon bien specifique.
Pour de la verification d'executables dont la version initiale a ete
posee par l'admin "normal", on ne peut donc (a ma connaissance) pas
(encore ?) utiliser les faiblesses (connues) de MD5 pour poser un
autre binaire qui va "faire la meme chose plus d'autres trucs sympas
pour l'attaquant et qui a le meme hash MD5".
Mais effectivement, la "vraie vie du monde du dehors" a eu une grosse
migraine, sur ce coup la......
On Fri, 24 Jun 2005 12:26:13 +0000, VANHULLEBUS Yvan wrote:
Par contre, on ne sait faire ca que si le premier executable est construit d'une facon bien particuliere, actuellement, ce qui rend le truc inexploitable "dans la vraie vie du monde du dehors".
La "vraie vie du monde du dehors" a morflé récemment : http://www.cits.rub.de/MD5Collisions/
Oui et non: il faut encore que l'attaquant genere les 2 fichiers de facon bien specifique.
Pour de la verification d'executables dont la version initiale a ete posee par l'admin "normal", on ne peut donc (a ma connaissance) pas (encore ?) utiliser les faiblesses (connues) de MD5 pour poser un autre binaire qui va "faire la meme chose plus d'autres trucs sympas pour l'attaquant et qui a le meme hash MD5".
Mais effectivement, la "vraie vie du monde du dehors" a eu une grosse migraine, sur ce coup la......
A +
VANHU.
MaXX
Xavier wrote:
[ je reste sur fcs, où c'est en thème] MaXX wrote:
J'ai parlé avec le créateur de l'appli propriétaire de la boite et il n'a pas pu me dire pourquoi je savais lire les données en clair avec ethereal (requêtes SQL et autres sans compter sur le fait que cette base est stoquée sur un partion FAT, bonjour la sécurité) La BDD est stockée sur quel OS ? Windows ou Fribi ?
Du Windows pour celle là (Interbase)... J'aurais presque tendance à dire
malheusement. Je sais pas si Interbase supporte le SSH ou quoi que ce soit de plus sur que le texte clair, mais ça ne ferait pas de mal. Je lui parlerai de ça la prochaine fois.
J'ai trouvé pire encore, l'appli est authentifié par user/password mais pas la base... En tout cas je n'en ai pas trouvé de trace avec ethereal.
[...]
-- MaXX
CityParade Bof... mais bon me suis bien maré quand même...
Xavier wrote:
[ je reste sur fcs, où c'est en thème]
MaXX <bs139412@skynet.be> wrote:
J'ai parlé avec le créateur de l'appli propriétaire de la boite et il n'a
pas pu me dire pourquoi je savais lire les données en clair avec ethereal
(requêtes SQL et autres sans compter sur le fait que cette base est
stoquée sur un partion FAT, bonjour la sécurité)
La BDD est stockée sur quel OS ? Windows ou Fribi ?
Du Windows pour celle là (Interbase)... J'aurais presque tendance à dire
malheusement.
Je sais pas si Interbase supporte le SSH ou quoi que ce soit de plus sur que
le texte clair, mais ça ne ferait pas de mal. Je lui parlerai de ça la
prochaine fois.
J'ai trouvé pire encore, l'appli est authentifié par user/password mais pas
la base... En tout cas je n'en ai pas trouvé de trace avec ethereal.
[...]
--
MaXX
CityParade Bof... mais bon me suis bien maré quand même...
[ je reste sur fcs, où c'est en thème] MaXX wrote:
J'ai parlé avec le créateur de l'appli propriétaire de la boite et il n'a pas pu me dire pourquoi je savais lire les données en clair avec ethereal (requêtes SQL et autres sans compter sur le fait que cette base est stoquée sur un partion FAT, bonjour la sécurité) La BDD est stockée sur quel OS ? Windows ou Fribi ?
Du Windows pour celle là (Interbase)... J'aurais presque tendance à dire
malheusement. Je sais pas si Interbase supporte le SSH ou quoi que ce soit de plus sur que le texte clair, mais ça ne ferait pas de mal. Je lui parlerai de ça la prochaine fois.
J'ai trouvé pire encore, l'appli est authentifié par user/password mais pas la base... En tout cas je n'en ai pas trouvé de trace avec ethereal.
[...]
-- MaXX
CityParade Bof... mais bon me suis bien maré quand même...
GERBIER Eric
Marc Espie wrote:
sinon, tripwire, aide...
<pub>
afick (http://afick.sourceforge.net/index.fr.html) : c'est du perl donc entierement portable
</pub>
Marc Espie wrote:
sinon, tripwire, aide...
<pub>
afick (http://afick.sourceforge.net/index.fr.html) : c'est du perl donc
entierement portable
afick (http://afick.sourceforge.net/index.fr.html) : c'est du perl donc entierement portable
</pub>
ggregl
Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de tous les exécutables du système (nom de fichier / hash MD5) et la graver sur CD afin de vérifier toute les nuits (au pire à intervalle régulier en fonction du temps nécessaire) qu'il n'y a aucune altération (rootkit/corruption d'origine suspecte).
samhain (déjà cité) fait ça très bien avec la possibilité de faire des signatures gpg (tu trouveras un petit comparatif pas super à jour la : http://www.la-samhna.de/library/scanners.html ). Il faut garder à l'esprit que les signatures sont réalisées en userland ce qui implique que les rootkit modernes passent facilement à travers. C'est pourquoi samhain propose également un module kernel (pour linux par contre) dont je n'ai pas testé l'efficacité. Dans la mesure du possible pour les signatures préfère du SHA1 ou mieux du SHA256 à la place de md5 qui n'est plus à considérer comme un hash sûr.
Pour l'instant, cette machine tourne en mode "parano" (kern.securelevel=5), system accouting activé, j'essaie d'inspecter les logs tout les 2 à 4 jours, mais je ne me sens pas assez à l'aise.
A quoi correspond "kern.securelevel=5" niveau protections (désolé je suis pas super au fait concernant freebsd) ? Est-ce que ça implique des protections contre les corruptions mémoire (type PaX ou W^X) ?
Tu peux déjà recompiler les applications importantes avec SSP de GCC (option -fstack-protector) pour prévenir pas mal de buffer overflow courants.
Il vaut mieux prévenir que guérir ;).
L'idéal est de pousser la prévention jusqu'aù kernel.
J'en suis au point de vouloir booter la machine sur un cd live avec uniquement les données sur le disque dur; quitte à sacrifier qq Mb de RAM... Bonne idée, perte de temps ou pur délire?
Ca n'empêchera pas l'exploitation d'un service vulnérable ou d'une faille applicative. Tu n'as pas besoin d'écrire dans le fs pour exécuter des commandes après avoir injecté du code ou bien accéder à des données (via des failles applicatives type sql injection).
Je ne pense pas qu'un livecd soit une mesure utile et viable (trop chiant pour les mises à jour). Par contre les partitions et fichiers qui n'ont pas besoin d'être accessibles en écriture ne doivent l'être qu'en lecture bien sûr. Suivre le principe du moindre privilège est un bon point de départ.
Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de
tous les exécutables du système (nom de fichier / hash MD5) et la graver
sur CD afin de vérifier toute les nuits (au pire à intervalle régulier en
fonction du temps nécessaire) qu'il n'y a aucune altération
(rootkit/corruption d'origine suspecte).
samhain (déjà cité) fait ça très bien avec la possibilité de
faire des signatures gpg (tu trouveras un petit comparatif pas super à
jour la : http://www.la-samhna.de/library/scanners.html ). Il faut
garder à l'esprit que les signatures sont réalisées en userland ce
qui implique que les rootkit modernes passent facilement à travers.
C'est pourquoi samhain propose également un module kernel (pour linux
par contre) dont je n'ai pas testé l'efficacité. Dans la mesure du
possible pour les signatures préfère du SHA1 ou mieux du SHA256 à la
place de md5 qui n'est plus à considérer comme un hash sûr.
Pour l'instant, cette machine tourne en mode "parano" (kern.securelevel=5),
system accouting activé, j'essaie d'inspecter les logs tout les 2 à 4
jours, mais je ne me sens pas assez à l'aise.
A quoi correspond "kern.securelevel=5" niveau protections (désolé je
suis pas super au fait concernant freebsd) ? Est-ce que ça implique
des protections contre les corruptions mémoire (type PaX ou W^X) ?
Tu peux déjà recompiler les applications importantes avec SSP de GCC
(option -fstack-protector) pour prévenir pas mal de buffer overflow
courants.
Il vaut mieux prévenir que guérir ;).
L'idéal est de pousser la prévention jusqu'aù kernel.
J'en suis au point de vouloir booter la machine sur un cd live avec
uniquement les données sur le disque dur; quitte à sacrifier qq Mb de
RAM... Bonne idée, perte de temps ou pur délire?
Ca n'empêchera pas l'exploitation d'un service vulnérable ou d'une
faille applicative. Tu n'as pas besoin d'écrire dans le fs pour
exécuter des commandes après avoir injecté du code ou bien accéder
à des données (via des failles applicatives type sql injection).
Je ne pense pas qu'un livecd soit une mesure utile et viable (trop
chiant pour les mises à jour). Par contre les partitions et fichiers
qui n'ont pas besoin d'être accessibles en écriture ne doivent
l'être qu'en lecture bien sûr. Suivre le principe du moindre
privilège est un bon point de départ.
Une fois que j'aurais tout terminé, j'aimerais faire "une sorte de photo" de tous les exécutables du système (nom de fichier / hash MD5) et la graver sur CD afin de vérifier toute les nuits (au pire à intervalle régulier en fonction du temps nécessaire) qu'il n'y a aucune altération (rootkit/corruption d'origine suspecte).
samhain (déjà cité) fait ça très bien avec la possibilité de faire des signatures gpg (tu trouveras un petit comparatif pas super à jour la : http://www.la-samhna.de/library/scanners.html ). Il faut garder à l'esprit que les signatures sont réalisées en userland ce qui implique que les rootkit modernes passent facilement à travers. C'est pourquoi samhain propose également un module kernel (pour linux par contre) dont je n'ai pas testé l'efficacité. Dans la mesure du possible pour les signatures préfère du SHA1 ou mieux du SHA256 à la place de md5 qui n'est plus à considérer comme un hash sûr.
Pour l'instant, cette machine tourne en mode "parano" (kern.securelevel=5), system accouting activé, j'essaie d'inspecter les logs tout les 2 à 4 jours, mais je ne me sens pas assez à l'aise.
A quoi correspond "kern.securelevel=5" niveau protections (désolé je suis pas super au fait concernant freebsd) ? Est-ce que ça implique des protections contre les corruptions mémoire (type PaX ou W^X) ?
Tu peux déjà recompiler les applications importantes avec SSP de GCC (option -fstack-protector) pour prévenir pas mal de buffer overflow courants.
Il vaut mieux prévenir que guérir ;).
L'idéal est de pousser la prévention jusqu'aù kernel.
J'en suis au point de vouloir booter la machine sur un cd live avec uniquement les données sur le disque dur; quitte à sacrifier qq Mb de RAM... Bonne idée, perte de temps ou pur délire?
Ca n'empêchera pas l'exploitation d'un service vulnérable ou d'une faille applicative. Tu n'as pas besoin d'écrire dans le fs pour exécuter des commandes après avoir injecté du code ou bien accéder à des données (via des failles applicatives type sql injection).
Je ne pense pas qu'un livecd soit une mesure utile et viable (trop chiant pour les mises à jour). Par contre les partitions et fichiers qui n'ont pas besoin d'être accessibles en écriture ne doivent l'être qu'en lecture bien sûr. Suivre le principe du moindre privilège est un bon point de départ.
MaXX
wrote:
A quoi correspond "kern.securelevel=5" niveau protections (désolé je suis pas super au fait concernant freebsd) ? Est-ce que ça implique des protections contre les corruptions mémoire (type PaX ou W^X) ?
la page de man de init donne ces infos... http://www.FreeBSD.org/cgi/man.cgi?query=init En très gros impossible de charger des modules kernels, règles de firewall gelées...
Tu peux déjà recompiler les applications importantes avec SSP de GCC (option -fstack-protector) pour prévenir pas mal de buffer overflow courants. Il vaut mieux prévenir que guérir ;). L'idéal est de pousser la prévention jusqu'aù kernel. Faut voir si la machine ne va pas devenir instable... J'ai abandonné l'idée
de changer les options de compilations pour le kernel... Pour les applis c'est au cas par cas...
Quel en serait le prix en terme de performances?
Je ne pense pas qu'un livecd soit une mesure utile et viable (trop chiant pour les mises à jour). Par contre les partitions et fichiers qui n'ont pas besoin d'être accessibles en écriture ne doivent l'être qu'en lecture bien sûr. Suivre le principe du moindre privilège est un bon point de départ.
J'ai upgradé mes applis et je suis en train de synthétiser ce qui à été proposé sur fcob et fcs pour arriver à une solution viable et sécurisée le + possible...
-- MaXX
ggregl@gmail.com wrote:
A quoi correspond "kern.securelevel=5" niveau protections (désolé je
suis pas super au fait concernant freebsd) ? Est-ce que ça implique
des protections contre les corruptions mémoire (type PaX ou W^X) ?
la page de man de init donne ces infos...
http://www.FreeBSD.org/cgi/man.cgi?query=init
En très gros impossible de charger des modules kernels, règles de firewall
gelées...
Tu peux déjà recompiler les applications importantes avec SSP de GCC
(option -fstack-protector) pour prévenir pas mal de buffer overflow
courants.
Il vaut mieux prévenir que guérir ;).
L'idéal est de pousser la prévention jusqu'aù kernel.
Faut voir si la machine ne va pas devenir instable... J'ai abandonné l'idée
de changer les options de compilations pour le kernel... Pour les applis
c'est au cas par cas...
Quel en serait le prix en terme de performances?
Je ne pense pas qu'un livecd soit une mesure utile et viable (trop
chiant pour les mises à jour). Par contre les partitions et fichiers
qui n'ont pas besoin d'être accessibles en écriture ne doivent
l'être qu'en lecture bien sûr. Suivre le principe du moindre
privilège est un bon point de départ.
J'ai upgradé mes applis et je suis en train de synthétiser ce qui à été
proposé sur fcob et fcs pour arriver à une solution viable et sécurisée le
+ possible...
A quoi correspond "kern.securelevel=5" niveau protections (désolé je suis pas super au fait concernant freebsd) ? Est-ce que ça implique des protections contre les corruptions mémoire (type PaX ou W^X) ?
la page de man de init donne ces infos... http://www.FreeBSD.org/cgi/man.cgi?query=init En très gros impossible de charger des modules kernels, règles de firewall gelées...
Tu peux déjà recompiler les applications importantes avec SSP de GCC (option -fstack-protector) pour prévenir pas mal de buffer overflow courants. Il vaut mieux prévenir que guérir ;). L'idéal est de pousser la prévention jusqu'aù kernel. Faut voir si la machine ne va pas devenir instable... J'ai abandonné l'idée
de changer les options de compilations pour le kernel... Pour les applis c'est au cas par cas...
Quel en serait le prix en terme de performances?
Je ne pense pas qu'un livecd soit une mesure utile et viable (trop chiant pour les mises à jour). Par contre les partitions et fichiers qui n'ont pas besoin d'être accessibles en écriture ne doivent l'être qu'en lecture bien sûr. Suivre le principe du moindre privilège est un bon point de départ.
J'ai upgradé mes applis et je suis en train de synthétiser ce qui à été proposé sur fcob et fcs pour arriver à une solution viable et sécurisée le + possible...
-- MaXX
MaXX
Marc Espie wrote:
Ils ont mtree chez FreeBSD ? dans OpenBSD, c'est l'outil du systeme de base qui permet de faire ca... Oui.
sinon, tripwire, aide... J'ai trouvé un how-to pour utiliser samhain et aide en même temps... Mais je
n'ai pas encore eu beaucoup de temps pour regarder à ça et tester le machin.
-- MaXX
Marc Espie wrote:
Ils ont mtree chez FreeBSD ? dans OpenBSD, c'est l'outil du systeme de
base qui permet de faire ca...
Oui.
sinon, tripwire, aide...
J'ai trouvé un how-to pour utiliser samhain et aide en même temps... Mais je
n'ai pas encore eu beaucoup de temps pour regarder à ça et tester le
machin.
Je prends le train en marche avec retard. Personne n'a cite <http://www.hostintegrity.com/osiris/>, personne n'a essaye ?
-- pc
Jeremy JUST
On 27 Jun 2005 08:26:34 GMT GERBIER Eric wrote:
afick (http://afick.sourceforge.net/index.fr.html) : c'est du perl donc entierement portable
Hum, je suis d'accord qu'en Perl, tu auras l'avantage de la portabilité, mais tu risques aussi de devoir utiliser beaucoup des fichiers que tu contrôles (et qui sont potentiellement corrompus).
Pour utiliser un outil de vérification, l'idéal serait de booter sur un CD, pour n'utiliser que des fichiers qu'on sait dater d'avant une potentielle corruption. Mais sur une machine en production, ce n'est généralement pas faisable. Au moins faut-il n'utiliser que des fichiers venant d'un CD (à l'exception du noyau, donc).
Avec un programme C compilé en statique, c'est simple (un fichier à mettre sur le CD); avec ton programme Perl, ça doit l'être beaucoup moins (toute une arborescence de modules à copier, en s'assurant que ce seront bien ceux du CD qui seront compilés à l'appel du programme).
-- Jérémy JUST
On 27 Jun 2005 08:26:34 GMT
GERBIER Eric <eric_nospam_gerbier@meteo.fr.invalid> wrote:
afick (http://afick.sourceforge.net/index.fr.html) : c'est du perl
donc entierement portable
Hum, je suis d'accord qu'en Perl, tu auras l'avantage de la
portabilité, mais tu risques aussi de devoir utiliser beaucoup des
fichiers que tu contrôles (et qui sont potentiellement corrompus).
Pour utiliser un outil de vérification, l'idéal serait de booter sur
un CD, pour n'utiliser que des fichiers qu'on sait dater d'avant une
potentielle corruption. Mais sur une machine en production, ce n'est
généralement pas faisable.
Au moins faut-il n'utiliser que des fichiers venant d'un CD (à
l'exception du noyau, donc).
Avec un programme C compilé en statique, c'est simple (un fichier à
mettre sur le CD); avec ton programme Perl, ça doit l'être beaucoup
moins (toute une arborescence de modules à copier, en s'assurant que
ce seront bien ceux du CD qui seront compilés à l'appel du programme).
afick (http://afick.sourceforge.net/index.fr.html) : c'est du perl donc entierement portable
Hum, je suis d'accord qu'en Perl, tu auras l'avantage de la portabilité, mais tu risques aussi de devoir utiliser beaucoup des fichiers que tu contrôles (et qui sont potentiellement corrompus).
Pour utiliser un outil de vérification, l'idéal serait de booter sur un CD, pour n'utiliser que des fichiers qu'on sait dater d'avant une potentielle corruption. Mais sur une machine en production, ce n'est généralement pas faisable. Au moins faut-il n'utiliser que des fichiers venant d'un CD (à l'exception du noyau, donc).
Avec un programme C compilé en statique, c'est simple (un fichier à mettre sur le CD); avec ton programme Perl, ça doit l'être beaucoup moins (toute une arborescence de modules à copier, en s'assurant que ce seront bien ceux du CD qui seront compilés à l'appel du programme).
