Bonjour Fran.b,
ton script permet à n’importe qui de recalculer les hash ou il faut se munir d’un mot de passe ou d’un certificat pour le faire ? Je pense que l’idée est bonne à la condition que le prétentu “pirate” ne puisse pas lui même modifier les signatures.
Merci du retour.
SecuIP
Le but est de trouver si la machine est corrompue. La corruption passe systématiquement par la modification de binaires existants ou le rajout de services au démarrage. C’est le principe. Les fichiers controlés par défaut sont ceux de /bin, /sbin, /usr/sbin, /usr/bin ainsi que les fichiers de démarrage /etc/rc*.d et /etc/init.d. On peut y rajouter les librairies, les scripts locaux. Une façon de contourner un système de ce type, quel qu’il soit, si on le connait consiste à bêtement remplacer le binaire par son propre binaire. Il faut donc relativiser ce genre de système et éventuellement en mettre plusieurs. L’intérêt de celui là est qu’il est peu diffusé et donc peu connu (550 chargement cette année). Quelqu’un de prévenu et qui a pu devenir root peut aussi reconfigurer le paquet (il suffit dans ce cas de virer /var/lib/dpkg/info/surveillance.postinst), etc. Il faut donc mesurer le degré de paranoïa voulu et adapter la configuration (celle choisie par défaut est assez lache). En serrant les choses (ce qui se fait simplement), on obtient un système difficilement contournable. Une bonne sécurité consiste à mettre les hashs sur un système en lecture seule (j’utilisais un clef USB en RO). Dans la mesure où les sources sont publiques, il est illusoire d’essayer de empêcher la surcharge du fichier contenant les md5sums par des certificats ou autres, si on admet que l’intrus a les droits root (à ce stade on est mal), il peut imposer ces propres certificats et surcharger le fichier des md5sums ou carrément modifier le binaire, la seule solution est la protection physique des fichiers. Si on ne veut pas le faire une astuce consiste à faire régulièrement un md5sum du fichier des md5sums et à le vérifier, mais ça devient pénible. Un système de sécurité trop pénible est toujours délaissé à un moment ou à un autre.
Encore une fois, pour une protection paranoïaque du système, il est à mon avis indispensable d’utiliser un système en RO plus AUFS (un peu comme clefagreg en fait quand j’y pense) qui opermet de voir immédiatement quel fichier a été modifié et de revenir à l’ancienne version.
Par curiosité, quel programme sur un serveur modifie ses propres fichiers de configuration? Sur aucun de mes serveurs le répertoire /etc n’est modifié par un programme (y compris /etc/resolv.conf, /etc/mtab, etc).
merci pour cette réponse claire et détaillée.
tout récemment, en utilisant openzave, j’ai du autoriser le fichier en écriture. Je n’ai pas cherché pourquoi.
C’est le premier exemple qui me vient à l’esprit car le plus récent.
A noter qu’il existe de la documentation francophone, hélas pas gratuite.
“Sécurité réseau avec Snort et les IDS” éditions O’Reilly (ISBN 2-84177-308-6)
Oui, probablement parce que Snort, dans sa version étendue est payant.
Je l’utilise (dans sa version libre) sur une passerelle sous FreeBsd, je suis mitigé… beaucoup d’alertes inutiles et de faux positifs.