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..
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).
tout-a-fait d'accord, une des solutions que j'utilise, c'est de le lancer depuis un live-cd (knoppix par exemple), avec une base de donnee sur disquette ou clef usb.
dans mon cas, je voulais que le logiciel marche sur la pluspart des os (windows compris), sans que l'utilisateur ait a le compiler, et je n'avais pas les moyens de le compiler pour toutes les plateformes visées ...
Jeremy JUST wrote:
On 27 Jun 2005 08:26:34 GMT
GERBIER Eric <eric_nospam_gerbier@meteo.fr.invalid> wrote:
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).
tout-a-fait d'accord, une des solutions que j'utilise, c'est de le
lancer depuis un live-cd (knoppix par exemple), avec une base de donnee
sur disquette ou clef usb.
dans mon cas, je voulais que le logiciel marche sur la pluspart des os
(windows compris), sans que l'utilisateur ait a le compiler, et je
n'avais pas les moyens de le compiler pour toutes les plateformes visées ...
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).
tout-a-fait d'accord, une des solutions que j'utilise, c'est de le lancer depuis un live-cd (knoppix par exemple), avec une base de donnee sur disquette ou clef usb.
dans mon cas, je voulais que le logiciel marche sur la pluspart des os (windows compris), sans que l'utilisateur ait a le compiler, et je n'avais pas les moyens de le compiler pour toutes les plateformes visées ...
