Les scanners de vulnérabilité de site web sont des logiciels qui analysent les pages d’un site web (“crawling”), puis effectuent des requêtes HTTP en ajoutant des codes malicieux dans l’URL (ainsi que dans les variables POST, etc.) et analysent le contenu de la page obtenue pour détecter si le code malicieux a été filtré ou non.
L’utilisation de scanners est intéressante dans le cadre de l’audit de sécurité d’un site (à noter que l’usage non autorisé d’un de ces logiciels sur un site est susceptible de relever de l’article 323 du code pénal).
En revanche, ces scanners de vulnérabilité sont dangereux lorsque ce sont des pirates qui les utilisent.
Par ailleurs, certains scanners sollicitent fortement le serveur (exemple : 2 millions de requêtes en 15 heures de scan). Enfin, les variations d’URL, effectuées par les scanners de vulnérabilité, remplissent inutilement le cache de SPIP (exemple : 59 900 fichiers ajoutés dans le cache de second niveau SPIP au bout d’une heure de scan).
Les objectifs de ce plugin sont les suivants :
- Ne pas donner les véritables pages au scanner de vulnérabilité, afin de l’empêcher de conduire ses recherches de vulnérabilité.
- Réduire le temps de traitement des pages demandées par le scanner de vulnérabilité (une fois détecté).
- Diminuer l’impact, sur le cache de SPIP, des variations d’URL envoyées par le scanner de vulnérabilité.
Le bannissement est temporaire, afin de limiter l’impact d’éventuels faux positifs. Une réponse compréhensible avec un décompte de temps est affichée en cas de bannissement.
Différentes mesures effectuées, montrent que les gains obtenus avec le plugin CISEC, lors d’un scan de vulnérabilité, sont conséquents (cf. documentation ci-jointe).
Le périmètre porte sur le site public uniquement. Le périmètre ne porte pas sur les attaques de type spam (un plugin pour SPIP existe déjà sur ce sujet), ni sur les attaques de type déni de service ou déni de service distribué.
Pour plus de détails, se reporter à la documentation ci-jointe.
Version 1.2 du plugin CISEC
- Ajout de la raison du bannissement dans le courriel, qui est automatiquement envoyé, ainsi que dans le fichier de log "cisec_detail.log".
- Si la constante _CISEC_EMAIL est définie dans un fichier d’options, avec comme valeur une adresse email avec une syntaxe valide, le courriel sera envoyé à cette adresse email (et non pas à l’adresse du webmestre qui figure dans le menu configuration de SPIP).
Exemple : define(’_CISEC_EMAIL’,’assistance@test.fr’) ;
- Possibilité d’augmenter les seuils (mais pas de les diminuer) via deux constantes dans un fichier d’options :
- Au moins N POST d’une même adresse IP pendant une seconde.
- Au moins M POST d’une même adresse IP pendant 10 secondes.
Exemple :
define(’_CISEC_MAX_POST_EN_1_S’,5) ;
define(’_CISEC_MAX_POST_EN_10_S’,15) ;
Version 1.3 du plugin CISEC
Ajout d’une règle qui rejette les tentatives d’injection qui utilisent dans l’URL une double occurrence de page=recherche
Version 1.5 du plugin CISEC
Apporte la compatibilité avec PHP 8.0 et 8.1, ainsi que la compatibilité avec SPIP 4.1.
Version 1.6 du plugin CISEC
Apporte la compatibilité avec SPIP 4.2.
Discussions par date d’activité
14 discussions
Bonjour,
Mon hébergement ne permet pas à SPIP d’envoyer des mails, aussi je surcharge la fonction inc_envoyer_mail_dist de SPIP dans le fichier d’options d’un plugin que j’ai réalisé. Avec cette surcharge, SPIP arrive à envoyer des mails.
Le problème c’est que les mails envoyés par le plugin CISEC ne partent pas.
Dans le cas précité, il convient de surcharger la fonction inc_envoyer_mail_dist de SPIP dans le fichier config/mes_options.php (au lieu du fichier d’options du plugin que vous avez réalisé).
ne serait-il pas plus pertinent d’utiliser le plugin facteur ? et si vous ne passez pas par un smtp, il serait bon d’ouvrir un ticket (https://core.spip.net/projects/spip/issues) expliquant en quoi la surcharge permet de contourner une limite de spip, pour que cela soit intégré en natif dans SPIP.
Pour surcharger l’envoi de mails, une autre approche consiste à surcharger le fichier ecrire/inc/envoyer_mails.php (qui est chargé uniquement lorsque l’on a besoin d’envoyer un mail).
L’inconvénient est que cette approche est plus sensible aux évolutions de SPIP. En effet, il faut prendre en compte les évolutions des 3 autres fonctions contenues dans ecrire/inc/envoyer_mails.php.
L’avantage est que cette approche est meilleure en termes de performance. En effet, comme l’indique la documentation de SPIP : « Tous les fichiers d’options (celui du site, puis de tous les plugins) sont chargés à chaque appel de l’espace public et de l’espace privé ; ils doivent donc être les plus légers et économes possible. »
A noter que le plugin facteur, cité par Maïeul, utilise cette seconde approche qui consiste à surcharger le fichier ecrire/inc/envoyer_mails.php.
Répondre à ce message
Lorsque CISEC bannit une adresse IP, il bannit celle du reverse proxy.
Le plugin CISEC utilise l’adresse IP qui est stockée dans la variable $ip de SPIP.
SPIP initialise la variable $ip avec le contenu de ’REMOTE_ADDR’ s’il existe, sinon avec le contenu de ’HTTP_X_FORWARDED_FOR’.
Si un reverse proxy est utilisé par l’hébergement, il est possible que l’adresse IP de l’utilisateur figure dans ’HTTP_X_FORWARDED_FOR’ et que celle du proxy figure dans ’REMOTE_ADDR’.
Pour contourner ce problème, la solution, qui est très simple, consiste à mettre dans un fichier d’option propre à l’hébergeur (par exemple le fichier mes_options) la ligne suivante :
$ip = $_SERVER[’HTTP_X_FORWARDED_FOR’] ;
SPIP utilise le contenu de la variable $ip, par exemple lors du dépôt d’un commentaire. Aussi, même si le site ne dispose pas du plugin CISEC, il est indispensable d’adapter SPIP à la présence du reverse proxy (cf. solution précitée).
Dans le cas où l’on utilise un reverse proxy et que l’on peut ajouter des modules à Apache, il peut être intéressant d’examiner les modules mod_rpaf (apache v2.2) et mod_remoteip (apache v2.4+).
Pour en savoir plus : https://github.com/spip/SPIP/pull/13
Une précision :
Pour contourner ce problème, la solution, qui est très simple, consiste à mettre dans le fichier config/mes_options.php la ligne suivante :
$ip = $_SERVER[’HTTP_X_FORWARDED_FOR’] ;
Pour pallier au cas où la modification du fichier config/mes_options.php poserait de réels problèmes, je viens de joindre, à la présente page, la version 1.1.0 du plugin CISEC, qui tient compte du cas où la ligne précitée ne figure pas dans le fichier config/mes_options.php.
Pour plus de détails, se reporter au nouveau chapitre 4.3 de la documentation.
Répondre à ce message
Dans le cas d’un POST suspect dans un formulaire, le plugin CISEC enregistre les logs dans un fichier sans nom (uniquement « .log »).
La version 1.0.1 du plugin CISEC, qui figure dans la présente page (cisec_161010.zip), donne un nom complet à ce fichier (dans le cas d’un POST suspect dans un formulaire).
Répondre à ce message
Bonjour,
Dans la doc il est question des fichiers de log :
cisec_bannir.log
cisec_detail.log
cisec_mail.log
cisec_post.log
Je ne les trouve pas dans le répertoire du plugin sur mon site.
Sinon comment peut-on voir si des scanners de vulnérabilités ont été détectés ?
Merci
Les fichiers de logs sont dans le sous dossier ’log’ du dossier ’tmp’ à la racine de SPIP.
Bonsoir et merci de ta réponse. J’aurais pu y penser..
Je viens de voir un log cisec_log.txt : c’est marrant il a enregistré ma propre adresse IP.
dd
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
