Objet du rapport / réunion - inetdoc.net

IUP STRI – M2 2007
Projet Sécurité – Equipe attaque G1
Pour ceci, voici un petit script appelant le script test.php en boucle:
#! /bin/bash
#Ouvre une chiée de connexions a la BD
i=0
while [ $i -eq 0 ]
do
wget -N http://172.17.0.2/test.php
done
Résultats:
Au moment de l’attaque, on s’est rendu compte que le script test.php avait été supprimé.
En effet, en observant les connexions et les statistiques de leur site web, l’équipe
« Défense » s’est rendu compte que la page test.php avait été très sollicitée (notamment
pendant nos tests avant l’attaque).
Ceci les a emmené à retirer la page test.php, et à la remplacer par:
L’attaque n’a donc pas pu avoir lieu.
Préconisations :
Tout d’abord, la «Défense» a vu l’initiative après la découverte de la page test.php oubliée
sur le serveur. Il en découle deux préconisations :
Eviter de laisser des pages de test ou de développement sur le serveur, qui
contiennent souvent beaucoup d’informations
Détecter les scripts qui visent à découvrir l’arborescence du serveur web. Si les logs
sont capables de détecter les requêtes qui aboutissent au code d’erreur 400 par
exemple, le serveur web devrait être capable de bloquer les requêtes venant d’une
adresse IP qui a déjà généré un nombre élevé de codes 400. On peut utiliser le
module « modsecurity » pour Apache pour faciliter la détection de ce genre d'activité.
. Copyright (c) 2007 – GNU Free Documentation licence ­ Équipe Attaque G1 – M2 STRI 24