#!/bin/bash
apt-get update
(
echo To: vous@fai.tld
echo From: rapport@sdxxx.sivit.org
if [ “$( df -h | grep hda1 | cut -c40-42)” -ge “80” ]; then
echo Subject: Rapport du date +%e\ %B\ %Y : ESPACE DISQUE FAIBLE
else echo Subject: Rapport quotidien du date +%e\ %B\ %Y pour hostname
fi
echo Rapport de hostname
echo Usage du disque :
echo
df -h
echo
echo Charge du serveur :
echo
uptime
echo
echo Mises à jour nécessaires
echo
apt-get -s upgrade
) | /var/qmail/bin/qmail-inject vous@fai.tld
// La ligne ci-dessus doit être configurée pour Exim (mon serveur de mail).
Pouvez-vous m’aider svp ?
Ton apt-get update peut poser des questions, je ferais donc un
apt-get update -q -y avec une capture de sortie d’erreurs.
Mais en fait j’évite les mises à jours automatiques, régulièrement je regardes quelles sont les mises à jour qu’il veut faire et je les installe. Je préfère bétonner la surveillance des machines.
En fait, j’avais un serveur personnel qui me servait à l’époque juste de passerelle (depuis il me sert professionnellement). J’avais chkrootkit et je ne faisais pas de mise à jour. Un soir de Décembre, un type (de Munich) a pénétré le système et installé un rootkit. Je m’en suis aperçu en regardant la console (mode promiscuous). J’ai fait des tests avec chkrootkit, il n’avait rien vu.
J’ai fait une image de mon disque et ai réparé tout le bazar (sans réinstaller d’ailleurs) mais cela a été assez pénible.
L’analyse de l’image du disque m’a permis de savoir quasiment minute après minute ce qu’avait fait le gars, son origine etc notamment parce que cet abruti se croyait sur une RedHat et ne connaissait pas l’emplacement de tous les fichiers logs
J’ai constaté que chkrootkit aurait du détecter ce gars mais n’avait pas fonctionné (il utilisait suckIT).
J’ai fini par faire deux utilitaires très précieux:
cacheproc qui recherche tous les processus cachés et affichent la ligne de commande et l’environnement lors d’une tel trouvaille. Il y a quelques faux positifs lors qu’un processus se termine au cours de son analyse mais bon c’est très rare.
surveillance qui teste l’intégrité du série de fichiers avec md5sums. Il fournit également un md5sum-static. Dans la pratique, je regardes l’intégrité de /bin, /sbin, /usr/bin, /usr/sbin, /etc/init.d, /etc/rcS.d toutes les heures. Un mail m’est envoyé en cas de problèmes. Je me suis aperçu d’ailleurs que les inversions de bits sur disque dur ne sont pas si rare que cela (une rangée de bits passant à 0 par exemple).
A chaque mise à jour, il faut refaire la table des md5sums soit
dpkg-reconfigure surveillance
Ces deux programmes (20 à 30K donc petits) sont compilés en statique et sont donc indépendant d’une quelconque alteration des librairies. Le deuxième peut être mis entièrement sur un CD.
Merci à toi c’est bien sympas, j’ai en gros compris, mais (si je n’abuse pas) pourrais-tu m’expliquer avec un peu plus de mots sur les resultats qu’amenent tes 2 scripts stp.
PWD=/usr/.sk12REMOTEHOST=R2D3.rebellesHZ=100PS1=\h:\w$ USER=rootMAIL=/var/mail/boissonOLDPWD=/home/boissonLANG=fr_FR@euroDISPLAY=toto
che.rebelles:0.0LOGNAME=boissonSHLVL=2HUSHLOGIN=FALSESHELL=/bin/bashTERM=xtermHOME=/rootPATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X1
1:/usr/local/sbin:/usr/local/bin_=./sk
Ligne de commande:
Cela permet de savoir le repertoire d’exécution (PWD=/usr/.sk12 ici), qui l’a
lancé (USER=root), plusieurs renseignements divers dans l’environnement et bien
sûr, la ligne de commande ayant lancé le processus (ici ./sk).
regarde est le même programme mais sans sortie écran si tout se passe bien.
Mettre
0 * * * * root /usr/bin/regarde
enverra un mail à root (via la sortie standard, bien configurer cron) en cas
de processus trouvé.
Le principe est décrit dans le fichier bash boisson.homeip.net/processus
qui fait la même chose (mais qui est très long)
Sur surveillance, le programme calcule les md5sums de tous les fichiers indiqués dans une liste. surveille appelé sans argument vérifie ces md5sums et signale les différence. Le programme est fait de tel manière à ne dépendre d’aucune librairie et à pouvoir être sur CDrom avec le fichier de signatures et la listes des fichiers à surveiller.
La moindre modification de ces fichiers est signalée dans l’heure qui suit par email à root.
sous stable les mises à jour ne sont que des mises à jour de sécurité: sans soucis, elles ne changent pas le système SAUF singalement clairement dit.
sous testing, il n’y a pas de mise à jour régulière, lorsqu’il y a des maj, ça peut être le grand saut.
sous unstable, il y a des maj de sécurité et des maj de debugguage. Plus régulières, le système peut être incohérent pendant qques jours donc prévoir des soucis et la possibilité de revenir en arrière (conserver les paquets précédents).
